Nouvelles fonctionnalités spécifiques aux déploiements auto-hébergés
Cette page cumule toutes les nouvelles fonctionnalités de ThingPark Enterprise introduites par les différentes versions logicielles 8.0.x, qui sont spécifiques aux déploiements auto-hébergés (c'est-à-dire non applicables au SaaS). Voir le journal des modifications 8.0 pour en savoir plus sur la répartition de ces fonctionnalités par version de maintenance.
Compaction de la plateforme RDTP-21050 RDTP-18325
L'objectif de ces fonctionnalités est de retravailler le modèle de données MongoDB pour réduire son empreinte et offrir une capacité plus élevée pour les profils de dimensionnement auto-hébergés existants.
-
RDTP-21050 introduit le modèle de séries temporelles. Grâce à ce nouveau modèle de données, l'empreinte MongoDB est divisée par deux pour une capacité cible donnée.
-
RDTP-18325 optimise l'agrégation horaire/quotidienne de la charge système de la passerelle et des statistiques de backhaul.
Plus de détails
Principaux avantages pour les clients
Économies CAPEX/OPEX sans compromettre la performance du système.
Les gains apportés par ces améliorations se reflètent dans les exigences de dimensionnement par une capacité système plus élevée pour chaque profil de dimensionnement, en termes de nombre maximal de capteurs, de passerelles et de nombre maximum de paquets/seconde.
Cette réduction de l'empreinte entraîne des économies substantielles sur le coût d'hébergement de la plateforme, réduisant ainsi de manière significative le coût total de possession (TCO).
Activation de la fonctionnalité
Les fonctionnalités décrites ci-dessus sont automatiquement activées après la mise à jour vers la version 8.0.
Cependant, pour simplifier le processus de migration et éviter une interruption de service trop longue pendant la fenêtre de maintenance de mise à jour, seul l'historique du trafic LoRaWAN des 7 derniers jours précédant la mise à jour est conservé après la mise à jour.
Limitations de la fonctionnalité
Pour optimiser les performances de Wireless Logger dans le nouveau modèle de données MongoDB, à partir de la version 8.0, les utilisateurs peuvent voir le trafic appartenant à leurs propres capteurs mais ils ne voient plus le trafic d'itinérance retransmis par leurs passerelles vers leurs partenaires d'itinérance, également connu sous le nom de trafic d'itinérance fNS.
SNMP v3 pour la surveillance de la plateforme et des services RDTP-23193
À partir TPE 8.0, les administrateurs de la plateforme peuvent choisir entre la version 2 et la version 3 du Protocole Simple de Gestion de Réseau (SNMP) pour surveiller le système et les services TPE :
- SNMP v2 offre des fonctionnalités de base de surveillance et de gestion du réseau.
- SNMP v3 fournit une sécurité avancée supplémentaire avec authentification et cryptage. La configuration supporte jusqu'à trois utilisateurs.
Pour en savoir plus, voir surveillance SNMP.
Cette fonctionnalité n'est pas pertinente pour les déploiements auto-hébergés sur Kubernetes, puisque la surveillance des services est effectuée directement depuis le cluster Kubernetes.
Plus de détails
Principaux avantages pour les clients
SNMP v3 est plus sécurisé que SNMP v2, comme illustré par le tableau suivant :
| Caractéristique | SNMP v2 | SNMP v3 |
|---|---|---|
| Authentification | Chaîne communautaire | Nom d'utilisateur + HMAC |
| Chiffrement | Non | Oui (AES) |
| Intégrité des messages | Non | Oui |
| Contrôle d'accès | Basique | Basé sur les rôles |
Activation de la fonctionnalité
La surveillance du système et des services peut utiliser différentes versions SNMP, si nécessaire pour le client. Par exemple, il est possible de configurer la surveillance du système pour utiliser SNMP v3 tout en gardant SNMP v2 pour la surveillance des services, ou vice versa. Pour en savoir plus, consultez Suivi SNMP.
Limitations de la fonctionnalité
Cette fonctionnalité n'impacte pas les alarmes des capteurs et passerelles, qui restent en SNMP v2.
Supporter le protocole BACnet via Node-Red RDTP-23677
À partir de ThingPark Enterprise auto-hébergé 8.0, un flux BACnet est intégré nativement dans Node-RED. Cela permet aux capteurs LoRaWAN d'exposer automatiquement les données à l'intérieur d'un serveur BACnet intégré en mode Plug-and-Play, profitant de l'ensemble riche de drivers de payload offerts par ThingPark.
La cartographie des données de capteurs LoRaWAN vers des objets BACnet est entièrement automatisée, sans aucune action manuelle de l'utilisateur. Néanmoins, les utilisateurs peuvent personnaliser cette cartographie automatique pour mieux s'adapter à leurs contraintes de déploiement.
Pour en savoir plus sur l'utilisation du BACnet dans les déploiements auto-hébergés, consultez Using BACnet.
Plus de détails
Avantages clés pour les clients
Grâce à cette fonctionnalité, les utilisateurs de ThingPark Enterprise peuvent intégrer leurs plateformes auto-hébergées à leurs systèmes d'automatisation des bâtiments en exploitant le protocole largement utilisé BACnet avec un minimum d'efforts opérationnels.
Activation de la fonctionnalité
Pour utiliser le protocole BACnet, une connexion Node-RED doit d'abord être définie comme décrit dans Ajout d'une connexion Node-RED. Ensuite, le flux BACnet doit être chargé dans Node-RED comme décrit dans Utilisation de BACnet.
Limitations de la fonctionnalité
-
Dans les déploiements à haute disponibilité, le flux BACnet fonctionne uniquement sur le premier nœud. Si ce nœud échoue pour une raison quelconque, le flux BACnet sera interrompu jusqu'à ce que ce nœud soit opérationnel. Néanmoins, les données d'uplink ne sont pas perdues pendant que le nœud-1 est en panne, grâce à la résilience offerte par le cluster kafka interne hautement disponible.
-
L'envoi de commandes de downlink aux capteurs LoRaWAN via BACnet n'est pas encore automatisé dans cette version.