9MA00048 AHU ManualeDeveloper 0212 IT

Baseline
Unit Trattamento Aria
Manuale per lo sviluppatore

Indice generale
1.Introduzione...............................................................................................................................4
1.1.FREE Studio........................................................................................................................4
1.2.EULA....................................................................................................................................4
2.Glossario.....................................................................................................................................5
2.1.Abbreviazioni e definizioni...............................................................................................5
3.Architettura baseline................................................................................................................6
3.1.Schema a blocchi...............................................................................................................6
3.2.Blocco GOAL......................................................................................................................7
3.3.Blocco DIAGNOSTICS.......................................................................................................8
3.4.Blocco STRATEGY..............................................................................................................9
3.5.Blocchi REGULATORS e ACTUATORS..........................................................................11
4.Applicazioni derivate.............................................................................................................12
4.1.Scegliere la baseline.......................................................................................................12
4.2.Derivare un nuovo progetto dalla baseline.................................................................14
4.3.Introdurre le proprie modifiche all'applicazione........................................................14
5.Modificare l'applicazione......................................................................................................15
5.2.Stato ON/OFF..................................................................................................................20
5.3.Modo COOL/HEAT.........................................................................................................23
5.4.Setpoint.............................................................................................................................24
5.5.Sonda di regolazione......................................................................................................26
5.6.Diagnostica......................................................................................................................28
5.7.Strategia............................................................................................................................33
5.8.Regolazione e attuazione delle uscite..........................................................................39
5.9.Interfaccia Uomo-Macchina...........................................................................................44
6.Librerie.....................................................................................................................................59
6.1.Actuators...........................................................................................................................59
6.2.Alarms...............................................................................................................................60
6.3.Regulators.........................................................................................................................61
6.4.SmartHMI..........................................................................................................................64
6.5.Thermodynamics.............................................................................................................71
6.6.Utils....................................................................................................................................72
A1.Schema a blocchi....................................................................................................................II
A1.1.INPUT................................................................................................................................II
A1.2.PARAMETERS..................................................................................................................III
A1.3.GOAL...............................................................................................................................III
A1.4.DIAGNOSTICS................................................................................................................IV
A1.5.STRATEGY.......................................................................................................................VI
A1.6.REGULATORS e ACTUATORS....................................................................................VIII
A1.7.OUTPUT..........................................................................................................................IX
A1.8.HMI...................................................................................................................................X
A2. Struttura del progetto FREE Studio...................................................................................XI
A2.1.Task, programmi e blocchi funzionali..........................................................................XI
A2.2.Librerie...........................................................................................................................XII
A2.3.INPUT............................................................................................................................XIII
A2.4.PARAMETERS...............................................................................................................XIII
2 Baseline Unit Trattamento Aria - Manuale per lo sviluppatore
A2.5.GOAL............................................................................................................................XVI
A2.6.DIAGNOSTICS............................................................................................................XVII
A2.7.STRATEGY..................................................................................................................XVIII
A2.8.REGULATORS e ACTUATORS....................................................................................XIX
A2.9.OUTPUT........................................................................................................................XIX
A2.10.HMI...............................................................................................................................XX
Baseline Unit Trattamento Aria - Manuale per lo sviluppatore 3

1. Introduzione
Questo manuale ha lo scopo di guidare lo sviluppatore che intenda utilizzare Eliwell
FREE Studio e le baseline Unit Trattamento Aria (U.T.A oppure, in inglese AHU, Air
Handling Unit) di Eliwell per costruire una propria applicazione per Unit Trattamento
Aria.
1.1. FREE Studio
Le Baseline AHU sono compatibili con la versione FREE Studio 2.0 o successive
1.2. EULA
Per installare FREE Studio e le baseline Unit Trattamento Aria obbligatoria

laccettazione della licenza duso.
Leggere attentamente le condizioni duso descritte (End User License Agreement
'EULA') prima di continuare.
Le condizioni d'uso sono disponibili anche sul sito all'indirizzo
http://www.eliwell.it/content.aspx?id=4533

2. Glossario
DEVELOPER: progettista / sviluppatore che prevede la conoscenza di uno o pi
linguaggi standard di programmazione IEC61131-3. Utente di FREE Application
USER: utente finale che utilizza tipicamente FREE Device. Non previsto che scriva linee
di codice. Lo USER disporr di documentazione dedicata.
RESPONSABILIT: descrizione funzionalit blocchi
COLLABORAZIONI: interazioni fra blocchi dell'Architettura Baseline
2.1. Abbreviazioni e definizioni
U.T.A.: Unit Trattamento Aria ( in inglese AHU, Air Handling Unit)
Application, Device, Connection: abbreviazioni di FREE (Studio) Application, FREE
Device rispettivamente. Suite Software
Applicazione IEC, Applicazione PLC, PROGRAM PLC: applicazione realizzata secondo
le normative IEC61131-3 (standard di programmazione per il controllo industriale)
tramite l'ambiente (tool) di sviluppo Application da scaricare sul target tramite
Application o Device
dispositivo Target, Target: nome attribuito al controllore programmabile FREE Smart
oppure FREE Evolution, ovvero strumento
HMI: acronimo di Human Machine Interface. Interfaccia grafica sviluppata con per FREE
Smart e terminali SKP SKW
Istanza: oggetto di una 'classe' di oggetti predefinita (blocco funzione, template, ecc)
Linguaggio IEC: linguaggio di programmazione secondo la normative IEC61131-3 (es.
FBD, SFC)
Menu BIOS, BIOS: menu parametri BIOS pre-impostato in fabbrica. Non modificabile
Smart: abbreviazione di FREE Smart; Evolution: abbreviazione di FREE Evolution
Studio: abbreviazione di FREE Studio. Suite Software descritta nel presente documento
Tab o scheda. L'ambiente di lavoro diviso in sezioni o pannelli. Ogni pannello pu
essere suddiviso a sua volta in schede o tab (es. tab Resources)
Nota: Molte definizioni o abbreviazioni sono standard del gergo informatico e/o PLC e
non sono riportate in questo elenco
Ad esempio una Funzione un termine standard. Altri termini, quali 'Blocco' saranno
descritti nei relativi paragrafi.

3. Architettura baseline
Questo capitolo descrive la struttura software di alto livello (ossia, l'architettura) delle
baseline Eliwell, introducendo informazioni che facilitano la comprensione
dell'applicazione di partenza, con il risultato di agevolare il lavoro dello sviluppatore che
intenda intervenire su di essa per derivare una propria applicazione.
3.1. Schema a blocchi
Lo schema a blocchi di Figura 1 rappresenta l'architettura delle baseline. I singoli
elementi dello schema e le loro connessioni sono descritti nei paragrafi successivi.
L'intera archittetura descritta in modo esaustivo in Appendice Architettura con
descrizioni sulle RESPONSABILIT dei singoli blocchi e sulle relazioni (definite
Collaborazioni) fra il blocco GOAL e gli altri blocchi
Figura 1: Struttura software di alto livello

3.2. Blocco GOAL
Il blocco GOAL determina quali sono gli obiettivi che il controllo dell'unit deve
perseguire.
In particolare, i dati risultanti dal blocco GOAL sono:
lo stato ON/OFF dell'unit;
il modo COOL/HEAT (estate/inverno) di funzionamento dell'unit;
lo stato di attivazione di modalit di risparmio energetico (modalit ECO);
i setpoint da inseguire;
le misure (feedback) da utilizzare nella regolazione, derivanti dalla scelta delle
sonde di regolazione.
Il blocco GOAL necessario per sintetizzare questi dati a partire dalle diverse possibili
sorgenti, che includono parametri e ingressi digitali e analogici.
ESEMPIO 3.1
Come esempio, si consideri come viene determinato lo stato ON/OFF nelle
baseline.
previsto un ingresso digitale dedicato alla forzatura dello stato di OFF (OFF
remoto): quando l'ingresso alto lo stato dell'unit forzato a OFF.
Quando invece l'OFF remoto non attivo, lo stato dell'unit dipende
dall'abilitazione della gestione a fasce orarie: se questo il caso, lo stato ON/OFF
viene determinato dalle impostazioni della fascia oraria attiva, altrimenti dato da
un parametro utente (ad esempio, impostato da interfaccia grafica o tramite
Device).
Il blocco GOAL valuta e assegna una priorit alle condizioni elencate sopra,
determinando lo stato ON/OFF risultante.
Il blocco GOAL non si occupa del se e del come possano essere realizzati questi
obiettivi, lasciando ai blocchi che seguono questo compito.
Si rimanda alla Appendice Architettura per ulteriori informazioni sulle relazioni fra il
blocco GOAL e gli altri blocchi
3.2.1. Forma software nelle baseline AHU

Lavorando con una baseline AHU, il blocco GOAL costituito da una serie di programmi
scritti in linguaggio FBD, il cui nome inizia per Goal_.
ESEMPIO 3.2
Ad esempio, il programma che si occupa di determinare lo stato ON/OFF
dell'U.T.A. Goal_State.
I risultati del blocco GOAL sono resi disponibili come dati globali al resto
dell'applicazione, nella cartella Global shared > Variables.

3.3. Blocco DIAGNOSTICS
Il blocco DIAGNOSTICS valuta la presenza di condizioni di anomalia nell'unit e gestisce
l'attivazione e la disattivazione (riarmo) degli allarmi.
I test eseguiti dal blocco DIAGNOSTICS includono:
la valutazione di ingressi digitali diagnostici per la rilevazione di condizioni di
anomalia nell'unit;
ESEMPIO 3.3
Ad esempio, il blocco DIAGNOSTICS valuta lo stato degli ingressi digitali associati
alle protezioni termiche dei ventilatori dell'unit trattamento aria.
il controllo dei valori derivanti dalle sonde, al fine di rilevare sonde assenti o
guaste;
la valutazione di ingressi analogici associati a sicurezze/pre-allarmi;
ESEMPIO 3.4
Sempre a titolo di esempio, il blocco DIAGNOSTICS delle baseline AHU verifica
che la temperatura rilevata dalla sonda antigelo non sia al di sotto di un valore
considerato critico.
Il blocco DIAGNOSTICS ha il compito di rilevare le condizioni di errore, ma non di porvi

rimedio.
blocco DIAGNOSTICS e gli altri blocchi

Lavorando con una baseline AHU, il blocco DIAGNOSTICS costituito dal programma
omonimo, scritto in linguaggio FBD.
I risultati del blocco DIAGNOSTICS sono resi disponibili come variabili di allarme,
raggruppati dunque nella cartella Global shared > Alarms.
Ogni rete del programma Diagnostics ha il compito di valorizzare un singolo allarme.

3.4. Blocco STRATEGY
Il blocco STRATEGY ha il compito di scegliere la strategia da usare per raggiungere gli
obiettivi determinati dal blocco GOAL. Nel dettaglio, questo si traduce in:
valutare, in base alle misure provenienti dal campo e agli obiettivi calcolati dal
blocco GOAL, se esistono richieste da soddisfare o situazioni di pre-allarme o di
emergenza a cui porre rimedio;
dare una priorit alle richieste pendenti;
ESEMPIO 3.5
Ad esempio, nelle baseline AHU si pu verificare che n l'obiettivo di temperatura
n l'obiettivo di umidit siano soddisfatti.
In questa situazione, il blocco STRATEGY sceglie quale dei due obiettivi perseguire
per primo.
scegliere tra le diverse strategie possibili quella da utilizzare per soddisfare la

richiesta.
ESEMPIO 3.6
Considerando sempre le baseline AHU, una richiesta di raffreddamento pu essere
soddisfatta attraverso l'uso di una batteria freddo oppure, in particolari condizioni,
attraverso il meccanismo di free-cooling, che pi conveniente.
Il blocco STRATEGY valuta le condizioni necessarie per l'attivazione del free-
cooling (in particolare, la temperatura esterna deve essere all'interno di un
intervallo ben determinato): se tali condizioni sono soddisfatte, il free-cooling
viene adottato come strategia per soddisfare la richiesta di raffreddamento;
altrimenti, si ricorre alla sola batteria freddo.
La strategia scelta dal blocco STRATEGY determina l'abilitazione dei diversi componenti
dell'unit e i dati da utilizzare nella loro regolazione - come i setpoint da inseguire e le
misure dal campo (i feedback) da utilizzare.
ESEMPIO 3.7
Ad esempio, la strategia di raffreddamento abilita il regolatore della batteria
freddo trasmettendogli il valore letto dalla sonda di termoregolazione e il valore di
temperatura da raggiungere (setpoint di temperatura in modo COOL).
Viceversa, la regolazione della batteria caldo disabilitata.
blocco STRATEGY e gli altri blocchi

Lavorando con una baseline AHU, il blocco STRATEGY costituito dal programma
omonimo, scritto in linguaggio SFC.
Il blocco STRATEGY un modello della macchina a stati dell'unit, che definisce:
le azioni da compiere (cio, la strategia da usare) per ogni stato macchina;
le possibili transizioni tra stati e le condizioni in cui esse avvengono.
Il linguaggio di programmazione scelto, l'SFC, permette una traduzione efficace di
questa macchina a stati:
le strategie corrispondono ad ACTION del programma SFC, implementate in
linguaggio FBD: ogni strategia contiene una rete FBD per ogni componente
dell'unit;
le transizioni corrispondono a TRANSITION del programma SFC, implementate in
linguaggio ST.

3.5. Blocchi REGULATORS e ACTUATORS
I valori assunti dalle uscite fisiche del controllore sono determinati dall'insieme di
blocchi REGULATORS e ACTUATORS, che raccolgono le logiche di regolazione e di
attuazione delle uscite, rispettivamente.
ESEMPIO 3.8
Concretamente, per logica di regolazione si intende, ad esempio, un regolatore
proporzionale o proporzionale-integrale o a gradini.
Come esempio di logica di attuazione si pu citare l'attuatore per una valvola a 3-
punti.
I blocchi REGULATORS e ACTUATORS svolgono collettivamente il compito di esaudire

le richieste che il blocco STRATEGY esprime in termini di setpoint o di valori percentuali.
ESEMPIO 3.9
Ad esempio, quando la strategia di raffreddamento abilita la batteria freddo e gli
assegna un setpoint pari a 25C, il blocco REGULATOR traduce questa richiesta in
un valore percentuale di attuazione che pu essere assegnato direttamente ad un
uscita analogica oppure processato dall'eventuale blocco ACTUATOR, che lo
traduce nei valori delle uscite digitali e/o analogiche.
Si rimanda alla Appendice Architettura per ulteriori informazioni sulle relazioni fra i
blocchi REGULATORS, ACTUATORS e gli altri blocchi

I blocchi REGULATORS e ACTUATORS sono raggruppati in blocchi funzionali che
rappresentano i componenti fisici dell'unit trattamento aria.
ESEMPIO 3.10
Le baseline AHU hanno, ad esempio, un blocco per il ventilatore di mandata, uno
per la batteria caldo, uno per la batteria freddo, uno per l'umidificatore, ecc...
Ogni strategia determina gli ingressi di tutti i blocchi e ne causa l'esecuzione.

4. Applicazioni derivate
Questo capitolo descrive le operazioni da compiere per derivare una propria
applicazione a partire dalle baseline AHU di Eliwell.
4.1. Scegliere la baseline
La prima decisione da prendere riguarda la baseline AHU da cui partire: la scelta
dipende essenzialmente dalla tipologia di U.T.A.che l'applicazione dovr controllare.
La Tabella 1 elenca le differenze principali tra le baseline AHU.
Si noti che l'unica baseline AHU fornita per la famiglia di controllori programmabili FREE
Evolution il layout 3.
Tabella 1: Elenco delle baseline AHU
LAYOUT 1 - AHU01
Il layout 1 un'applicazione dedicata al controllo di un'U.T.A. semplice, composta da:
serrande ON/OFF,
un singolo ventilatore (di mandata),
batteria caldo,
batteria freddo.
L'unico obiettivo perseguito dal layout 1 mantenere la temperatura dell'ambiente
controllato entro un dato range di valori.

LAYOUT 2 - AHU02
Il layout 2 estende il layout 1, includendo:
umidificatore,
batteria post-riscaldo (ci che permette il processo di deumidificazione).
Questo layout ha l'obiettivo ulteriore di mantenere l'umidit relativa dell'ambiente
controllato entro un dato range di valori.
LAYOUT 3 - AHU03
Il layout 3 un'applicazione dedicata al controllo di un'U.T.A. completa, che include
tutti gli elementi previsti dai layout precedenti e, inoltre:
un secondo ventilatore (di ripresa),
gestione modulante serrande (per free-cooling/free-heating),
recuperatore di calore.

La scelta della baseline di partenza pu essere guidata dalle seguenti considerazioni:
se l'U.T.A. ha il solo obiettivo di temperatura e differisce in maniera sostanziale
dalle caratteristiche del layout 3 (ad esempio, non ha gestione free-cooling/free-
heating, serrande modulanti e ventilatore di ripresa), pu essere conveniente
partire dal layout 1;
se l'U.T.A. ha il duplice obiettivo di temperatura e umidit relativa e differisce in
maniera sostanziale dalle caratteristiche del layout 3 (ad esempio, non ha
gestione free-cooling/free-heating, serrande modulanti e ventilatore di ripresa),
pu essere conveniente partire dal layout 2;
in tutti gli altri casi, pu essere conveniente partire dal layout 3.
4.2. Derivare un nuovo progetto dalla baseline
Una volta scelta la baseline di partenza necessario crearne una copia, per poterla
modificare e derivare cos una propria applicazione.
Se si utilizza FREE Smart, i passi da seguire sono:
1. aprire il progetto Application corrispondente alla baseline scelta;
2. salvare con un nuovo nome l'applicazione (menu File > Save project as...).
Si faccia riferimento al manuale utente di Application per ulteriori dettagli.
Se, al contrario, si utilizza FREE Evolution, necessario duplicare:
il progetto Application;
il progetto User Interface;
la soluzione Connection che li unisce.
Il modo pi semplice per fare ci creare una copia dell'intera cartella corrispondente
alla baseline scelta.
4.3. Introdurre le proprie modifiche all'applicazione
Una volta ottenuta una copia di lavoro della baseline. possibile modificarne il codice
sorgente, cos da introdurre tutte le differenze richieste dal proprio specifico caso
applicativo.
Per un'introduzione alla struttura di alto livello dell'applicazione si raccomanda la lettura
del Capitolo 3.
Sebbene non vi siano limitazioni al genere e numero di modifiche che possibile
introdurre, il Capitolo 5 raccoglie i casi pi frequenti, descrivendo le modalit di
intervento e proponendo esempi concreti.

5. Modificare l'applicazione
Questo capitolo discute le pi frequenti necessit di intervento sulle baseline e fornisce
indicazioni su come modificare l'applicazione, ricorrendo a numerosi esempi concreti.
5.1.1. Configurazione statica dell'I/O

spesso necessario modificare la mappatura dell'I/O fisico (ingressi e uscite
dell'hardware che esegue l'applicazione) sull'I/O logico, cio sui simboli utilizzati
nell'applicazione per riferirsi ai valori di ingresso e di uscita.
ESEMPIO 5.1
Lavorando su un'applicazione per Smart derivata dal layout 2, si decide di
spostare l'ingresso digitale corrispondente all'allarme umidificatore dall'I/O esteso
a quello locale.
Application permette la modifica della configurazione dell'I/O, in forma tabellare, nella

sezione Resources > I/O Mapping dell'ambiente di sviluppo: sufficiente ordinare i nomi
simbolici presenti nelle griglie nella maniera che meglio si adatta al proprio caso
applicativo per soddisfare questo requisito.
ESEMPIO 5.2
Considerando l'Esempio 5.1, per ottenere il risultato desiderato possibile seguire
questo procedimento:
1. si apre la sezione Resources > I/O Mapping > Local;
2. si sceglie l'ingresso digitale da utilizzare, supponiamo DIL3, e si modifica il
contenuto della cella corrispondente inserendo il nome simbolico
dell'allarme umidificatore, I_HumidifierAlarm;
3. si apre la sezione Resources > I/O Mapping > Extended e si rimuove il nome
simbolico dell'allarme umidificatore dalla sua posizione precedente;
4. l'ingresso logico sostituito al punto 2, I_ElectricHeaterThermal, pu
essere assegnato ad un ingresso digitale non utilizzato dell'espansione.
Se la modifica della mappatura dell'I/O fisico sull'I/O logico coinvolge l'espansione EVE
di Evolution, necessario intervenire anche sulla configurazione di rete definita in
Connection, come illustrato nell'esempio seguente
ESEMPIO 5.3
Lavorando su un'applicazione per Evolution derivata dal layout 3, si decide di
spostare l'ingresso digitale corrispondente all'allarme umidificatore dall'I/O esteso
(configurato come nodo CANopen in rete field) a quello locale.

L'I/O dell'espansione EVE viene letto dalla rete field e reso disponibile all'applicazione
PLC come Status variable. L'associazione tra Status variable e I/O fisico viene fatta in
Connection, nelle sezioni corrispondenti (dipendenti dal protocollo di comunicazione
adottato) della configurazione dell'espansione EVE.
. ESEMPIO 5.4
Considerando l'Esempio 5.3, per ottenere il risultato desiderato possibile seguire
questo procedimento:
in Application, si apre la sezione Resources > Status variables e si elimina la
variabile corrispondente all'allarme umidificatore, I_HumidifierAlarm;
si apre la sezione Resources > I/O Mapping > Local, si sceglie l'ingresso digitale da
utilizzare, supponiamo DIL3, e si modifica il contenuto della cella corrispondente
inserendo il nome simbolico dell'allarme umidificatore, I_HumidifierAlarm;
in Connection, si apre la sezione PDO Tx - Input e si rimuove l'assegnamento
dell'input digitale di indice 3 alla variabile di stato rimossa al punto 1;
l'ingresso logico sostituito al punto 2, I_ElectricHeaterThermal, pu essere

assegnato ad un ingresso digitale non utilizzato dell'espansione; per fare ci, in
Application, nella sezione Resources > Status variables si inserisce un nuovo
elemento di tipo BOOL e nome I_ElectricHeaterThermal;
si compila l'applicazione PLC, cos che la nuova configurazione possa essere letta
da Connection;
in Connection, nella sezione PDO Tx - Input si assegna ad un oggetto CANopen
libero la variabile di stato introdotta al punto 4.

5.1.2. Configurazione dinamica dell'I/O
Si potrebbe voler rendere la mappatura dell'I/O fisico sull'I/O logico dipendente dal
valore di uno o pi parametri utente, in modo da poter essere modificata anche
successivamente alla fase di sviluppo (ad esempio, in fase di installazione).
ESEMPIO 5.5
Lavorando su un'applicazione per Smart derivata dal layout 1 e che fa uso di tutti
e soli gli ingressi digitali locali (DIL1...6), si vuole rendere parametrico
l'assegnamento di questi ingressi ai corrispondenti simboli logici.
Per ottenere questo risultato necessario introdurre un ulteriore livello software, come
nuovo PROGRAM assegnato al task Timed, che, sulla base dei valori dei parametri di
configurazione, assegni ad ogni ingresso logico i valori letti dall'ingresso digitale/dalla
sonda corrispondente e - specularmente - assegni il valore di ogni uscita logica all'uscita
digitale/analogica corrispondente.

ESEMPIO 5.6
Per implementare il requisito espresso nell'Esempio 5.5, possibile seguire questo
procedimento:
1. nella sezione Resources > EEPROM Parameters, si definiscono sei nuovi
parametri (ad esempio, IO01, IO02, ..., IO06), uno per ogni ingresso
logico (ad esempio, IO01 si riferisce a I_OutletFanThermal, IO02 a
I_OutletFanFlowSwitch, ecc.), il cui valore, compreso tra 1 e 6, indica
l'ingresso digitale locale corrispondente;
2. nella sezione Resources > Menu Prg, si pubblicano i nuovi parametri in un

menu;
3. nella sezione I/O Mapping > Local, si assegnano dei nomi generici alle
variabili corrispondenti agli ingressi digitali locali;

4. i simboli che, in precedenza, erano assegnati agli ingressi digitali locali,
vengono definiti in altro modo, ad esempio come variabili di stato (sezione
Resources > Status variables);
5. si crea un nuovo PROGRAM in linguaggio FBD, di nome Input_DILMapping,

costituito da una rete FBD per ogni ingresso logico; ogni rete FBD
seleziona, in base al valore letto dal parametro corrispondente, l'ingresso
digitale locale da usare;
6. il nuovo PROGRAM viene assegnato al task Timed come primo PROGRAM

da eseguire: il resto dell'applicazione rimane immutato.

5.2. Stato ON/OFF
Il PROGRAM Goal_State determina lo stato ON/OFF (pi precisamente, lo stato pu
essere OFF, STD_BY oppure ON) dell'U.T.A. e lo stato di attivazione di particolari
modalit operative, come la modalit ECO (Economy).
Il risultato dell'esecuzione di Goal_State codificato nelle variabili di stato state e
economy: questo significa che possibile modificare o, addirittura, sostituire
completamente il PROGRAM senza impatto sul resto dell'applicazione, fintanto che
queste variabili di stato vengono valorizzate correttamente.
Nelle baseline AHU, lo stato dell'unit viene determinato analizzando gli ingressi e i
parametri utente dedicati allo scopo, secondo una priorit codificata nel codice del
PROGRAM Goal_State (si veda la Figura 2).
Figura 2: Determinazione dello stato dell'U.T.A. a partire dall'ingresso digitale di OFF remoto, dal
parametro utente di stato locale St10 e dalle informazioni derivanti dalla gestione fasce orarie, se
abilitata
Inoltre, Goal_State si occupa di determinare se la modalit Economy attiva o meno

(si veda la Figura 3).
Figura 3: L'attivazione della modalit Economy dipende dall'ingresso digitale dedicato e dal valore
corrente del modo macchina derivato dalla gestione fasce orarie, se abilitata

Lo stesso PROGRAM si occupa preliminarmente di determinare la fascia oraria corrente,
cos da poterne utilizzare le informazioni associate (si veda la Figura 4).
Figura 4: L'abilitazione della gestione a fasce orarie dipende dalla disponibilit

dell'orologio di sistema e dal valore del parametro tE00; la fascia oraria corrente
viene determinata facendo uso del blocco di libreria TimeFrameManager_t
5.2.1. Modificare l'algoritmo che determina lo stato ON/OFF

I dati da considerare per determinare lo stato ON/OFF dell'unit trattamento aria, cos
come la priorit da assegnare ad essi, possono differenziarsi in modo sostanziale da
caso a caso. dunque frequente la necessit di modificare l'algoritmo per il calcolo
dello stato ON/OFF.
ESEMPIO 5.7
Come esempio, si consideri una situazione in cui non sia opportuno dare sempre
priorit alla gestione fasce orarie (se abilitata) rispetto all'impostazione di stato
tramite parametro utente, ma in cui l'OFF da parametro abbia priorit rispetto ad
uno stato di ON da fascia oraria.
Per fare questo sufficiente modificare la rete FBD che determina il valore della
variabile di stato state, all'interno del PROGRAM Goal_State.

ESEMPIO 5.8
Considerando la necessit espressa nell'Esempio 5.7, possibile modificare la rete
numero 3 del PROGRAM Goal_State in modo da forzare lo stato OFF se il
parametro locale St10 vale OFF.
5.2.2. Modificare la gestione a fasce orarie

La gestione a fasce orarie pu essere sostituita con una personalizzata secondo le
esigenze del proprio caso applicativo.
ESEMPIO 5.9
Lavorando su un'applicazione derivata, si desidera introdurre un profilo COMFORT
24/24h (sempre COMFORT), da utilizzare nella programmazione settimanale.
Per far questo sufficiente:

sostituire il blocco di gestione fasce orarie con uno diverso, che pu
opportunamente essere derivato dal primo;
modificare (aggiungere/rimuovere/ridefinire) l'insieme di parametri utente
necessari alla memorizzazione delle fasce orarie.

ESEMPIO 5.10
Considerando il requisito espresso nell'Esempio 5.9, si pu procedere nel modo
seguente:
1. si modifica la definizione dei parametri tE01, tE02, ..., tE07, a cui deve
essere possibile assegnare il valore corrispondente al profilo aggiunto;
2. si importa dalla libreria Utils una copia del blocco TimeFrameManager_t;

3. si modifica il codice sorgente della copia locale del blocco
TimeFrameManager_t in modo da gestire il profilo aggiunto.
5.3. Modo COOL/HEAT

Il PROGRAM Goal_Mode determina il modo COOL/HEAT di funzionamento dell'unit
trattamento aria.
Il risultato dell'esecuzione di Goal_Mode codificato nella variabile di stato hcMode:
questo significa che possibile modificare o, addirittura, sostituire completamente il
PROGRAM senza impatto sul resto dell'applicazione, fintanto che questa variabile di
stato viene valorizzata correttamente.
Nelle baseline AHU, il modo COOL/HEAT viene determinato incrociando il valore di

ingressi e parametri utente dedicati allo scopo con il valore di un ulteriore parametro
utente che definisce i modi selezionabili (si veda la Figura 5).
Figura 5: Determinazione del modo di funzionamento COOL/HEAT dell'unit trattamento aria; il

parametro St00 limita i modi selezionabili e indica le sorgenti (modo locale, modo AUTO, modo remoto)
da utilizzare nel calcolo
Lo stesso PROGRAM si occupa anche di risolvere preliminarmente il modo AUTO

(Figura 6), selezionabile dall'utente: in modo AUTO, il cambio modo (da COOL a HEAT e
viceversa) avviene senza intervento dell'utente sulla base del valore di una sonda
selezionabile tramite parametro.
Figura 6: Risoluzione del modo AUTO: in questo caso, il modo di funzionamento COOL/HEAT dell'unit
viene determinato valutando il valore della sonda selezionata tramite parametro utente St20 con
riferimento ad un intervallo di valori (zona neutra) fissato da una combinazione di diversi parametri
utente (il limite inferiore dato da SP20 + St22, il limite superiore da SP10 + St21)
5.4. Setpoint

Il PROGRAM Goal_Setpoint calcola i setpoint relativi a tutti gli obiettivi di controllo
gestiti dall'applicazione.
Il risultato dell'esecuzione di Goal_Setpoint codificato nell'insieme di variabili di
stato dedicate ai setpoint: questo significa che possibile modificare o, addirittura,
sostituire completamente il PROGRAM senza impatto sul resto dell'applicazione,
fintanto che queste variabili di stato vengono valorizzate correttamente.
Nelle baseline AHU, il setpoint viene prima selezionato all'interno di una lista di possibili
sorgenti alternative e, successivamente, sommato a uno o pi differenziali (si veda come
esempio la Figura 7).
Figura 7: Calcolo del setpoint di temperatura in modo COOL, a partire dal valore del parametro SP10
oppure SP11, a seconda che la modalit Economy sia attiva o meno; l'unico differenziale applicato il
differenziale dinamico su temperatura esterna, se abilitato da parametro (dS00)

5.5. Sonda di regolazione
Il PROGRAM Goal_RegulationProbe seleziona le sonde da utilizzare nella fase di
regolazione (una sonda per ogni obiettivo del controllo: temperatura, umidit relativa,
ecc.).
Il risultato dell'esecuzione di Goal_RegulationProbe codificato nell'insieme di
variabili di stato dedicate alle sonde di regolazione: questo significa che possibile
modificare o, addirittura, sostituire completamente il PROGRAM senza impatto sul resto
dell'applicazione, fintanto che queste variabili di stato vengono valorizzate
correttamente.
Nelle baseline AHU il valore di uno o pi parametri utente seleziona la sonda da usare
all'interno di una lista (si veda, come esempio la Figura 8).
Figura 8: Selezione della sonda di umidit relativa, scelta in funzione del valore del parametro Hr01 tra
la sonda di ripresa, la sonda di mandata e la sonda ambiente
5.5.1. Modificare la selezione della sonda di regolazione

Potrebbe essere necessario aggiungere o rimuovere una sonda dalla lista di quelle
selezionabili come sonda di regolazione.
ESEMPIO 5.11
Ad esempio, considerando la selezione della sonda di regolazione di umidit, si
vuole eliminare la possibilit di regolare con la sonda di mandata.
Per ottenere questo risultato sufficiente:

modificare la rete FBD corrispondente all'interno del PROGRAM
Goal_RegulationProbe, perch nella selezione sia inclusa/esclusa la sonda;
modificare la definizione del parametro di selezione, in particolare per
incrementarne/decrementarne il massimo.

ESEMPIO 5.12
Riprendendo l'Esempio 5.11, si pu procedere nel modo seguente:
1. Si rimuove I_OutletAirRelativeHumidity dalla rete numero 2 del
PROGRAM Goal_RegulationProbe, decrementando il numero di ingressi
del blocco MUX e modificando opportunamente i collegamenti;
2. Si modifica la definizione del parametro Hr01_HumidityProbeSelection,

modificandone l'intervallo di valori tra 0 e 1.
5.5.2. Fissare la sonda di regolazione

Come caso limite del requisito espresso nel paragrafo 5.5.1., si potrebbe voler fissare la
sonda di regolazione, svincolandola dal parametro di selezione che pu quindi essere
rimosso.
ESEMPIO 5.13
Portando all'estremo l'Esempio 5.11, si decide che la sonda di regolazione umidit
relativa debba essere la sonda di ripresa.
Per ottenere questo risultato sufficiente:

semplificare la rete FBD corrispondente all'interno del PROGRAM
Goal_RegulationProbe, che diventa un semplice assegnamento;
eliminare il parametro di selezione.

ESEMPIO 5.14
Per raggiungere l'obiettivo fissato nell'Esempio 5.13, si pu procedere nel modo
seguente:
1. rimuovere il blocco MUX, Hr01_HumidityProbeSelection,
I_OutletAirRelativeHumidity e I_RoomRelativeHumidity dalla rete
numero 2 del PROGRAM Goal_RegulationProbe;
2. inserire un blocco MOVE, che collega I_InletAirRelativeHumidity e
RH_RegulationProbe;
3. nella sezione Resources > EEPROM Parameters, cancellare il parametro

Hr01_HumidityProbeSelection.
5.6. Diagnostica
Il PROGRAM Diagnostics determina lo stato di attivazione degli allarmi, ossia:
nel caso Smart, di tutte le variabili definite nella sezione Resources > Alarms; in
questo caso, Application si preoccupa di mantenere in modo automatico uno
stato globale di attivazione allarmi per la visualizzazione a display;
nel caso Evolution, di un sottoinsieme di variabili di tipo USINT definite nella
sezione Resources > Status variables; in questo caso, cura dello sviluppatore
mantenere lo stato globale di attivazione allarmi per la visualizzazione a display
(variabile Er_GlobalAlarmStatus) attraverso il PROGRAM
Diagnostics_GlobalAlarmStatus.
Il PROGRAM Diagnostics valuta innanzitutto se abilitare la diagnostica: in caso
contrario, tutti gli allarmi sono disattivati (si veda la Figura 9).
Figura 9: Se lo stato dell'U.T.A. OFF, la diagnostica disabilitata

Successivamente (Figura 10), si gestisce l'eventuale richiesta di riarmo degli allarmi,
ricevuta attraverso l'interfaccia utente.
Figura 10: Gestione della richiesta di reset allarmi
Infine (Figura 11), sono analizzate una per una tutte le condizioni di allarme monitorate
dall'applicazione.
Figura 11: Er_ClockError codifica lo stato di errore orologio: un allarme a riarmo manuale
(richiede cio il reset esplicito da parte dell'utente) e controlla lo stato della variabili di sistema
sysClockError. Er_InletAirTemperatureProbeError codifica lo stato di errore sonda di
temperatura di ripresa
Se si modificano le logiche che determinano il valore di uno o pi allarmi gi previsti

nelle baseline, non necessario modificare le parti dell'applicazione che ne fanno uso.
Tuttavia, le modifiche pi frequenti al PROGRAM Diagnostics sono legate all'aggiunta
o alla rimozione di un allarme, che pu incidere sulla sua gestione demandata a parti
successive dell'applicazione (in particolare, al PROGRAM Strategy).

5.6.1. Aggiungere un allarme
Qualora un'applicazione derivata preveda la segnalazione/gestione di una condizione
di allarme non prevista nelle baseline U.T.A., necessario aggiungere un allarme,
gestire la sua segnalazione ed implementare l'eventuale reazione del controllore.
ESEMPIO 5.15
Si supponga, ad esempio, di voler aggiungere la gestione di un allarme incendio,
rilevato tramite ingresso digitale collegato ad un sensore di fumo.
Per gestire una nuova condizione di allarme necessario:

creare una nuova variabile di allarme;
gestire, in una nuova rete FBD del PROGRAM Diagnostics, attivazione e riarmo
dell'allarme appena aggiunto;
se richiesto, gestire nel PROGRAM Strategy la condizione di allarme attivo con
un'adeguata procedura di reazione/messa in sicurezza.
Nel caso Evolution, necessario anche, in User Interface, aggiungere nella sezione
Resources > Sets un elemento ai set Alarm_Labels e Alarm_Values.

ESEMPIO 5.16
Riprendendo l'Esempio 5.15, possibile soddisfare il requisito con le modifiche
seguenti:
1. in Application, aggiungere una nuova variabile di allarme, Er_FireAlarm:
a. nel caso di Smart, nella sezione Resources > Alarms;
b. nel caso di Evolution, nella sezione Resources > Status variables; il tipo
della variabile deve essere USINT;
2. aggiungere l'ingresso digitale diagnostico I_FireAlarm, corrispondente al

rilevatore di fumo;
a. nel caso Smart, si deve intervenire in Application nella sezione
Resources > I/O Mapping;
b. nel caso Evolution, pu essere necessario modificare anche la

configurazione di rete con Connection, qualora venga scelto un
ingresso digitale dell'espansione;
3. codificare l'attivazione e il riarmo dell'allarme con una semplice rete FBD e
l'ausilio dei blocchi disponibili nella libreria Alarms;
4. aggiungere, in Strategy > Act_EvaluateSecurities, Er_FireAlarm tra
gli allarmi che determinano la messa in sicurezza dell'unit trattamento
aria;

5. solo nel caso Evolution, modificare il PROGRAM
Diagnostics_GlobalAlarmStatus, per includere il nuovo allarme nel
calcolo dello stato globale di attivazione allarmi per la visualizzazione a
display;
6.
7. solo nel caso Evolution, compilare l'applicazione PLC, cos che il nuovo
allarme sia visibile in User Interface, in seguito all'operazione di
aggiornamento parametri (Refresh parameters);
8. solo nel caso Evolution, con User Interface, aggiungere nella sezione
Resources > Sets un elemento al set Alarm_Labels; impostare
Er_FireAlarm come visibilit del nuovo elemento;
9.
10. solo nel caso Evolution, con User Interface, aggiungere nella sezione
Resources > Sets un elemento al set Alarm_Values.; impostare
Er_FireAlarm come valore e come visibilit del nuovo elemento.

5.7. Strategia
Il PROGRAM Strategy definisce la macchina a stati dell'applicazione.
Gli stati principali (Figura 12) sono:
ON (funzionamento normale);
OFF (unit spenta);
stati di pre-allarme o di emergenza:
OFF da allarme (condizione di emergenza);
antigelo.
Figura 12: Stati principali delle baseline AHU: oltre allo stato di normale funzionamento
(ON) e allo stato di OFF, previsto uno stato di allarme e una procedura straordinaria per
l'antigelo
Lo stato di ON a sua volta una macchina a stati (Figura 13), dove ogni stato
rappresenta una strategia per il soddisfacimento di un obiettivo (di temperatura, di
umidit, ecc.).

Figura 13: macchina a stati del layout 2, durante il normale funzionamento dell'unit: considerando ad
esempio il modo estivo (COOL), l'unit pu attivare le procedure di raffreddamento (STEP Cooling),
prioritario, e di deumidificazione (STEP Dehumidification)
5.7.1. Rimuovere una strategia

possibile che alcune delle situazioni di pre-allarme/emergenza previste dalle baseline
Unit Trattamento Aria, o delle strategie per il soddisfacimento degli obiettivi del
controllo, non siano significative per il proprio caso applicativo: pu dunque essere
opportuno eliminarle.
ESEMPIO 5.17
Si consideri, ad esempio, un'applicazione derivata dal layout 2, che differisce da
quest'ultimo per l'assenza di un umidificatore e, dunque, per l'impossibilit di
eseguire la strategia di umidificazione.
Per far ci, necessario:

rimuovere lo STEP SFC corrispondente allo stato da eliminare;
se non utilizzata in altri STEP, eliminare la ACTION corrispondente alla strategia
da eliminare;
intervenire sulle connessioni dello schema SFC, eliminando le transizioni da e
verso lo stato eliminato.
Potrebbe essere richiesto l'intervento su altre parti del PROGRAM Strategy o
dell'applicazione, ad esempio per eliminare un allarme o un componente l'U.T.A. non
pi necessario.

ESEMPIO 5.18
Rifacendosi all'Esempio 5.17, sufficiente:
1. nella ACTION Act_On, eliminare lo STEP Humidification e il codice
associato (Act_Humidification);
2. eliminare la transizione uscente dallo STEP eliminato ed il terzo pin della

transizione uscente dallo STEP Heat (entrante nello STEP eliminato);
3. eliminare il FUNCTION_BLOCK Humidifier_AHU02, la sua istanza globale

humidifier e le reti FBD nel PROGRAM Strategy (una per strategia)
dedicate alla sua gestione.

5.7.2. Aggiungere una strategia
Applicazioni derivate possono gestire situazioni di pre-allarme o di emergenza non
previste dalle baseline Unit Trattamento Aria, cos come prevedere ulteriori strategie
per il soddisfacimento degli obiettivi del controllo.
ESEMPIO 5.19
Riprendendo l'Esempio 5.33, si vuole reagire ad un allarme incendio con una
procedura dedicata.
Per far ci, necessario:

creare lo STEP SFC corrispondente allo stato da aggiungere;
creare la ACTION corrispondente alla strategia da aggiungere, assegnandola allo
STEP appena creato;
intervenire sulle connessioni dello schema SFC, aggiungendo le transizioni da e
verso lo stato aggiunto.
Potrebbe essere richiesto l'intervento su altre parti del PROGRAM Strategy o
dell'applicazione, ad esempio per gestire una nuova variabile di allarme o un nuovo
componente l'unit trattamento aria.

ESEMPIO 5.20
Per soddisfare il requisito espresso nell'Esempio 5.19, si pu procedere nel modo
seguente:
1. si modifica Act_EvaluateSecurities, perch valorizzi un flag dedicato
all'allarme incendio, forceFireAlarm;
2. si inserisce un nuovo STEP, FireAlarm, connesso in parallelo agli altri stati

principali, ma in prima posizione, in quanto pi prioritario;
3. come condizione della transizione di ingresso allo STEP FireAlarm, si
sceglie forceFireAlarm; come condizione di uscita una nuova
TRANSITION, corrispondente al valore negato di forceFireAlarm;
4. si crea una nuova ACTION Act_FireAlarm e la si assegna allo STEP
FireAlarm;

5. si codifica la nuova strategia nella ACTION Act_FireAlarm, ad esempio in
linguaggio FBD, dove ogni rete dedicata al controllo di un componente
dell'unit trattamento aria.

5.8. Regolazione e attuazione delle uscite
I componenti dell'U.T.A. vengono modellati all'interno delle baseline AHU con dei
FUNCTION_BLOCK utilizzati dal PROGRAM Strategy nell'esecuzione delle diverse
strategie.
5.8.1. Modificare la regolazione di un componente dell'U.T.A.

Nello sviluppo di un'applicazione derivata dalle baseline U.T.A. spesso necessario
modificare la regolazione e/o l'attuazione delle uscite del controllore per rispecchiare le
differenze negli attuatori fisici che compongono l'unit. Purch l'interfaccia del
FUNCTION_BLOCK rimanga immutata, non sar necessario apportare modifiche al
resto dell'applicazione.

ESEMPIO 5.21
Come esempio, si consideri un'applicazione derivata dal layout 1, da cui differisce
per la presenza di una batteria a resistenze (in numero di 3) in luogo della
batteria a valvola modulante calda.
Si pu procedere nel modo seguente:
1. modificare le uscite dell'applicazione: la baseline fa uso di un'uscita
analogica per regolare la batteria calda, mentre l'applicazione derivata usa
tre uscite digitali (una per ogni resistenza);
2. cambiare l'implementazione del blocco Heater_AHU01, affinch traduca gli

stessi comandi ricevuti da STRATEGY in azioni sulle tre uscite digitali; in
particolare:
a) quando la batteria caldo non abilitata, le tre uscite digitali sono
FALSE;
b) quando il livello di potenza della batteria caldo fissato, se il livello

uguale a 33%, solo l'uscita digitale corrispondente alla prima resistenza
TRUE; se il livello uguale a 66%, due uscite digitali sono TRUE; se il
livello uguale a 100%, tutte e tre le uscite digitali sono TRUE;

c) nel normale funzionamento della batteria caldo, si effettua una
regolazione a tre gradini, i cui differenziali corrispondono ad un terzo
della banda per la termoregolazione in modo HEAT (si pu usare il
blocco ThreeStepsRegulator_t della libreria Regulators); l'attuazione
delle uscite disabilitata se la temperatura di mandata supera il limite
superiore impostato tramite parametro.

5.8.2. Aggiungere un componente all'U.T.A.
Nello sviluppo di una propria applicazione derivata da una baseline, pu essere
necessario gestire un componente fisico dell'U.T.A. non previsto da quest'ultima.
ESEMPIO 5.22
Si consideri il caso di un'applicazione derivata dal layout 1, da cui differisce per la
presenza di un recuperatore di calore.
La gestione del nuovo componente richiede:

la definizione di un ulteriore FUNCTION_BLOCK che si occupi di tradurre i
comandi ricevuti da STRATEGY in operazioni sulle uscite;
la modifica del PROGRAM Strategy, affinch venga gestito - in ogni modo
operativo (in ogni "strategia") - il nuovo componente.
ESEMPIO 5.23
Considerando l'Esempio 5.22, si pu procedere nel modo che segue:
1. si definisce l'uscita logica per il controllo del recuperatore di calore, che si
suppone essere di tipo rotativo e che richiede al controllore l'indicazione
della velocit (uscita analogica);
2. si definiscono i parametri necessari alla regolazione del recuperatore di

calore rotativo, che nel nostro esempio supponiamo essere limitati a:
a) un setpoint sulla differenza tra temperatura di espulsione e
temperatura esterna;
b) la banda proporzionale oltre la quale il regolatore satura (velocit
uguale al 100%);

3. si crea il FUNCTION_BLOCK dedicato al controllo del recuperatore di calore,
che gestisce le seguenti modalit operative:
a) disabilitato: in questo caso la velocit del recuperatore rotativo nulla
l'uscita I_HeatRecoveryUnit posta a 0;
b) abilitato: la velocit del recuperatore rotativo soggetta a regolazione
proporzionale controllata dai parametri rC01 e rC02;
c) velocit fissa: la velocit del recuperatore rotativo fissata ad un livello
indicato da STRATEGY;
4. si crea un'istanza globale del FUNCTION_BLOCK;
5. si modifica il PROGRAM Strategy, inserendo - in ciascuna strategia - una

nuova rete FBD dedicata al controllo del recuperatore di calore.

5.9. Interfaccia Uomo-Macchina
La gestione dell'interfaccia uomo-macchina dipende in maniera sostanziale dallo
specifico target utilizzato.
5.9.1. FREE Smart

L'interfaccia uomo-macchina prevista nelle baseline per FREE Smart costituita dal
menu visualizzato sul display locale e da un menu per il terminale LCD, distinto dal
primo.
5.9.1.1. Menu locale

Il menu utente visualizzato sul display locale costruito automaticamente da FREE
Studio Application, a partire dalla definizione ad alto livello dei menu (si veda la Figura
14) e dei loro elementi (Figura 15) data dallo sviluppatore nella sezione Resources.
Figura 14: Struttura del menu per il display locale: dal menu principale possibile accedere al
menu set, per la modifica dei setpoint e la visualizzazione degli allarmi attivi, oppure al menu
Prg, che a sua volta permette l'accesso a diversi sotto-menu per la programmazione dei
parametri

Figura 15: Esempio di definizione di un menu parametri: ogni riga della tabella corrisponde ad
un elemento contenuto nel menu
Per modificare la definizione del menu locale sufficiente intervenire sulle strutture di
alto livello sopra indicate.
Il PROGRAM SmartHMI gestisce, in visualizzazione fondamentale, lo stato di accensione
dei LED e gli eventi di pressione prolungata tasti. Il PROGRAM si esaurisce con una
chiamata al blocco di libreria LocalMainView_t (si veda il paragrafo 6.4.1).
5.9.1.2. Menu terminale LCD

Il PROGRAM SKWHMI si occupa della definizione del menu utente per il terminale LCD.
L'albero del menu rappresentato da un analogo costrutto in linguaggio SFC (si veda la
Figura 16), dove ogni STEP rappresenta un sotto-menu ed ogni TRANSITION le possibili
transizioni tra di essi.
Figura 16: Struttura del menu per il terminale LCD: dal menu principale possibile accedere al menu
set, per la modifica dei setpoint e la visualizzazione degli allarmi attivi, oppure al menu Prg, che a sua
volta permette l'accesso a diversi sotto-menu per la programmazione dei parametri
Ogni transizione associata ad una variabile booleana che rappresenta l'abilitazione di

un singolo sotto-menu (si veda, ad esempio, la Figura 17): queste variabili sono
valorizzate nelle ACTION associate agli STEP dello schema e, in ogni istante, una e una
sola di esse deve valere TRUE.
Figura 17: la transizione nel menu set abilitata quando la variabile

enableSetMenu TRUE; la transizione nel menu Prg quando la
variabile enablePrgMenu TRUE
Le ACTION del PROGRAM SKWHMI definiscono i sotto-menu e i loro elementi,

appoggiandosi sui blocchi della libreria SmartHMI per la gestione della navigazione da
parte dell'utente (Figura 18).
Figura 18: due frammenti di Act_DayMenu, contenenti la definizione del menu Day e dei suoi 7
elementi, l'invocazione al blocco di libreria SKWRightDisplayMenu_t (variabile dayMenu) e la gestione
dei flag di abilitazione del menu stesso e del menu padre (menu Prg)
5.9.1.2.1. Aggiungere un elemento ad un menu

Una variazione frequente al menu per il terminale LCD incluso nelle baseline U.T.A.
l'aggiunta di un elemento ad un menu.
ESEMPIO 5.24
Riprendendo l'Esempio 5.23, si vuole inserire il parametro rC01 nel menu protetto
da password ThermoregulationMenu.
In questo caso le modifiche sono limitate alla ACTION che definisce il menu da
modificare. In particolare, si deve provvedere a:
modificare la definizione del menu, incrementandone il numero di elementi;
aggiungere la definizione del nuovo elemento.

ESEMPIO 5.25
Per raggiungere l'obiettivo fissato nell'Esempio 5.24, si pu procedere come
segue:
1. incrementare il valore assegnato a thermoregulationMenu.itemNumber;
2. inserire la definizione di rC01 nella posizione desiderata, specificandone

valore minimo, massimo, identificativo testuale e tipologia del dato da
visualizzare (DISPLAY_TEMPERATURE).

5.9.2. HMI
L'interfaccia uomo-macchina prevista nelle baseline per FREE Evolution costituita da
un'applicazione HMI sviluppata con FREE Studio User Interface.
Il menu composto dagli elementi seguenti:
una schermata iniziale di avvio (splash screen), che visualizza un'immagine per
alcuni secondi, prima di accedere alla pagina principale;
una pagina principale, che visualizza in forma grafica lo stato dell'applicazione

(stato ON/OFF, stato di attivazione della modalit ECO, modo di funzionamento
COOL/HEAT, ecc.);
un menu principale, accessibile dalla pagina principale per pressione prolungata

del tasto destro, che d a sua volta accesso ad un insieme di sotto-menu di

visualizzazione dello stato o di programmazione (impostazione ora e data,
setpoint, fasce orarie, allarmi, ecc.);
i menu secondari, accessibili a partire dal menu principale, suddivisi in menu di

stato e menu di programmazione.

Ogni singolo menu realizzato ricorrendo al costrutto set di FREE Studio User Interface:
per ogni menu viene definito un set di label descrittive e un set di valori.
Figura 19: Menu di programmazione delle fasce orarie. Il set Prg_TE_Labels raccoglie l'insieme delle
stringhe descrittive visualizzate nella colonna sinistra dell'interfaccia uomo-macchina; il set
Prg_TE_Values raccoglie i riferimenti ai parametri EEPROM di programmazione fasce orarie
I paragrafi seguenti presentano, con esempi concreti, alcune tra le pi frequenti
necessit di intervento sull'interfaccia uomo-macchina, in particolare quelle derivanti da
una modifica all'applicazione PLC.
Comunque, lo sviluppatore ha la massima libert di intervento, potendo sfruttare tutte le
potenzialit dello strumento per costruire un'interfaccia utente personalizzata. Si faccia
riferimento al manuale utente di User Interface per ulteriori dettagli.
5.9.2.1. Aggiungere un elemento ad un menu

Una variazione frequente al menu incluso nelle baseline U.T.A. l'aggiunta di un
elemento ad un menu.

ESEMPIO 5.26
In seguito ad una modifica all'applicazione PLC, che ha introdotto, in fase di
deumidifica, un controllo di non superamento di un limite inferiore di temperatura
(se la temperatura rilevata scende al di sotto di tale limite, il processo di
deumidificazione si arresta), si vuole inserire il parametro Hr15, che precisa tale
limite, nel menu Hr (parametri di regolazione umidit relativa).
Come gi discusso, un menu realizzato ricorrendo al costrutto set di User Interface:

per ogni menu viene definito un set di label descrittive e un set di valori; l'aggiunta di
un elemento al menu comporta dunque l'aggiunta di un elemento ad entrambi i set.
Non invece necessario intervenire sulla pagina che rappresenta il menu, gi
predisposta per la gestione di questo genere di cambiamenti.
ESEMPIO 5.27
Il menu Hr realizzato attraverso il set di label descrittive Prg_HR_Labels e il set
di valori Prg_HR_Values. Per soddisfare il requisito espresso nell'Esempio 5.33,
dunque necessario:
1. assicurarsi preventivamente di aver compilato, con Application,
l'applicazione PLC, dopo la modifica relativa all'introduzione del nuovo
parametro; aggiornare la definizione dei parametri PLC con User
Interface (comando Refresh parameters);
2. aggiungere un elemento nella tabella Resources > String table del progetto
User Interface, con l'identificativo testuale del nuovo parametro;
3. inserire un nuovo elemento nel set Prg_HR_Labels, che faccia riferimento

all'elemento della string table aggiunto al punto precedente;
4. inserire un nuovo elemento nel set Prg_HR_Values, che faccia riferimento
al parametro PLC aggiunto.
Non necessario modificare la pagina Prg_HR.

5.9.2.2. Aggiungere un menu
L'interfaccia utente di un'applicazione derivata dalle baseline U.T.A. pu richiedere
l'aggiunta di un intero menu.
ESEMPIO 5.28
In seguito all'introduzione, nell'applicazione PLC, della gestione di un recuperatore
di calore, si desidera creare un menu dedicato alla sua configurazione, contenente
un insieme di parametri protetti da password.
Per aggiungere un menu necessario:

definire un nuovo set di label descrittive per il nuovo menu;
definire un nuovo set di valori per il nuovo menu;
definire una nuova pagina per la visualizzazione degli elementi del menu e
collegarla al resto del menu.

ESEMPIO 5.29
Per soddisfare i requisiti espressi nell'Esempio 5.26, si pu procedere nel modo
seguente:
1. nella tabella Resources > Sets, si inserisce un nuovo set di tipo STRINGS e
gli si assegna, in armonia con quanto gi presente, il nome
Prg_RC_Labels;
2. nella stessa tabella, si inserisce un nuovo set di tipo VARIANT, con nome
Prg_RC_Values;
3. per ogni parametro costituente il menu, si inserisce un nuovo elemento nel

set Prg_RC_Labels e un nuovo elemento nel set Prg_RC_Values;
4. si inserisce una nuova pagina e gli si assegna il nome Prg_RC; per operare
nel modo pi efficiente possibile, la nuova pagina viene creata per copia di
un altro menu di programmazione, ad esempio Prg_HR, cos da trovare gi
inseriti tutti gli elementi necessari alla visualizzazione del menu;
5. nella tabella Resources > String table, inserire un nuovo elemento con la
descrizione testuale del menu, da visualizzare nella barra del titolo
dell'applicazione;
6. nelle Properties della nuova pagina, modificare la propriet Caption, cos
che faccia riferimento alla stringa inserita al punto precedente;
7. nelle Properties delle tre etichette parametro presenti nella pagina,

sostituire i riferimenti al set sorgente presenti nella propriet Text, cos che
facciano riferimento al set Prg_RC_Labels;
8. nelle Properties dei tre controlli di modifica del valore parametro presenti
nella pagina, sostituire i riferimenti al set sorgente presenti nella propriet
Variable, cos che facciano riferimento al set Prg_RC_Values;
9. nella pagina Prg, inserire un nuovo bottone per il collegamento al menu.
5.9.2.3. Modificare la modalit di navigazione nei menu
La navigazione tra i menu e all'interno dei menu segue delle semplici regole, codificate
nella finestra Action > Global action di User Interface:
il passaggio all'elemento successivo (sia esso il prossimo menu, nelle pagine di
pi alto livello, oppure il prossimo elemento del menu) avviene con la pressione
del tasto DOWN oppure RIGHT;
il passaggio all'elemento precedente avviene con la pressione del tasto UP
oppure LEFT;
la funzione di chiusura pagina, con ritorno alla precedente, avviene con la
pressione prolungata del tasto LEFT;
la funzione di conferma operazione (sia essa l'ingresso in modifica, la conferma
della modifica stessa o l'ingresso in un sotto-menu) avviene con la pressione del
tasto OK.
Si noti che alcune pagine modificano e/o estendono quanto descritto sopra, con quanto
codificato nella finestra Action > Local action. Si consideri, ad esempio, la pagina Main: essa
cancella la funzione di chiusura pagina (poich non si vuole che dalla pagina principale
si possa tornare allo splash screen) e aggiunge la possibilit di aprire il menu principale
attraverso la pressione prolungata del tasto RIGHT.
Per modificare la modalit di navigazione nei menu necessario dunque intervenire su

quanto definito nella finestra Action.

ESEMPIO 5.30
Si supponga di voler utilizzare per la navigazione soltanto i tasti UP e DOWN, per
la chiusura della pagina la pressione semplice del tasto LEFT e il tasto RIGHT
esclusivamente per l'accesso al menu principale dalla pagina principale.
I passi da seguire sono:
1. eliminare l'azione globale associata alla pressione prolungata del tasto
LEFT;
2. eliminare l'azione globale associata alla pressione del tasto RIGHT;
3. modificare l'azione globale associata alla pressione del tasto LEFT affinch
provochi la chiusura della pagina corrente;
4. modificare in LEFT l'evento di pressione tasto associato alla chiamata dello

script NullScript tra le azioni locali alla pagina Main;
5. modificare in RIGHT l'evento di pressione tasto associato all'apertura della
pagina Settings (menu principale) tra le azioni locali alla pagina Main.
5.9.2.4. Associare un comportamento custom ad un evento di pressione tasto

Pu essere necessario arricchire ulteriormente l'interfaccia di navigazione menu con
funzionalit custom non previste nell'insieme di azioni predefinite associabili agli eventi
di pressione tasto. In questo caso d'obbligo il ricorso ad uno script, come discusso
nell'esempio seguente.

ESEMPIO 5.31
Si vuole dare la possibilit, nel menu di visualizzazione dello stato degli allarmi, di
inviare una richiesta di reset allarmi con la pressione prolungata del tasto RIGHT,
oltre che con il bottone dedicato.
Si pu utilizzare la procedura seguente:
1. nella pagina Alarms, nella finestra Actions > Local actions, si inserisce una
nuova azione associata alla pressione prolungata del tasto RIGHT, che
invoca lo script ResetAlarms (gi presente, poich associato al bottone di
reset allarmi).
5.9.2.5. Differenziare la visualizzazione in base al valore di pi parametri PLC

Nella costruzione dell'interfaccia utente, pu essere necessario visualizzare un dato
calcolato a partire (o che comunque dipende) dal valore di pi parametri
dell'applicazione PLC.
In questo caso, non possibile assegnare direttamente, al controllo componente
l'interfaccia utente, il parametro PLC corrispondente; al contrario, necessario utilizzare
uno script per la lettura di tutti i parametri rilevanti per il calcolo e per il calcolo stesso.

ESEMPIO 5.32
La pagina Main visualizza i setpoint correnti di temperatura, scelto tra i parametri
PLC T_CoolingSetpoint e T_HeatingSetpoint, e umidit relativa, scelto tra i
parametri PLC RH_DehumidificationSetpoint e RH_HumidificationSetpoint, a
seconda del valore del modo COOL/HEAT corrente.
Per fare ci, lo script locale LocalOnTimerScript, eseguito periodicamente poich
associato all'evento OnTimer della pagina Main:
1. legge il parametro PLC che corrisponde al modo COOL/HEAT corrente;
2. in base al valore del parametro PLC appena letto, legge nelle variabili locali
temperatureSetpoint e humiditySetpoint, i parametri PLC
T_CoolingSetpoint e RH_DehumidificationSetpoint oppure i parametri
PLC T_HeatingSetpoint e RH_HumidificationSetpoint;
3. i controlli grafici presenti nella pagina Main fanno infine riferimento alle
variabili locali temperatureSetpoint e humiditySetpoint.

5.9.2.6. Modificare lo splash screen
Lo sviluppatore che deriva un'applicazione a partire dalla baseline U.T.A. vuole
tipicamente personalizzare lo splash screen con un'immagine significativa per il proprio
prodotto.
ESEMPIO 5.33
Si vuole inserire nello splash screen il logo della famiglia prodotti a cui appartiene
l'U.T.A. da programmare. Per ottenere questo risultato sufficiente:
1. in Resources > Bitmaps, importare una versione in bianco e nero del logo
come nuova bitmap;
2. nella finestra Properties della pagina Splash, modificare la propriet Bitmap
perch faccia riferimento alla bitmap appena importata.

6. Librerie
Le baseline per U.T.A. fanno uso di diverse librerie di blocchi (FUNCTION e
FUNCTION_BLOCK). Queste stesse librerie possono essere utilizzate efficacemente
nello sviluppo di applicazioni derivate dalle baseline.
Questo capitolo descrive in dettaglio i blocchi contenuti nelle diverse librerie.
6.1. Actuators
La libreria Actuators raccoglie l'insieme di logiche di attuazione pi frequentemente
utilizzate in applicazioni HVAC.
6.1.1. DelayedStarter_t
Tipologia FUNCTION_BLOCK
Descrizione Attuatore di un'uscita digitale che aggiunge un ritardo di avvio e un
ritardo di arresto
Ingressi 1) in : BOOL
Valore da attuare all'uscita digitale prima dell'applicazione dei ritardi.
2) delayOnStart : UDINT
Ritardo di avvio, espresso in millisecondi [ms].
3) delayOnStop : UDINT
Ritardo di arresto, espresso in millisecondi [ms].
4) delayBetween : UDINT
Tempo minimo di attesa tra avvii successivi, espresso in millisecondi
[ms].
Uscite 1) out : BOOL
Valore da attuare all'uscita digitale dopo l'applicazione dei ritardi.
6.1.2. StarDeltaStarter_t
Descrizione Avviamento stella-triangolo.
Ingressi 1) in : BOOL
Valore da attuare all'uscita digitale.
2) lineStarDelay : UDINT
Ritardo linea-stella, espresso in millisecondi [ms].
3) starDuration : UDINT
Durata stella, espresso in millisecondi [ms].
4) starDeltaDelay : UDINT
Ritardo stella-triangolo, espresso in millisecondi [ms].
Uscite 1) line : BOOL
Contattore di linea.
1) star : BOOL

Contattore di stella.
1) delta : BOOL
Contattore di triangolo.
6.2. Alarms
La libreria Alarms raccoglie l'insieme di logiche di gestione degli allarmi pi
frequentemente utilizzate nelle applicazioni.
6.2.1. AutoRearmAlarm_t
Descrizione Allarme a riarmo automatico
Ingressi 1) enable : BOOL
Abilita il test della condizione di allarme. Se FALSE, l'uscita del blocco
viene impostata al valore 0 (allarme non attivo).
2) condition : BOOL
Condizione di allarme, attiva quando condition vale TRUE.
Uscite 1) alarm : USINT
Stato dell'allarme: 0 = non attivo, 1 = attivo
6.2.2. DelayAutoRearmAlarm_t
Descrizione Allarme ad attivazione ritardata e riarmo automatico
2) condition : BOOL
3) delay : UDINT
Ritardo di attivazione dell'allarme, espresso in millisecondi.
6.2.3. DelayManualRearmAlarm_t
Descrizione Allarme ad attivazione ritardata e riarmo manuale
2) reset : BOOL
Comando di reset allarmi. Se TRUE e l'allarme nello stato di attesa di

reset manuale, questo transita nello stato di non attivazione (l'uscita
del blocco 0).
3) condition : BOOL
4) delay : UDINT
Ritardo di attivazione dell'allarme, espresso in millisecondi.
Stato dell'allarme: 0 = non attivo, 1 = attivo, 2 = in attesa di reset
manuale
6.2.4. ManualRearmAlarm_t
Descrizione Allarme a riarmo manuale
2) reset : BOOL
Comando di reset allarmi. Se TRUE e l'allarme nello stato di attesa di
reset manuale, questo transita nello stato di non attivazione (l'uscita
del blocco 0).
3) condition : BOOL
Stato dell'allarme: 0 = non attivo, 1 = attivo, 2 = in attesa di reset
manuale
6.2.5. ProbeError_t
Descrizione Errore sonda
2) probe : INT
Valore letto dalla sonda il cui funzionamento/la cui presenza deve
essere verificata.
6.3. Regulators
La libreria Regulators raccoglie l'insieme di logiche di regolazione pi frequentemente
utilizzate in applicazioni HVAC.

6.3.1. Hysteresis_t
Descrizione Isteresi
Ingressi 1) clockwise : BOOL
Verso dell'isteresi: se FALSE, il senso antiorario; se TRUE, orario.
2) in : INT
Valore da confrontare con le soglie date dai parametri lo e hi.
3) lo : INT
Valore soglia inferiore dell'isteresi.
4) hi : INT
Valore soglia superiore dell'isteresi.
Stato dell'isteresi.
6.3.2. OnOffRegulator_t
Descrizione Regolatore ON/OFF
Ingressi 1) hcMode : USINT
Verso del regolatore: se COOL, l'azione di controllo attiva finch
feedback superiore a setpoint; se HEAT, finch feedback
inferiore a setpoint.
2) feedback : INT
Misura della grandezza fisica oggetto dell'azione di controllo letta
dalla sonda di regolazione e utilizzata come feedback per il confronto
con setpoint.
3) setpoint : INT
Valore desiderato della grandezza fisica oggetto dell'azione di
controllo.
4) diff : INT
Differenziale da aggiungere/sottrarre a setpoint per il cambio stato da
OFF a ON: se hcMode vale COOL, l'azione di controllo si attiva quando
feedback diventa maggiore o uguale a setpoint + diff; se
hcMode vale HEAT, quando feedback diventa minore o uguale a
setpoint - diff.
Stato ON/OFF dell'azione di controllo.
6.3.3. ProportionalRegulator_t
Descrizione Regolatore proporzionale

2) feedback : INT
con setpoint.
3) setpoint : INT
controllo.
4) band : INT
Dimensione della banda proporzionale: se hcMode vale COOL, il
regolatore satura (azione di controllo uguale al 100%) quando
feedback diventa maggiore o uguale a setpoint + band; se
hcMode vale HEAT, quando feedback diventa minore o uguale a
setpoint - band.
Uscite 1) out : INT
Livello dell'azione di controllo, in parti per migliaio [].
6.3.4. ThreeStepsRegulator_t
Descrizione Regolatore a tre gradini
2) feedback : INT
con setpoint.
3) setpoint : INT
controllo.
4) diff : INT
Differenziale totale da aggiungere/sottrarre a setpoint per l'attivazione
dei tre gradini di potenza: se hcMode vale COOL, il primo gradino si
attiva quando feedback diventa maggiore o uguale a setpoint +
diff/3, il secondo quando feedback diventa maggiore o uguale a
setpoint + 2diff/3, il terzo quando feedback diventa
maggiore o uguale a setpoint + diff; se hcMode vale HEAT, il
primo gradino si attiva quando feedback diventa minore o uguale a
setpoint - diff/3, il secondo quando feedback diventa minore

o uguale a setpoint - 2diff/3, il terzo quando feedback
diventa minore o uguale a setpoint - diff;
Uscite 1) step1 : BOOL
Stato ON/OFF del primo gradino di potenza.
2) step2 : BOOL
Stato ON/OFF del secondo gradino di potenza.
3) step3 : BOOL
Stato ON/OFF del terzo gradino di potenza.
6.3.5. TwoStepsRegulator_t
Descrizione Regolatore a due gradini
2) feedback : INT
con setpoint.
3) setpoint : INT
controllo.
4) diff : INT
Differenziale totale da aggiungere/sottrarre a setpoint per l'attivazione
dei due gradini di potenza: se hcMode vale COOL, il primo gradino si
attiva quando feedback diventa maggiore o uguale a setpoint +
diff/2, il secondo quando feedback diventa maggiore o uguale a
setpoint + diff; se hcMode vale HEAT, il primo gradino si attiva
quando feedback diventa minore o uguale a setpoint - diff/2,
il secondo quando feedback diventa minore o uguale a setpoint -
diff;
Uscite 1) step1 : BOOL
Stato ON/OFF del primo gradino di potenza.
2) step2 : BOOL
Stato ON/OFF del secondo gradino di potenza.
6.4. SmartHMI
La libreria SmartHMI raccoglie blocchi per la costruzione di interfacce utente per Smart
e I relativi terminali (SKW, SKP).
6.4.1. LocalMainView_t
Descrizione Blocco per la gestione dei LED e la rilevazione della pressione
prolungata dei tasti (funzione di tasto "caldo") del display locale
Smart, in visualizzazione fondamentale.
Ingressi 1) state : USINT
Stato ON/OFF dell'unit, utilizzato da LocalMainView_t per la
gestione del LED stand-by e la visualizzazione del testo 'OFF' a
display.
2) remoteState : BOOL
Se TRUE, lo stato ON/OFF determinato da un'impostazione remota e
la sua visualizzazione (accensione del LED stand-by o visualizzazione
del testo 'OFF' a display) intermittente.
3) mode : USINT
Modo di funzionamento COOL/HEAT, utilizzato da LocalMainView_t
per la gestione dei LED corrispondenti.
4) remoteMode : BOOL
Se TRUE, il modo di funzionamento COOL/HEAT determinato da
un'impostazione remota e la sua visualizzazione (accensione dei LED
COOL o HEAT) intermittente.
5) economy : BOOL
Attivazione della modalit Economy, utilizzata da LocalMainView_t
per la gestione del LED corrispondente.
6) timeIsEnabled : BOOL
Attivazione della gestione a fasce orarie, utilizzata da
LocalMainView_t per la gestione del LED corrispondente.
7) resource1 : BOOL
Abilitazione della risorsa no. 1 (dipendente dalla applicazione),
utilizzata da LocalMainView_t per la gestione del LED
corrispondente.
8) resource2 : BOOL
corrispondente.
9) resource3 : BOOL
corrispondente.
10) resource4 : BOOL
corrispondente.
corrispondente.

corrispondente.
corrispondente.
Uscite 1) hotKeyUP : BOOL
Pressione prolungata del tasto UP del display locale rilevata.
2) hotKeyDW : BOOL
Pressione prolungata del tasto DW del display locale rilevata.
3) hotKeyESC : BOOL
Pressione prolungata del tasto ESC del display locale rilevata.
4) hotKeySET : BOOL
Pressione prolungata del tasto SET del display locale rilevata.
6.4.2. SKWAlarmMenu_t
Descrizione Blocco per la navigazione da tastiera remota di un menu allarmi
Ingressi 1) totalAlarms : USINT
Numero totale degli allarmi visualizzabili nel menu.
2) currentAlarmValue : USINT
Valore dell'allarme corrente (cio, dell'allarme in posizione
currentAlarm): 0 = non attivo, 1 = attivo, 2 = in attesa di reset
manuale.
3) currentAlarmLabel : STRING
Identificativo testuale dell'allarme corrente (cio, dell'allarme in
posizione currentAlarm).
Variabili 1) currentAlarm : USINT
INOUT Allarme corrente, espresso come posizione all'interno del menu,
derivante dalle operazioni di navigazione eseguite dall'utente.
2) enable : BOOL
Abilitazione del menu: pu essere disattivato in seguito ad un
comando utente o per timeout.
Uscite 1) back : BOOL
Comando utente di ritorno al livello superiore del menu.
6.4.3. SKWFolderMenu_t
Descrizione Blocco per la navigazione da tastiera remota di un menu l'accesso ad
una lista di sotto-menu

Ingressi 1) folderNumber : USINT
Numero totale dei sotto-menu visualizzabili nel menu.
2) currentFolderLabel : STRING
Identificativo testuale del sotto-menu corrente (cio, del sotto-menu in
posizione currentFolder).
Variabili 1) currentFolder : USINT
INOUT Sotto-menu corrente, espresso come posizione all'interno del menu,
2) enable : BOOL
Uscite 1) back : BOOL
2) enableCurrentFolder : BOOL
Comando utente di ingresso nel sotto-menu corrente (cio, del sotto-
menu in posizione currentFolder).
6.4.4. SKWLeftDisplayMenu_t
Descrizione Blocco per la navigazione da tastiera remota di un menu di elementi,
con visualizzazione del loro valore sul display sinistro
Ingressi 1) itemNumber : USINT
Numero totale degli elementi visualizzabili nel menu.
2) currentItemValue : INT
Identificativo testuale dell'elemento corrente (cio, dell'elemento in
posizione currentItem).
3) currentItemMin : INT
Valore minimo dell'elemento corrente (cio, dell'elemento in
4) currentItemMax : INT
Valore massimo dell'elemento corrente (cio, dell'elemento in
5) currentItemLabel : STRING
6) currentItemDisplayType : USINT
Tipologia del valore dell'elemento corrente (cio, dell'elemento in
posizione currentItem), espresso con le costanti
DISPLAY_TEMPERATURE, DISPLAY_PRESSURE_ONE_DEC, ...
7) subFolder : BOOL
Se TRUE, il menu consente l'accesso anche a un sotto-menu (non
incluso nel conteggio itemNumber).
8) subFolderName : STRING

Identificativo testuale del sotto-menu.
Variabili 1) currentItem : USINT
INOUT Elemento corrente, espresso come posizione all'interno del menu,
2) enable : BOOL
Uscite 1) enableSubFolder : BOOL
Comando utente di ingresso nel sotto-menu.
2) back : BOOL
3) updateCurrentItemValue : BOOL
Comando utente di modifica del valore dell'elemento corrente (cio,
dell'elemento in posizione currentItem).
4) localValue : INT
Valore da assegnare all'elemento corrente (cio, dell'elemento in
posizione currentItem) quando updateCurrentItemValue vale
TRUE.
6.4.5. SKWMainView_t
Descrizione Blocco per la gestione dei LED e la rilevazione della pressione
prolungata dei tasti (funzione di tasto "caldo") del display locale
Smart, in visualizzazione fondamentale.
Ingressi 1) state : USINT
Stato ON/OFF dell'unit, utilizzato da SKWMainView_t per la gestione
del LED stand-by e la visualizzazione del testo 'OFF' a display.
2) stateSource : USINT
Sorgente dello stato ON/OFF: 0 = locale, 1 = remota, 2 = gestione a
fasce orarie.
3) mode : USINT
Modo di funzionamento COOL/HEAT/AUTO, utilizzato da
SKWMainView_t per la gestione dei LED corrispondenti.
4) modeSource : USINT
Sorgente del modo di funzionamento COOL/HEAT/AUTO: 0 = locale,
1 = remota, 2 = auto.
5) modeSelection : USINT
Modi di funzionamento COOL/HEAT/AUTO selezionabili (per la
modifica da parte dell'utente con tastiera remota): 0 = solo COOL, 1 =
solo HEAT, 2 = COOL e HEAT, 3 = COOL, HEAT e AUTO, 4 =
impostazione remota.
6) rightValueType : USINT
Tipologia del valore da mostrare sul display destro delil terminale

LCD, espresso con le costanti DISPLAY_TEMPERATURE,
DISPLAY_PRESSURE_ONE_DEC, ...
7) rightValue : INT
Valore da mostrare sul display destro delil terminale LCD.
8) leftValueType : USINT
Tipologia del valore da mostrare sul display sinistro delil terminale
LCD, espresso con le costanti DISPLAY_TEMPERATURE,
DISPLAY_PRESSURE_ONE_DEC, ...
9) leftValue : INT
Valore da mostrare sul display sinistro delil terminale LCD.
10) leftText : STRING
Testo da visualizzare sul display sinistro delil terminale LCD, se
leftValueType vale TEXT.
11) generalAlarm : BOOL
Se TRUE, l'unit si trova in uno stato di OFF da allarme e
generalAlarmMsg viene visualizzato a display.
12) generalAlarmMsg : STRING
Messaggio da visualizzare a display quando generalAlarm TRUE.
13) alarm : USINT
Stato degli allarmi, SKWMainView_t per la gestione del LED
corrispondente. Se 0, non c' nessun allarme attivo; se 1; almeno un
allarme attivo; se 2, tutti gli allarmi attivi sono in attesa di reset
manuale.
14) economy : BOOL
Attivazione della modalit Economy, utilizzata da SKWMainView_t per
la gestione del LED corrispondente.
15) currentTimeProfile : USINT
Profilo corrente di gestione a fasce orarie.
16) fanSpeedControl : BOOL
Se TRUE, abilitata la gestione della velocit ventole da tastiera LCD.
17) fanSpeed : USINT
Velocit ventole, se fanSpeedControl TRUE.
Variabili 1) enable : BOOL
INOUT Abilitazione del menu: pu essere disattivato in seguito ad un
comando utente (di ingresso in un sotto-menu).
Uscite 1) enableSetMenu : BOOL
Comando utente di ingresso nel menu set.
2) enablePrgMenu : BOOL
Comando utente di ingresso nel menu Prg.
3) timeout : BOOL
Rilevato time-out in visualizzazione fondamentale.
4) changeStateRequest : BOOL
Comando utente di cambio stato ON/OFF dell'unit.
5) newState : USINT

Nuovo valore dello stato ON/OFF dell'unit richiesto dall'utente, se
changeStateRequest TRUE.
6) changeModeRequest : BOOL
Comando utente di cambio modo di funzionamento
COOL/HEAT/AUTO.
7) newMode : USINT
Nuovo valore del modo di funzionamento COOL/HEAT/AUTO
richiesto dall'utente, se changeModeRequest TRUE.
8) changeFanSpeedRequest : BOOL
Comando utente di cambio velocit ventole.
9) newFanSpeed : USINT
Nuova velocit ventole richiesta dall'utente, se
changeFanSpeedRequest TRUE.
10) toggleTimeRequest : BOOL
Comando utente di abilitazione/disabilitazione della gestione a fasce
orarie.
6.4.6. SKWPswProtection_t
Descrizione Blocco per la protezione con password dell'accesso ad un menu per
tastiera remota
Ingressi 1) timeout : BOOL
Se TRUE, i diritti di accesso vengono dimenticati (per time-out) e per
l'accesso al menu richiesto un nuovo inserimento della password.
Variabili 1) enable : BOOL
INOUT Abilitazione del menu: pu essere disattivato in seguito ad un
Uscite 1) enableMenu : BOOL
Diritti di accesso al menu acquisti (l'utente ha inserito la password
correttamente).
2) back : BOOL
6.4.7. SKWRightDisplayMenu_t
Descrizione Blocco per la navigazione da tastiera remota di un menu di elementi,
con visualizzazione del loro valore sul display destro
Ingressi 1) itemNumber : USINT
Numero totale degli elementi visualizzabili nel menu.
2) currentItemValue : INT

3) currentItemMin : INT
Valore minimo dell'elemento corrente (cio, dell'elemento in
4) currentItemMax : INT
Valore massimo dell'elemento corrente (cio, dell'elemento in
5) currentItemLabel : STRING
6) currentItemDisplayType : USINT
Tipologia del valore dell'elemento corrente (cio, dell'elemento in
posizione currentItem), espresso con le costanti
DISPLAY_TEMPERATURE, DISPLAY_PRESSURE_ONE_DEC, ...
7) subFolder : BOOL
Se TRUE, il menu consente l'accesso anche a un sotto-menu (non
incluso nel conteggio itemNumber).
8) subFolderName : STRING
Identificativo testuale del sotto-menu.
Variabili 1) currentItem : USINT
INOUT Elemento corrente, espresso come posizione all'interno del menu,
2) enable : BOOL
Uscite 1) enableSubFolder : BOOL
Comando utente di ingresso nel sotto-menu.
2) back : BOOL
3) updateCurrentItemValue : BOOL
Comando utente di modifica del valore dell'elemento corrente (cio,
dell'elemento in posizione currentItem).
4) localValue : INT
Valore da assegnare all'elemento corrente (cio, dell'elemento in
posizione currentItem) quando updateCurrentItemValue vale
TRUE.
6.5. Thermodynamics
La libreria Thermodynamics raccoglie funzioni di calcolo di grandezze fisiche importanti
nello sviluppo di applicazioni HVAC.
6.5.1. CalcEnthalpy
Tipologia FUNCTION
Descrizione Calcolo approssimato dell'entalpia specifica

Ingressi 1) temperature : INT
Temperatura, in decimi di grado Celsius [C 10-1].
2) humidity : INT
Percentuale di umidit relativa, in parti per migliaio [].
3) altitude : INT
Altitudine sul livello del mare, in ettometri [m 102]
Uscite Entalpia specifica [(kJ/kg) 10-1].
6.6. Utils
La libreria Utils raccoglie generici blocchi di utilit, che non rientrano logicamente in
alcuna delle librerie precedenti.
6.6.1. DynamicSetpoint_t
Descrizione Blocco per la gestione di un differenziale dinamico da applicare ad un
setpoint
Abilitazione del differenziale dinamico. Se FALSE, l'uscita differential
vale 0.
2) hcMode : USINT
Verso del regolatore: se COOL, il differenziale dinamico maggiore di 0 quando
feedback superiore a setpoint; se HEAT, quando feedback inferiore
a setpoint.
3) maxDifferential : INT
Valore massimo del differenziale dinamico (cio, valore massimo dell'uscita
differential).
4) feedback : INT
Misura della grandezza fisica alla quale legato il valore del differenziale
dinamico, utilizzata come feedback per il confronto con setpoint.
5) setpoint : INT
Valore della grandezza fisica alla quale legato il valore del differenziale
dinamico, per il quale il differenziale si annulla.
6) band : INT
Banda proporzionale di incremento del valore del differenziale dinamico fino al
suo massimo, maxDifferential.
Uscite 1) differential : INT
Differenziale dinamico da applicare.
6.6.2. PercentageReduction
Tipologia FUNCTION
Descrizione Riduzione percentuale di un valore espresso in parti per migliaio []
Ingressi 1) in : INT

Valore da ridurre, espresso in parti per migliaio [].
2) reduction : INT
Valore della riduzione percentuale da effettuare, espressa in parti per
migliaio [].
Uscite Valore risultante dalla riduzione percentuale
6.6.3. TimeFrameManager_t
Descrizione Gestione a fasce orarie
Abilitazione della gestione a fasce orarie.
Uscite 1) mode : USINT
Modalit (COMFORT, ECO oppure OFF) corrispondente alla fascia
oraria corrente.

APPENDICE
APPENDICE - Baseline Unit Trattamento Aria - Manuale per lo sviluppatore I

A1. Schema a blocchi
Lo schema a blocchi di Figura 20 rappresenta la struttura software di alto livello di una
baseline. Si veda il medesimo schema di architettura Figura 1
Figura 20: Struttura software di alto livello

Nei paragrafi seguenti si descrivono in dettaglio i singoli elementi dello schema e le loro
connessioni.
A1.1. INPUT
A1.1.1. Responsabilit
Il blocco INPUT traduce gli ingressi fisici in ingressi logici, utilizzati dall'applicazione. In
particolare, si occupa di:
mappare gli ingressi fisici sui corrispondenti ingressi logici (ossia, INPUT
determina quali DI o AI corrispondono a quali nomi simbolici utilizzati
nell'applicazione);
convertire il valore fisico degli ingressi nel valore logico utilizzato all'interno
dell'applicazione.
II APPENDICE - Baseline Unit Trattamento Aria - Manuale per lo sviluppatore

A1.1.2. Collaborazioni
Gli ingressi fisici letti da INPUT sono esterni all'architettura dell'applicazione.
Gli ingressi logici prodotti da INPUT sono utilizzati da:
GOAL, per quanto riguarda l'impostazione remota del modo di funzionamento e
l'attivazione del modo Economy;
DIAGNOSTICS, per quanto riguarda gli ingressi digitali diagnostici (protezioni
termiche, flussostati, pressostati, ecc...) e la diagnostica analogica (errore sonda,
alta/bassa pressione, ecc...);
STRATEGY e REGULATORS, per quanto riguarda i feedback dei regolatori.
A1.2.PARAMETERS
Il blocco PARAMETERS rende disponibile all'applicazione i parametri di configurazione
forniti da USER.
Le uscite di PARAMETERS sono utilizzate da:
GOAL (setpoint, fasce orarie, ecc...);
DIAGNOSTICS (configurazione allarmi);
REGULATORS (configurazione regolatori);
ACTUATORS (configurazione attuatori).
A1.3. GOAL
Il blocco GOAL determina quali sono gli obiettivi che il controllo dell'unit deve
perseguire.
In particolare, i dati risultanti dal blocco GOAL sono:
lo stato ON/OFF dell'unit;
il modo COOL/HEAT (estate/inverno) di funzionamento dell'unit;
lo stato di attivazione di modalit di risparmio energetico (modalit ECO);
i setpoint da inseguire;
le misure (feedback) da utilizzare nella regolazione, derivanti dalla scelta delle
sonde di regolazione.
Il blocco GOAL necessario per sintetizzare questi dati a partire dalle diverse possibili
sorgenti, che includono parametri e ingressi digitali e analogici.
Il blocco GOAL non si occupa del se e del come possano essere realizzati questi
obiettivi, lasciando ai blocchi che seguono questo compito.
APPENDICE - Baseline Unit Trattamento Aria - Manuale per lo sviluppatore III

Per raggiungere questo scopo, GOAL fa uso di:
impostazione locale (da PARAMETERS) e remota (da INPUT) dello stato ON/OFF
e del modo di funzionamento richiesto;
setpoint (da PARAMETERS);
fasce orarie e loro attivazione (da PARAMETERS);
attivazione (da INPUT) e impostazioni (da PARAMETERS) della modalit Economy;
ingresso setpoint dinamico (da INPUT) e sue impostazioni (da PARAMETERS);
ingresso cambio modo automatico (da INPUT) e sue impostazioni (da
PARAMETERS);
parametri di selezione della sonda di regolazione (da PARAMETERS).
Il risultato del calcolo di GOAL viene propagato verso altri elementi dell'architettura, in
particolare verso:
DIAGNOSTICS (stato ON/OFF dell'unit);
STRATEGY (stato ON/OFF dell'unit, tipo di richiesta e setpoint da inseguire,
sonde di regolazione);
HMI (stato ON/OFF dell'unit e tipo di richiesta).
Quanto espresso schematizzato in Figura 21.
Figura 21: Relazioni tra GOAL e gli altri blocchi
A1.4. DIAGNOSTICS
IV APPENDICE - Baseline Unit Trattamento Aria - Manuale per lo sviluppatore

Il blocco DIAGNOSTICS valuta la presenza di condizioni di anomalia nell'unit e gestisce
l'attivazione e la disattivazione (riarmo) degli allarmi.
DIAGNOSTICS fa uso di:
stato ON/OFF dell'unit (da GOAL);
ingressi digitali diagnostici (da INPUT) per la rilevazione di condizioni di anomalia
nell'unit (ad esempio, una protezione termica);
ingressi analogici (da INPUT) per la diagnostica analogica (ad esempio, per il
rilevamento di una sonda assente o guasta);
configurazione delle logiche di attivazione e riarmo degli allarmi (da
PARAMETERS) (ad esempio, un ritardo);
comando utente di riarmo manuale degli allarmi (da HMI).
Lo stato (attivo oppure no) degli allarmi viene trasmesso da DIAGNOSTICS a:
HMI, per la segnalazione degli allarmi attivi e della possibilit di riarmarli;
STRATEGY, per l'esecuzione di procedure eccezionali di gestione anomalie.
Lo schema di Figura 22 riassume le collaborazioni di DIAGNOSTICS.
Figura 22: Relazioni tra DIAGNOSTICS e gli altri blocchi
APPENDICE - Baseline Unit Trattamento Aria - Manuale per lo sviluppatore V

A1.5. STRATEGY
Il blocco STRATEGY determina la strategia da utilizzare per raggiungere l'obiettivo del
controllo. Nel dettaglio, questo si traduce in:
valutare se esistono richieste da soddisfare;
dare una priorit alle richieste pendenti;
scegliere tra le diverse strategie possibili quella da utilizzare per soddisfare la
richiesta;
gestire la richiesta, in base alla strategia scelta.
VI APPENDICE - Baseline Unit Trattamento Aria - Manuale per lo sviluppatore

STRATEGY riceve come input le informazioni seguenti:
lo stato ON/OFF dell'unit, le richieste utente e i relativi setpoint (da GOAL);
informazioni diagnostiche che richiedono una procedura di gestione
dell'anomalia centralizzata (da DIAGNOSTICS);
lo stato di tutti i regolatori (da REGULATORS);
lo stato degli attuatori di interesse per la strategia (da ACTUATORS).
La strategia adottata di traduce in comandi verso REGULATORS/ACTUATORS.
Quanto espresso schematizzato in Figura 23.
Figura 23: Relazione tra STRATEGY e gli altri blocchi
APPENDICE - Baseline Unit Trattamento Aria - Manuale per lo sviluppatore VII

A1.6.REGULATORS e ACTUATORS
I valori assunti dalle uscite fisiche del controllore sono determinati dall'insieme di
blocchi REGULATORS e ACTUATORS, che raccolgono le logiche di regolazione e di
attuazione delle uscite, rispettivamente.
I blocchi REGULATORS e ACTUATORS svolgono collettivamente il compito di esaudire
le richieste che il blocco STRATEGY esprime in termini di setpoint o di valori percentuali.
REGULATORS riceve in ingresso:
i setpoint dei regolatori (da STRATEGY);
i feedback per la regolazione (da INPUT) (ad esempio, sonde di temperatura,
pressione, ecc...);
eventuali configurazioni delle logiche di regolazione delegate a USER (da
PARAMETERS);
dati di controllo - comandi di attivazione, by-pass, ecc... (da STRATEGY).
Le uscite di REGULATORS sono usate da:
ACTUATORS, come valore da attuare sulle uscite dell'unit.
ACTUATORS riceve in ingresso:

eventuali configurazioni delle logiche di attuazione delegate a USER (da
PARAMETERS);
i valori delle azioni di controllo da attuare (da REGULATORS).
Le uscite di ACTUATORS sono usate da:
STRATEGY, al fine di modificare la strategia adottata in base alla stato degli
attuatori;
OUTPUT, per l'attuazione fisica.
Quanto espresso viene schematizzato in Figura 24.
VIII APPENDICE - Baseline Unit Trattamento Aria - Manuale per lo sviluppatore

Figura 24: Relazioni tra REGULATORS, ACTUATORS e gli altri blocchi
A1.7. OUTPUT
Il blocco OUTPUT attua le uscite logiche sulle uscite fisiche, fornendo in particolare:
la mappatura tra uscite logiche e fisiche (a quali DO o AO corrispondono le uscite
logiche);
conversione del valore logico utilizzato all'interno dell'applicazione nel
corrispondente valore fisico.
Le uscite logiche utilizzate da OUTPUT sono calcolate da ACTUATORS.
Le uscite fisiche prodotte da OUTPUT sono esterne al sistema.
APPENDICE - Baseline Unit Trattamento Aria - Manuale per lo sviluppatore IX

A1.8. HMI
Il blocco HMI gestisce l'interfaccia utente dell'applicazione, in particolare per quanto
riguarda:
la segnalazione dello stato ON/OFF dell'unit;
la modalit di funzionamento (HEAT, COOL, ecc...);
la segnalazione delle utenze attive;
il menu applicativo;
la gestione dei tasti.
HMI raccoglie i seguenti dati da visualizzare:
stato ON/OFF dell'unit (da GOAL);
modalit di funzionamento (da GOAL);
l'insieme delle utenze attive (da OUTPUT).
I dati sulle attivit dell'utente gestiti da HMI sono usati da:
1. DIAGNOSTICS, per quanto riguarda il reset manuale degli allarmi.
X APPENDICE - Baseline Unit Trattamento Aria - Manuale per lo sviluppatore

A2. Struttura del progetto FREE Studio
Il capitolo precedente descrive l'architettura di una baseline da un punto di vista
astratto: in questo capitolo, tale architettura viene esplicitata e descritta in termini di
elementi di un progetto FREE Studio, il quale:
nel caso Smart, corrisponde al solo progetto Application;
nel caso Evolution, include il progetto Application, il progetto User Interface e la
soluzione Connection che li unisce.
A2.1. Task, programmi e blocchi funzionali

Tutti i blocchi descritti nel capitolo precedente, fatta eccezione per REGULATORS e
ACTUATORS, si traducono in programmi (PROGRAM, secondo lo standard IEC61131-3).
Questo implica, in particolare, che lo scambio di dati tra blocchi avviene per mezzo di
variabili globali, siano esse parametri (EEPROM Parameters), stati (Status variables),
allarmi (Alarms), I/O (I/O mapping) o variabili interne (Global variables).
rappresentano i componenti fisici dell'unit trattamento aria, istanziati come variabili
globali e invocati all'interno del PROGRAM STRATEGY.
Tutti i programmi che compongono la baseline sono eseguiti dal task Timed ad
esclusione di quelli dedicati all'HMI (significativi solo per Smart).
APPENDICE - Baseline Unit Trattamento Aria - Manuale per lo sviluppatore XI

A2.2. Librerie
L'applicazione baseline fa uso di numerosi blocchi di libreria, suddivisi in librerie distinte
a seconda del loro ruolo (regolatori nella libreria regulators, attuatori nella libreria
actuators, ecc...).
Il numero dei blocchi presenti in una libreria pu crescere contestualmente alla
necessit di implementare nuove logiche per nuove applicazioni.
DEVELOPER pu modificare in maniera significativa il comportamento di
un'applicazione con semplici sostituzioni di un blocco con uno analogo presente in
libreria.
XII APPENDICE - Baseline Unit Trattamento Aria - Manuale per lo sviluppatore

A2.3. INPUT
La conversione del valore fisico nel corrispondente valore logico utilizzato all'interno
dell'applicazione eseguito dal BIOS in base ai valori dei parametri di configurazione
I/O.
La mappatura tra ingressi fisici e ingressi logici effettuata staticamente con la tabella
I/O Mapping di Application.
A2.3.1. Possibilit di intervento da parte di DEVELOPER

DEVELOPER pu intervenire con grande semplicit nella mappatura dell'I/O.
A2.4. PARAMETERS
I parametri vengono resi disponibili all'applicazione tramite la loro definizione nelle
tabelle EEPROM Parameters (ed eventualmente Status variables) di Application.
APPENDICE - Baseline Unit Trattamento Aria - Manuale per lo sviluppatore XIII

Per quanto riguarda Smart, considerando l'assenza di un database parametri sul target
(a differenza di Evolution), il blocco PARAMETERS pu includere un PROGRAM
IEC61131-3 dedicato, che si occupa di validare i valore dei parametri applicativi. Questa
logica dovr essere isolata dal resto dell'applicazione, in modo tale da agevolare un
eventuale porting su Evolution.
Nel caso di Evolution, la mappatura tra ingressi fisici dell'espansione EVE e ingressi
logici definita in Connection, nelle sezioni corrispondenti della configurazione
dell'espansione EVE:
nella sezione PDO Tx - Input, se l'espansione configurata come slave CANopen;
XIV APPENDICE - Baseline Unit Trattamento Aria - Manuale per lo sviluppatore

nella sezione Input, se l'espansione configurata come slave Modbus.
In questo caso, gli ingressi logici corrispondono a variabili di stato del master Evolution,
definite in Application nella tabella Status variables.

DEVELOPER pu facilmente intervenire sulla definizione dei parametri (modifica del
valore di default, del range dei valori permessi, ecc...) o aggiungere di nuovi.
APPENDICE - Baseline Unit Trattamento Aria - Manuale per lo sviluppatore XV

A2.5.GOAL
Lavorando con una baseline AHU, il blocco GOAL costituito da una serie di programmi
scritti in linguaggio FBD, il cui nome inizia per Goal_.
I risultati del blocco GOAL sono resi disponibili come dati globali al resto
dell'applicazione, nella cartella Global shared > Variables.

Il blocco GOAL si presta ai seguenti interventi da parte di DEVELOPER:
sostituzione di una determinata logica (ad esempio, la priorit tra gli ingressi che
determinano il modo operativo) con una alternativa presente in libreria;
estendere o semplificare le reti logiche connesse ai pin dei blocchi (ad esempio,
per aggiungere una condizione per l'abilitazione della gestione a fasce orarie);
introdurre nuovi fattori per il calcolo dei setpoint da inseguire.
XVI APPENDICE - Baseline Unit Trattamento Aria - Manuale per lo sviluppatore

A2.6. DIAGNOSTICS
Lavorando con una baseline AHU, il blocco DIAGNOSTICS costituito dal programma
omonimo, scritto in linguaggio FBD.
I risultati del blocco DIAGNOSTICS sono resi disponibili come variabili di allarme,
raggruppati dunque nella cartella Global shared > Alarms.
Ogni rete del programma Diagnostics ha il compito di valorizzare un singolo allarme.

DEVELOPER pu agevolmente:
modificare le logiche di rilevazione e riarmo degli allarmi (ad esempio,
aggiungendo o rimuovendo ritardi, rendere tali logiche parametriche, richiedere
un riarmo manuale di un determinato allarme, ecc...);
aggiungere la gestione di nuove condizioni di allarme.
APPENDICE - Baseline Unit Trattamento Aria - Manuale per lo sviluppatore XVII

A2.7. STRATEGY
Lavorando con una baseline AHU, il blocco STRATEGY costituito dal programma
omonimo, scritto in linguaggio SFC.
Il blocco STRATEGY un modello della macchina a stati dell'unit, che definisce:
le azioni da compiere (cio, la strategia da usare) per ogni stato macchina;
le possibili transizioni tra stati e le condizioni in cui esse avvengono.
Il linguaggio di programmazione scelto, l'SFC, permette una traduzione efficace di
questa macchina a stati:
le strategie corrispondono ad ACTION del programma SFC, implementate in
linguaggio FBD: ogni strategia contiene una rete FBD per ogni componente
dell'unit;
le transizioni corrispondono a TRANSITION del programma SFC, implementate in
linguaggio ST.

Per quanto detto, in termini di intervento da parte di DEVELOPER, STRATEGY si presta a:
gestire situazioni di pre-allarme o di emergenza non previste dalle baseline Unit
Trattamento Aria, cos come prevedere ulteriori strategie per il soddisfacimento
degli obiettivi del controllo;
modificare le singole strategie gi previste, in termini di azioni sui blocchi
REGULATORS e ACTUATORS.
XVIII APPENDICE - Baseline Unit Trattamento Aria - Manuale per lo sviluppatore

A2.8. REGULATORS e ACTUATORS
rappresentano i componenti fisici dell'unit trattamento aria.
Ogni strategia determina gli ingressi di tutti i blocchi e ne causa l'esecuzione.

DEVELOPER ha grande libert di intervento in REGULATORS e ACTUATORS, ad
esempio per:
sostituire logiche di regolazione e attuazione (ad esempio con altri blocchi di
libreria);
inserire logica aggiuntiva sui pin del blocco regolatore;
sostituire ingressi fissi con ingressi parametrici, o viceversa.
costruire attuatori complessi, composti da pi blocchi attuatore ma gestiti come
un singolo attuatore da STRATEGY, coordinati da un blocco logico che si occupa
di suddividere la richiesta proveniente da STRATEGY sui diversi attuatori.
Si noti che in alcuni casi pu essere invece necessario, o pi opportuno, modificare
STRATEGY per gestire a quel livello un attuatore complesso.
A2.9. OUTPUT
La mappatura tra uscite logiche e uscite fisiche effettuata staticamente con la tabella
I/O Mapping di Application.
La conversione del valore logico utilizzato all'interno dell'applicazione nel
corrispondente valore fisico eseguito dal BIOS in base ai valori dei parametri di
configurazione I/O.
Nel caso di Evolution, la mappatura tra uscite logiche e uscite fisiche dell'espansione
EVE definita in Connection, nelle sezioni corrispondenti della configurazione
dell'espansione EVE:
nella sezione PDO Rx - Output, se l'espansione configurata come slave CANopen;
nella sezione Output, se l'espansione configurata come slave Modbus.
In questo caso, le uscite logici corrispondono a variabili di stato del master Evolution,
definite in Application nella tabella Status variables.
APPENDICE - Baseline Unit Trattamento Aria - Manuale per lo sviluppatore XIX

A2.10. HMI
Considerando Smart, il blocco HMI in parte automatizzato (menu applicativo locale), in
parte implementato in PROGRAM IEC61131-3 dedicati, che si occupano della
segnalazione dello stato ON/OFF, della modalit di funzionamento e delle utenze attive,
della gestione dei tasti e della gestione del menu per il terminale remota.
Considerando Evolution, il blocco HMI corrisponde al progetto User Interface.
DEVELOPER pu agevolmente intervenire su tutto il blocco HMI.
XX APPENDICE - Baseline Unit Trattamento Aria - Manuale per lo sviluppatore

Eliwell Controls Srl
Via dell Industria, 15 Z. I. Paludi
32010 Pieve d Alpago (BL) - Italy
Telephone +39 (0)437 986 111
Fax +39 (0)437 989 066
Sales:
+39 (0)437 986 100 (Italy)
+39 (0)437 986 200 (other countries)
saleseliwell@invensys.com
Technical helpline: +39 (0)437 986 250
eliwell.freeway@invensys.com
www.eliwell.it
9MA00048 02/12
Copyright Eliwell Controls s.r.l. 2011-2012 All rights reserved
APPENDICE - Baseline Unit Trattamento Aria - Manuale per lo sviluppatore XXI

9MA00048 AHU ManualeDeveloper 0212 IT

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

9MA00048 AHU ManualeDeveloper 0212 IT

Diunggah oleh

Hak Cipta:

Format Tersedia

Baseline

Unit Trattamento Aria

Manuale per lo sviluppatore

Baseline Unit Trattamento Aria - Manuale per lo sviluppatore 3

Per installare FREE Studio e le baseline Unit Trattamento Aria obbligatoria

4 Baseline Unit Trattamento Aria - Manuale per lo sviluppatore

Baseline Unit Trattamento Aria - Manuale per lo sviluppatore 5

Figura 1: Struttura software di alto livello

6 Baseline Unit Trattamento Aria - Manuale per lo sviluppatore

3.2.1. Forma software nelle baseline AHU

Baseline Unit Trattamento Aria - Manuale per lo sviluppatore 7

Il blocco DIAGNOSTICS ha il compito di rilevare le condizioni di errore, ma non di porvi

3.3.1. Forma software nelle baseline AHU

8 Baseline Unit Trattamento Aria - Manuale per lo sviluppatore

scegliere tra le diverse strategie possibili quella da utilizzare per soddisfare la

Baseline Unit Trattamento Aria - Manuale per lo sviluppatore 9

10 Baseline Unit Trattamento Aria - Manuale per lo sviluppatore

I blocchi REGULATORS e ACTUATORS svolgono collettivamente il compito di esaudire

3.5.1. Forma software nelle baseline AHU

Ogni strategia determina gli ingressi di tutti i blocchi e ne causa l'esecuzione.

Baseline Unit Trattamento Aria - Manuale per lo sviluppatore 11

Tabella 1: Elenco delle baseline AHU

12 Baseline Unit Trattamento Aria - Manuale per lo sviluppatore

Baseline Unit Trattamento Aria - Manuale per lo sviluppatore 13

14 Baseline Unit Trattamento Aria - Manuale per lo sviluppatore

5.1.1. Configurazione statica dell'I/O

Application permette la modifica della configurazione dell'I/O, in forma tabellare, nella

Baseline Unit Trattamento Aria - Manuale per lo sviluppatore 15

l'ingresso logico sostituito al punto 2, I_ElectricHeaterThermal, pu essere

16 Baseline Unit Trattamento Aria - Manuale per lo sviluppatore

Baseline Unit Trattamento Aria - Manuale per lo sviluppatore 17

2. nella sezione Resources > Menu Prg, si pubblicano i nuovi parametri in un

18 Baseline Unit Trattamento Aria - Manuale per lo sviluppatore

5. si crea un nuovo PROGRAM in linguaggio FBD, di nome Input_DILMapping,

6. il nuovo PROGRAM viene assegnato al task Timed come primo PROGRAM

Baseline Unit Trattamento Aria - Manuale per lo sviluppatore 19

Inoltre, Goal_State si occupa di determinare se la modalit Economy attiva o meno

20 Baseline Unit Trattamento Aria - Manuale per lo sviluppatore

Figura 4: L'abilitazione della gestione a fasce orarie dipende dalla disponibilit

5.2.1. Modificare l'algoritmo che determina lo stato ON/OFF

Baseline Unit Trattamento Aria - Manuale per lo sviluppatore 21

5.2.2. Modificare la gestione a fasce orarie

Per far questo sufficiente:

22 Baseline Unit Trattamento Aria - Manuale per lo sviluppatore

2. si importa dalla libreria Utils una copia del blocco TimeFrameManager_t;

5.3. Modo COOL/HEAT

Baseline Unit Trattamento Aria - Manuale per lo sviluppatore 23

Figura 5: Determinazione del modo di funzionamento COOL/HEAT dell'unit trattamento aria; il

Lo stesso PROGRAM si occupa anche di risolvere preliminarmente il modo AUTO

24 Baseline Unit Trattamento Aria - Manuale per lo sviluppatore

Baseline Unit Trattamento Aria - Manuale per lo sviluppatore 25

5.5.1. Modificare la selezione della sonda di regolazione

Per ottenere questo risultato sufficiente:

26 Baseline Unit Trattamento Aria - Manuale per lo sviluppatore

2. Si modifica la definizione del parametro Hr01_HumidityProbeSelection,

5.5.2. Fissare la sonda di regolazione

Per ottenere questo risultato sufficiente:

Baseline Unit Trattamento Aria - Manuale per lo sviluppatore 27

3. nella sezione Resources > EEPROM Parameters, cancellare il parametro

Figura 9: Se lo stato dell'U.T.A. OFF, la diagnostica disabilitata

28 Baseline Unit Trattamento Aria - Manuale per lo sviluppatore

Figura 10: Gestione della richiesta di reset allarmi

Se si modificano le logiche che determinano il valore di uno o pi allarmi gi previsti

Baseline Unit Trattamento Aria - Manuale per lo sviluppatore 29