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)

http://ec.europa.eu/ict_psp



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 Comando puntuale per il lampione 151390027 per spegnare la lampada

5 IMP 001 RESET 151390027

Comando puntuale per il lampione 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: <?xml version="1.0" ?><sps:Submit service="SPS" version="2.0.0" xmlns:sps="http://www.opengis.net/sps/2.0"





Alla pressione del bottone RESET corrisponde la seguente chiamata SPS: <?xml version="1.0" ?><sps:Submit service="SPS" version="2.0.0" xmlns:sps="http://www.opengis.net/sps/2.0"





Alla pressione del bottone DISCONNECT corrisponde la seguente chiamata SPS: <?xml version="1.0" ?><sps:Submit service="SPS" version="2.0.0" xmlns:sps="http://www.opengis.net/sps/2.0"





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/


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







CIP-ICT-PSP-2012-6 – 325161




2019 Sunday 31st March, 2:00 Sunday 27th 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


https://sunshine.sinergis.it/SPS

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>


http://www.sunshineproject.eu/sps/procedure/ROV-200b/6c9eab15-788e-4a43-b2bd-fb6f2ba3688d%3c/ns:task

http://www.sunshineproject.eu/sps/procedure/ROV-200b/6c9eab15-788e-4a43-b2bd-fb6f2ba3688d%3c/ns:task

http://www.sunshineproject.eu/sps/procedure/ROV-200b%3c/ns:procedure

http://www.sunshineproject.eu/sps/procedure/ROV-200b%3c/ns:procedure



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

dimming level = 40

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

dimming level = 40

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







CIP-ICT-PSP-2012-6 – 325161







CIP-ICT-PSP-2012-6 – 325161





Date post:	12-Apr-2017
Category:	Technology
Upload:	sunshineproject
View:	557 times
Download:	0 times

S.3.l Lamp Control Service

Technology