Gestion Informatisée des bâtiments, télégestion

..
..
..
..
..
88, 27e Avenue Nord
Bois des Filion, Québec
J6Z 4J6
SABACO inc.
Automatisation/Contrôle
Gestion Informatisée des
bâtiments, télégestion
.
.
.
.
.
Préparé par :
Pierre Kardous, ing.
Tél: (450) 965-8915
Fax: (450) 965-8369
Courriel: [email protected]
.
.
.
.
.
..
..
..
..
..
Télégestion
Il y a dix ans débutait les premiers
balbutiements de la télégestion!
Un peu d’histoire
En fait, la télégestion remonte à bien plus longtemps qu’on ne peut le penser. Déjà, en 1985,
je participai à l’installation et la mise en marche de mon premier projet d’automatisation en
milieu institutionnel.
Il s’agissait alors de l’installation d’un système de centralisation et de gestion énergétique qui
avait pour objectif de réduire les coûts d’exploitation en arrêtant les systèmes de ventilation
en période inoccupée. Ajouter à cela des startégies d’abaissement de température, de départ
optimisé, de délestage de charges, de réajustement de la température de l’eau chaude en
fonction de la température extérieure et voilà une centralisation en bonne et due forme d’un
système de contrôle digital direct, communément appelé: système DDC.
En ce temps-là, le système en question avait une architecture distribuée, basée sur un SAC
(Stand Alone Controller) et des RCUs (Remote Control Units). Le “SAC” assurait l’échange
des données du réseau et la synchronisation des tâches de gestion évoluées, telles que
l’optimisation et le délestage de charges. Les points d’entrées/sorties étaient raccordés aux
RCUs et ces derniers assuraient le contrôle des fonctions locales et relativement simples telles
que les boucles de contrôle PID. Le tout se rapportait à un poste opérateur pourvu d’une
interface graphique qui consistait d’un ordinateur personnel opérant sur le système
d’exploitation CPM/86. Ce n’était même pas DOS! Les disquettes de sauvegarde avaient 8
pouces et, en option, on pouvait installer un disque dur de 10 ou 20 MB.
Bien avant ça, on se rappellera des systèmes centralisés et, si on remonte encore plus loin, les
systèmes superviseurs. Ces derniers assuraient la surveillance à distance des points de
contrôles et permettaient, moyennant des installations coûteuses, le changement des points de
consigne et le démarrage à distance des systèmes électromécaniques.
Un outil de gestion mal exploité
L’obligation première d’un système de contrôle est, évidemment, de contrôler et maintenir le
confort dans les espaces et locaux. Mais cela ne représente, en général, qu’une partie minime
des capacités des systèmes d’aujourd’hui. La plupart permettent la collecte et l’analyse des
données, mais ces capacités restent souvent inexploitées; au même titre qu’une secrétaire
exploite rarement toutes les capacités de son logiciel de traitement de texte.
Avec les restrictions budgétaires incessantes, les contrats de service, monnaie courante il y a
quelques années seulement, sont mis en cause. Ils sont souvent annulés et les vérifications et
calibrage périodiques et systématiques des contrôles pourraient être négligées au point d’avoir
des répercutions sur les coûts d’exploitation.
2
Par souci de gestion et d’économie d’énergie les administrateurs doivent trouver des solutions
innovatrices pour les aider à accomplir leurs tâches et gérer le plus efficacement possible le
temps du personnel d’entretien. Une des solutions à envisager devrait se tourner vers les
capacités, encore peu exploitées, des systèmes de centralisation. La génération et l’analyse de
rapports de performance et rapports statistiques des systèmes CVAC peuvent générer des
économies substantielles.
Système #1
35
100
TAF-1
30
90
PMVT-1
80
TAP-1
TAR-1
25
70
TAM-1
60
TGF-1
20
HAF-1
50
VLM-1
VL-1
15
40
Malgré l'arrêt des pompes de chauffage, on
remarque que les températures de pièce n'ont
pas réagi. Cela a permis de réduire le point de
consigne de la gaine chaude sans affecter le
confort.
10
30
20
5
10
23:00
22:00
21:00
20:00
19:00
18:00
17:00
16:00
15:00
14:00
13:00
12:00
11:00
9:00
10:00
8:00
7:00
6:00
5:00
4:00
3:00
2:00
1:00
0
0:00
0
Heure
La figure ci-contre nous permet d’examiner la relation entre le signal d’ouverture des volets
de mélange d’un système versus le pourcentage d’air frais réel (tel qu’il est calculé en
fonction des températures extérieure, de retour et de mélange). Outre le fait qu’il nous permet
de nous assurer d’une ventilation
minimum, plus de 25 % ici, il nous
a permis de déceler un manque de
répétitivité du signal de modulation
des volets à grande ouverture. Ce
graphique a engendré un bon de
travail qui a permis au technicien
de se rendre compte que les tiges
d’assemblages (linkage) s’étaient
desserrées. De plus, il a permis de
calculer une approximation réaliste
du signal de contrôle nécessaire
pour maintenir une ventilation
adéquate en été, lorsque le calcul
dynamique n’est pas possible. Un
graphique similaire peut tout aussi
bien être appliqué à d’autres
équipements de contrôle pour
vérifier la modulation des valves de
chauffage et de refroidissement,
aux vannes d’entrée d’air des systèmes à volumes variables etc. Appliqué à une valve de
chauffage, on affichera le signal d’ouverture versus la capacité thermique en BTU, calculée
selon la différence de température en amont et en aval des serpentins et du débit de
ventilation; cela pourrait nous permettre de déceler des problèmes de valves et même
d’encrassement des serpentins.
VL-11
(au 29 avril 96)
100.00
90.00
80.00
70.00
% d'Air Frais
60.00
50.00
40.00
30.00
20.00
y = -0.0003x3 + 0.0317x2 + 0.1819x + 5.0994
10.00
0.00
0.00
10.00
20.00
30.00
40.00
50.00
Signal d'ouverture
3
60.00
70.00
80.00
90.00
100.00
% (VLM, AF, HAF)
TGC-1
Deg C
À titre d’exemple, en analysant
les rapports quotidiens ou
hebdomadaires des systèmes de
ventilation, on peut déceler des
problèmes d’opération et encore
mieux, optimiser les points de
consignes et modifier au besoin
les séquences de contrôles pour
rentabiliser au maximum
l’opération des systèmes. Dans
la figure ci-contre on
remarquera que l’arrêt des
pompes de chauffage n’a
pratiquement pas affecté les
températures de pièces. Cela a
permis de réduire le point de
consigne de la gaine chaude du
système sans affecter le confort.
L’évolution
Au début de la centralisation distribuée des contrôles, l’installation de systèmes DDC se
limitait aux points de lecture et de contrôle jugés le plus important pour accomplir les tâches
de gestion énergétique pouvant être rentabilisées dans un délai plus ou moins court. Le coût
du point se situait aux environs de 800 à 1,000 dollars et les superflus étaient simplement
éliminés. La fiabilité des systèmes était encore à éprouver et les ingénieurs exigeaient le
maintien des composantes pneumatiques en redondance sur les projets de rénovation. L’usage
généralisé des contrôles informatisés dans les nouvelles constructions était relativement
restreint puisqu’il était encore courant de voir des devis de construction avec des équipements
pneumatiques et la centralisation tenir le rôle d’une horloge glorifiée.
Depuis, les contrôleurs autonomes ont acquis plus de fiabilité, de flexibilité, de maturité et de
puissance. Les systèmes de contrôle distribués de type “Peer To Peer” (à passage de jeton) ont
surclassé les systèmes dits “Master/Slave” (maître/esclave).
Les systèmes de type “à passage de jeton” se caractérisent par la capacité des
contrôleurs, tous d’une même catégorie et d’un même niveau, de demander de
l’information et d’envoyer des commandes à d’autres, à un certain moment,
lorsqu’ils détiennent le jeton.Ils sont généralement préférés puisqu’ils
permettent une plus grande flexibilité d’installation et une plus grande fiabilité
du réseau.
Dans une architecture de type “maître/esclave”, le panneau maître gère
l’échange des données d’un panneau à un autre et permet la centralisation de
l’information au poste opérateur. Ce type d’architecture est encore très répandu
et représente l’architecture de choix lorsqu’il est question d’assurer le contrôle
terminal des locaux. Dans les systèmes traditionnels, les contrôleurs esclaves
seront dédiés aux unités de toits, aux pompes à chaleur, aux boîtes VAV, etc.
La programmation en langage informatique textuel du type “Basic, “C” et autres, a cédé la
place à la programmation orientée objet et la programmation graphique. Les interfaces se sont
uniformisées par des applications fonctionnant sur le système d’exploitation Windows, de loin
plus convivial que ne l’étaient les premiers systèmes graphiques, il y a 15 ans.
Comme tous les autres domaines touchés par l’informatique, la révolution dans le secteur des
contrôles a fait son chemin. On a assisté à une prolifération constante des contrôles à base de
microprocesseurs, influencée par la baisse continue du coût des composantes et l’amélioration
de leurs performances. Ces progrès étaient en partie responsables de leur propagation et usage
généralisé dans des applications jusque-là considérées trop dispendieuses ou trop complexes.
Aujourd’hui, on retrouve une multitude d’autres systèmes à base de microprocesseurs, utilisés
dans des bâtiments institutionnels, commerciaux ou industriels, permettant le contrôle et/ou la
télésurveillance de divers équipements tels que : chaudières, refroidisseurs, systèmes de
sécurité d’accès, système d’éclairage et d’alarme incendie, pour n’en nommer que quelquesuns. La plupart des systèmes permettent, d’une façon ou d’une autre, la communication avec
un poste opérateur et l’échange d’information entre eux et d’autres fabricants.
Cet échange avec d’autres fabricants se faisait, en général, à l’aide de
“Gateway” dont la tâche consistait à convertir les données entre deux
protocoles de communication différents et permettait ainsi de lire les données et
centraliser l’information à un seul et même poste opérateur.
4
Cela devait permettre une intégration transparente des diverses composantes qui forment un
tout dans le bâtiment. On pouvait alors rêver du bâtiment intelligent où l’ouverture d’une
porte par une carte de sécurité aurait automatiquement enclenché une série d’actions
préprogrammées telles que, la mise en marche de la ventilation, le changement des points de
consigne au point de consigne de jour, etc. Pour les fabricants qui commercialisent des
systèmes intégrés cela était relativement facile. C’était loin d’être le cas pour ceux qui
devaient intégrer l’opération de composantes d’autres fabricants avec les leurs; surtout
lorsqu’il était question de faire des mises à jour des systèmes (les logiciels et progiciels des
“Gateways” étaient souvent à la traîne puisqu’il fallait que les fabricants en cause
coordonnent leurs activités).
L’interopérabilité des systèmes avait donc un prix et les propriétaires et gestionnaires étaient
les premiers à en faire les frais. Cela a suscité un intérêt marqué au développement et
l’adoption de protocoles ouverts.
Les protocoles ouverts
Le concept des protocoles ouverts n’est pas nouveau. En Europe, les efforts de développement
dans ce sens ont permis l’adoption de PROFI, BUS et FND. Aux États-Unis, le DNP
(Distributed Network Protocol), l’UCA (Utility Communications Architecture) et SCADA
(Supervisory Control And Data Acquisition) furent récemment développés pour le secteur
industriel. Dans le secteur commercial, tel qu’appliqué en automatisation et contrôle des
bâtiments, deux protocoles de communication se disputent la première place: BACnet
parrainé par ASHRAE et LonTalk, parrainé par la corporation Echelon.
BACnet
BACnet (Building Automation and Control NETwork) est un protocole de communication de
données. Ce n’est ni un logiciel, ni un progiciel ni un équipement de contrôle.
C’est un ensemble de règles qui gouvernent l’échange des données entre
différents ordinateurs sur un réseau local et qui couvrent tous les éléments
nécessaires à cet échange; du câble de communication à la syntaxe d’une
requête ou d’une commande à exécuter.
Il a été développé par un comité de l’ASHRAE (American Society of Heating, Refrigeration
and Air-conditionning Engineers) et adopté, par la suite, comme un standard. Il serait en cours
d’évaluation par la communauté européenne pour son adoption comme préliminaire à un
standard. Il a également été soumis à l’organisation internationale de standardisation (ISO)
pour adoption comme un standard international.
L’objectif du comité était de développer un protocole qui permettrait l’interopérabilité de
différents systèmes et fabricants d’équipements d’automatisation/contrôle. Pour permettre une
communication efficace entre les ordinateurs, il fallait définir deux choses:
1.
Une langue commune pour la représentation des données et commandes;
2.
Une méthode sûre pour acheminer l’information entre les ordinateurs; les
réseaux locaux.
Cette langue commune représente la partie la plus innovatrice du standard. Elle définie les
marches à suivre qui devaient se regroupaient en trois parties principales. La première partie
consistait par la description d’une méthode de représentation uniforme de tous les types
d’équipement d’automatisation du bâtiment. La seconde partie devait définir les messages qui
devaient être échangés sur le réseau pour permettre la supervision et le contrôle des
5
équipements. La troisième partie devait définir l’encodage des messages BACnet (que nous
éviterons d’élaborer dans cette présentation).
Les objets BACnet
BACnet pourvoit une façon simple et uniforme pour représenter les caractéristiques
opérationnelles communes des éléments d’un système d’automatisation/contrôle en
définissant les “objets”, chacun ayant un ensemble de propriétés qui les caractérisent plus en
détail.
Par exemple, une sonde de température de pièce représente un objet de type entrée
analogique; Il y en a dix-huit (18) de définis dans le standard. Chaque objet, comme notre
sonde, a un ensemble de propriétés communes telles que : la valeur courante, le type de sonde,
la plage d’opération, les limites d’alarmes, etc. Certaines de ces propriétés sont obligatoires,
d’autres sont optionnelles. C’est ce qui laisse une grande marge de manoeuvre aux fabricants
de se différencier les uns des autres et de vendre les mérites de leurs équipements. BACnet
définis 132 propriétés différentes dont trois sont primordiales pour le définir :
“Object_Identifier”, “Object_Name” et “Object_Type”.
Un objet et ses propriétés seraient donc l’équivalent d’un point et ses attributs, ou d’une
variable et ses paramètres. Toute composante BACnet doit avoir au moins un objet identifiant
cet équipement, appelé: “Device Object”. Cet objet publie les informations et capacités de
cette composante aux autres contrôleurs sur le réseau BACnet.
Les services BACnet
Ce sont les moyens que se donne le protocole pour échanger les informations et assurer
l’interopérabilité entre les contrôleurs du réseau. Chaque requête envoyée et réponse reçue
correspond à des “packets” d’informations transférés sur le réseau BACnet.
Les services BACnet suivent le modèle informatique de Client/Serveur où un client sollicite
un service et un serveur l’exécute. Mais, contrairement à la bureautique où un serveur est une
pièce relativement compliquée, un serveur BACnet peut être tout simplement une sonde
intelligente (tel un compteur de consommation électrique). Ainsi, un programme
d’application, sur un contrôleur, sollicitera une information d’un autre contrôleur, lui
permettant de compléter sa séquence (par exemple : lire la température extérieure pour
réajuster un point de consigne). Pour qu’un équipement soit conforme BACnet, il faut au
moins qu’il ait le service “ReadProperty”.
Mais les services BACnet ne se limitent pas simplement à lire des informations d’autres
contrôleurs; BACnet en définit 32 et les classe dans 5 catégories distinctes :
1.
Services d’accès aux objets
Un client utilisera ce service pour lire et modifier les valeurs de certaines
propriétés dans un serveur. Certains serveurs permettront à un client de
créer et même d’effacer certains objets.
2.
Services des alarmes et évènements
Une des fonctions importantes de surveillance et de contrôle dans un
système d’automatisation de bâtiment est la capacité de signaler les fautes et
autres conditions anormales. Bacnet fournit des services à cet égard et
définit également un ensemble d’autres services permettant de maintenir les
“clients” informés du status de certaines variables du système. Le service de
changement d’état “Change_Of_Value Services” en est un.
3.
Services d’accès aux fichiers
Deux services permettent la lecture et la manipulation des fichiers;
6
“AtomicReadFile” et “AtomicWriteFile” (le terme atomique est utilisé ici
pour signifier qu’un seul accès à la fois est permis (les fonctions multitâches
et multiusagers ne sont pas supportées). Dans BACnet, un fichier est un
groupe de données “Databyte” de longueurs et significations arbitraires. Ils
peuvent contenir des programmes, un record de transactions, etc. Il est
intéressant de noter qu’il n’y a pas de format de fichier BACnet standard; à
ce jour et par définition, tous les accès aux fichiers sont privés.
4.
Services de terminal virtuel
Certains contrôleurs plus sophistiqués permettent le raccordement d’un
terminal pour sa configuration et programmation. BACnet prévoit des
services pour assurer cette possibilité via le réseau de communication.
Ainsi, l’opérateur établi une connection textuelle et bidirectionnelle avec un
programme d’application exécutant dans un contrôleur à distance.
5.
Services de télégestion.
Ses services représentent un recueil de fonctions qui ne peuvent être
harmonieusement classées dans les quatre premiers décrits, mais aident
dans les fonctions de gestion du réseau. Ils permettent entre autres de situer
les contrôleurs et leurs objets au moment de la configuration, la
synchronisation des horloges et la réinitialisation télécommandée (Remote
Reboot). De plus, deux autres services dans cette catégorie,
“Confirmed_Private_Transfer” et “Unconfirmed_Private_Transfer”,
permettent aux contrôleurs de transmettre des informations privilégiées que
nul autre fabricant ne pourra accéder.
Les classes de conformité, les groupes de fonctions et les PICS
Vu le nombre d’objets, de propriétés et de services, et en réalisant qu’il n’était pas nécessaire
que chaque composante BACnet ait les mêmes capacités pour exécuter les fonctions qui lui
étaient destinées, il devenait évident qu’il fallait définir une méthode de classification pour
permettre une évaluation et comparaison de contrôleurs d’un même type. Le comité ASHRAE
a reconnu cette situation et nous a fourni des outils pour nous aider à accomplir cette tâche.
1.
Les classes de conformité.
Le protocole BACnet définit 6 niveaux de conformité, chacun ayant un
minimum de services disponibles au contrôleur. Le plus bas niveau, la
classe 1, requiert que le contrôleur ait l’objet “Device”. et qu’il soit en
mesure de répondre à une demande de lecture “Read_Property” d’un autre
contrôleur. Chaque niveau successif requiert l’ajout de services qui doivent
être exécutés ou initiés par le contrôleur. Le plus haut niveau de conformité
“6” aurait 21 des 32 types de services que définis le protocole. La classe de
conformité représenterait donc la capacité d’un contrôleur à communiquer.
2.
Les groupes de fonctions
Ils spécifient un ensemble d’objets et de services nécessaires à l’exécution
de certaines tâches d’automatisation/contrôle. Ils sont indépendants des
classes de conformités bien que l’application de certaines fonctions induise
automatiquement un niveau supérieur à un (1). Pour n’en nommer quelquesuns, “Horloge”, “Terminal Portatif” et “Poste Opérateur”, en font partie,.
3.
Les “PICS” (Protocol Implementation Conformance Statement)
C’est une déclaration de conformité d’implantation du protocole, qui est
établie par lefabricantt pour décrire les capacités de son produit. Elle
identifie le fabricant, décrit brièvement le produit et détaille l’implantation
du protocole. On y trouve: la classe de conformité, les groupes de fonctions
supportés, les services standards et privés pouvant être exécutés ou initiés
7
ainsi que les objets standard ou privés avec toutes les options d’écriture, de
création et d’effacement de propriétés.
Le réseau local LAN
Pour satisfaire tous les intervenants et permettre l’intégration de composantes dédiées à des
applications diverses, les unes plus exigeantes que d’autres, le comité BACnet a incorporé
plusieurs types de réseaux locaux dans le protocole. Ils ont choisi des technologies de réseaux
éprouvées lorsque possible et lorsque leur application à certaines fonctions d’automatisation
du bâtiment devenait trop onéreuse, ont développé le leur; MS/TP. La table suivante liste les
réseaux adoptés :
LAN BACnet
Ethernet
ARCNET
MS/TP
Lontalk
Standard
ISO/IEC 8802.3
ATA/ANSI 878.1
ANSI/ASHRAE 135-1995
n/a
Vitesse
10 à 100Mbps
0.156 to 10 Mbps
9.6 to 78.4 kbps
4.8 à 1250 kbps
Coût
Élevé
Moyen
Bas
Varié
Ethernet est un réseau local à haute vitesse. Très répandu depuis plusieurs années, il est
présent presque partout dans les environnements bureautiques. Il utilise plusieurs types de
média pour le raccordement physique tel que : câble coaxial, fibre optique et plus
communément les paires de fils torsadés.
ARCNET est très populaire dans les applications industrielles. Il est moins chère qu’un réseau
Ehternet mais requiert des circuits intégrés dédiés pour la communication. C’est à cause de cet
avantage de prix que ce réseau a été préféré à d’autres d’envergure internationale.
Le réseau MS/TP “Master-Slave/Token-Passing” (Maître-Esclave/À-Passage-de-Jeton) a été
conçu pour permettre aux fabricants de développer des contrôleurs à un moindre coût et
permettre à BACnet de rivaliser compétitivement avec les offres des systèmes à protocoles
privés. De par sa simplicité, son implantation dans les contrôleurs unitaires devenait possible
sans l’utilisation de circuits intégrés dédiés. Le réseau MS/TP utilise EIA-485 signalant sur
une paire de fils torsadés. On retrouve deux types de contrôleurs MS/TP; les uns “Maîtres” et
les autres “Esclaves”. Un contrôleur “Maître” peut solliciter de l’information du réseau et doit
négocier un temps d’accès et de contrôle de ce dernier. Il est forcément plus cher que le
second type “Esclave” qui ne peut en aucun cas solliciter de l’information du réseau.
Initialement développé par Echelon comme un réseau privé, il fait usage de trois (3)
microprocesseurs pour assurer les fonctions de communications de réseau. Depuis, LonTalk
s’est récemment vu promu au rang des protocoles ouverts. Bien que développé pour les
systèmes “LonWorks”, il permet le transfert d’informations BACnet par des transmissions
qu’il définit comme “Foreign Frame Transmission”. Par analogie, le service des postes
canadien qui achemine une lettre écrite en langue étrangère. Son avantage est qu’il permet
l’utilisage d’un plus grand nombre de médias pour le signalement tel que : fréquences radio,
infrarouge, câble coaxial, fibre optique et paires de fils torsadés.
8
Echelon
Lorsqu’on parle d’Echelon, on pense au second choix permettant d’assurer l’interopérabilité
des systèmes de contrôles. On mêle souvent les mots “Echelon, LonTalk, Lonworks et
LonMark pour décrire la technologie. Sans vouloir s’étaler sur la question, Echelon est la
corporation qui a développé le protocole LonTalk. Elle fut fondée par M. Mike Markulla, a
son siège social à Palo Alto en Californie et des bureaux en Chine, au Japon et plusieurs pays
européens. La corporation Echelon a plusieurs partenaires et investisseurs dont Motorola et
Toshiba qui fabriquent et commercialisent le Neuron “Neuron Chip” qu’elle a conçue.
LonTalk
C’est un protocole conçu pour s’adapter à une gamme d’applications et d’industries
différentes en automatisation/contrôle. Il suit le modèle de référence OSI (Open System
Interconnection) développé par ISO (International Standard Organization) en 1984. Ce
modèle décrit comment un ensemble de logiciels et composantes doit collaborer à plusieurs
niveaux pour assurer la communication entre les ordinateurs. Lontalk implante des services
aux 7 niveaux définis par le modèle OSI.
Au coeur du protocole on trouve le Neuron, une puce qui intègre 3 processeurs distincts ayant
des fonctions bien définies : le processeur d’applications, celui d’accès au média de transport
et finalement, celui de gestion des fonctions de réseau. Cerveau de la technologie Lonworks,
Niv. OSI
7 Application
Où?
Comment?
Processeur d’application
Logiciel usager
Processeur de réseau*
Progiciel du
6 Presentation
5 Session
4 Transport
Neuron
3 Réseau
2 Lien
Processeur MAC
1 Physique
Transceiver du média
Quincaillerie
il est disponible en deux saveurs: le 3120 (où toute la mémoire est sur la puce) et le 3150
(ayant une mémoire externe). Il agit comme un micro-contrôleur multi-usage ayant des
capacités de communication intégrées. Le processeur d’application exécute les programmes
d’application dans un langage “C” adapté connu sous le nom de “Neuron C”. Chaque nœud
“Node”dans un réseau Lonworks est construit autour d’un Neuron et ce dernier sera
accompagné d’un “Tranceiver”, qui assure le lien physique et permet le transport des données
entre les nœuds sur le réseau.
Selon le type de média et de topologie utilisée, les “Transceivers” seront différents et auront
des caractéristiques spécifiques. Ils ne peuvent pas être mélangés sur un même canal d’un
réseau Lonworks. Sans se perdre dans les détails d’architecture du réseau, chaque nœud
Lonworks est branché sur un canal “Channel”. Le canal est défini comme étant le média
physique assurant le transport des paquets d’informations “Packets”. Un “Router” est
nécessaire pour relier deux canaux de topologies différentes. À titre indicatif, on trouvera cidessous quelques spécifications de Transceiver et topologies en paire de fils torsadés :
9
Transceivers pour Paire Torsadée
Produit
Vitesse
(bps)
Topologie Nœ uds/
Canal
Dist (m)
Notes
Applications
TPT/XF-1250
FTT-10A
FTT-10A
LPT-10
LPT-10
1.25M
78k
78k
78k
78k
Bus only**
Bus option
Free
Bus option
Free
130m
2700m*
500m*
2200m*
500m*
Isolation Xfrmr
Isolation Xfrmr
Isolation Xfrmr
Link Power
Link Power
Industriel; infrastructures
Commercial/Industriel
Commercial/Industriel
Sondes, Afficheurs, etc.
Sondes, Afficheurs, etc.
64
64
64
128
128
* Cable 16 AWG. D’autres options de cables diponibles
** Note: Exigences specifiques d’architecture et de raccordement
• LPT: power supply (100mA@5V) intégré
Tous insensibles à la polarité
Note de l’auteur:
On poursuivra la présentation avec
1.
Une définition de ce que représente LonWorks et sa pénétration du marché;
2.
Une introduction à l’association d’interopérabilité Lonmark et des guides
que l’association a mis en place pour assurer l’interopérabilité des systèmes
et des composantes;
3.
Une brève introduction aux objets LonMark, aux variables de réseau SNVT
(Standard Network Variable Type), au transfer des données, aux propriétés
de configuration, et profils fonctionnels;
4.
Une discussion des besoins réels d’interopérabilité et l’impact des nouvelles
technologies sur l’exploitation quotidienne des systèmes d’automatisation.
5.
En alternative, on examinera l’application du protocole TCP/IP à la
centralisation des contrôles.
10