PROPOSTA DI PROGETTO
Nome in codice: Odin

Negli anni abbiamo voluto sviluppare una basecode condivisa e replicabile per creare progetti verticali molto in fretta. Il progetto è completamente costruito a moduli con una logica base completamente estendibile a seconda delle esigenze del cliente senza andare ad intaccarne la base. 

Odin permette la raccolta e l’elaborazione di dati a campo attraverso algoritmi specifici o IA. I dati possono essere fruiti sia RAW sia aggregati con diverse condizioni che il nostro sistema ti permette di inserire.

< Architettura />

Base estendibile aws

L’architettura è composta da tre macro sezioni ognuna con una specifica funzione:
Field Layer (area rossa):

ha il compito di gestire i dati da e verso i device a campo.

Data Layer (area azzurra):

ha il compito di immagazzinare i dati provenienti dal campo e diretti verso il campo.

Presentation Layer (area verde):

ha il compito di esporre delle API in grado di rendere i dati fruibili da GUI esterne e da programmi di terze parti.

I database scelti sono quelli base ma sono cambiabili o estendibili con altre tipologie di database per esempio SQL.

Il cloud scelto è AWS, il progetto è dockerizzato in modo che possa essere compatibile con il maggior numero di provider cloud possibili.

I dati, dopo essere stati generati dai diversi tipi di device a campo vengono immagazzinati in una coda di ingresso e, una volta elaborati dal Field Layer risultato immagazzinabili uniformemente nei database e nelle tabelle corrispondenti. Le regole di standardizzazione dei dati derivano da una combinazione di regole anagrafiche immagazzinate nel database Mongo e da dati passati direttamente dai device. I dati immagazzinati all’interno del Data Layer sono da distinguere in due tipi: dati da campo (generati dai device) e dati di anagrafica (inseriti a mano dall’utente o generati in automatico per autoapprendimento). I dati così salvati vengono poi resi disponibili tramite librerie ORM ad altri servizi (raggruppati nel Presentation Layer) che hanno il compito di renderli fruibili da client REST che forniranno una GUI per l’utente finale. Tramite GUI è anche possibile inviare dei comandi al campo passando sempre per il Field Layer.

Alcuni servizi non inseriti nello schema ma che saranno comunque presenti saranno quelli di Scheduling (necessario per permettere di automatizzare task ricorrenti come watchdog e polling) e quello di SSO. Per il servizio di scheduling verrà utilizzato il modulo node Agenda che permette di schedulare task e di eseguirli in un ambiente distribuito senza gestire manualmente la concorrenza dei processi. Per quanto riguarda le politiche ed i meccanismi di gestione degli accessi e autorizzazione delle richieste da parte dell’SSO verrà utilizzata la tecnologia Bearer, utilizzando un JWT minimale con chiave pubblica/privata.

Marketing Headquarter

Via Castelfidardo, 1 - Monza (MB)

Software house

Via Pastrengo, 9 - Seriate (BG)