Manual d'Usuari per la creació de Quadres de Comandament (QdCs)
1. Tipus de QdC’s
Els quadres de comandament permeten visualitzar les dades emmagatzemades que provenen de la Plataforma Smart Region per tal de mostrar-les en un Dashboard i poder analitzar les dades de forma més ràpida i senzilla.
Existeixen dos tipus de QdC:
- Globals: d’interès per a totes les organitzacions
- Locals: específics d’una organització
1.1. Globals
Els QdC’s globals es creen pels usuaris super-administradors, personal de l’equip Smart Region de la Diputació de Barcelona.
Aquests es creen amb l’objectiu de que tots els municipis puguin fer-ne ús, on es troben diferents tipus d’informació:
- Anàlisi de dades per tipus de component específic
- Dades agregades de múltiples components
Actualment existeixen els següents QdC globals, agrupats per àrea:
1.1.1. Acústica:
- Anàlisi del soroll ambiental
- Anàlisi limitadors
1.1.2. Aigua:
- Anàlisi dades dipòsit
- Consum d’aigua
- Reg de parcs i jardins
1.1.3. Energia:
- Anàlisi interruptors
- Anàlisi usos punts de càrrega de vehicles elèctrics
- Balanç energètic instal·lació fotovoltaica
- Monitorització Mercat Municipal
1.1.4. Medi ambient:
- Anàlisi condicions ambientals
- Anàlisi meteorològic
- Anàlisi qualitat de l’aire
- Monitoratge dels temporals marítims
1.1.5. Mobilitat:
- Anàlisi flux de vehicles
- Anàlisi zones d’estacionament
1.1.6. Residus:
- Estació reciclatge de verds
1.1.7. Seguretat:
- Control aforament
- Càmera lectora de matrícules
Si es detecten nous requeriments per fer modificacions sobre algun QdC ja realitzat, o per la creació d’un nou cal posar-se en contacte a través del mail a la bústia smartregion@diba.cat
1.2. Locals
Els QdC’s locals es creen pels usuaris administradors de les organitzacions.
Aquests QdC’s es realitzen per necessitats específiques, que no puguin ser extrapolables a la resta d’organitzacions.
Per tant, cada organització té al seu abast tots els QdC’s globals, i els seus QdC’s locals de la seva pròpia organització.
2. Creació dels QdC’s
- Accés al Grafana
1. URL
https://pre-grafana.diba.cat (Entorn de Pre-producció)
https://grafana.diba.cat (Entorn de Producció)
2. Opció de menú
Des del visor general, a partir de la ruta Menú > Indicadors i Qdc > Grafana
URL's del visor:
https://pre-sentilo.diba.cat/ (Entorn de Pre-producció)
https://sentilo.diba.cat/ (Entorn de Producció)
- Estructura de dades:
1. Estructura de BBDD timescaleDB
Esquema simplificat de les principals taules involucrades als QdC:
sentilo_tenants: Es diu tenant a una organització, normalment una ciutat, que posseeix una instància virtual de Sentilo. Cada tenant pot gestionar de manera autònoma els seus proveïdors, components i sensors. Tots aquests elements són propietat de l'organització, i ningú aliè a l'organització no hi pot accedir, tret que l'organització concedeixi permisos d'accés a altres organitzacions.
sentilo_providers: Es diu proveïdor a una entitat que representa un grup de components i els permet comunicar-se amb Sentilo per enviar dades i rebre ordres.
sentilo_components: Es diu component a un element de maquinari o programari, amb localització geoespacial (fixa o mòbil) que podria estar compost per 1 o més Sensors.
sentilo_sensors: Es diu sensor a un element de maquinari o programari amb la capacitat de generar una observació (dades).
sentilo_obsertavions: Es diu observació al valor de la magnitud física mesurada per un sensor en un instant concret, i expressada a les unitats definides a sentilo_sensors.unit. Les dades que envia el proveïdor es guarden als camps value i event_timestamp (timestamp és la traducció d'event_timestamp al format DD/MM/YYYYTHH24:MI:SS).
Qualsevol accés a la taula sentilo_observations s’ha de fer amb sensor i proveïdor.
El que identifica un sensor és el sensor i el proveïdor, ja que pot haver-hi sensors amb el mateix identificador i diferent proveïdor.
2. Variables Sentilo necessàries (tenant_id, povider_id, component_id, nova usuari connectat, Url extesa i Url imatge, doc, informació addicional)
- Definició de variables
1. Comunes a tots els QdC’s
component_type: Nom identificador del tipus de component que es vol monitorar al QdC.
tenant_list: Definida per select id AS "__value", name AS "__text" from sentilo_tenants where id in ( select distinct tenant from sentilo_components c where c.type='${component_type}' and c.doc->'additionalInfo' is not null and exists ( select 1 from sentilo_sensors s where s.component=c.name and ( s.public_access or ${ul} ) ) ). Es tracta d'obtenir la llista d'organitzacions que posseeixen almenys un component de tipus 'component_type' i un sensor associat. S'obté filtrant la taula sentilo_components i agafant el camp tenant.
tenant_id: Definida per select id AS "__value", name AS "__text" from sentilo_tenants where id IN ('${tenant_list:csv}') limit 1. Es tracta d'agafar el primer element de 'tenant_list'. Quan l'usuari selecciona una opció del desplegable d'organitzacions, 'tenant_id' agafa el valor seleccionat.
bbdd: Definida per select (case when ('${tenant_id}' ~ '^[0-9]+$') then '_' else '' end) || '${tenant_id}' ||'.'. És una cadena de text que concatena el valor de 'tenant_id' i un punt al final. La DIBA és una organizació multi-tenant, és a dir, que les dades específiques de cada organització s'emmagatzemen dins d'una base de dades diferent. L'estructura de taules de totes elles és idèntica, diferenciant-se només per un prefix que identifica l'organització. Així, de manera general les dades dels sensors es troben a {$bbdd}sentilo_sensors, i per exemple, les dades de l'organització 'mataro' estan a mataro.sentilo_sensors.
ul (user logged): Per defecte, true. Es fa servir per controlar la privadesa de les dades. Alguns components i sensors poden tenir visibilitat privada, i només han de mostrar informació pels usuaris logats al sistema. Així, a les queries que impliquen sensors o components s'afegeix la clàusula de filtrat and ( s.public_access or ${ul} ). Quan un usuari no està logat, accedeix per un URL que conté &ul=false.
component_list: Definida per SELECT components.name AS "__value", components.alias AS "__text" <br>from (select name, doc ->> 'friendlyName' as alias from ${bbdd}sentilo_components c where type='${component_type}' and ( public_access or ${ul} = true ) and exists (select 1 from ${bbdd}sentilo_sensors where component=c.name)) components. Es tracta d'obtenir, per l'organització 'bbdd' la llista de components de tipus 'component_type' que tinguin almenys un sensor associat.
component_id: Definida per select name from ${bbdd}sentilo_components where name in (${component_list}) limit 1. Es tracta d'agafar el primer element de 'component_list'. Quan l'usuari selecciona una opció del desplegable de components, 'component_id' agafa el valor seleccionat.
provider_list: Definida per select distinct provider from ${bbdd}sentilo_components where type='${component_type}'. Es tracta d'obtenir la llista de proveïdors de components de tipus 'component_type' per l'organització 'bbdd'. Es fa servir poc.
provider_id: Definida per select provider from ${bbdd}sentilo_components where name ='${component_id}'. Es tracta d'obtenir el proveïdor del component 'component_id'.
2. Específiques
Hi ha una gran diversitat de variables, depenent del propòsit de cada QdC. Normalment, es construeix una variable per a cada tipus de sensor. Així, ens podem trobar:
sensors: select name AS "__value",name AS "__text" from ${bbdd}sentilo_sensors where provider='${provider_id}' and component= '${component_id}' and type='status' and (public_access or ${ul}).
temperature: select name AS "__value",description || ' (' || unit || ')' AS "__text" from ${bbdd}sentilo_sensors where provider='${provider_id}' and component= '${component_id}' and type = 'temperature' and ( public_access or ${ul} = true ).
vehicle_environmental_label: select name from ${bbdd}sentilo_sensors where type='vehicle_environmental_label' and provider='${provider_id}' and component= '${component_id}' and (public_access or ${ul}).
La mecànica és sempre la mateixa: accedir als sensors de l'organització 'bbdd' i filtrar pel tipus de component desitjat.
- Diferències entre organizacions municipals i supramunicipals
Una organització municipal, com es comenta a la definició de tenant, gestiona només les seves dades. En contrast, una organització supramunicipal pot accedir a les dades de diverses organitzacions a nivell de taules del catàleg: proveïdor, aplicacions, components, etc.
A l'entorn de la DIBA actualment totes les organitzacions són municipals excepte la "ptgu", que engloba totes les organitzacions.
A la organització “ptgu” accedeixen els usuaris super-administradors, amb visibilitat de totes les dades de catàleg de les organitzacions, i dret d’accés als esquemes específics on es pot accedir a les observacions registrades pels sensors.
Una organització municipal té accés a les taules sentilo_observations i sentilo_alarms.
Ara bé, una organització supramunicipal no té accés a la taula sentilo_observations de forma directa, però sí que tenen accés a les dades de cada entitat mitjançant un Dblink (DataBase Link) que s’utilitza el nom del municipi.
Per tant, una organització supramunicipal per accedir a la taula sentilo_observations de cada municipi cal utilitzar la sintaxis: <municipi<.sentilo_observations.
Això influeix en la manera de construir els Quadres de Comandament. L'estructura de variables que es defineix al punt anterior aplica a "ptgu" mentre que la resta d'organitzacions se simplifica.
A les organitzacions municipals:
- No cal definir les variables "tenant_list", "tenant_id" i "bbdd".
- No cal aplicar el prefix ${bbdd} a les queries. De fet, afegir-ho provoca un error.
- Desplegables dels dashboards i relació amb les variables globals
Es pot aplicar directament un desplegable a qualsevol de les variables globals mitjançant els camps "label" i "show on dashboard". Basta amb relacionar pel nom de l'etiqueta i aplicar "value" o "label and value".
- Fonts de dades
Cada organització posseeix la seva Base de Dades, a la qual es pot accedir directament des de Grafana. A "ptgu", a més a més, es disposa de les connexions a PRE i PRO.
La font de dades és única per cada organització. En conseqüència, quan es vol migrar un QdC d'una organització a una altre, s'ha d'editar el fitxer JSON corresponent, actualitzant a l'id de la font de dades de l'organització destí.
- Visibilitat dels QdC’s i de les dades
-
- Pública --> Com publicar un QdC
- Restringida --> Tractament visibilitat restringida de les dades
3. Visibilitat dels QdC's i de les dades
3.1. Publicar un QdC global
Per poder publicar un Quadre de Comandament global a la Plataforma Smart Region i poder veure el gràfic segons el tipus component caldrà tenir en compte que només els usuaris super-administradors ho podran realitzar, seguint els següents passos:
- Des del Quadre de Comandament creat clicar a “Compartir” i copiar l’URL d’enllaç fins al nom del QdC, tal i com es mostra en la imatge:
- Des de la Plataforma Smart Region, anar al tipus de component corresponent i afegir l’enllaç copiat al camp “URL extesa”.
En aquest enllaç cal afegir: ?var-tenant_id=${tenant_id}&var-provider_id=${provider_id}&var-component_id=${component_id}&kiosk&theme=light
Si hi ha diferents components amb el mateix tipus es definirà per defecte el mateix component.
Si per cada component es vol definir un QdC diferent, caldrà definir el camp “URL extesa” al component corresponent.
En resum:
- Si el component no té definida cap “URL extesa” s’utilitzarà la del tipus de component.
- Si el component té definida una “URL extesa” i també en té el tipus de component, s’utilitzarà la del component en específic.
3.2. Publicar un QdC local
Per publicar un QdC local és necessari tenir un usuari amb permisos d’administrador, seguint els següents passos:
- Des del Quadre de Comandament creat clicar a “Compartir” i copiar l’URL d’enllaç fins al nom del QdC, tal i com es mostra en la imatge:
- Des de la Plataforma Smart Region, anar al component corresponent i afegir l’enllaç copiat al camp “URL extesa”.
En aquest enllaç cal afegir: ?var-tenant_id=${tenant_id}&var-provider_id=${provider_id}&var-component_id=${component_id}&kiosk&theme=light
Si hi ha diferents components amb el mateix tipus de component caldrà definir la URL extesa a cada un dels components.
En aquest cas, no es pot definir el QdC per tipus de component i compartir-ho per tots els components.
3.3. Selecció de filtres als QdC's
Per tal de poder realitzar filtres als Quadres de Comandament cal accedir als gràfics estant loguejat i clicar a la tecla “ESC”.
En aquest moment, apareixerà una barra a la part superior on es podran realitzar els filtres segons informació que es vulgui.
En cas de que s’accedeixi sense estar loguejat no es podran realitzar filtres.
4. Accés als QdC's
Per tal de poder accedir a un QdC d’un component cal accedir al menú principal de la Plataforma Smart Region, on es visualitza el mapa que estan ubicats tots els sensors.
5. Annexos
- Taula amb la relació de QdCs - Ontologia - Fluxos NodeRED
3. Ontologies definides | SmartRegion Barcelona
- Tutorials de Grafana
https://grafana.com/tutorials/
- 168 lectures
