Canali
Questa sezione presenta i canali smartCORE e descrive i principi del loro utilizzo.
Architettura
Nel contesto smartCORE, i canali garantiscono la comunicazione tra moduli produttori e moduli consumatori. Vengono creati e scritti da un solo modulo produttore e possono essere letti da più moduli consumatori. Dal punto di vista del software, un canale smartCORE (con timestamp) rappresenta essenzialmente un buffer circolare di valori di misura con timestamp di un tipo di dati definito in precedenza. Inoltre, un cosiddetto canale di variabile di processo rappresenta un singolo valore di misura con il timestamp del suo ultimo aggiornamento.
Tipi di canale e di dati
Si distingue fondamentalmente tra
- canali con timestamp (timestamped channels), che mettono a disposizione una serie temporale di valori di misura, e
- variabili di processo (process values), che mettono a disposizione soltanto l'ultimo valore di misura (ad es. un parametro o una proprietà) e il momento dell'ultima modifica, ma NESSUN andamento temporale.
Tutti i valori di misura "trasmessi" all'interno di un canale smartCORE hanno sempre un tipo univoco. Sono supportati i seguenti tipi di dati
| Tipo di dati | Descrizione |
|---|---|
| bool | Valori di verità booleani come true e false |
| int64 | numeri interi con segno a 64 bit |
| int32 | numeri interi con segno a 32 bit |
| int16 | numeri interi con segno a 16 bit |
| int8 | numeri interi con segno a 8 bit |
| uint64 | numeri interi senza segno a 64 bit |
| uint32 | numeri interi senza segno a 32 bit |
| uint16 | numeri interi senza segno a 16 bit |
| uint8 | numeri interi senza segno a 8 bit |
| double | numeri in virgola mobile a precisione doppia |
| float | numeri in virgola mobile a precisione singola |
| string | stringhe di caratteri codificate in UTF-8 |
| bytearray | blocchi di dati binari |
| gpslocation | strutture per le coordinate di posizione GPS, composte da tre numeri in virgola mobile a precisione doppia consecutivi per latitudine, longitudine e altitudine sul livello del mare |
Parametri dei canali
Complessivamente, inclusi i tipi di canale e di dati sopra indicati, è possibile specificare i seguenti parametri dei canali
| Parametro | Tipo di dati | Descrizione |
|---|---|---|
| name | STRING | Nome del canale |
| channelType | STRING ENUM | Tipo di canale, con timestamp ("timestamped") oppure variabile di processo ("processvalue") |
| dataType | STRING ENUM | Tipo di dati dei valori di misura (vedere sopra) |
| bufferSize | UINT > 0 | Dimensione del buffer, ossia numero massimo di valori di misura all'interno di una serie temporale prima che i valori più vecchi vengano sovrascritti |
| physicalDimension | STRING | Dimensione fisica del canale (ad es. velocità, tensione, temperatura, ...) |
| physicalUnit | STRING | Unità fisica del canale (km/h, V, °C, ...) |
| metaData | JSON OBJECT | Metadati definiti dall'utente |
| filter | JSON ARRAY of channel filter specifications | Cascata di filtri definita dall'utente (di norma per la riduzione dei dati) |
| persistent | BOOL | Flag che indica se il canale sopravvive a un riavvio del sistema |
| preserved | BOOL | Flag che indica se il canale viene caricato all'avvio di smartCORE da un database sul dispositivo di misura e scritto in tale database a intervalli di tempo regolari (utile ad es. per contatori o altre informazioni di esercizio) |
Integrazione negli stati operativi di smartCORE
Nei diversi stati operativi di smartCORE, i canali smartCORE vengono gestiti come segue. Per maggiori dettagli si rimanda alla documentazione sulla state machine di smartCORE.
Creazione dei canali da produrre
Il modulo produttore richiede alla gestione dei canali di smartCORE la creazione di un oggetto canale e ne riceve in cambio un riferimento.
Dal punto di vista del software, questa operazione è possibile esclusivamente nello stato operativo di inizializzazione dei canali producer (InitProducerChannels).
Selezione dei canali da consumare
Un modulo consumatore può richiedere in qualsiasi momento un riferimento ai canali messi a disposizione dalla gestione dei canali di smartCORE. Inoltre, tale modulo deve registrare un consumer (handle di lettura) di questo canale, operazione anch'essa possibile in qualsiasi momento.
Se questi canali sono già noti al momento della configurazione del modulo, nel software viene di norma utilizzato a tale scopo lo stato operativo di inizializzazione dei canali consumer (InitConsumerChannels).
Produzione di valori di misura nei canali
Dopo che la produzione di un modulo è stata segnalata a smartCORE (StartProduce), tale modulo può scrivere valori di misura nei propri canali producer. Ciò avviene utilizzando un timestamp, che può avere origini diverse (ad es. derivare direttamente dai dati oppure corrispondere al momento della produzione).
Nella maggior parte dei casi la produzione dei valori di misura non avviene direttamente, ma tramite una cascata configurata di filtri (filter chain), per lo più con l'obiettivo della riduzione dei dati.
In particolare nel contesto della riduzione dei dati si è rivelato utile il concetto di timestamp attendibile.
Timestamp attendibili (Trusted Timestamps)
In una sottosequenza di due valori di misura con timestamp consecutivi, si può assumere che il primo valore di misura sia valido fino al timestamp del secondo valore di misura (ESCLUSO). Per l'ultimo valore di una sequenza, e quindi anche per l'ultimo valore prodotto, non è invece noto fino a quando sia valido, o in altre parole se e quando arriveranno ulteriori valori di misura (identici o modificati).
La conseguenza è che l'intero intervallo di tempo trascorso dall'ultimo campione NON può essere utilizzato, ad es. per eseguire calcoli basati su di esso nei moduli consumatori.
Nell'ambito della riduzione dei dati ciò si è rivelato particolarmente d'ostacolo, poiché ad es. un valore costante viene prodotto una sola volta e poi semplicemente filtrato, cioè scartato.
Fondamentalmente NON è quindi possibile distinguere tra
- canali i cui valori di misura sono costanti e sono stati tutti filtrati tranne un valore iniziale,
- canali che temporaneamente non forniscono più valori di misura (ad es. perché si è verificato un ritardo dovuto al carico) e
- canali che non forniscono più valori di misura in modo definitivo (ad es. perché un sensore si è guastato).
Il concetto di timestamp attendibile offre una soluzione. Questo timestamp, definito dal modulo produttore, corrisponde
- (implicitamente) al timestamp dell'ultimo valore di misura prodotto
- oppure può essere definito (esplicitamente). Opportunamente, questo timestamp è più recente del timestamp dell'ultimo valore di misura prodotto. In tal caso si può assumere che l'ultimo valore di misura della sequenza di dati sia valido fino al timestamp attendibile (INCLUSO).
Architettura dei filtri
L'architettura dei filtri di smartCORE è composta essenzialmente da una cascata di stadi di filtro consecutivi.
Un singolo stadio di filtro riceve in ingresso sia una sequenza di valori di misura con timestamp sia un timestamp attendibile e li trasforma, in linea di principio in modo arbitrario, in una nuova sequenza di valori di misura con timestamp e in un nuovo timestamp attendibile.
Filtro per la riduzione dei dati
Per una riduzione dei dati lato moduli produttori è opportuno configurare una cascata di filtri composta dal filtro datareduction.
Questo filtro viene configurato (ad es. nell'ambito di una configurazione interattiva dei canali da parte dell'utente) come oggetto JSON, ad esempio come segue
{
"name": "datareduction",
"absTolerance": 0.0,
"timeoutMs": 60000
}
Nel caso di valori di misura numerici, vengono scartati tutti i valori che si discostano dall'ultimo valore prodotto di un importo assoluto inferiore allo scostamento specificato absTolerance.
Questo filtraggio avviene tuttavia solo se tra l'ultimo valore prodotto e il valore attualmente considerato trascorre meno tempo di quello specificato da timeoutMs, ossia allo scadere di timeoutMs un campione viene in ogni caso inserito nel canale da produrre (produzione di valori di supporto aggiuntivi).
Per i tipi string e bytearray la tolleranza assoluta specificata viene ignorata e ogni scostamento viene considerato uno scostamento effettivo.
La produzione di valori di supporto aggiuntivi è (formalmente) superflua, poiché i moduli consumatori sono essi stessi responsabili di un'interpretazione sensata degli intervalli di validità dei dati messi a disposizione (in base ai timestamp attendibili). Si è tuttavia rivelato opportuno inserire valori di supporto aggiuntivi (reali) lato moduli produttori, poiché ciò consente di utilizzare moduli produttori con moduli consumatori implementati in modo errato (ad es. evitando che si verifichi una situazione di timeout indesiderata).