A Workflow Automation Engine (WAE) for event processing in Iot Platform
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
A Workflow Automation Engine (WAE)
for event processing in Iot Platform
Studente/i Relatore
Samuel B. Martins Massimo Coluzzi
Correlatore
-
Committente
Paradox Engineering
Corso di laurea Modulo
Ingegneria informatica TP M-P6080 Progetto di diploma
Anno
2021
Data
3 settembre 2021
i
Indice
1 Introduzione 3
2 Motivazione e contesto 5
2.1 Information Flow Processing (IFP) . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Stream processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Data stream management system (DSMS) . . . . . . . . . . . . . . . . . . . 6
2.4 Complex event processing (CEP) . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Confronto motori Stream Processing e CEP . . . . . . . . . . . . . . . . . . . 7
2.6 Paradox Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6.1 Infrastruttura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6.2 Formato trasmissione telemetria . . . . . . . . . . . . . . . . . . . . . 9
2.6.3 Formato trasmissione eventi . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.4 API MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6.5 Inviare comandi ai device . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Problema 17
3.1 Richiesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.1 Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.2 Building blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.3 Valutazione dei tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4 Stato dell’arte 21
4.1 Node-RED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 ThingsBoard Community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3 ThingsBoard Professional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4 Apache NiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5 Apache Flink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.6 Drools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.7 AWS IoT Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
A Workflow Automation Engine (WAE) for event processing in Iot Platformii INDICE
5 Valutazione 29
6 Prototipo e casi d’uso 31
6.1 Struttura, regole e gruppi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2 Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.3 Nodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.3.1 Telemetry input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.3.2 Event input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.3.3 Numeric telemetry evaluation . . . . . . . . . . . . . . . . . . . . . . . 36
6.3.4 Same state check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.3.5 No clear event check . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.3.6 Send command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.3.7 Send event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.3.8 Send mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.4 Casi d’uso reali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.4.1 Monitoraggio della connessione di rete via RSSI . . . . . . . . . . . . 40
6.4.2 Smart Parking: stato di occupazione di un parcheggio . . . . . . . . . 41
6.4.3 Smart Lighting: monitoraggio tensione lampada . . . . . . . . . . . . . 41
6.5 Programmazione nodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.5.1 UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.5.2 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.6 Containerizzazione Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.7 Integrazione nel CMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.8 Demo e simulazione device . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.9 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7 Risultati e limiti riscontrati 49
7.1 Difficoltà nella creazione di flussi . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.2 Problemi per la gestione di multi-tenants . . . . . . . . . . . . . . . . . . . . . 49
7.3 Scalabilità e clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8 Conclusione 51
A Workflow Automation Engine (WAE) for event processing in Iot Platformiii
Elenco delle figure
2.1 Stream Processing[11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Architettura CMS Paradox . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Apache NiFi con ZooKeeper . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 API Apache Flink [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3 Parallelizzazione stream[3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1 Flusso per recuperare informazioni sulle zone per ogni device . . . . . . . . . 33
6.2 UI - Telemetry input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.3 UI - Numeric telemetry evaluation . . . . . . . . . . . . . . . . . . . . . . . . 36
6.4 UI - Same state check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.5 UI - No clear event check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.6 UI - Send command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.7 UI - Send event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.8 UI - Send mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.9 Flusso - Monitoraggio della connessione di rete via RSSI . . . . . . . . . . . . 41
6.10 Flusso - Stato di occupazione di un parcheggio . . . . . . . . . . . . . . . . . 41
6.11 Flusso - Monitoraggio tensione lampada . . . . . . . . . . . . . . . . . . . . . 42
6.12 Frontend CMS di Paradox Engineering . . . . . . . . . . . . . . . . . . . . . . 46
6.13 Interfaccia demo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
A Workflow Automation Engine (WAE) for event processing in Iot Platformiv ELENCO DELLE FIGURE A Workflow Automation Engine (WAE) for event processing in Iot Platform
v
Elenco delle tabelle
2.1 Resource IDs eventi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1 Software valutati in questo documento . . . . . . . . . . . . . . . . . . . . . . 21
A Workflow Automation Engine (WAE) for event processing in Iot Platformvi ELENCO DELLE TABELLE A Workflow Automation Engine (WAE) for event processing in Iot Platform
1
Abstract
Una delle funzionalità fondamentali delle piattaforme IoT è il sistema di
gestione eventi (e relative notifiche). Questi sistemi devono essere in gra-
do di riceve misure o eventi da device IoT, analizzarli e produrre diversi
tipi di output che vanno dalla creazione di allarmi fino all’invio di comandi.
L’obbiettivo del progetto, svolto in collaborazione con l’azienda svizzera
Paradox Engineering SA, è stato quello di studiare i sistemi per la ge-
stione di eventi, compararli e valutarli al fine di sviluppare un prototipo
in grado di soddisfare casi d’uso reali. Il prototipo ottenuto è stato inte-
grato nel sistema di Paradox Engineering e permette al suo utilizzatore
di creare regole, in modo semplice e immediato, tramite flussi logici su
un’interfaccia web.
One of the most important functionalities of IoT platforms is the event
management system (and related notifications). These kinds of systems
receive measurements or events from IoT devices, analyze them and pro-
duce different outputs such as creating alarms or sending out commands.
The objective of the project carried out in collaboration with the Swiss
company Paradox Engineering SA was to study event management sy-
stems, compare and evaluate them in order to develop a prototype, able
to satisfy real-life use cases. The prototype obtained has been integrated
into Paradox Engineering’s system and allows its user to create rules, in
a simple and immediate way, through logical flows on a web interface.
A Workflow Automation Engine (WAE) for event processing in Iot Platform2 ELENCO DELLE TABELLE A Workflow Automation Engine (WAE) for event processing in Iot Platform
3
Capitolo 1
Introduzione
Un problema comune nell’ambito Internet of Things (IoT) è quello di gestire dati generati dai
dispositivi ed analizzare questi dati in maniera rapida e significativa. I dati possono essere
semplici telemetrie come le temperature oppure possono essere eventi come il superamen-
to di un certa soglia di voltaggio. L’analisi che si desidera fare con questi dati è il rilevamento
di pattern anomali, per esempio nell’ambito dello smart parking è interessante controllare
che le auto non occupino un certo parcheggio più del tempo stabilito. I tool che permet-
tono di fare analisi di questo tipo sono chiamati Information Flow Processing (IFP) engine
e grazie a delle regole, dichiarate dall’utente, sono in grado di analizzare e processare i dati.
Paradox Engineering (PE) è un’azienda tecnologica che sviluppa soluzioni avanzate per
l’IoT, attualmente ha già un IFP engine dedicato ad un specifico dominio applicativo. In col-
laborazione con loro si desidera studiare vari strumenti per la gestione degli eventi al fine di
implementare un prototipo in grado di supportare diversi domini applicativi e che permetta
la realizzazione di regole in modo semplice e senza nessuna conoscenza di formati di tra-
smissione o linguaggi di programmazione.
Il resto del documento è organizzato come segue. Il capitolo 2 spiega perché questo do-
cumento è stato redatto, si introduce il contesto spiegando vari termini dell’ambito in cui ci
troviamo e si introduce Paradox Engineering e i suoi sistemi. Il capitolo 3 descrive quale
problema viene affrontato in questo progetto, qual’è la richiesta del committente assieme
ai requisiti. Il capitolo 4 descrive lo studio sullo stato dell’arte descrivendo tutti gli strumenti
analizzati. Il capitolo 5 compara questi strumenti tra loro e decide quale usare per la creazio-
ne del prototipo. Il capitolo 6 spiega come il prototipo è stato sviluppato e si mostrano alcuni
esempi di cosa è in grado di fare. Il capitolo 7 descrive i problemi e le difficoltà riscontrate
durante il progetto. Il capitolo 8 conclude descrivendo la portata e i limiti del lavoro.
A Workflow Automation Engine (WAE) for event processing in Iot Platform4 Introduzione A Workflow Automation Engine (WAE) for event processing in Iot Platform
5
Capitolo 2
Motivazione e contesto
È stato richiesto, come progetto di tesi di bachelor in ingegneria informatica alla SUPSI, di
realizzare uno strumento in collaborazione con l’azienda Paradox Engineering. Questo stru-
mento come verrà spiegato più in dettaglio nel capitolo 3 dovrà essere in grado di leggere
flussi di eventi da dei device IoT ed elaborarli.
Per ottenere questo strumento si è deciso di fare affidamento a strumenti già esistenti, per
comprendere al meglio questi strumenti è necessario capire il significato di alcuni sistemi,
modelli e concetti relativi al dominio su cui si lavora come: Information Flow Processing
(IFP); Stream Processing; Data Stream Management Systems (DSMS) e Complex Event
Processing (CEP).
Figura 2.1: Stream Processing[11]
A Workflow Automation Engine (WAE) for event processing in Iot Platform6 Motivazione e contesto
2.1 Information Flow Processing (IFP)
Cugola e Margara[5] definiscono il dominio IFP come domino applicativo dove gli utenti
necessitano di collezionare informazioni prodotte da sorgenti multiple e distribuite in modo
tempestivo, cosi da estrarre nuova conoscenza. Esempi di sistemi IFP possono venire dai
campi più disparati come IoT, click-stream inspection e controllo del traffico. La componente
centrale di questi sistemi è il motore IFP che viene definito come strumento che richiede
di processare grandi flussi di informazioni che viaggiano verso il centro del sistema[5]. I
concetti chiave di questi sistemi sono la tempestività e il flow processing. Lo sviluppo di
questi ha portato a due principali modelli: lo stream processing model e il complex event
processing model.
2.2 Stream processing
Lo Stream Processing è un paradigma per l’elaborazione di flussi di dati, una serie di ope-
razioni, solitamente organizzate in pipeline, elaborano ogni elemento del flusso. Questo
paradigma si presta allo sviluppo tramite grafi, infatti i motori di stream processing permet-
tono di creare grafi dove ogni nodo è un’operazione (o insieme di operazioni) che elabora
il flusso ricevuto in input e manda l’output creato al prossimo nodo. Questi nodi vengono
poi collegati fra di loro per stabilire il percorso del flusso. Certi tool permettono di eseguire
questi grafi in parallelo su più macchine.
2.3 Data stream management system (DSMS)
Il DSMS è un sistema che si occupa di gestire continui flussi di dati, è simile al più famoso
Data Base Management System (DBMS). I DSMS rispetto ai DBMS non salvano i dati in
modo persistente, le query eseguite continuano nel tempo e vengono valutate anche su
dati che dovranno ancora arrivare. Il linguaggio di queste query può cambiare da sistema
a sistema nella maggior parte dei casi si tratta di linguaggi compatibili con SQL dotati di
funzionalità aggiuntive come le time windows. Un possibile esempio è StreamSQL:
1 SELECT AVG ( price ) FROM examplestream [ SIZE 10 ADVANCE 1 TUPLES ] WHERE
value > 100.0
Listing 2.1: Esempio query StreamSQL[13]
Questa query continua a calcolare la media del prezzo degli ultimi 10 elementi con valore
maggiore di 100, per calcolare gli ultimi 10 elementi viene usata una sliding window.
A Workflow Automation Engine (WAE) for event processing in Iot Platform7
2.4 Complex event processing (CEP)
I modelli di Complex Event Processing gestiscono i dati che ricevono come eventi e l’ag-
gregazione di questi genera eventi di alto livello. Il modello ha come radice i sistemi di
publish/subscribe[5], questi sistemi permetto lo scambio di messaggi, tra sistemi autorizza-
ti, grazie a dei topic, in questo modo chiunque sia sottoscritto a un certo topic riceverà tutti i
messaggi pubblicati su quel topic. Il CEP può essere visto come sistema publish/subscribe
più avanzato dove l’utente definisce che eventi vuole ricevere non semplicemente da un to-
pic ma da una query, queste query verranno usate dal motore CEP per analizzare i dati ed
inviare eventuali risposte se vengono rilevati degli eventi che rispecchiano le regole presenti
nelle query.
"Contrariamente all’obiettivo primario dei DSMS, che eseguono analisi dei flussi in un luo-
go geograficamente concentrato, la preoccupazione principale di CEP è di dedurre la co-
noscenza necessaria dal vasto volume di eventi grezzi da trasmettere il più velocemente
possibile"[7]
La differenza fra DSMS e CEP è che i DSMS si occupano principalmente di elaborare valori
numerici e producono risultati analitici mentre i CEP lavorano su eventi avvenuti nel mondo
reale e questi eventi vengono analizzati secondo delle regole per rilevare nuovi eventi di alto
livello.
2.5 Confronto motori Stream Processing e CEP
La differenza più evidente tra i motori di stream processing e i motori CEP è nel modo in
cui l’utente costruisce le regole. Nei motori di stream processing, come spiegato al capitolo
2.2, l’utente crea dei grafi dove ogni nodo elaborerà i dati, mentre nei motori CEP l’utente
scrive delle query che il motore CEP utilizzerà per analizzare i dati.
Oggigiorno la differenza fra questi sistemi è sempre più labile, gli obiettivi che questi tool
si propongono di ottenere sono simili e quindi questo ha portato le caratteristiche che una
volta erano dei motori di streaming Processing ad essere presenti anche nei motori CEP e
viceversa:
• Lo Stream Processing era pensato per essere facilmente scalato su molti nodi, grazie
alla sua natura di flusso, mentre per i motori CEP era più difficile e venivano quindi
scalati verticalmente. Ora però tool per il CEP come Esper offrono supporto per la
scalabilità, e Drools ha promesso di aggiungere il supporto alla scalabilità entro fine
2021.
A Workflow Automation Engine (WAE) for event processing in Iot Platform8 Motivazione e contesto
• Le time-windows, caratteristica principalmente dei tool CEP, ora esistono anche in tool
per lo streaming processing come Apache Flink.
• Tool come Siddhi permettono sia di scrivere le proprie regole con delle query sia di
creare dei flussi di nodi graficamente.
2.6 Paradox Engineering
Paradox Engineering è un’azienda tecnologica che sviluppa soluzioni avanzate per l’Internet
of Things (IoT) che consentono ai clienti di migliorare la gestione di servizi urbani e infrastrut-
ture industriali, nonché progettare nuove applicazioni. Tecnologie radio, sviluppo e gestione
di architetture di rete, soluzioni low power, dispositivi per la raccolta e la trasmissione dati
sono gli ambiti chiave in cui si esprime il primato tecnologico di Paradox Engineering, che
offre wireless sensor network per ambienti smart, reti virtuali globali e versioni OEM delle
proprie tecnologie, tutte basate su standard aperti. Fondata nel 2005 in Svizzera, l’azienda
è oggi parte del gruppo giapponese MinebeaMitsumi, che ha acquisito l’intero capitale e gli
asset di Paradox Engineering SA nel luglio 2015.
2.6.1 Infrastruttura
I device IoT di Paradox sono connessi a dei gateway che a loro volta comunicano con il
DeviceManager, che è un servizio del Central Management System (CMS). Il CMS (vedi
figura 2.2) usa un architettura a microservizi, questa ha diverse caratteristiche:
• ha una maggiore scalabilità rispetto ad architetture tradizionali grazie alla sua capacita
di essere modulabile
• permette un ottima flessibilità poiché è possibile impiegarla con diverse combinazioni
di microservizi in base alle esigenze
• è possibile aggiornare singoli servizi senza perturbare le funzionalità dei altri servizi
• vengono usati dei MQTT brokers per la comunicazione tra i servizi, questa soluzione
permette un canale di comunicazione centralizzato ed evita di dover creare canali di
comunicazioni specifici per i singoli servizi
• i servizi del BackEnd hanno accesso al database ed ogni servizio è il proprietario dei
dati su cui lavora e non può accedere a dati di altri servizi, lo scambio di informazioni
tra servizio avviene solamente tramite API
• le applicazioni del FrontEnd non hanno accesso al database e devono richiedere le
informazioni di cui necessitano tramite API call ai servizi di BackEnd
A Workflow Automation Engine (WAE) for event processing in Iot Platform9
Figura 2.2: Architettura CMS Paradox
2.6.2 Formato trasmissione telemetria
I dati transitano grazie ha un sistema di publish/subscribe, il message broker può essere sia
un MQTT server che un server Kafka, il secondo è preferibile quando il traffico è elevato e
il sistema deve garantire scalabilità. I dati sono mandati in formato JSON e possono essere
compressi con la libreria zlib. Il modello dei dati è basato sullo standard OMA Lightweight.
L’implementazione del data model è salvata nel LWM2M Registry che definisce l’insieme
degli oggetti gestiti dal sistema.
LwM2M registry contiene identificativi per una grande variante di dati che possono viag-
giare da e verso dispositivi IoT. Per esempio, i dati riguardo all’umidità vengono codificati
con l’identificativo 3304 e all’interno di questo oggetto sono contenute diverse risorse relati-
ve al umidità, per esempio la risorsa con ID 5700 contiene l’ultimo valore misurato, mentre
la risorsa 5701 contiene informazioni sull’unità di misura.
1 {
A Workflow Automation Engine (WAE) for event processing in Iot Platform10 Motivazione e contesto
2 " payload_ipso " : {
3 " bt " : 1 6 2 5 1 2 9 3 4 0 ,
4 " ver " : 1 ,
5 "e": [
6 {
7 "v": 48.490395,
8 "n": "6/0/0"
9 },
10 {
11 "v": 2.416155,
12 "n": "6/0/1"
13 }
14 ],
15 " bn " : " urn : dev : mac : 6 D 7 EC 7 9 4 0 7 6 9 E 6 0 0 /"
16 }
17 }
Listing 2.2: Esempio telemetria inviata dai device IoT
Come si può vedere nell’esempio, i dati sono all’interno del oggetto payload_ipso. Vengo-
no sempre inviati certi valori:
• payload_ipso.bn - il MAC address del dispositivo
• payload_ipso.bt - timestamp
• payload_ipso.ver - versione
L’informazione più importante è all’interno dell’array payload_ipso.e. Questo array con-
tiene una lista di oggetti, dove ogni oggetto ha una chiave n che indica l’identificativo della
risorsa nel LwM2M registry ed il secondo elemento è il valore di quella risorsa. Nel esempio
mostrato precedentemente la stringa "6/0/0" corrisponde alla risorsa 0 del object 6 che
corrisponde alla latitudine, che in questo caso è 2.416155.
Questi messaggi possono essere letti sottoscrivendosi ad un certo topic del broker MQTT.
Il topic è formato nel seguente modo:
1 < tenant >/ Devices / Data / < DeviceManager >/ Gateways / < MACGateway >/ Devices / <
IDDevice >/ Objects / < ObjectID >
Listing 2.3: Formato topic MQTT per telemetrie
Per esempio:
A Workflow Automation Engine (WAE) for event processing in Iot Platform11
1 pdxeng / Devices / Data / DeviceManager_1 / Gateways / F8 : DC :7 A :47:68: ED / Devices /
B1000007BE000300 / Objects /27017
Listing 2.4: Esempio topic MQTT per telemetrie
2.6.3 Formato trasmissione eventi
Gli eventi vengono trasmessi anche loro grazie a MQTT. Il formato è lo stesso delle tele-
metrie, nel caso degli eventi l’object ID è sempre 27000 mentre ci sono 6 resource ID che
vengono usati per descrivere l’evento (vedi tabella 2.1).
Resource ID Meaning Type
26251 Severity Integer
26252 Set Boolean
26253 Code Integer
26277 Reference Integer
5518 Timestamp Time
4014 LogData Opaque
Tabella 2.1: Resource IDs eventi
Severity descrive l’importanza del evento, ci sono quattro livelli di severity: INFORMATION,
WARNING, ALARM, ERROR.
Set è un booleano e indica se un evento si sta attivando o disattivando, è usato per quegli
eventi che hanno una durata. Per esempio, nel caso di una lampada, un evento indican-
te l’alto voltaggio potrebbe venire generato quando questa supera un certo limite, quando
il voltaggio della lampada, in un secondo momento, ritorna ai livelli desiderati un secondo
evento con la risorsa Set a false verrà inviato, questo secondo evento viene chiamato evento
di clear.
Code è il numero identificativo del evento, il numero di eventi è predefinito dal azienda.
Alcuni esempio possono essere:
• 0x01 - LM_VOLTAGE_LOW
• 0x02 - LM_VOLTAGE_HIGH
• 0x0F - EVENT_CONNECTED
• 0x3A - BATT_DISCONNECTED
Reference indica l’oggetto del LwM2M registry a cui è associato l’evento, per esempio, la
risorsa 27011 indica tutti gli eventi associati con l’illuminazione.
A Workflow Automation Engine (WAE) for event processing in Iot Platform12 Motivazione e contesto
LogData viene usato per inviare ulteriori informazioni se necessario. Per esempio, nel caso
di un evento di LM_VOLTAGE_LOW LogData contiene 2 byte di mVRMS (voltage root mean
square) e 2 byte di Threshold in Volt.
Di seguito un esempio di evento:
1 {
2 " payload_ipso " : {
3 " bn " : " urn : dev : mac : 8 4 8 4 3 3 B 1 0 0 0 0 0 7 BF /" ,
4 " bt " : 1 6 2 7 9 0 3 9 9 9 ,
5 "e": [
6 {
7 "n": "27000/0/26251",
8 "v": 1
9 },
10 {
11 " bv " : true ,
12 "n": "27000/0/26252"
13 },
14 {
15 "n": "27000/0/26253",
16 "v": 15
17 },
18 {
19 "n": "27000/0/26277",
20 "v": 3
21 },
22 {
23 "n": "27000/0/5518",
24 "v": 1627899560
25 },
26 {
27 "n": "27000/0/4014",
28 " sv " : ""
29 }
30 ],
31 " ver " : 1
32 }
33 }
A Workflow Automation Engine (WAE) for event processing in Iot Platform13
Listing 2.5: Esempio evento inviato dai device IoT
Questi eventi vengono inviati a un broker MQTT, il topic del evento può cambiare a dipen-
denza che l’evento sia stato generato da un device o da un gateway.
1 < tenant >/ Devices / Data / < DeviceManager >/ Gateways / < MACGateway >/ Events
Listing 2.6: Formato topic MQTT per eventi inviati dai gateway
1 < tenant >/ Devices / Data / < DeviceManager >/ Gateways / < MACGateway >/ Devices / <
IDDevice >/ Events
Listing 2.7: Formato topic MQTT per eventi inviati dai device
Per esempio:
1 pdxeng / Devices / Data / DeviceManager_1 / Gateways / F8 : DC :7 A :47:68: ED / Devices /
B1000007BE000300 / Events
2 pdxeng / Devices / Data / DeviceManager_1 / Gateways / F8 : DC :7 A :47:68: ED / Events
Listing 2.8: Esempio topic MQTT per eventi
2.6.4 API MQTT
Esiste un API per richiedere informazioni aggiuntive sui device come posizione, ID, MAC
address e zone a cui appartiene. Richieste e risposte di questa API viaggiano su MQTT
quindi sarà necessario pubblicare dei messaggi in un certo topic e sottoscriversi ad un altro
per leggere la risposta. Nell’ambito di questo progetto è utile ricevere informazioni supple-
mentari sui device IoT, queste informazione ci verranno fornite dal Configuration service.
Per fare una richiesta al Configuration service è necessario pubblicare i messaggi nel topic
pdxeng/Services/Requests/SLMS_DEVCONF_SERVICE. La risposta la si potrà leggere al
topic pdxeng/Services/Replies/, dove indicherà chi ha fatto
la richiesta, nel nostro caso il topic sarà quindi pdxeng/Services/Replies/nodered.
Le richieste si formano nel seguente modo:
1 {
2 " params " : { param_ 1 : 1 } ,
3 " command " : " api_call " ,
4 " message_id " : " 1 " ,
5 " requestor " : " nodered "
6 }
Listing 2.9: MQTT API call
A Workflow Automation Engine (WAE) for event processing in Iot Platform14 Motivazione e contesto
Le api call più interessanti per questo progetto sono quelle relative alle zone. Questa in-
formazione non viaggia assieme alle telemetrie o agli eventi, quindi è necessario fare API
call se si necessita di sapere a quali zone appartiene un device. Le zone hanno un centro e
possono avere dei limiti geografici. Le zone nel sistema IoT di PE seguono una gerarchia ad
albero dove la radice è la zona 1. Si possono, inoltre, creare zone all’interno di altre zone.
Per esempio, la zona Roma è figlia della zona Italia che è a sua volta figlia della zona 1. In
questo modo un device appartenente alla zona Roma è anche appartenente alla zona Italia
e alla zona 1. Di seguito le API:
getDevicesByZoneId permette di ottenere informazioni su tutti i nodi appartenenti ad una
zona. Come parametri prende zone_oid che sarà un intero ed indicherà la zona a cui si è
interessati:
1 {
2 " params " : { " zone_oid " : 1 } ,
3 " command " : " getDevicesByZoneId " ,
4 " message_id " : " 1 " ,
5 " requestor " : " nodered "
6 }
Listing 2.10: MQTT API call getDevicesByZoneId
Come risposta si otterrà un array di device, per ogni device saranno fornite varie informazio-
ni, tra cui: ID device, MAC address device, ID e MAC address del gateway a cui è collegato,
latitudine e longitudine, stato del nodo, label ed altro.
Un’altra API call interessante è getZoneList, questa chiamata permette di ottenere tutte
le sotto-zone di una certa zona. Il nodo radice è la zona 1 e tutte le altre zone saranno sue
discendenti, per questo motivo richiedere le sotto-zone della zona 1 equivale a chiedere la
lista di tutte le zone.
2.6.5 Inviare comandi ai device
È possibile inviare comandi ai device, questo allo scopo di settare alcuni parametri. per
esempio, è possibile settare il dimming di una lampada oppure le coordinate di un device
che non ha un GPS integrato. Il LwM2M registry definisce quali risorse sono di sola lettura e
quali invece si possono sovrascrivere, questo ci permette di avere già un standard su come
identificare i parametri che si vogliono modificare.
1 {
2 " command " : " set_ipso_object " / " get_ipso_object " ,
3 " requestor " : " nodered " ,
A Workflow Automation Engine (WAE) for event processing in Iot Platform15
4 " message_id " : " 1 " ,
5 " params " : {
6 " gateway_mac " : string ,
7 " node_mac " : string ,
8 " objects " : [ {
9 " object_id " : int ,
10 " instance_id " : int ,
11 " resource_id " : int ,
12 " value " : " < val >" # come stringa
13 }]
14 }
15 }
Listing 2.11: Come mandare comandi ai device
Come si può vedere dall’esempio appena mostrato, per mandare un comando ai device è
necessario indicare sia il MAC address del nodo sia quello del gateway, questo perché il
sistema deve essere informato su quale gateway il nodo desiderato è collegato. All’inter-
no dell’array objects si definiscono tutte le risorse che si vogliono modificare e il nuovo
valore. Oltre a modificare le risorse è possibile anche solo richiederne l’attuale contenuto,
per fare ciò è necessario indicare nel parametro "command" "get_ipso_object" invece
di "set_ipso_object". Questo comando deve essere inviato al topic pdxeng/Devices/
Commands/Gateways/ e le risposte si potranno leggere al topic
pdxeng/Devices/Replies/, queste risposte riguardano il corretto inoltro del
comando al gateway. Per controllare se il valore è stato cambiato bisogna leggere la
telemetria come specificato al capitolo 2.6.2.
A Workflow Automation Engine (WAE) for event processing in Iot Platform16 Motivazione e contesto A Workflow Automation Engine (WAE) for event processing in Iot Platform
17
Capitolo 3
Problema
Nelle IoT platform un aspetto importante è quello di gestire eventi e relative notifiche. Queste
piattaforme ricevono misure dai sensori o direttamente eventi dai dispositivi sul campo, li
processano, memorizzano e analizzano per poi generare diversi tipi di azioni che vanno
dalla creazione di allarmi (per esempio misura sopra soglia) a notifiche di diverso tipo, come
la creazione di report o invio di messaggi, fino all’aggregazione degli stessi eventi in altri
eventi complessi.
3.1 Richiesta
La piattaforma di Paradox Engineering integra un gestore di eventi che implementa un set
di logiche personalizzabili, ed un Complex Event Processing engine ad oggi dedicato ad
un dominio specifico di logica applicativa. Si vuole quindi aggiungere gli strumenti neces-
sari per rendere il CEP engine in grado di supportare diversi domini applicativi attraverso
l’integrazione di un Workflow Automation Engine (WAE). Lo strumento dovrà avere una con-
figurabilità che sia sufficientemente intuitiva e flessibile per poter rendere il sistema efficace
e facile da usare. Per fare questo è utile avere uno strumento per la realizzazione dei flussi
logici (visual coding) e la loro automazione (workflow automation engine). È stato quindi
richiesto di:
• studiare i sistemi di gestione degli eventi, in particolare i sistemi di complex event
processing
• studiare i sistemi di backend e frontend già esistenti
• valutare i sistemi studiati secondo dei parametri ben definiti (vedi capitolo 3.2.3)
• definire una proposta per la realizzazione del tool
• implementare un prototipo e integrarlo nel CMS
• preparare una demo che mostri dei casi d’uso interessanti
A Workflow Automation Engine (WAE) for event processing in Iot Platform18 Problema
3.2 Requisiti
L’analisi dei requisiti dell’utilizzatore del sistema è fondamentale e permette di definire una
metrica di giudizio e scelta che consideri gli aspetti più importanti.
3.2.1 Casi d’uso
Di seguito verranno elencati alcuni casi d’uso che il WAE deve poter gestire:
• Eventi anomali: non frequenti, richiedono delle regole che generano un evento e ne
inviano la notifica quando un device (o gruppo di device) riporta dei dati di telemetria
anomali per un certo numero di volte.
• La gestione della notifica deve quindi poter rispondere all’evento con delle azioni sui
device, per esempio accendendo un led.
• Un device che continua a mandare sempre lo stesso valore di telemetria è anomalo,
bisogna quindi segnalarlo.
• Il sistema deve anche essere in grado di segnalare consumi di batteria sopra la norma,
analizzando i dati di telemetria sulle attività svolte dal dispositivo.
3.2.2 Building blocks
Qui di seguito verranno elencati alcuni diversi input e output che il WAE dovrà essere in
grado di gestire, per quanto riguarda gli input:
• Più di X occorrenze dell’evento A
• Più di X occorrenze di una telemetria sopra una certa soglia
• Processi pianificati (Ogni notte alle 2:00)
Mentre per gli output:
• Nuovi eventi
• Notifiche (e-mail)
• Inviare comandi (es. accendere una lampada)
3.2.3 Valutazione dei tool
I prodotti software esistenti verranno valutatati sui seguenti punti:
• Risorse (RAM, CPU, ...) utilizzate dal prodotto in stand-by oppure in base al carico di
lavoro e quindi in base al numero di eventi che elabora.
A Workflow Automation Engine (WAE) for event processing in Iot Platform19
• La possibilità di scalare il prodotto, magari anche automaticamente. È richiesto che
le regole possano essere stateful, è quindi necessario trovare una soluzione che si
possa scalare mantenendo la possibilità di avere uno stato, per esempio, la richiesta
di poter raggruppare gli eventi per intervallo di tempo.
• Tipi di dati che il prodotto è in grado di elaborare. Per esempio, poter inviare gli eventi
in formato binario.
• Possibilità di modificare regole a runtime. Questo permette di velocizzare il deploy di
nuove regole.
• Licenza d’uso, è importante analizzare se il prodotto è gratuito oppure se la licenza
obbliga l’azienda a pubblicare il codice del prodotto sotto la stessa licenza (esempio
GPL).
• Integrabilità con la piattaforma IoT di PE in uso. Possibilità di riusare le informazione
già presenti nella IoT platform, come la descrizione dei device e gruppi di device.
• Security: gestione e riuso dell’autenticazione degli utenti integrata nella IoT platform.
• Possibilità di esportare e importare le configurazioni.
• Diffusione del software: esistenza di comunità di sviluppatori, loro livello di attività e
possibilità di avere supporto.
• Maturità del software e suo ciclo di vita, è ragionevole scegliere un prodotto esistente
da diverso tempo e stabile che probabilmente verrà supportato ancora per diversi
anni. È consigliato evitare prodotti end of life o prodotti sviluppati da una sola persona
che rischiano di essere abbandonati.
• Curva di apprendimento. La difficoltà di scrittura di nuove regole è un fattore da
prendere in considerazione.
A Workflow Automation Engine (WAE) for event processing in Iot Platform20 Problema A Workflow Automation Engine (WAE) for event processing in Iot Platform
21
Capitolo 4
Stato dell’arte
Alla tabella 4.1 si può vedere la lista di tool che si è scelto di analizzare per questo lavoro.
Tutti i tool analizzati, a parte ThingsBoard professional e AWS sono gratuiti.
Nome Licenza Ultimo update
Node-RED[9] Apache-2.0 18.05.2021
ThingsBoard Comunità[12] Apache 24.03.2021
ThingsBoard Professional[12] Proprietary Sconosciuto
Apache NiFi[4] Apache-2.0 16.07.2021
Apache Flink[2] Apache-2.0 05.08.2021
Drools[6] Apache-2.0 13.05.2021
AWS IoT Core[1] Proprietary Sconosciuto
Tabella 4.1: Software valutati in questo documento
4.1 Node-RED
Node-RED è un tool di programmazione flow-based mantenuto dalla JS Foundation. I crea-
tori lo definiscono come una rete di black-boxes (nodi), in cui ogni nodo riceve dei dati, li
elabora e invia l’output generato al successivo nodo. Il tool include una ricca serie di blocchi
(nodi) predefiniti e pronti all’uso. Inoltre c’è una comunità molto attiva e una vasta libreria di
blocchi di ogni tipo. La creazione di nuovi blocchi avviene in JavaScript ed è relativamente
semplice. Il tool permette l’aggiunta di nuovi blocchi e la modifica dei flussi senza dover fare
un nuovo deploy. I data flow possono essere esportati e importati, cosa utile, per esempio,
nel caso il flow venga progettato in un ambiente di test e poi importato nell’ambiente di pro-
duzione. L’interfaccia utente, web based, è semplice da inserire in applicazioni già esistenti.
Gli input supportati ufficialmente da Node-RED sono i seguenti:
• MQTT
• Websocket
A Workflow Automation Engine (WAE) for event processing in Iot Platform22 Stato dell’arte
• Rest API
Esistono inoltre vari blocchi creati dalla community che aggiungono altre fonti come, per
esempio, Kafka.
Node-RED è un tool semplice che fornisce il supporto per la creazione dei flussi logici.
Diversi dei requisiti di sistema richiesti non sono presenti. Per esempio, non ha un siste-
ma di autenticazione, non è possibile suddividere i device e flows per tenent e non è stato
pensato per scalarlo in ambienti con un gran numero di eventi. Per quanto riguarda la sca-
labilità si potrebbe pensare di scalare il software creando più istanze dello stesso identico
Node-RED, questo però creerebbe dei problemi. Ogni nodo avrebbe la sua interfaccia web
e questo sarebbe uno spreco di risorse, inoltre bisogna fare in modo che aggiornando la
logica su una istanza venga aggiornata anche sulle altre. Il problema più grande riguarda
però l’elaborazione stateful di dati, per esempio è possibile raggruppare eventi in un certo
lasso di tempo (funzione richiesta dall’utente), ma questa funzionalità combinata con lo sca-
ling creerebbe ulteriori problemi in quanto richiederebbe che le diverse istanze di Node-RED
comunicassero tra di loro. Per esempio, se volessi raggruppare tutti gli eventi ricevuti nel
lasso di 10 minuti dovrei fare in modo che tutti gli eventi passino dalla stessa istanza questo
però va in conflitto con la scalabilità orizzontale.
4.2 ThingsBoard Community
ThingsBoard è una piattaforma IoT completa, open-source, con l’obbiettivo di abilitare lo
sviluppo e la gestione di progetti IoT, fornendo scalabilità e configurabilità. In pratica può
essere considerato un sistema in larga parte alternativo alla piattaforma IoT di Paradox En-
gineering.
ThingsBoard permette un’architettura a microservizi è quindi pensato per essere scalabi-
le. Nel loro sito ci sono alcuni esempi di deploy interessanti per poter stimare risorse ne-
cessarie in base al numero di device e dati che il cluster deve ricevere. Inoltre, può essere
impiegato in high availability mode ed è fault-tolerant poiché ogni nodo nel cluster e identico.
È possibile creare dei nuovi blocchi personalizzati in Java, questo però richiede di fare un
nuovo deploy del server.
4.3 ThingsBoard Professional
Questo prodotto ha tutte le funzionalità della versione community più alcune funzionalità co-
me l’utilizzo di blocchi che permettono l’aggregazione di dati. È anche possibile raggruppare
device in gruppi e pianificare azioni come la creazione di report.
A Workflow Automation Engine (WAE) for event processing in Iot Platform23
La versione community permette di usare MQTT ma i device devono connettersi al ser-
vizio MQTT integrato di ThingsBoard, se si desidera usarne uno esterno è necessaria la
versione professional, lo stesso vale per altri servizi come Kafka.
È importante poter aggregare gli eventi ricevuti, la versione Professional, come spiega-
to precedentemente, mette a disposizione dei blocchi che permettono di aggregare i dati
temporalmente. Si potrebbe pensare di sviluppare questi blocchi così da evitare di usare
la versione professional. Lo sviluppo di questi blocchi non è però banale poiché bisogna
assicurarsi che siano in grado di lavorare in un cluster con più istanze.
4.4 Apache NiFi
Sistema per processare flussi di dati mantenuto da Apache, basato sul concetto di program-
mazione flow-based, ha un interfaccia web per progettare i flussi di dati che possono essere
modificati a runtime. È stato pensato per ingerire flussi di dati da diverse fonti, analizzare
questi flussi e distribuire i dati verso altri sistemi. I componenti dei flussi che si occupano di
elaborare i dati si chiamano processori, esistono molti processori per le operazioni più co-
muni ed inoltre è possibile svilupparne di personalizzati in Java. Questi processori vengono
eseguiti in parallelo e quindi devono essere thread-safe, questo rende il loro sviluppo più
complicato. È possibile usare il software in un cluster e scalarlo usando ZooKeeper (figura
4.1). Si può configurare in varie maniere
Figura 4.1: Apache NiFi con ZooKeeper
A Workflow Automation Engine (WAE) for event processing in Iot Platform24 Stato dell’arte
4.5 Apache Flink
Apache Flink è un tool open source che si occupa di fare processing stateful di stream di
dati. È scalabile e pensato per le applicazioni business-critical. Viene usato per esempio da
Amazon nel loro prodotto Amazon Kinesis.
Il software ha 4 diverse API per l’elaborazione dello streaming (vedi figura 4.2). Da quelle
più ad alto livello come SQL fino a quelle più complete come Stateful Stream Processing[3].
Il prodotto non ha un tool di visual coding già pronto, se lo si desidera è necessario utilizzar-
ne uno esterno e implementare una traduzione del visual coding in una delle API mostrate
a figura 4.2.
Figura 4.2: API Apache Flink [3]
Il software permette di essere impiegato in modi diversi e su piattaforme diverse. Di seguito
le diverse modalità. [3]
• Session Mode. Lo stesso cluster permette di eseguire tutti i lavori che riceve. Tutti i
lavori condividono lo stesso Task Manager.
• Per-Job Mode. Questa modalità fa sì che un cluster possa eseguire un solo job e
questo deve essere definito a deploy time. Permette un isolamento maggiore rispetto
al session-time.
• Application Mode è una via di mezzo delle due precedenti. Richiede, come il Per-Job
Mode, di fornire i job in deploy time, in questo caso però se ne possono fornire più di
uno.
Il software può essere caricato in 2 modi Standalone oppure con un resoruce provider. I
resource provider permettono di allocare e de-allocare risorse in caso di aumento o diminu-
zione del carico di lavoro e permettono anche di fare ripartire i processi falliti[3]. Mentre per
A Workflow Automation Engine (WAE) for event processing in Iot Platform25
quando riguarda la modalità standalone questo compito e lasciato all’utente. È possibile ca-
ricare la modalità standalone in locale, su docker oppure su kubernetes. Invece la modalità
con resource provider può essere caricata su: Kubernetes, YARN e Mesos.
Il software ha anche una modalità High Availability, questa crea dei servizi che tiene in
stand-by e vengono attivati immediatamente dopo il crash di un servizio in funzione. Questa
funzionalità si può ottenere con ZooKeeper oppure Kubernetes[3].
Gran parte delle operazioni possono essere parallelizzate. Si può definire per ogni TaskMa-
nager quanti task può elaborare contemporaneamente. Inoltre per ogni job si può definire
quanto lo si vuole parallelizzare. Per esempio potrei avere 3 TaskManager che possono
elaborare 2 task contemporaneamente e potrei chiedere al cluster di elaborare un job con
parallelizzazione 6 e il carico di lavoro di questo job verrebbe distribuito in tra i 3 TaskMa-
nager automaticamente. Si può inoltre utilizzare la Reactive Mode che permette di scalare i
job automaticamente facendo si che utilizzi tutte le risorse a disposizione del cluster[3] (vedi
figura 4.3).
Figura 4.3: Parallelizzazione stream[3]
Si può settare la sicurezza con kerberos[3].
• Per utilizzare connettori (es. Kafka)
A Workflow Automation Engine (WAE) for event processing in Iot Platform26 Stato dell’arte
• Per autenticazione su ZooKeeper oppure Hadoop
Questi sono i connettori già esistenti che è possibile utilizzare in Flink[3]. Per source si
intende tutti i dati che Flink può ricevere in input ed elaborarli mentre per sink si intende
dove il risultato dell’elaborazione può venire salvato.
• Apache Kafka (source/sink)
• Apache Cassandra (sink)
• Amazon Kinesis Streams (source/sink)
• Elasticsearch (sink)
• FileSystem (Hadoop included) - Streaming only (sink)
• FileSystem (Hadoop included) - Streaming and Batch (sink)
• RabbitMQ (source/sink)
• Apache NiFi (source/sink)
• Twitter Streaming API (source)
• Google PubSub (source/sink)
• JDBC (sink)
FlinkCEP è una libreria per il complex event processing che permette di rilevare pattern di
eventi in uno stream di eventi. Qui di seguito dei semplici esempi di utilizzo di questa libreria.
Si possono fare se necessario anche logiche più complesse[3].
1 // expecting 4 occurrences
2 start . times (4) ;
3
4 // expecting 0 or 4 occurrences
5 start . times (4) . optional () ;
6
7 // expecting 2 , 3 or 4 occurrences
8 start . times (2 , 4) ;
9
10 // expecting 2 , 3 or 4 occurrences and repeating as many as possible
11 start . times (2 , 4) . greedy () ;
12
13 // expecting 0 , 2 , 3 or 4 occurrences
14 start . times (2 , 4) . optional () ;
15
16 // expecting 0 , 2 , 3 or 4 occurrences and repeating as many as possible
17 start . times (2 , 4) . optional () . greedy () ;
A Workflow Automation Engine (WAE) for event processing in Iot Platform27
18
19 // expecting 1 or more occurrences
20 start . oneOrMore () ;
Listing 4.1: FlinkCEP - Patter API
Flink permette anche l’elaborazione stateful di stream di dati. Queste elaborazione sono
fault tolerant e sono parallelizzabili fra più istanze[3].
4.6 Drools
Drools fornisce un rule engine il quale e in grado di processare dati in input, chiamati facts,
e ritornare un output. Le regole possono essere scritte in Drools Rule Language (DRL) op-
pure come Decision Tables in un file Excel. Le azioni che possono essere eseguite dal rule
engine sono codice Java, quindi è potenzialmente possibile svolgere qualsiasi azione che
Java permette.
Drools supporta la modalità stream per analizzare gli eventi, in questa modalità Drools co-
nosce il concetto di flusso ed e in grado di capire quanto vecchi sono alcuni eventi. Grazie
a questo può ritardare certi eventi oppure creare delle sliding window.
Attualmente Drools non supporta la scalabilità, questo è un requisito importante del siste-
ma poiché una istanza di drools potrebbe non essere abbastanza performante per leggere
i dati inviati da tutti i device. I sviluppatori di Drools hanno però comunicato che la prossi-
ma versione 8.x che dovrà uscire a fine 2021 supporterà una scalabilità orizzontale ed high
availability.
In drools ad ogni modifica o aggiunta di regole è necessario ricaricare l’applicazione, esi-
stono però dei metodi per aggirare il problema, da Drools 6 in poi, come inserire tutti i DRL
in una cartella e far si che Drools recuperi le regole da quella cartella.
4.7 AWS IoT Core
AWS IoT Core è il servizio di Amazon per gestire device IoT, è considerabile una alternativa
alla piattaforma di PE. Per quanto riguarda la trasmissione di eventi è possibile usare i
protocolli MQTT o HTTPS. Il prodotto permette anche di gestire delle regole, queste regole
possono essere scritte in un linguaggio SQL-like e supportano task come:
• Filtrare dati ricevuti da un device
• Scrivere dati ricevuti su DB
• Inviare SMS
A Workflow Automation Engine (WAE) for event processing in Iot Platform28 Stato dell’arte
• Invocare Lambda Functions
• Inviare dati su un Elasticsearch
• Inviare dati su una web application
I vantaggi di questo prodotto sono la semplicità nella sua gestione poiché gestito da Ama-
zon non richiede manutenzione da parte del cliente.
Il prodotto permette di creare regole semplici con il loro linguaggio, non ha una UI per il
visual coding e crearla risulta molto difficile visto che non e possibile modificare il prodotto
di Amazon.
A Workflow Automation Engine (WAE) for event processing in Iot Platform29
Capitolo 5
Valutazione
La versione community di ThingsBoard è molto limitata non permette di leggere dati da
server MQTT esterni e non permette di raggruppare dati in finestre temporali. ThingsBoard
Professional è a pagamento, ha funzionalità extra non necessarie che potrebbero renderlo
più pesante in termini di risorse, inoltre è proprietario il che rende più difficile aggiungere
nuove funzionalità se necessario. ThingsBoard non si occupa solo di gestire eventi ma è
una completa IoT platform, in larga parte alternativo alla piattaforma IoT di Paradox En-
gineering. Apache NiFi non è stato pensato per il trattamento di dati ma piuttosto per
aggregare e redirigere flussi di dati. È in grado di fare semplici elaborazioni di dati JSON ma
risulta limitato se si desiderano fare elaborazioni più complesse. Inoltre programmare nuovi
processori per NiFi non è semplice perché i processori eseguono in parallelo e quindi bi-
sogna prendere in considerazione la thread-safety mentre si programma. Drools permette
di creare regole con delle Decision Tables su excel questo risulta scomodo inoltre bisogna
ricaricare il sistema ad ogni modifica delle regole. AWS IoT Core è closed source quindi
non si può modificare il software per adattarlo alle proprie esigenze, obbliga i propri utenti
ad utilizzare il cloud Amazon rendendo più difficile abbandonarlo se lo si desidera. Inoltre
come per ThingsBoard, AWS IoT Core è un alternativa alla piattaforma di PE. Node-RED
è molto semplice da utilizzare ma non è pensato per venir utilizzato in contesti con grandi
flussi di dati, infatti non è clusterizzabile e non ha un supporto per il multi-tenency.
Ritengo che Apache Flink sia il tool più completo e robusto di tutti i tools visti finora, è
in grado di fare elaborazione stateful parallela di stream ed è stato progettato fin da subito
per essere scalabile. Questi due aspetti sono molto importanti perché difficili da ottenere
in un tool già esistente. L’unico aspetto negativo è che non dispone di un tool di visual
coding, questo infatti è un requisito importante, sarebbe quindi interessante sviluppare un
software di visual coding in grado di sfruttare le potenzialità di Apache Flink, una possibilità
potrebbe essere quella di usare la UI di Node-RED. Node-RED infatti genera un XML per
il flusso creato e sarebbe quindi possibile creare un software che converte questo XML in
A Workflow Automation Engine (WAE) for event processing in Iot Platform30 Valutazione
codice funzionante per Flink. Un’alternativa a Flink sarebbe quella di utilizzare Node-RED
ed renderlo scalabile orizzontalmente, però ritengo sia più semplice sviluppare un interfac-
cia grafica per un software già esistente piuttosto che riscrivere parte di un software per
aggiungere il supporto alla clusterizzazione. Per far si che un software sia impiegato come
cluster è necessario bilanciare il carico di lavoro, rendere i nodi fault-tolerant, fare attenzione
al utilizzo di risorse condivise fra più nodi (evitare race condition). Per questi motivi il mio
suggerimento sarebbe quello di utilizzare Apache Flink e sviluppare un’interfaccia grafica
per semplificare la creazione di regole.
Assieme al cliente si è deciso di optare per una soluzione gratuita che verrà implementata
nel cloud privato di Paradox Engineering, quindi proposte come ThingBoards Professional
e AWS IoT Core sono state scartate. Tra i tool analizzati i più promettenti sono stati Apache
Flink e Node-RED per motivi opposti. Apache Flink permette di scalare il sistema senza
problemi ed è in grado di elaborare una grande quantità di dati ed ha una libreria specifica
per il CEP. Invece Node-RED ha un interfaccia grafica intuitiva, una grande community ed è
facilmente personalizzabile.
Il requisito di avere un interfaccia grafica che permetta a utenti che non sanno program-
mare di creare regole, è molto importante per il cliente poiché una possibile versione finale
verrebbe fornita ai clienti. Questo ha portato ha due opzioni:
• utilizzare Apache Flink e cercare di creare un interfaccia grafica per il loro sistema.
• creare i primi prototipi su Node-RED ed affrontare le sue mancanze, come la scalabi-
lità o il supporto al multi-tenent successivamente e in modo incrementale.
Si è deciso di continuare con Node-RED, vista la durata del progetto si è pensato che questa
opzione possa permettere di portare un prototipo in grado di soddisfare la maggior parte dei
casi d’uso entro la scadenza.
A Workflow Automation Engine (WAE) for event processing in Iot Platform31
Capitolo 6
Prototipo e casi d’uso
Si è deciso di sviluppare un prototipo su Node-RED per testare la sua fattibilità come scel-
ta. L’obiettivo è quello di creare dei blocchi personalizzati che semplificano la creazione di
regole e permettano all’utente di creare nuove regole senza la conoscenza di linguaggi di
programmazione.
6.1 Struttura, regole e gruppi
Prima di iniziare con la creazione dei nodi si sono analizzati i requisiti e si è cercato di
estrapolare tutti i differenti tipi di nodi necessari alla creazione di regole. In base ha questa
analisi si è deciso di suddividere i blocchi in 3 gruppi:
• Input
• Condizione
• Output
Ogni regola dovrà avere un input, 0 o più condizioni e un output. Questi blocchi dovranno
essere collegati tra di loro nell’ordine con il cui sono stati presentati, infatti non si potrà col-
legare un nodo condizione dopo uno di output.
L’input è quel gruppo di nodi che permettono di ricevere dati dall’esterno e di integrarli
nel formato di Node-RED. In questa categoria i nodi leggono dati di telemetria nel formato
della piattaforma IoT di PE. Queste telemetrie possono essere più o meno compresse. L’in-
put può inoltre venire filtrato in base a dei parametri preimpostati. I nodi in questo gruppo
richiedono di indicare a quali dati si è interessati, questo è utile sia per filtrare dati non ine-
renti sia perché i dati possono contenere più telemetrie assieme, è quindi necessario isolare
quelle desiderate cosi da facilitare i nodi successivi nelle operazioni su questi dati. Infine i
dati possono venire raggruppati. Il raggruppamento è utile in due casi: il primo quando una
A Workflow Automation Engine (WAE) for event processing in Iot Platform32 Prototipo e casi d’uso
regola necessita informazioni da dispositivi diversi (per esempio la temperatura media dei
device in una zona); il secondo è quando la stessa regola va applicata su più device, in que-
sto caso è possibile raggruppare i dati per device (per esempio segnalare se la temperatura
di un device è sopra una certa soglia). Se volessimo applicare quest’ultimo esempio senza
il secondo tipo di raggruppamento, sarebbe necessario creare tante regole uguali per ogni
device. Di seguito una lista di operazioni che i nodi in questa categoria potranno svolgere:
• leggere telemetrie da broker MQTT
• leggere eventi da broker MQTT
• aggregare telemetrie ricevute in una certa finestra temporale da tutti i device
• aggregare telemetrie ricevute in una certa finestra temporale per device singolo
• rilevare se l’informazione è stata compressa e in caso decomprimerla con zlib
• filtrare dati in base a ID del device, MAC address del gateway e zona di appartenenza
del device
Il gruppo condizioni racchiude la parte più importante della regola, è quel gruppo che
analizzando i dati ricevuti in input, valuterà se questi dati sono anomali e meritano di essere
segnalati. Inizialmente queste regole, vista la complessità nel realizzarle, venivano scritte in
JSONata. Si è poi cercato di creare dei nodi con un UI semplice in sostituzione a JSONata.
Di seguito alcuni esempi di cosa sono in grado di fare i nodi di questo gruppo:
• fare operazioni come: conte, medie e somme su gruppi di dati aggregati
• valutare se una telemetria non ha mai cambiato valore in un arco di tempo predefinito
• valutare se un evento non è stato resettato dopo un certo periodo di tempo.
L’output permette di decidere come segnalare l’evento. È possibile che l’output sia un
ulteriore evento pubblicato nel MQTT server oppure può essere un comando inviato a un
device (per esempio, se il consumo di batteria della lampada e troppo alto allora è opportuno
ridurre il suo dimming). Altri esempi di output possono essere l’invio di email o notifiche su
Telegram.
6.2 Configurazione
Uno dei requisiti è quello di permettere di dichiarare delle regole solo su certe zone, ogni
device è associato a una o più zone (vedi sezione 2.6.4). Le zone non vengono però inviate
assieme agli eventi è quindi necessario recuperare questa informazione prima di elaborare
gli eventi. Queste informazioni si possono richiedere utilizzando un’API MQTT come spie-
gato al capitolo 2.6.4.
A Workflow Automation Engine (WAE) for event processing in Iot PlatformPuoi anche leggere
