Canaux
Cette section présente les canaux smartCORE et décrit les principes de leur utilisation.
Architecture
Dans le contexte de smartCORE, les canaux assurent la communication entre les modules producteurs et les modules consommateurs. Ils sont créés et alimentés par un seul module producteur et peuvent être lus par plusieurs modules consommateurs. Du point de vue du logiciel, un canal smartCORE (horodaté) constitue essentiellement un tampon circulaire de valeurs de mesure horodatées d'un type de données défini au préalable. Par ailleurs, un canal dit de variable de processus représente une seule valeur de mesure avec l'horodatage de sa dernière mise à jour.
Types de canaux et types de données
On distingue fondamentalement
- les canaux horodatés (timestamped channels), qui fournissent une s érie temporelle de valeurs de mesure, et
- les variables de processus (process values), qui fournissent uniquement la dernière valeur de mesure (p. ex. un paramètre ou une propriété) ainsi que l'instant de la dernière modification, mais AUCUN historique temporel.
Toutes les valeurs de mesure « transmises » au sein d'un canal smartCORE sont toujours typées de manière univoque. Les types de données suivants sont pris en charge
| Type de données | Description |
|---|---|
| bool | Valeurs booléennes telles que true et false |
| int64 | entiers signés sur 64 bits |
| int32 | entiers signés sur 32 bits |
| int16 | entiers signés sur 16 bits |
| int8 | entiers signés sur 8 bits |
| uint64 | entiers non signés sur 64 bits |
| uint32 | entiers non signés sur 32 bits |
| uint16 | entiers non signés sur 16 bits |
| uint8 | entiers non signés sur 8 bits |
| double | nombres à virgule flottante en double précision |
| float | nombres à virgule flottante en simple précision |
| string | chaînes de caractères encodées en UTF-8 |
| bytearray | blocs de données binaires |
| gpslocation | structures pour les indications de position GPS, composées de trois nombres à virgule flottante en double précision consécutifs pour la latitude, la longitude et l'altitude au-dessus du niveau de la mer |
Paramètres de canal
Au total, y compris les types de canaux et de données mentionnés ci-dessus, les paramètres de canal suivants peuvent être spécifiés
| Paramètre | Type de données | Description |
|---|---|---|
| name | STRING | Nom du canal |
| channelType | STRING ENUM | Type de canal, soit horodaté ("timestamped"), soit variable de processus ("processvalue") |
| dataType | STRING ENUM | Type de données des valeurs de mesure (voir ci-dessus) |
| bufferSize | UINT > 0 | Taille du tampon, c.-à-d. nombre maximal de valeurs de mesure au sein d'une série temporelle avant que les valeurs les plus anciennes ne soient écrasées |
| physicalDimension | STRING | Dimension physique du canal (p. ex. vitesse, tension, température, ...) |
| physicalUnit | STRING | Unité physique du canal (km/h, V, °C, ...) |
| metaData | JSON OBJECT | Métadonnées définies par l'utilisateur |
| filter | JSON ARRAY of channel filter specifications | Cascade de filtres définie par l'utilisateur (généralement pour la réduction de données) |
| persistent | BOOL | Indicateur précisant si le canal survit à un redémarrage du système |
| preserved | BOOL | Indicateur précisant si le canal est chargé au démarrage de smartCORE depuis une base de données de l'appareil de mesure et écrit à intervalles réguliers dans cette base de données (utile p. ex. pour des compteurs ou d'autres informations de fonctionnement) |
Intégration dans les états de fonctionnement de smartCORE
Dans les différents états de fonctionnement de smartCORE, les canaux smartCORE sont gérés comme suit. Pour plus de détails, veuillez consulter la documentation sur la machine à états de smartCORE.
Création des canaux à produire
Le module producteur demande à la gestion des canaux de smartCORE la création d'un objet canal et reçoit en retour une référence à celui-ci.
Du point de vue du logiciel, cette opération n'est possible que dans l'état de fonctionnement d'initialisation des canaux producteurs (InitProducerChannels).
Sélection des canaux à consommer
Un module consommateur peut, à tout moment, demander une référence aux canaux fournis par la gestion des canaux de smartCORE. En outre, un tel module doit enregistrer un consommateur (handle de lecture) de ce canal, ce qui est également possible à tout moment.
Si ces canaux sont déjà connus au moment de la configuration du module, l'état de fonctionnement d'initialisation des canaux consommateurs (InitConsumerChannels) est généralement utilisé à cet effet dans le logiciel.
Production de valeurs de mesure dans les canaux
Une fois que la production a été signalée par un module à smartCORE (StartProduce), ce module peut écrire des valeurs de mesure dans ses canaux producteurs. Cela se fait à l'aide d'un horodatage, qui peut être d'origine différente (p. ex. directement issu des données ou bien l'instant de la production).
Dans la plupart des cas, la production des valeurs de mesure ne se fait pas directement, mais par l'intermédiaire d'une cascade de filtres configurée (Filter chain), le plus souvent dans le but de réduire les données.
En particulier dans le contexte de la réduction de données, le concept d'horodatage fiable s'est avéré pertinent.
Horodatages fiables (Trusted Timestamps)
Alors que, dans une sous-séquence de deux valeurs de mesure horodatées consécutives, la validité de la première valeur peut être supposée jusqu'à l'horodatage de la seconde valeur (EXCLU), on ignore pour la dernière valeur d'une séquence, et donc aussi pour la dernière valeur produite, jusqu'à quand elle est valide - ou, formulé autrement, si et quand d'autres valeurs de mesure (identiques ou modifiées) vont arriver.
Il en résulte que toute la plage temporelle depuis le dernier échantillon NE peut PAS être utilisée, p. ex. pour exécuter des calculs basés sur celle-ci dans des modules consommateurs.
Dans le cadre de la réduction de données, cela s'est révélé particulièrement gênant, car, par exemple, une valeur constante n'est produite qu'une seule fois puis simplement filtrée, c.-à-d. écartée.
On ne peut donc fondamentalement PAS distinguer entre
- des canaux dont les valeurs de mesure sont constantes et ont toutes été filtrées à l'exception d'une valeur initiale,
- des canaux qui ne fournissent temporairement plus de valeurs de mesure (p. ex. en raison d'un retard dû à la charge) et
- des canaux qui ne fournissent définitivement plus de valeurs de mesure (p. ex. parce qu'un capteur est tombé en panne).
Le concept d'horodatage fiable apporte ici une solution. Cet horodatage, défini par le module producteur, correspond
- soit (implicitement) à l'horodatage de la dernière valeur de mesure produite
- soit peut être défini (explicitement). Il est judicieux que cet horodatage soit plus récent que celui de la dernière valeur de mesure produite. Dans ce cas, la validité de la dernière valeur de mesure de la séquence de données peut être supposée jusqu'à l'horodatage fiable (INCLUS).
Architecture des filtres
L'architecture des filtres de smartCORE se compose essentiellement d'une cascade d'étages de filtrage successifs.
Un seul étage de filtrage reçoit en entrée une séquence de valeurs de mesure horodatées ainsi qu'un horodatage fiable, et les transforme, de manière en principe arbitraire, en une nouvelle séquence de valeurs de mesure horodatées ainsi qu'en un nouvel horodatage fiable.
Filtre de réduction de données
Pour une réduction de données du côté des modules producteurs, il est recommandé de configurer une cascade de filtres constituée du filtre datareduction.
Ce filtre est configuré (p. ex. dans le cadre d'une configuration interactive des canaux par l'utilisateur) sous forme d'objet JSON, par exemple comme suit
{
"name": "datareduction",
"absTolerance": 0.0,
"timeoutMs": 60000
}
Dans le cas de valeurs de mesure numériques, toutes les valeurs qui diffèrent de la dernière valeur produite de moins, en valeur absolue, que l'écart spécifié absTolerance sont écartées.
Ce filtrage n'est toutefois effectué que si l'intervalle de temps entre la dernière valeur produite et la valeur actuellement considérée est inférieur à celui spécifié par timeoutMs, c.-à-d. qu'à l'expiration de timeoutMs, un échantillon est dans tous les cas enregistré dans le canal à produire (production de points d'appui supplémentaires).
Dans le cas des types string et bytearray, la tolérance absolue spécifiée est ignorée et tout écart est considéré comme un écart effectif.
La production de points d'appui supplémentaires est (formellement) inutile, car les modules consommateurs sont eux-mêmes responsables de l'interprétation correcte des plages de validité des données fournies (grâce aux horodatages fiables). Il s'est toutefois avéré judicieux d'insérer des points d'appui supplémentaires (réels) du côté des modules producteurs, car cela permet d'utiliser des modules producteurs avec des modules consommateurs mal implémentés (p. ex. afin qu'aucune situation de timeout indésirable ne survienne).