Sistemi e Architetture per l'Automazione Lsapa.campusfc.unibo.it/SAPA_06_Attuatore_Generalizzato... · 2018. 3. 21. · Ing. Lorenzo Moriello - Sistemi e Architetture per l'Automazione

Sistemi e Architetture per l'Automazione L

Laurea in Ingegneria e Scienze Informatiche

Ing. Lorenzo Moriello

DEI - Università di Bologna

E-mail: [email protected]

https://www.unibo.it/sitoweb/lorenzo.moriello2

Attuatore Generalizzato

Ing. Lorenzo Moriello - Sistemi e Architetture per l'Automazione L Attuatore Generalizzato - 2

Contenuti

Contenuti

Introduzione


Esempio


Introduzione


Introduzione

Design funzionale del Sistema di controllo• Sequenza di azioni e funzioni da eseguire per raggiungere l'obiettivo

• Alto livello di astrazione (non sono necessarie informazioni HW)

Controllo logico (o Controllo di sequenze)• Automa o insieme di automi che reagiscono agli eventi per imporre al

sistema un comportamento desiderato

• Spesso definito come DEDS (Discrete-events Dynamic Systems)

• La macchina a stati finiti è un tipo di automa


Introduzione

Problemi legati alla programmazione classica

• Difficoltà di distinzione tra logica di supervisione e meccanismi di

attuazione (politica di supervisione “nascosta” nel grafico)

• Mancanza di modularità e riusabilità. L’introduzione di una modifica

risultrebbe in un nuovo schema:

• Modifiche del supervisore = introduzione nuove funzionalità (es.

gestione di un nuovo prodotto)

• Modifiche del meccanismo di attuazione (varaizione profilo di

pressione/temperatura/...)

• Diagnostica “nascosta” nel grafico:

• Anomalie di basso livello = maulfunzionamenti di sensori/ attuatori

• Anomalie funzionali = mancata esecuzione di sequenze di

controllo


Introduzione

Obiettivo dell’approccio ad Attuatore Generalizzato:• Definire una metodologia per la progettazione funzionale dei

controllori logici

In dettaglio:

• Leggibilità e documentazione semplice: il software è strutturato secondo alcuni

criteri.

• Riutilizzabilità delle parti: modularità / incapsulamento.

• Semplificare la verifica della correttezza dei codici e dei risultati: verifica dei

singoli componenti e della loro composizione, simulazione e metodi formali, ...

• Semplifica la diagnosi dei guasti di sistema durante il funzionamento e semplifica

la riconfigurazione, se possibile (tolleranza d'errore): diagnostica gestita a livello di

componente.

• Srutturazione gerarchica del sistema di controllo: separazione tra politica di

supervisione e meccanismi di attuazione;

Correttezza Altre proprietà:

• Modularità

• Leggibilità

• Riutilizzabilità

• …

Dipende dallo

sviluppatore


Introduzione

Nota• Gli elementi 1, 2, 3 sono comuni a livello di ingegneria SW (Object-

oriented programming).

• L‘elemento 4 è molto importante nei moderni sistemi di automazione.

• In questo corso l'attenzione sarà focalizzata sugli elementi 1, 2

•AcknowledgmentsProf. Eugenio Faldella

Prof. A. Paoli, Ing. M. Sartini, Prof. A. Tilli

More details in their publication:

A logic control which “works correctly” is a necessary condition

to say that it is well done, but indeed it is not sufficient!

If the properties 1,2,3,4 are achieved too, then it is well done!

Hierarchical control architectures in industrial automation: a design approach based on the generalized actuator concept, Proceedings of the 17th IFAC World Congress 2008, pp. 69 - 76, Seoul, South Korea, 6-11 July 2008)


Esempio


Esempio

Macchina timbratrice.

FUNZIONALITA’ DESIDERATE:

Timbrare sfruttando un sensore di presenza

Controllo della temperatura del timbro

DESCRIZIONE DEL PROCESSO:

Quando un nuovo pacco arriva sotto il timbro,

quest’ultimo deve raggiungere la sua posizione limite

inferiore e fermarsi per 0.2 secondi

Durante questo intervallo la temperatura del timbro deve

rimanere ai livelli desiderati

StartProcess attiva / disattiva l’intero processo

Assunzione di idealità del sensore di presenza

Assunzione temperatura di riferimento costante


Esempio


Esempio

Soluzione “CLASSICA”

Initial State

Belt & Ram

coordinated

motion

Tool

temperature

Control

StartProcess

.

TRUE


Esempio

Initialization

Co

nv

ey

or

be

lta

nd

ma

rkra

m c

oo

rdin

ati

on

Te

mp

era

ture

co

ntr

ol

• Common control solution


Esempio

• Common control solution (cont’d)


Esempio

I problemi emergono quando introduciamo alcune varianti

Sensore di presenza non ideale = gestione del tempo di ritardo

(BASSO LIVELLO)

Gestione di due differenti prodotti = richiesta di due profili di

temperatura differenti (ALTO LIVELLO)


Esempio

LEGEND

(1) Sensor Modification

(2) Policy Modification


• Analisi delle modifiche

Modifica 1: COME una particolare operazione viene eseguita, non la

sequenza di operazioni.

Modifica 2: COSA deve fare la macchina (cambia la sequenza di operazioni),

non il modo in cui esegue ogni operazione.

Il codice che definisce la sequenza di azioni (Policy) è mescolato

con il codice che descrive come viene eseguita l'azione

(Mechanisms) ... CONFUSIONE!

LOW

READIBILITY

LOW

REUSABILITY

POOR

DIAGNOSTICS

Policies e mechanisms

allo stesso livello

No incapsulamento!

E se volessi riutilizzare il

controllo di temperatura?

Difficile rilevare i guasti!

Cosa succede se

PackPlacedSensor si

arresta mentre è attivo

lo Step4?

Esempio


• Approccio proposto

• 2 Macro steps

Logic

Control

Actuation

Mechanisms

(How is it done?)

Control

Policy

(What to do next?)

Automi per le azioni di base che

descrivono come vengono attuate

le richieste della politica di

controllo.

Automi per il coordinamento che

coordinano le azioni di base per

raggiungere la funzionalità

desiderata.

(1) attendere il flacone -> (2) riempire il

flacone -> (3) quando il flacone è pieno

spostarlo.

Come viene realizzato il posizionamento della bottiglia? Possiamo usare un sensore o possiamo usare un timer. La politica non se ne preoccupa.

Mechanism automata definition.Si introduce il concetto di attuatore

generalizzato (GA -> Generalized

Actuator)

Policy automata definition.Coordina le azioni eseguite dai

Mechanisms


1.A) Definizione dei meccanismi

• Identificazione delle azioni di base dell'attività del sistema.

Esempio: decorare delle torte (trasportate con un nastro trasportatore) con

crema.

a) Posizionamento della torta: attivare il nastro fino a quando il sensore di presenza

sotto il tubo decorativo rileva la torta.

b) Decorazione: spostare il tubo vicino alla torta e aprire la valvola per convogliare la

crema mentre l’ugello si muove in circolo.

c) Espulsione della torta: attivare il nastro fino a quando il sensore rileva la torta

successiva

• Variante 1: Cosa succede se decoriamo torte usando sia la crema che il cioccolato?

• Variante 2: Cosa succede se abbiamo bisogno di pulire il tubo prima di usare il

cioccolato?

DI BASE ???Tutte quelle azioni che, ragionevolmente, non

possono essere ulteriormente scomposte per

essere chiamate dalla politica.

Mechanism definition


1.B) Associare a ogni azione attuatori e sensori utilizzati

Positioning: sposta il pezzo nella posizione di marcatura

Expulsion: espelle il pezzo

GoUp: muove verso l'alto il marcatore

GoDown: sposta verso il basso il marcatore

TemperatureControl: controlla la temperatura del marker su un valore fisso



1.C) Identificazione degli attuatori generalizzati (GAs)

GA???

• Entità software (controllori logici) che gestiscono una o più azioni di base.

GAs gestiscono

un set di sensori

e attuatori

GAs comunicano

con le policy

GAs sono

sempre attivi

- Interfaccia con l’impianto - Eseguono le richieste

delle policy

- Comunicano alla policy lo

stato dell'azione

- Rilevano guasti di sensori

e/o attuatori

- Gestione continua di

sensori e attuatori

- Utile per la diagnostica

Control

PolicyGAs

Sensors Measurements

ActuationSignals

Acks

Requests

Real

system

Logic

Control



1.C) Identificazione degli attuatori generalizzati (GAs) – cont’d

Come definirli? Quali azioni assegniamo ad ognuno? 2 semplici regole

A : tutti gli attuatori

a_GA_i : attuatori associati all’i-esimo GA

s_GA_i : sensori attuatori associati all’i-esimo GA

L'unione degli attuatori appartenenti all'intero set di GA deve

essere uguale all'intero set di attuatori del sistema (A).

a_GA_1 U … U a_GA_i U … U a_GA_n = A

I set di sensori e attuatori appartenenti a GA diversi devono

essere disgiunti.

a_GA_i ∩ a_GA_j = 0 ∀i,j with i≠j

s_GA_i ∩ s_GA_j = 0 ∀i,j with i≠j

Assumiamo:



1.C) Identificazione degli attuatori generalizzati (GAs) – cont’d

3 GAs needed!

I GA sono diversi o hanno similarità?

• Dovendo gestire diverse azioni, le GA sono tutte diverse, ma esistono

macro-similitudini

DO-DONE GAs: ricevono una richiesta e restituiscono un DONE quando l'azione è

finita.

START-STOP GAs: ricevono una richiesta e attendono un comando STOP esterno per

terminare l'azione.




1.D) Definizione interfaccia I/O dei GA

Segnali e parametri di input e output.

Uso dei FB per implementarli.



1.E) Definizione dell’algoritmo dei GA

Progetto di un automa per la gestione/esecuzione di azioni

SFC is the suggested language.



1.E) Definizione dell’algoritmo dei GA – cont’d


SFC is the suggested language

I GA dovrebbero essere progettati considerando come modello di

riferimento l’automa in figura.


Pack Motion GA algorithm


1.E) Definizione dell’algoritmo dei GA – cont’d


SFC is the suggested language

I GA dovrebbero essere progettati considerando come modello di

riferimento l’automa in figura.


2. Definizione della policy di coordinamento

Design dell’automa (o del set di automi) con cui attivare i GA.

SFC is the suggested language.

continue

From

GA

From

Policy

time


2. Definizione della policy di coordinamento – cont’d

Lo scambio di informazioni tra policy e GA deve essere gestito.

Possibili soluzioni:

Policy definition

Note:OperationOK deve essere resettato quando

lo stato viene disattivato:• nello step successivo• come “exit action”

DO-DONE START-STOP


• IdeaDefinire il codice con una struttura gerarchica che divide :

• Mechanisms: codice per la realizzazione delle azioni.

• Policy: codice per il coordinamento delle azioni.

• Generalized Actuators (GAs) Entità software utilizzate per l'incapsulamento del codice del meccanismo:

• Un GA può gestire una o più azioni.

• Un GA può gestire uno o più sensori e attuatori per realizzare una

azionr.

• Un GA è sempre attivo:

- anche se non deve eseguire azioni.

- molto utile per la diagnostica: monitoraggio continuo di sensori e

attuatori.

• Un GA può essere di tipo START-STOP o DO-DONE (interfaccia

standard).

Generalizzazione


• Valutazione (qualitativa) dell'approccio proposto Le modifiche alla policy non influiscono sui meccanismi e viceversa:

o La modifica di un sensore (un meccanismo) è trasparente per gli automatismi della

policy

o La modifica della sequenza di azioni (la policy) è trasparente rispetto ai

meccanismi

Incapsulamento:

o Un sensore o un attuatore utilizzato in un GA specifico non può essere utilizzato in

altri GA

o Un sensore o un attuatore utilizzato in un GA specifico non può essere utilizzato

nella policy

Riutilizzabilità:

o Un GA è un'unità software autonoma che può essere riutilizzata più volte nello

stesso progetto o in un progetto diverso

o La stessa policy può essere riutilizzata con diversi GA

Diagnostica (non analizzata nell'esempio ma per intuizione ...)

o Un GA è sempre attivo e può rilevare immediatamente guasti su sensori / attuatori

o Un GA può gestire l'errore o comunicarlo alla policy se non è possibile


• GA standard interface

Generalizzazione

DO-DONE

Interface

START-STOP

interfaceExamples:


• Policy – GAs CommunicationAsincrona è preferibile:

• La Policy invia un evento per attivare il GA che a quel punto esegue.

• Il GA invia un segnale (acknowledgement) per comunicare alla Policy

che l’azione è stata eseguita.

DO - DONE

START-STOP

From GA :

From Policy : time

Action starts Action finishes

From GA :

From Policy :

Action starts Action finishes

START

STOP

START

STOP

time

Generalizzazione


• Ricapitolando…

1. GAs definition

2. Policy definition

• GAs definition: Identificazione delle azioni di base nel processo/sistema da controllare.

Classificazione:

• DO-DONE o START-STOP

Definizione dei GA raggruppando le azioni in base a due regole:

• Ogni attuatore deve essere assegnato a una specifica GA (tipicamente

anche sensori ma non necessariamente).

• Un sensore/attuatore appartenente a un GA non può appartenere anche

a un altro.

Design dei GA:

• Interface definition (I/O)

• Design algoritmo: per eseguire azioni quando richiesto.

• Diagnostica relativa alla funzione del GA (non considerato in dettaglio).


FB internal algorithm

GA logic State Diagram

Macro stati (può contenere più passi SFC).

Inizializzazione attiva solo una volta all’inizio o

dopo guasti, se necessario.

Ready è lo stato di attesa della richiesta.

Busy è attivo quando l’azione è in esecuzione

Fault si attiva in occasione di un guasto.

Tipico schema SFC di un GA con 2 azioni.

Fault state non definito.

Busy state composto da un certo numero di

passi.


• Policy Definition (coordination/management/supervision)

Nessuna struttura di riferimento è proposta per implementare la policy

• Esistono troppi casi diversi.

• In letteratura alcuni approcci di standardizzazione ... GEMMA

Non considerato qui. Comunque indipendente da GAs.

La policy invia richieste ai GA nella giusta successione.

• Ricorda l'interfaccia di comunicazione di Policy-GAs.

Gli attuatori non possono essere utilizzati direttamente dalla policy.

I sensori utilizzati negli AG non possono essere utilizzati dalla policy.

La policy deve gestire i guasti e le emergenze se i GA non possono farlo.


• La diagnostica può essere vista su due livelli:1) Diagnostica di basso livello

2) Diagnostica di alto livello

• Diagnostica di basso livello Controlla il corretto comportamento di sensori/attuatori.

È completamente incapsulata in GA.

Rilevamento dei guasti: dopo aver impartito i comandi agli attuatori, i

sensori non si comportano come previsto

esempio:

•Sequenza errata di attivazione dei sensori

•Troppo tempo prima dell'attivazione del sensore

Se viene rilevata un'anomalia, GA lo comunica alla politica.

Un GA può provare a gestire l'errore.

Cenni di Diagnostica


• Diagnostica di alto livello

Controlla:

1) Interazione corretta tra policy e GA.

• I comandi da Policy a GA devono essere non conflittuali Un GA può rilevare un «errore» in un comando emesso dalla politica

• Risposte da GA La politica rileva una risposta mancante da un GA

Una risposta GA è sempre dovuta, anche se ci sono errori (altrimenti

errore GA)

• Osservazione Se la progettazione logica è corretta, gli errori di cui sopra NON devono

essere presenti (dopo il debug), SALVO PERTURBAZIONI ESTERNE

CHE SI POSSONO VERIFICARE

Possibile perturbazione può verificarsi se l'implementazione è distribuita

su molti controller con comunicazioni "non affidabili" ...

2) Corretto comportamento del sistema confrontando le informazioni

provenienti dai GA.

• La politica esegue un perfezionamento della diagnosi GA

Sistemi e Architetture per l'Automazione L

Laurea in Ingegneria e Scienze Informatiche

Ing. Lorenzo Moriello

DEI - Università di Bologna

E-mail: [email protected]

https://www.unibo.it/sitoweb/lorenzo.moriello2


FINE

Documents

Sistemi e Architetture per l'Automazione Lsapa.campusfc.unibo.it/SAPA_06_Attuatore_Generalizzato... · 2018. 3. 21. · Ing. Lorenzo Moriello - Sistemi e Architetture per l'Automazione