PROTOCOLE DU RESEAU

Pour garantir la transmission et s'affranchir des erreurs, on a le choix entre un protocole interactif ou à répétition.


1) Protocole simplex répétitif (par exemple : clés électroniques ou protocole X10) :

2) Protocole duplex interactif (par exemple : protocole I2C) :

En fait, on n'est pas obligé de faire un choix. On peut même considérer que chaque terminal peut avoir un protocole particulier. Le central choisira en fonction de la destination.


DETECTION DES ERREURS ET PROTOCOLE

Dans le cas d'une liaison filaire, le bus RS485 peut être partagé avec une transmission analogique différentielle, dont le mode  commun est plus haut que 5V. Dans ce cas, il sera fréquent d'avoir des impulsions qui seront vues comme parasites par les récepteurs RS485.

Si on utilise autre chose que le bus RS485 (radio ou optique, par exemple), la présence de parasites est hautement probable.

On constate que la gestion des erreurs de transmission et donc la robustesse du protocole est de la plus haute importance.


 

TYPE DE DETECTION D'ERREUR

 

Matériel

Bit de parité

Duplication quartet
(4 bits/octet)

Répétition  octet
(1 octet/N)

checksum + Accusé de réception

TYPES D'ERREURS ET CAPACITE A DETECTER CES ERREURS

Erreur de format : exemple : on attendait un bit stop et c'est un zéro.

oui

       

Parasite non différentiel

possible

       

Erreur de start : un parasite est compris comme le front descendant d'un bit start. Il s'en suit la réception fictive d'un octet dont des LSB sont nuls, de la forme : FF, FE, FC, F8, F0, E0, C0, 80, 00 selon la longueur du parasite.

non

50%

75%

100%

100%

Erreur sur un bit : typiquement un parasite différentiel au moment de l'échantillonnage bit

non

100%

100%

100%

100%

Idem mais sur plusieurs bits

non

50%

100%

100%

100%

           

IMPLANTATION

         

overhead en taille sur la liaison

0

+1/8

2 fois

N fois

+8 octets typ

taille du logiciel (base MCS51)

 

4 inst

30 instr

30 instr + timer

30 instr + gestion buffer

espionnage par PC sur port COM

 

oui

non

oui

possible

difficulté d'implantation, de validation, coût

0

epsilon

€€

€€€

           

Impression générale

très simple, pas cher, mais peu performant

valide en mode simplex

valide en mode duplex


Deux cas présents selon les capacités du terminal adressé :

On peut aussi cumuler les 2 méthodes, c'est à dire duppliquer les données sensibles (adresses par exemple) tout en utilisant un accusé de réception par dessus.


ENCAPSULATION

Les données à transmettre doivent être précédées de l’adresse du terminal destinataire.

On peut prévoir aussi un champ pour mettre l’adresse du maître émetteur.

On peut aussi prévoir un champ pour mettre la longueur du message, et pourquoi pas enfin un champ pour mettre une somme de contrôle.

On vient de ré-inventer le protocole RFC768, UDP (User Datagram Protocol) utilisé dans la mouvance Internet, basé sur des mots de 32 bits, donc offrant des adresses sur 16 bits.


0.......7 8.....15 16....23 24.....31

+--------+--------+--------+--------+

|     Central     |     Terminal    |

+--------+--------+--------+--------+

|     Length      |    Checksum     |

+--------+--------+--------+--------+

| data octets ...
+---------------- ...


Champ Signification
Central Adresse du central
Terminal Adresse du terminal adressé
Length Nombre d'octets dans le champs data
Checksum Somme de tous les octets transmis

On pourrait aller jusqu’au protocole TCP (Transmission Control Protocol, RFC793) mais il est bien compliqué pour faire de la domotique. Toutefois, il présente l'énorme avantage d'être un standard industriel très fort.

Bref on considère une encapsulation de type RFC768, un peu aménagée pour permettre l’utilisation de terminaux ASCII standards et simplifier son implantation dans un µcontrôleur.


Exemple : U,U,0,0,0,0x01,1,d est un datagramme valide (‘d’=somme de contrôle binaire)


PROTOCOLE DUPLEX A ACCUSE DE RECEPTION

Le central envoie un message à un terminal.

Si celui ci reçoit un message où il décode son adresse, il doit renvoyer un accusé de réception composé comme un message. Il faut indiquer comment le datagramme a été reçu, et pouvoir associer ce compte rendu au datagramme initial. Une solution simple consiste à répéter le check sum du datagramme initial.

La réponse pourrait ainsi comporter 9 octets :








PROTOCOLE SIMPLEX A REPETITION

C'est le cas le plus simple. Le central répète N fois le message, le terminal adressé prends en considération le message s'il est reçu au moins P fois correctement, pendant un temps déterminé (non infini !). On utilise l'octet 5 de protocole pour indiquer le numéro de répétition du datagramme, de x1 à xF maximum.

La longueur des messages sera sans doute inférieure à 10 octets, soit 100 bits par message. A 9600 bauds cela représente une durée de 10.4 ms par message. Choisir une répétition de 10, fait que le central va passer 100 ms à émettre le même ordre. Après, tout dépend de la longueur des perturbations possibles du bus ; considérer que 3 datagrammes valides sur 10 sont suffisant, c’est prendre l’hypothèse qu’il existe au moins 3 « fenêtres » calmes de 10ms dans toute tranche de 100ms.

Il n'y a jamais de réponse à un ordre émis en répétition.


GESTION DES ERREURS

Gestion des erreurs à l'émission d'un datagramme :

Gestion des erreurs à la réception d'un détagramme :