Nouveau «
Les immeubles de bureaux sont remplis de systèmes techniques complexes,
collectivement dénommés
Autrefois, de tels systèmes étaient connectés, comme le rappelle le
RFC, par un lien
J'ai parlé d'une centrale de contrôle. En fait, il s'agit d'un
système de contrôle bien plus complexe, en général dénommé FMS (pour
La section 3 du RFC décrit l'organisation générale d'un FMS. En
3.2, on découvre le bestiaire qui peuple un immeuble de bureaux
(capteurs, contrôleurs, etc). En 3.3, les méthodes utilisées pour
l'installation de cet équipement. Le réseau informatique traditionnel
est installé en commençant par le câblage, puis les équipements
actifs, puis enfin les terminaux. Le FMS, au contraire, croît à partir
d'équipements installés immédiatement, puis connectés petit-à-petit et
ensuite reliés aux systèmes centraux, voire au réseau informatique
« normal » (voir aussi section 5.6). Les raisons de cette méthode sont en bonne partie
organisationnelles : tous les corps de métier n'accèdent pas au
bâtiment en même temps. D'autre part, certains systèmes de sécurité
(comme la détection incendie) doivent être en place très tôt dans la
vie de l'immeuble, avant
qu'on ne branche l'électricité partout. Le système de détection du feu
ne peut donc pas compter sur des serveurs
Enfin, la section 3.4, très détaillée et où le lecteur
informaticien qui n'a pas d'expérience du bâtiment apprendra bien des
choses, explique les problèmes spécifiques liés à la densité des
machines. Par exemple, la tendance actuelle à la
Tiens, à propos de capacité nécessaire, quelles sont les caractéristiques du trafic des équipements de l'immeuble ? La section 4 analyse quantitativement (200 octets pour un message typique au contrôleur, envoyé toutes les minutes..., 30 % des paquets restent sur le réseau local et 70 % ont besoin d'être routés...) et qualitativement (lors d'une coupure de courant, le plus dur est la reprise, lorsque les machines alimentées par batterie vont tout à coup essayer de transmettre les données qu'elles avaient stockées) le trafic sur le réseau du FMS.
Puis le cœur de notre RFC, la section 5, expose le cahier des
charges proprement dit. Comme l'installation est souvent faite par des
non-informaticiens (des
Le réseau doit pouvoir fonctionner pour des immeubles de cent mille
mètres carrés. Le RFC demande que les protocoles marchent avec des
réseaux de deux mille machines, dont la moitié routent des paquets
pour le compte des autres (section 5.2.1). Un sous-réseau (par exemple une pièce) doit
accepter 255 machines. Et chaque machine doit pouvoir parler
directement à n'importe quelle autre, en pair-à-pair. Par exemple, si les
La plupart des machines dans l'immeuble sont fixes, accrochés au
mur ou dans un faux plafond. Il n'y a donc pas d'énormes exigences de
mobilité (section 5.3). Toutefois, les équipements mobiles se
répandent et le RFC ajoute donc quelques demandes pour eux :
Les équipements de l'immeuble sont souvent très limités dans leurs
ressources matérielles. La section 5.4 liste donc les règles à suivre
pour ne pas les épuiser :
Il existe aussi des exigences pour la sélection des routes. Ainsi, le RFC demande que les applications prioritaires (alarme incendie, par exemple) puissent prendre le pas sur les autres (section 5.7.7).
Enfin, le cahier des charges se conclut par une longue section sur
la sécurité (section 5.8). D'abord, s'il y a une configuration de la
sécurité, celle-ci doit pouvoir être faite via le réseau (beaucoup
d'équipements seront en effet peu accessibles). Cette configuration
par le réseau est délicate à réaliser mais nécessaire puisque le même
équipement peut être installé dans des immeubles aux règles de
sécurité très variables (petite entreprise banale vs. bâtiment
Une autre règle sur le chiffrement (section 5.8.3) est que les
protocoles développés par le groupe ROLL
Un cahier des charges tourne toujours facilement à la « lettre au Père Noël », où on accumule des dizaines de demandes toutes plus irréalistes que les autres. La valeur d'un bon cahier des charges n'est donc pas dans les demandes mais plutôt dans ce que les auteurs ont eu le courage d'écarter. Pour ce RFC, ces exigences non retenues ont fini dans l'annexe A : intéressantes idées mais qui ne sont pas considérées par le groupe de travail ROLL comme obligatoires. Par exemple, la section A.3.5 dit que cela serait sympa si le protocole de routage permettaient à certains routeurs, les plus limités en mémoire, de ne garder qu'une partie des routes. La A.4.1 voudrait bien imposer une limite basse de capacité à 20 Kb/s...
Merci à Nicolas Riou pour sa relecture (mais, bien évidemment, les erreurs sont de moi).