WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

réseaux locaux industriels

( Télécharger le fichier original )
par farhat benighil
université d'ANNABA - licence Automatique 2007
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

2.1 Couches ISO du bus CAN

La norme ISO 11519 du bus CAN spécifie :

· dans sa partie A, un champ d'identification sur 11 bit (format dit standard)

· dans sa partie B, un champ d'identification sur 29 bit (format dit étendu)

Nota : dans ce recueil, on présentera uniquement le format standard.

Cette norme définit une partie de la couche 1, au sens de la normalisation

ISO qui s'occupe de la définition du signal physique, de l'interface électrique et du codage des bits ainsi que de la totalité de la couche 2 (liaison de données).

L'architecture de communication considérée est comparable à celle d'un réseau local ; elle est limitée à trois couches (figure 2) qui sont, de haut en bas : la couche application, la sous-couche LLC ( Logical Link Control ), la sous-couche MAC ( Medium Access Control ) et la couche physique.

2.1.1 Couche application

Cette couche fournit les services nécessaires à la gestion des tâches et du contrôle tout en respectant les contraintes de temps.

2.1.2 Sous-couche LLC (Logical Link Control)

La fragmentation des messages, correspondant à la couche transport du modèle OSI (Open System Interconnection), n'est pas gérée dans cette norme.

L'application temps réel spécifie à la couche LLC les contraintes temporelles des messages envoyés tels que la période, le temps d'arrivée, l'échéance...

Pour un service de garantie, tous les messages préparés (mis dans une file de transmission) sont transmis avec respect de leurs échéances. Par contre, pour un service de Meilleur effort, les messages en attente de transmission seront mis dans un ordre tel que le taux de perte de messages (le nombre de messages dont les échéances ne sont pas respectées) soit minimal.

L'une des fonctions de la couche LLC est de transformer les messages provenant de la couche application sous une forme appropriée à la couche MAC. C'est le mécanisme de fragmentation qui consiste à découper chaque message en petits paquets. La couche LLC propage les contraintes temporelles de chaque message à ses paquets. L'échéance d'un message peut être copiée à chacun de ses paquets ou encore associée au dernier paquet tout en la réduisant pour les autres paquets de manière à ce que le premier paquet ait l'échéance la plus petite. Une fois fragmentés, les messages sont mis dans une file de transmission selon une politique d'ordonnancement.

- Gestion des erreurs

C'est un mécanisme responsable de la détection et de la correction d'erreurs lors de la transmission de paquets. Le mécanisme classique ARQ ( Automatic Repeat Request), qui consiste à renvoyer à l'émetteur un acquittement positif si un paquet est bien reçu et négatif dans le cas contraire, ne s'applique pas dans notre cas car le mécanisme ne tient pas compte de la composante temps réel.

Une solution avec acquittement serait d'associer un nombre maximal de retransmissions de paquets en fonction de son échéance. Si un acquittement positif est reçu, la copie du paquet est supprimée localement. Une autre solution sans acquittement serait d'envoyer à la fois le maximum de copies de paquets sans se préoccuper des erreurs, le receveur s'arrangera pour garder la copie sans erreur et supprimer les autres. Il est clair qu'aucune solution n'est complètement fiable et présente toujours un taux d'erreurs.

- Contrôle de flux

C'est une technique de synchronisation qui garantit au récepteur de ne pas être débordé par les messages de l'émetteur. Pour un service de garantie, il faut s'assurer qu'il existe suffisamment d'espace dans le buffer récepteur avant d'accepter un message. Par contre, pour un service de Meilleur effort, si le buffer récepteur est plein, le message reçu est perdu.

Nous allons maintenant présenter plus particulièrement les spécificités de la couche liaison de données du bus CAN.

-Principe de l'échange de données

Lors de la transmission des données sur un bus CAN, aucune station n'est adressée, mais le contenu d'un message est identifié par un identificateur univoque sur l'étendue du réseau. Outre identifier le contenu du message, l'identificateur détermine également sa priorité, ce qui est déterminant pour l'assignation d'un bus lorsque plusieurs messages sont en concurrence pour le droit d'accès au bus. Si l'unité centrale d'une des stations souhaite envoyer un message à une ou plusieurs stations, elle transfère les données à transmettre et leur identificateur au module CAN qui lui est affectée. Ce dernier se charge de la constitution et la transmission du message.

Dès qu'il reçoit l'assignation du bus (« émission du message ») toutes les autres stations du réseau se mettent à l'écoute (« réception du message »). Chaque station du réseau CAN est en mesure d'ignorer ou de prendre en compte le message qui est sur le bus (« Sélection »). Ce type d'adressage permet d'avoir une grande flexibilité au niveau de la configuration (figure 3). Contrairement à d'autres réseaux aucune adresse cible physique n'est prescrite du côté du protocole de transmission de données. Ainsi les valeurs de certains capteurs sont réparties sur toutes les stations du réseau évitant que chaque organe de commande n'ait son propre capteur (« diffusion générale multidestinataire »).

l Arbitrage bit à bit non destructif

Pour le traitement temps réel des données, le débit binaire physique (ici 1 Mbit/s maximum) n'est pas le seul critère, il faut aussi que l'assignation du bus soit efficace. Comme les informations traitées n'ont pas le même niveau de priorité, un identificateur de chaque trame a été défini pour déterminer dans quelle mesure le message doit être transmis par rapport à un autre moins urgent. Ainsi le conflit d'accès au bus est résolu au moyen d'un arbitrage bit à bit par l'intermédiaire d'identificateurs respectifs.

- Efficacité de l'attribution du bus

Les procédés d'assignation de bus utilisés sont nombreux, on distingue

Les suivants.

Assignation à tranches de temps fixe : l'assignation s'effectue de manière séquentielle au niveau de chaque poste pour une fourchette de temps maximale, sans se préoccuper du fait que la station a besoin du bus à ce moment-là (exemple : Token Slot).

Assignation en fonction des besoins : l'assignation est fonction de la volonté de transmettre, seules les stations souhaitant émettre sont prises en compte, c'est le procédé utilisé par le bus CAN.

Accès non destructif au bus : en effet chaque accès au bus par une ou plusieurs stations conduit toujours à l'attribution univoque d'un bus, alors que l'accès destructif impose que à tout accès simultané par plusieurs stations, il faut interrompre les tentatives d'émission.

Le rattachement de la priorité d'accès au contenu du message permet en cas de surcharge du bus, d'éviter la saturation de l'ensemble de la transmission comme c'est le cas du CSMA/CD (Carrier Sense Multiple Access/Collision Avidance). Le bus CAN est doté d'un contrôle décentralisé de l'accès au bus, c'est-à-dire que tous les mécanismes essentiels à la communication, y compris le contrôle de l'accès au bus, sont repris en plusieurs points du réseau. Ceci permet d'empêcher de ramener ces mécanismes vers une seule unité qui, une fois en panne, serait très difficile à substituer. Une station redondante mettra beaucoup de temps à prendre en charge la gestion du bus (ce qui peut empêcher tout fonctionnement en temps réel).

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Piètre disciple, qui ne surpasse pas son maitre !"   Léonard de Vinci