Ce qui rend BACnet réellement puissant et intelligent, ce n'est pas seulement la liste de ses différentes propriétés, mais surtout la manière dont ses propriétés sont interconnectées de façon native. Dans d'autres protocoles de communication un peu plus simples, vous n'avez que des chiffres bruts. En BACnet, chaque objet est une petite machine logique autonome. La réputation de BACnet ne vient pas de la vitesse de transmission, mais de l'intelligence embarquée dans ses objets. En BACnet, une propriété n'existe jamais seule. Elle fait partie d'une réaction en chaîne logique. Dans un protocole classique, vous lisez une valeur brute. En BACnet, vous lisez un objet. Un objet, c'est un ensemble de propriétés qui communiquent entre elles. Prenons un exemple concret avec la configuration des objets analogiques BACnet qui repose sur plusieurs types de limites. Bien qu'elles se ressemblent, leurs fonctions diffèrent entre la surveillance du procédé, la maintenance matérielle et les contraintes de conception. Analysons ces différences à l'aide d'exemples concrets. Les propriétés “High_Limit” et “Low_Limit” servent à la surveillance du processus. Elles définissent une plage de fonctionnement normal. Prenons une sonde de température par exemple, dans une salle de serveurs. On fixe la “High_Limit” à 26°C. Si la température “Present_Value” de cet objet atteint 27 degrés, le système génère une alarme “Off_Normal”. La donnée reste techniquement valide, mais elle indique qu'une dérive opérationnelle nécessite une intervention sur la climatisation par exemple. La propriété “Fault_Low_Limit” concerne la fiabilité du signal physique. Elle est utilisée pour identifier une défaillance de l'équipement comme par exemple une rupture de câble ou alors un court circuit. Exemple pour une sonde de température dont la plage normale est de -20°C à 50°C. On peut configurer la Fault_Low_Limit à -20°C. Donc si la valeur chute soudainement à -50°C, cela signifie généralement que le circuit est ouvert. La propriété ou “Reliability” qui renseigne si la valeur de l'objet est plausible ou non, passera alors directement en défaut signalant aux techniciens que le capteur lui même est hors service, donc non fiable, et que le système ne peut donc en conséquence plus faire confiance aux valeurs qu'il va renvoyer. La propriété “Min_Pres_Value” définit la butée physique ou logique de l'objet. Ce n'est pas un seuil d'alarme mais une limite de conception. Notre exemple ici est un variateur de vitesse pilotant un ventilateur. Pour des raisons de refroidissement moteur, le ventilateur ne devra jamais descendre en dessous de 15% de sa capacité. On fixe le “Min_Pres_Value” à 15. Toute commande qui sera envoyée par un objet device inférieur à ce seuil sera automatiquement limité à 15 par l'objet lui même. Ça garantit ainsi l'intégrité du matériel. Les high et low limits surveillent votre environnement. Exemple il fait trop chaud. La Fault_Low_Limit, surveille votre matériel. Exemple: “le capteur est cassé”, on ne peut plus lui faire confiance. La “Min_Pres_Value” définit le cadre d'utilisation avec une valeur minimale. Ce sont toutes ces cause à effet natives qui font la différence. Dès qu'un problème survient, l'objet s'auto diagnostique. Il ne se contente pas uniquement d'envoyer un chiffre erroné, il va lever un drapeau d'erreur, il va changer son état de fiabilité et va même lui même déclencher une notification d'alarme vers la supervision via des propriétés comme “Event_Entrollement” par exemple. Tout cela se passe à l'intérieur de l'équipement, sans qu'aucune ligne de code supplémentaire ne soit nécessaire de la part de l'intégrateur. Cela rend le système prévisible, peu importe la marque du contrôleur que vous installez. Si la propriété “Relaiability” passe en défaut, tous les logiciels de supervision du marché sauront exactement comment l'interpréter. Cette structure BACnet de cause à effet crée un langage vraiment universel et standardisé pour la maintenance et l'exploitation.