S.3.l Lamp Control Service

WP8 – Project coordination
D8.1 Project Handbook
CIP-ICT-PSP-2012-6 – 325161
"This project is partially funded under the ICT Policy Support Programme (ICT PSP) as part of the
Competitiveness and Innovation Framework Programme by the European Community"
(http://ec.europa.eu/ict_psp).
Lamp Control Service
Technical documentation part of
WP4 Integration of SUNSHINE pilot smart urban services
Revision: 1.0
Authors:
Luca Giovannini, Oscar Benedetti (SGIS)
Umberto Di Staso, Gabrio Girardi (GRAPHITECH)

CIP-ICT-PSP-2012-6 – 325161
Dissemination level PU (public)
Contributor(s)
Reviewer(s)
Editor(s)
Partner in charge(s)
Due date
Submission Date
REVISION HISTORY AND STATEMENT OF ORIGINALITY
Revision Date Author Organisation Description
V0.1 28/10/2015 Luca Giovannini SGIS
Document
created
V0.5 05/11/2015 Luca Giovannini SGIS Major update
V1.0 21/12/2015 Luca Giovannini SGIS Final release
Statement of originality:
This deliverable contains original unpublished work except where clearly indicated otherwise.
Acknowledgement of previously published material and of the work of others has been made
through appropriate citation, quotation or both.
Moreover, this deliverable reflects only the author’s views. The European Community is not
liable for any use that might be made of the information contained herein.

CIP-ICT-PSP-2012-6 – 325161
Table of Contents
1 Componenti del Servizio.................................................................................................... 4
1.1 Interfaccia Client / Server .............................................................................................. 4
1.2 Interfaccia Server / PowerOne (Rovereto) .................................................................... 5
1.3 Interfaccia Server / Reverberi (Bassano) ....................................................................... 6
2 Casi d'Uso........................................................................................................................... 8
2.1 Programmazione di lungo periodo ................................................................................ 8
2.1.1 mockup interfaccia ................................................................................................. 9
2.1.2 comandi da impartire al server............................................................................... 9
2.2 Programmazione eccezionale...................................................................................... 11
2.2.1 mockup interfaccia ............................................................................................... 12
2.2.2 comandi da impartire al server............................................................................. 12
2.3 Comandi da impartire istantaneamente ..................................................................... 13
2.4 Rimozione dei comandi schedulati.............................................................................. 15
Appendice: Specifiche SPS ......................................................................................................... 17
3.4 General consideration ................................................................................................. 17
3.5 SPS................................................................................................................................ 19
3.5.1 GetCapabilities...................................................................................................... 19
3.5.2 Submit................................................................................................................... 19

CIP-ICT-PSP-2012-6 – 325161
1 Componenti del Servizio
Il servizio si compone su più livelli:
 L’interfaccia client
 I servizi server centrali (grouping, scheduling, SPS)
 I servizi specifici lato pilot (Reverberi plug-in, SPS-to-Access SET)
 I dispositivi di controllo e illuminazione
Lo scopo di questo documento è di chiarire le interfacce tra i primi tre livelli:
 Client / server centrale
 Server centrale / servizi lato pilot (caso Reverberi e caso PowerOne)
L’ultima interfaccia, tra i servizi specifici lato pilot e i dispositivi di controllo ed
illuminazione è delegata interamente ai singoli pilots.
Le interfacce dipendono dal caso d’uso. I casi d’uso possibili sono 3:
 programmazione di lungo periodo
 programmazione eccezionale
 comandi da impartire istantaneamente
1.1 Interfaccia Client / Server
I servizi server direttamente disponibili ai client sono:
 Servizio di GROUPING, per definire raggruppamenti di lampade sui quali impartire i
comandi.
 Servizio SPS di SCHEDULING del LIVELLO di INTENSITA’ (vedi descrizione dettagliata in
3.5.2), per pianificare l’applicazione del comando di impostazione del livello di
intensità alle lampade afferenti ai gruppi, sia per un uso periodico che per un uso
istantaneo.
Il servizio di SCHEDULING dei LIVELLI di INTENSITA’ ha diversi attributi di cui solo due obbligatori
(dimming level e start date). Scegliendo opportunamente gli attributi da valorizzare, attraverso
questo servizio il client può inviare in maniera diretta i seguenti comandi elementari alle
lampade afferenti ai gruppi:
 comando DIMMING, modifica del livello di intensità
(parametro SPS dimming = 1 [poco intenso] fino a 100 [intensità massima])
o OneShot -> dimming level, start date, priority = highest
o Periodico -> dimming level, start date, expiration date, days of the week, priority
 comando OFF, lampada spenta
(parametro SPS dimming = 0)

CIP-ICT-PSP-2012-6 – 325161
 comando RESET, ripristino profili di intensità di default
 comando CONNECT, per attivare la connessione tra infrastruttura pilot e gli impianti
 comando DISCONNECT, per disattivare la connessione tra infrastruttura e impianti
Sarà poi a livello dell’interfaccia tra server e servizi lato pilot che questi comandi
verranno interpretati nei diversi linguaggi delle infrastrutture. In particolare:
 PowerOne (Rovereto): tutti e 5 i comandi verranno mappati.
 Reverberi (Bassano): solo i comandi DIMMING, OFF e RESET verranno mappati.
Maggiori dettagli nelle due sezioni seguenti.
I comandi che il client deve impartire al server dipendono dal caso d’uso. Nel capitolo
seguente per ciascuno dei 3 casi d’uso viene descritta l’interfaccia utente e viene
riportata la sequenza appropriata di comandi che il client deve impartire al server per
attuare le richieste espresse dall’utente.
1.2 Interfaccia Server / PowerOne (Rovereto)
SPS
ID
SPS
Dest
SPS Dest
Param
SPS
Command SPS_CB_SN
SPS
Para
m1
3 IMP 001 DIMMING 151390086 100
Comando puntuale per il lampione
151390086 di dimming al 100%
4 IMP 001 OFF 151390027
151390027 per spegnare la lampada
5 IMP 001 RESET 151390027
151390027 per annullare il
comando di dimming
6 IMP 001 DIMMING BROADCAST 80
Comando Broadcast di
dimming all'80%
7 IMP 001 OFF BROADCAST
Comando Broadcast per
spegnare la lampada
8 IMP 001 RESET BROADCAST
Comando Broadcast per
annullare il comando di dimming
9 APP 001 CONNECT
10 APP 001 DISCONNECT
Impianto
di
destinazi
one Comando
S/N del
lampione
destinatario
Para
metro
dimmi
ng

CIP-ICT-PSP-2012-6 – 325161
Una prima distinzione dei comandi inviati verso l’interfaccia di comunicazione del pilot
di Rovereto identifica il destinatario del comando: IMP, il comando è destinato a
raggiungere l’impianto di illuminazione, APP, il comando è destinato all’interfaccia di
comunicazione.
I comandi destinati all’impianto vengono poi identificati in comandi puntuali, quindi
diretti ad una singola lampada ed in comandi broadcast che verranno inviati a tutti i
lampioni dell’impianto. Il comando BROADCAST viene attivato se l’utente ha creato uno
schedule su di un gruppo fisico (un quadro), il comando puntuale deve essere
accompagnato dal numero seriale del lampione destinatario.
I comandi di OFF e RESET sono attivati dall’SPS plugin quando lo scheduling prevede un
commando di impostazione livello di intensità pari rispettivamente a 0 e 110. Nello
specifico il comando di RESET si utilizza per annullare la configurazione di dimming
imposta ai lampioni riportandoli ad un valore di default.
Il comando DIMMING oltre all’indirizzo del destinatario contiene anche il valore in
percentuale della potenza lampada che si desidera (100 = intensità massima).
I comandi destinati all’applicazione di interfaccia, come anzidetto identificati con APP,
possono essere 2: CONNECT e DISCONNECT. Il primo attiva la procedura di connessione
all’impianto il secondo serve per interromperla. Nel mentre una connessione è attiva
tutti i comandi destinati all’impianto verranno direttamente inoltrati allo stesso, in caso
contrario resteranno in attesa della prima connessione utile.
1.3 Interfaccia Server / Reverberi (Bassano)
Lo scopo di questa interfaccia è quello di mappare i comandi di DIMMING, OFF e RESET in
arrivo dal servizio SPS di SCHEDULING del LIVELLO di INTENSITA’ lato server nelle tabelle del
DB Maestro Reverberi da cui poi verranno autonomamente propagate agli impianti.
Non viene usata la modalità di ripetizione periodica dei comandi presente all’interno del DB
Reverberi, bensì si trattano come comandi singoli tutti i comandi in arrivo dal server, anche
quelli provenienti dai casi d’uso di programmazione di lungo periodo o eccezionale.
I comandi di DIMMING e OFF vengono mappati nel DB Maestro Reverberi nella tabella
tblHwyCommands che ha i seguenti campi:
CommandID ComponentID RecDate ExecDate CmdStatus DimmerPercent Username DivNum

CIP-ICT-PSP-2012-6 – 325161
Questa tabella ha lo scopo di raccogliere tutti i comandi in attesa di essere attuati, in una coda
FIFO. Appena il comando viene inserito in questa struttura, la tecnologia Reverberi se ne fa
carico attuando lo stesso. L’operazione effettiva di inserimento del comando nella tabella
tblHwyCommands è a carico dell’infrastruttura server e viene gestita da un webservice che si
collega al data base Reverberi tramite le librerie Hibernate.
A basso livello, la comunicazione effettiva tra webservice e database Reverberi, si traduce in
una semplice query:
INSERT INTO dbo.tblHwyCommands (ComponentID CmdStatus, DimmerPercent) VALUES
(<valueCOMPONENTID>,<valueSTATUS>,<valueDIMERPERCENT>);
Per attuare il webservice, viene eseguita da parte del job SPS dedicato a Reverberi, una
chiamata http con verbo GET come segue:
http://sunshine.sinergis.it/maestro/ws/Action/light_control?PROCEDURE_ID=<IDLAMPADA
>&DIMMERPERCENT=<DIMMERPERCENT>&USERNAME=<CODESPACE>
Il comando RESET nel caso di tecnologia Reverberi corrisponde ad un comando di DIMMING a
livello di intensità massimo e viene quindi mappato di conseguenza nel DB Maestro Reverberi.

CIP-ICT-PSP-2012-6 – 325161
2 Casi d'Uso
I casi d’uso possibili sono 4:
 programmazione di lungo periodo
 programmazione eccezionale
 comandi da impartire istantaneamente
 rimozione die comandi schedulati
Web client: gestisce tutti i casi d’uso tranne l’invio istantaneo di comandi.
Energy App: gestisce tutti i casi d’uso.
2.1 Programmazione di lungo periodo
LA FORM PER LO SCHEDULING DI BASE VIENE USATA PER LE IMPOSTAZIONI SULLA LINEA CHE
DURANO STAGIONALMENTE O PER UNO SVARIATO PERIODO.
 IN GENERALE ACCENSIONE INDICA UN DIMMING CHE VIENE SCHEDULATO PER LE ORE
12.00 (è il client a valorizzare in tal senso in automatico il comando SPS
corrispondente), TALE PER CUI LA LAMPADA SI ACCENDE CON IL SENSORE
CREPUSCOLARE CON QUELLA IMPOSTAZIONE.
 DIMMING 1 2 3 VENGONO USATI PER SETTARE LA LAMPADA A DIFFERENTI ORARI.
Questi campi sono opzionali, solo quello di accensione è obbligatorio.
 LA PRIORITA DI QUESTI 4 COMANDI DEVE ESSERE LA STESSA. Il client deve fornire
come livello di default quello MINIMO e deve comunque impedire la scelta del livello
di massima priorità (riservato al reset).
 I TASTI DI RIPETIZIONE DEVONO ESSERE USATI PER SETTARE DIRETTAMENTE DALL'SPS
LA RIPETIZIONE SETTIMANALE. Se l’utente non specifica nessuna ripetizione
settimanale il sistema sottintende che i comandi siano da ritenersi validi per TUTTI i
giorni della settimana compresi nell’intervallo di validità. Sarà carico del client fare la
chiamata opportuna in ciascuno dei due casi (ripetizione settimanale presente oppure
assente).
 FROM / TO PER LA DURATA DI VALIDITA’ DELLO SCHEDULING. L’utente può specificare
solo le date di validità (giorno/mese/anno) ma non l’ora. In automatico l’ora sarà
impostata alle 12:00 per lo start e alle 11:00 per l’end. Di conseguenza il client
impedisce all’utente di valorizzare i campi from / to con la stessa data.
 ALLA FINE DEL PERIODO COMPLESSIVO DI SCHEDULING DEVE ESSERE INVIATO UN
COMANDO DI RESET DELL'IMPIANTO. Il comando 5 deve avere priorità massima e verrà
schedulato per le 11:00, in coincidenza della fine del periodo di validità della
programmazione, in modo da non sovrapporsi ad una eventuale nuova
programmazione in partenza lo stesso giorno che avrebbe come prima azione un
comando di accensione impostato alle 12:00.

CIP-ICT-PSP-2012-6 – 325161
2.1.1 mockup interfaccia
2.1.1.1 web client
2.1.1.2 energy app
2.1.2 comandi da impartire al server
1) SPS DA 01/01/2016 alle 12:00 A 31/12/2016 alle 11:00

CIP-ICT-PSP-2012-6 – 325161
Attivazione ORE 12.00 90% 0000011
2) SPS DA 01/01/2016 alle 12:00 A 31/12/2016 alle 11:00
3) SPS DA 01/01/2016 alle 12:00 A 31/12/2016 alle 11:00
4) SPS DA 01/01/2016 alle 12:00 A 31/12/2016 alle 11:00
5) SPS DA 31/12/2016 alle 11:00 A 31/12/2016 alle 11:00
SPS COMMAND 1 --> <?xml version="1.0" ?><sps:Submit service="SPS" version="2.0.0"
xmlns:sps="http://www.opengis.net/sps/2.0"
xmlns:swe="http://www.opengis.net/swe/2.0"><sps:procedure>http://www.sunshineproject.eu
/sps/procedure/ROV-100</sps:procedure><sps:taskingParameters>
<sps:ParameterData><sps:encoding><swe:TextEncoding tokenSeparator=","
blockSeparator="@@"/></sps:encoding><sps:values>2016-01-01T11:00:00+0100,Y,2016-12-
31T11:00:00+0100,90,
N,Y,1000001,Y,1200,N,Y,1</sps:values></sps:ParameterData></sps:taskingParameters></sps:
Submit>
31T11:00:00+0100,70,
Submit>
31T11:00:00+0100,30,
Submit>
31T11:00:00+0100,60,
Submit>
SPS RESET 5 --> <?xml version="1.0" ?><sps:Submit service="SPS" version="2.0.0"

CIP-ICT-PSP-2012-6 – 325161
31T11:00:00+0100,110,
Submit>
2.2 Programmazione eccezionale
LA FORM PER LO SCHEDULING DI BASE VIENE USATA PER LE IMPOSTAZIONI SULLA LINEA CHE
DURANO STAGIONALMENTE O PER UNO SVARIATO PERIODO.
 IN GENERALE ACCENSIONE INDICA UN DIMMING CHE VIENE SCHEDULATO PER LE ORE
12.00 (è il client a valorizzare in tal senso in automatico il comando SPS
corrispondente), TALE PER CUI LA LAMPADA SI ACCENDE CON IL SENSORE
CREPUSCOLARE CON QUELLA IMPOSTAZIONE.
 DIMMING 1 2 3 VENGONO USATI PER SETTARE LA LAMPADA A DIFFERENTI ORARI.
Questi campi sono opzionali, solo quello di accensione è obbligatorio.
 LA PRIORITA DI QUESTI 4 COMANDI DEVE ESSERE LA STESSA. Il client deve fornire
come livello di default quello MINIMO e deve comunque impedire la scelta del livello
di massima priorità (riservato al reset).
 I TASTI DI RIPETIZIONE DEVONO ESSERE USATI PER SETTARE DIRETTAMENTE DALL'SPS
LA RIPETIZIONE SETTIMANALE. Se l’utente non specifica nessuna ripetizione
settimanale il sistema sottintende che i comandi siano da ritenersi validi per TUTTI i
giorni della settimana compresi nell’intervallo di validità. Sarà carico del client fare la
chiamata opportuna in ciascuno dei due casi (ripetizione settimanale presente oppure
assente).
 FROM / TO PER LA DURATA DI VALIDITA’ DELLO SCHEDULING. L’utente può specificare
solo le date di validità (giorno/mese/anno) ma non l’ora. In automatico l’ora per
entrambi i campi sarà impostata alle 11:00. Di conseguenza il client impedisce
all’utente di valorizzare i campi from / to con la stessa data.
 ALLA FINE DEL PERIODO COMPLESSIVO DI SCHEDULING DEVE ESSERE INVIATO UN
COMANDO DI RESET DELL'IMPIANTO. Il comando 5 deve avere priorità massima e verrà
schedulato per le 11:00, in coincidenza della fine del periodo di validità della
programmazione, in modo da non sovrapporsi ad una eventuale nuova
programmazione in partenza lo stesso giorno che avrebbe come prima azione un
comando di accensione impostato alle 12:00.

CIP-ICT-PSP-2012-6 – 325161
2.2.1.1 web client
2.2.1.2 energy app
1) SPS DA 05/01/2016 alle 12:00 A 06/01/2016 alle 11:00
2) SPS DA 05/01/2016 alle 12:00 A 06/01/2016 alle 11:00

CIP-ICT-PSP-2012-6 – 325161
3) SPS DA 07/12/2016 alle 11:00 A 07/12/2016 alle 11:00
07T11:00:00+0100,40,
Submit>
07T11:00:00+0100,100,
Submit>
SPS RESET 5 --> <?xml version="1.0" ?><sps:Submit service="SPS" version="2.0.0"
07T11:00:00+0100,110,
Submit>
2.3 Comandi da impartire istantaneamente
Form dedicata e solo su App:
 Ha un unico campo per il valore di livello di intensità.
 La priorità del comando è di default la MASSIMA possibile.
 L’inizio della validità del comando è impostata automaticamente alla data/ora
corrente
 Le interfacce sono diverse per i due pilot coinvolti
o Rovereto: l’interfaccia è dotata anche di 3 bottoni extra per inviare i comandi
di CONNECT, RESET e DISCONNECT. Questi tre comandi non hanno un
feedback sul client e l’accertamento del loro compimento è demandato
empiricamente all’utente.
o Bassano: l’interfaccia è dotata in aggiunta del solo bottone di RESET. Questi
tre comandi non hanno un feedback sul client e l’accertamento del loro
compimento è demandato empiricamente all’utente..

CIP-ICT-PSP-2012-6 – 325161
2.3.1.1 energy app (Rovereto)
2.3.1.2 energy app (Bassano)
Alla pressione del bottone SEND SCHEDULING corrisponde un solo comando SPS:

CIP-ICT-PSP-2012-6 – 325161
 start date = data corrente al momento dell’invio del commando (rilevata in automatic
dal client)
 dimming level (%) = come da immesso dall’utente
 Priority = highest
<?xml version="1.0" ?><sps:Submit service="SPS" version="2.0.0" xmlns:sps="http://www.opengis.net/sps/2.0"
xmlns:swe="http://www.opengis.net/swe/2.0"><sps:procedure>http://www.sunshineproject.eu/sps/procedure/R
OV-159</sps:procedure><sps:taskingParameters><sps:ParameterData><sps:encoding><swe:TextEncoding
tokenSeparator="," blockSeparator="@@"/></sps:encoding><sps:values>2015-11-
09T08:14:08+0100,N,52,N,N,N,N,Y,4</sps:values></sps:ParameterData></sps:taskingParameters></sps:Submit>
Alla pressione del bottone CONNECT corrisponde la seguente chiamata SPS:
Alla pressione del bottone RESET corrisponde la seguente chiamata SPS:
Alla pressione del bottone DISCONNECT corrisponde la seguente chiamata SPS:
2.4 Rimozione dei comandi schedulati
2.4.1.1 web client

CIP-ICT-PSP-2012-6 – 325161
2.4.1.2 energy app
La rimozione dei comandi schedulati viene eseguita tramite il comando DELETE relativo al
servizio di grouping.
La documentazione è disponibile online:
http://sunshine.sinergis.it/grouping/docs/swagger/

CIP-ICT-PSP-2012-6 – 325161
Appendice: Specifiche SPS
In this document we describe the SPS service with some new features to resolve some
usability issues. We have extracted paragraph 5.2 of document D4.6 and integrated it with the
new features.
3.4 General consideration
We use the Sensor Planning Service in order to modify the light pole dimming level; in this
way we force quite a bit the nature of the service because this should be a case of dealing
with an actuator rather than with a sensor. OGC standard that face actuators interaction is not
yet released and that’s why we choose this solution. Therefore this choice has some
limitations that are quite difficult to solve completely.
The main characteristics of the solutions are:
 SPS is exposed to clients; in particular the Submit operation is the one that can be
used to plan a task on a light pole, that is, a request to change its dimming level.
 The implementation of SPS that we use (52°North) introduces the concept of plugin
to transform a standard request of task planning into a technology specific command
towards the light pole control infrastructure.
 A scheduling component has been introduced to extend the task planning requests in
order to improve usability. In other words, a client can post a request that sound like
these examples:
o dim light 30% at this hour every day in this interval of days;
o dim light 20% every Friday at this hour in this interval of days;
o dim light 40% every weekend at this hour from today on;
o dim light 10% at this hour in these specific days;
o for that light pole:
 dim light 10% at this hour in these specific day;
 dim light another 20% at this hour in the same day.
o for that group of light pole
 dim light 10% at this hour in this interval of days;
 during the week end of that interval, delay the dimming of two
hours.
 three main ways to schedule a command are implemented:
o by specifying an interval of validity and a frequency of repetition
o by specifying an interval of validity and a week pattern
o by indicating a list of specific days
 the concept of priority has been introduced to regulate the presence of several
commands in the same day.
 due to limitations about the data type of the parameters of the SPS request, we are
not able to use the standard ISO notation for date and time. So, in order to support

CIP-ICT-PSP-2012-6 – 325161
different time zones, although at the moment SPS use involves only Italian pilots, the
information of the time zone from which the request is made can be inserted among
the parameters. For coding the time zone, we use the offset from UTC; examples:
Time Zone UTC offset
WET (Western European Time) 0
CET (Central European Time) 1
EET (Eastern European Time) 2
WEST (Western Europe Summer Time) 1
CEST (Central European Summer Time) 2
EEST (Eastern European Summer Time) 3
Note that in this way also information on DST is passed, but it is treated as if it were
another time zone: when a request arrives on the server, the time zone information is
compared with the time zone valid for the server (now it is CET o CEST depending on
the DST) and the correct time is stored on the scheduler, i.e.:
if the server is on CEST (+2) and a request arrives from a client in WET (+0) for a
dimming at 4:00, in the scheduler DB will be registered 6:00 (note that among
European Union member states, DST start and end are homogeneous, so situations
like this one should not happen).
 no correction for daylight saving time start or end is made in tasking operation: a task
that spans across the change time date, will not be adjusted according to the
advancing or delaying of clocks that occurs. In other words, a dimming starting at
4:00 in the morning will be sent always at 4:00 because the system clock will be
adjusted automatically when the DST starts or ends. If that particular time was
chosen because of the duration of the night or considering the level of darkness in
that period, after the DST adjustment those considerations will no longer be valid.
In this piloting phase, the server that receives request of planning is located in Italy
and its system clock is set on UTC+1. Daylight saving times follow the subsequent
calendar:
Year DST Start (Clock forward) DST End (Clock backward)
2015 Sunday 29th
March, 2:00 Sunday 25th
October, 3:00
2016 Sunday 27th
October, 3:00
2017 Sunday 26th
October, 3:00
2018 Sunday 25th
October, 3:00

CIP-ICT-PSP-2012-6 – 325161
2019 Sunday 31st
October, 3:00
 no correction for the sunrise/sunset time continuous variation is made. A task that
dims light at 6:00 am that applies from 1st
January to 30th
June will become totally
useless around 1st
April (in Trento) as sunrise precede the scheduled task and twilight
switch will turn off the light pole prior to dimming.
3.5 SPS
The SPS server of the Sunshine’s platform is listening at the URL:
https://sunshine.sinergis.it/SPS
3.5.1 GetCapabilities
As for all OGC services, a GetCapabilities request allows to retrieve service metadata from a
SPS server.
3.5.2 Submit
The Submit operation allows clients to submit a tasking request for a specific sensor. A sensor
exposes its tasking parameters by declaring them in its SensorML1
encoded metadata. These
metadata is a standard description of the sensor that is used characterize the device during its
insertion in the SOS or SPS server. The InsertSensor operation is used to populate the system
with the physical sensors and then dynamically to enable a virtual group to be controlled.
In an InsertSensor request one fundamental parameter is the SensorML document that
describes the sensor being inserted. Inside this document you can declare which parameters
are “taskable”, i.e. when inserting a web cam a set taskable parameter could be the pan and
tilt values defining the camera’s orientation or, for a temperature sensor, a taskable
parameter could be the frequency of the reading.
The tasking parameters can be mandatory or optional and this characteristic influences the
way a Submit request is encoded.
3.5.2.1 Sample request for SUNSHINE
The tasking parameters for the Sunshine lighting networks are the following:
 start date (yyyy-MM-dd'T'HH:mm:ssZ). Mandatory, it’s the first day in which the
command has to be applied or the schema of repetition (week pattern) evaluated. If
the frequency parameter is present, then this start date represent the first time of a
sequence of command applications. When itemizing a list of specific dates, it would
not be necessary because the interval of validity is implicit: for technical limitation
instead you must indicate this parameter as well.
1
http://portal.opengeospatial.org/files/?artifact_id=21273

CIP-ICT-PSP-2012-6 – 325161
 expiration date (yyyy-MM-dd'T'HH:mm:ssZ). Optional, it represents the moment
after which the command should be no more applied. If not specified it means
“forever”.
 dimming level (%). Mandatory, it’s the real characteristic of the sensor that the
command wants to modify. A dimming request of 0% corresponds to have no light at
all, while a dimming request of 100% corresponds to lamp maximum power.
 frequency (dd2
). Optional. It represents in days the frequency of repetition of the
command. If you are using a week pattern or a list of specific dates it should be null,
while if not specified when a starting date is set, it means “only once”.
 Days of the week (nnnnnnn) Optional. It I a seven digit number of 1s or 0s,
representing the 7 days of week (English order, i.e.: SUN, MON, TUE, WED, THU, FRI,
SAT) where we want run the command. I.e.: if I set 1001001, the command will be run
on Wednesday, Saturday and Sunday.
 Activation hour (hhmm) Optional. Specified only when using the week pattern: it is
the hour of activation of the command for all the days ON specified in the 7-digit
number. In the other cases the activation hour is specified implicitly in the start date
(frequency pattern) or in the individual days (list of days pattern)
 List of days(yyyy-MM-dd'T'HH:mm:ssZ;yyyy-MM-dd'T'HH:mm:ssZ;...) Optional. If we
want launch the command on specific set of dates.
 Priority. Optional. The priority of the command. Domain 1 to 5, where the major
priority is 5. I there are several command scheduled for the same day, only that (or
those) with the greatest priority will be launched. If no priority is specified, a value of
1 will be set.
These parameters must be coded in one string, concatenating them with a separator (a
comma, but can be specified) and adding a “Y,” before the optional parameters that are
present, nothing for the mandatory and “N” for the optional not present.
Example 1
“I want to set the intensity of a lamp to the 40% of the nominal maximum power and I want to
do this every night at 02:00 a.m. starting from tomorrow (13th
March 2015) till the end of the
month.” The parameters will be the followings:
 start date = 2015-10-30T20:00:00+0100
 expiration date = 2015-10-30T22:00:00+0100
 dimming level = 40
 frequency = 1
and the command string will look like this:
2015-10-30T20:00:00+0100,Y, 2015-10-30T22:00:00+0100,40,Y,1,N,N,N,N
2
The minimal period of frequency will be, one day.

CIP-ICT-PSP-2012-6 – 325161
Note that the expiration date and the frequency are preceded by the “Y,” being these ones
optional parameters.
2015-10-30T20:00:00+0100,Y, 2015-10-30T22:00:00+0100,40,Y,1,N,N,N,N
If no repetition were needed, but only a one-time command, no optional parameters would
appear in the string, but only an “N” instead of them and the string would look like:
2015-10-30T20:00:00+0100,N,40,N,N,N,N,N
The complete XML that represents the payload of the HTTP POST to the SPS service:
<?xml version="1.0" ?>
<sps:Submit service="SPS" version="2.0.0" xmlns:sps="http://www.opengis.net/sps/2.0"
xmlns:swe="http://www.opengis.net/swe/2.0">
<sps:procedure>http://www.sunshineproject.eu/sps/procedure/ROV-200</sps:procedure>
<sps:taskingParameters>
<sps:ParameterData>
<sps:encoding>
<swe:TextEncoding tokenSeparator="," blockSeparator="@@"/>
</sps:encoding>
<sps:values>2015-10-30T20:00:00+0100,Y, 2015-10-
30T22:00:00+0100,40,Y,1,N,N,N,N</sps:values>
</sps:ParameterData>
</sps:taskingParameters>
</sps:Submit>
The corresponding response is listed below and you can see apart from the task id, other
auxiliary information.
<?xml version="1.0" encoding="UTF-8"?>
<ns:SubmitResponse xmlns:ns="http://www.opengis.net/sps/2.0">
<ns:result>
<ns:StatusReport>
<ns:task>http://www.sunshineproject.eu/sps/procedure/ROV-200b/6c9eab15-
788e-4a43-b2bd-fb6f2ba3688d</ns:task>
<ns:estimatedToC>2015-04-03T16:55:04.445+02:00</ns:estimatedToC>
<ns:event>TaskSubmitted</ns:event>
<ns:percentCompletion>0.0</ns:percentCompletion>
<ns:procedure>http://www.sunshineproject.eu/sps/procedure/ROV-
200b</ns:procedure>
<ns:requestStatus>Accepted</ns:requestStatus>
<ns:taskStatus>InExecution</ns:taskStatus>
<ns:updateTime>2015-04-03T16:54:58.438+02:00</ns:updateTime>
</ns:StatusReport>
</ns:result>

CIP-ICT-PSP-2012-6 – 325161
</ns:SubmitResponse>
Example 2
“I want to set the intensity of a lamp to the 40% of the nominal maximum power and I want
to do this every Saturday and Sunday of November 2015 at 20:30. The parameters will be the
followings:
 start date = 2015-10-30T20:00:00+0100
 expiration date = 2015-10-30T22:00:00+0100
 Days of the week = 1000001
 Activation hour = 2030
The command string will look like this:
= 2015-10-30T20:00:00+0100,Y, 2015-10-30T22:00:00+0100,40,N,Y,1000001,Y,2030,N,N
Example 3
“I want to set the intensity of a lamp to the 40% of the nominal maximum power and I want to
do this the 7th
, 8th
and 12th
of November 2015 at 20:30 for 7th
and 8th
and at 21:00 for the 12th
.
The parameters will be the followings:
 start date = = 2015-11-06T20:00:00+0100
 List of days = 2015-11-07T20:30:00+0100; 2015-11-08T20:30:00+0100; 2015-11-
12T21:00:00+0100
The command string will look like this:
= 2015-11-06T20:00:00+0100,N,40,N,N,N,Y, 2015-11-07T20:30:00+0100;2015-11-
08T20:30:00+0100;2015-11-12T21:00:00+0100,N
Usage of “Priority”:
Priority concept is useful to resolve eventual conflicts due to possibility of inserting more
commands for one sensor in the same day. Every day, only command(s) with the highest
priority of the day will be executed.

CIP-ICT-PSP-2012-6 – 325161

S.3.l Lamp Control Service

Recommended

Recommended

More Related Content

What's hot

What's hot (14)

Similar to S.3.l Lamp Control Service

Similar to S.3.l Lamp Control Service (20)

More from SUNSHINEProject

More from SUNSHINEProject (11)

Recently uploaded

Recently uploaded (20)

S.3.l Lamp Control Service