Objet

Ce document explique et précise les notions d'adressage: constructeur, étendue, symbolique, topologique dans le contexte des divers équipements dynamiques: PIP (PMV), PIC (caméras), PIV (matrices vidéo), et ultérieurement PIX (sites complexes comme les BRA = barrières de rabattement, sites de coupure, Contrôles d'accès) et PIM (sites de mesure UMT et UD=Unités de détection)

(La structure complète de codification des PI est décrite en annexe C, page 285 de la norme LCR NF-P-99-340).

Adressage constructeur

Les différents PI (Pilote Informatique ) constituant un réseau pour l'exploitation de la route sont organisés topologiquement par l'architecte de ce réseau dans une structure arborescente rgs de réseau, groupe, sites, pour permettre leur organisation structurée et leur désignation par le LCR.

Les différents constituants d'un Pilote Informatique sont organisés par le constructeur du PI, topologiquement dans une structure arborescente de modules, pour permettre leur désignation par le LCR.

Certains modules sont directement pilotables par une commande spécifique LCR, d'autres sont simplement identifiables (localisables) dans les réponses à certaines commandes.

Ces constituants peuvent être différents, selon la fonction du PI :

par exemple:

etc.

(La structure complète de codification des PI est décrite en annexe C, page 285 de la norme LCR NF-P-99-340).

 

Le tronc commun de l'arbre des modules est le code-adresse de site du Pilote Informatique, de niveau "s" tel qu'exprimé par l'argument de COD dans ST.

par exemple, si un PIP a pour adresse " COD=ILN59.4" dans un réseau ALLEGRO, le caractère "4" représente le niveau s, le caractère "N" représente le niveau g de groupe, le caractère "L" représente le niveau r de réseau. On dit que le rgs de ce PIP est LN4, ce que l'on retrouve dans le champs "ADR=LN4" restitué par le status, en réponse du PIP à une commande ST.

Chaque module identifiable appartenant au Pilote Informatique s est repéré par construction par son code-adresse exprimant un niveau inférieur: ijk...

Pour le niveau "i", dans un PIP panneaux, on distingue obligatoirement les modules positionnables dont le code sur un caractère est situé dans l'intervalle [Ø,Z] du jeu de caractères J7, et les modules non positionnables dont le code est situé dans l'intervalle [a,z] du jeu de caractères J7

Adressage utilisateur

Pour tout module, un ou les deux premiers niveaux de l'arborescence peuvent être changés par l'utilisateur au moyen de la commande CFET (si elle existe dans cette gamme de PI) dans une autre topologie, sur 1 ou 2 niveaux, qui sont propres à l'utilisateur, et dénommée ici xy.

Le CFET permet par exemple de convertir:

un module 1.Ø en un module A.Ø

 

On peut également convertir à volonté, par exemple:

le module 1.Ø en A

un module 1 en A

un module 2 en A.Ø, ou le module 2 en 2.Ø, etc.

On ne peut pas convertir un module 1.Ø en a.Ø, ni un module m.4 en A.Ø

La nouvelle arborescence résultant du CFET doit être unique et non ambiguë et respecter les mêmes règles d'affectation dans J7 que pour le niveau i constructeur.

module pilotable

Un module pilotable est un module qui peut être actionné ou positionné, configuré, transcodé, relu, cité.

Dans un PIP, il peut être positionné (voir PA, PE), ou être configuré (voir CFPP, CFAL), ou être transcodé (CFET), ou être relu (voir PE, PS, TRACE P), ou être mentionné en cas de dysfonctionnement (ST).

L'adresse d'un module pilotable est exprimée soit par une amtc constructeur de forme i[.j], soit par une amt utilisateur de forme x[.y] si un CFET a été configuré préalablement.

module non pilotable

Un module non pilotable est un module qui peut seulement être relu, cité, et quelquefois transcodé.

Dans un PIP, l'adresse peut seulement être utilisée dans les retours d'erreur ERI de ST, ou transcodée (CFET) pour ses 2 premiers niveaux. Le module ne peut pas être actionné ni positionné (PA, PE), ni configuré (CFPP, CFAL), ni relu (PE, PS, TRACE P).

L'adresse d'un module non pilotable est exprimée par une aetc constructeur de forme i[.j[.k]...] si aucun CFET n'a transcodé préalablement cette adresse, et elle est exprimée par une aet utilisateur dans le cas contraire.

Restitution "ERI dans le Status

Dans l'argument de ERI, l'adresse d'un module, pilotable ou non, est exprimée sous la forme de 2 champs consécutifs:

REGLES diverses

Lorsque dans un Pilote Informatique, au moins un module a eu son adresse changée par un CFET, tous les modules pilotables sont adressés par leur x ou leur x.y d'utilisateur défini dans le CFET, et tout module pilotable non décrit dans le CFET actif en cours est considéré comme inexistant, y compris les éléments non pilotables qui en dépendent. Les modules non pilotables dont le code de niveau "i" est un caractère situé dans l'intervalle [a,z] du jeu J7 ne sont pas concernés par cette règle et sont toujours identifiés.

Certains modules ont une adresse fixe et ne peuvent pas être modifiés par le CFET.

Le Pilote Informatique lui même est considéré comme un élément logiciel non pilotable d'amtc réservée: "z.z". Ses constituants logiciels éventuels sont désignés "z.j".

Les ports de transmission sont des constituants non pilotables d'amtc "p.j". composés du caractère "p" (<7/Ø>) et du numéro de port exprimé par un caractère de 1 à 9 (de <3/1> à <3/9>).

rappel des notations:

amtc

adresse module en topologie constructeur de forme i[.j]

aetc

adresse étendue en topologie constructeur de forme i.[j[.k]...]

amt

adresse de module en topologie utilisateur de forme x[.y]

aet

adresse étendue en topologie utilisateur de forme x[.y[.z]...]