Mais quel est l’intérêt d’avoir des services EnergyWise qui tournent sur les commutateurs et ne pas avoir un serveur qui interroge directement des équipements intelligents à travers un réseau quelconque ?
Il existe plusieurs réponses :
- Quid de l’extensibilité (« scalability ») ? Si jamais les serveurs commandaient directement les équipements alors il faudrait un certain nombre de serveurs pour supporter la charge de toutes les requêtes pour récupérer les données. Tout l’intérêt d’EnergyWise réside dans le fait que les commutateurs effectuent ce travail et le premier commutateur interrogé par la plateforme d’administration va agréger les réponses et envoyer une réponse synthétique à la plateforme d’administration, soulageant d’autant le réseau. Pour les politiques peu évoluées – par exemple éteindre les équipements à 22h00 – elles peuvent également être enregistrées directement sur le commutateur. Ainsi même si certains liens tombent, ces politiques continueront à être appliquées
- Une fois qu’un équipement PoE est éteint, comment faire pour le rallumer sans intelligence sur le commutateur ? l’équipement ne peut plus recevoir de commande puisqu’il est éteint. On pourrait imaginer laisser un faible courant pour alimenter une CPU (« Central Processor Unit ») mais cela ne sera jamais aussi efficace que lors d’une extinction. Les fonctions de cache dans le commutateur (décrites dans la note Tech Notes – Les mécanismes d’autodécouverte d’EnergyWise ) permettent de conserver la topologie et les adjacences
- Comment se passerait la découverte des équipements au niveau 2 ou 3 ? Les paquets de type broadcasts sont souvent bloqués par les commutateurs (entre VLAN par exemple), les empêchant d’atteindre la plateforme d’administration. Faudrait-il alors les entrer manuellement ? Une tâche titanesque !
- dès lors qu’on touche au contrôle d’équipement, le besoin de sécurité grimpe en flèche ! Or l’utilisation d’un serveur global induirait une trop grande vulnérabilité de l’ensemble. EnergyWise utilise différents (3 pour être précis) mots de passe pour les communications entre commutateurs, entre équipements terminaux et commutateurs, entre commutateurs et plateformes d’administration. Ainsi si la plateforme est corrompue, on peut empêcher son action en changeant le mot de passe correspondant au niveau du commutateur. De plus les commutateurs ont une surface d’attaque réduite par rapport à des OS tels que Windows ou Linux sur lesquels tourneraient ces potentielles plateformes. L’aspect sécurité a été abordé dans un article précédent (Tech Notes – EnergyWise & la sécurité)
- Utiliser le réseau offre aussi la possibilité d’ajouter de l’information contextuelle, de l’autoconfiguration. Comme on sait à quel port du commutateur l’équipement est relié et où se situe ce commutateur, on peut en déduire la localisation de l’équipement. Ou alors reconnaître automatiquement un équipement et ajouter un mot-clé correspondant. Et ainsi de suite.
L’approche EnergyWise se démarque clairement des protocoles traditionnels utilisés dans la gestion technique du bâtiment comme BACNet, ModBus, LonWorks ou KNX qui n’ont pas été conçu pour IP et son formidable système de couches indépendantes entre elles, ni pour tirer avantage du réseau. Ils demandent un réseau dédié et séparé et des passerelles vers les plateformes d’administration (qui utilisent IP) et reposent sur un modèle client serveur centralisé, bien loin du modèle distribué d’EnergyWise.
Matthieu.
Authors
Laisser un commentaire