TP Khepera - Automates Conception du logiciel de communication avec le khepera

Transcription

1 TP Khepera - Automates Conception du logiciel de communication avec le khepera 3IF, INSA de Lyon, 2006/2007 Guillaume Beslon, Frédérique Biennier, Christian Wolf Préambule Ce TP est le premier d une série de quatre au cours desquels vous réaliserez progressivement le logiciel de commande d un robot de type Khepera. Il s agit d un mini-robot mobile (5 cm de diamètre, voir ci-dessus) propulsé par deux roues (propulsion différentielle) et disposant de dix capteurs de proximité à infra-rouge. Il embarque un microcontrôleur Mororola qui peut fonctionner en mode autonome ou en mode contrôlé. Dans ce dernier cas, on pilote le Khepera depuis une station de travail via une liaison série de type RS232. Dans le cadre de ces TPs, nous utiliserons le robot en mode contrôlé (le robot sera contrôlé par une station VxWorks maître, voir figure 1). Il est donc indispensable de disposer d un service de communication contrôle-robot fiable sur la base de la liaison RS232. Le but des premiers TPs de cette série sera donc de développer ce service. Pour cette première séance, nous nous attacherons en particulier à concevoir un service de communication fiable en nous basant sur une architecture de type OSI. Travail demandé dans ce TP Conception, sur papier, des automates pour la couche liaison et pour la couche physique du protocole de communication. Validation par un compte rendu en fin de séance. 1 Rappels sur les protocoles de communication Un système de communication doit au minimum permettre un échange de données fiable, sans perte ni duplication entre systèmes informatiques. Pour cela, il faut s assurer que (i) 1

2 Fig. 1 Organisation du système de contrôle. Le robot Khepera est rélié, via une liaison série RS232, à une station VxWorks chargée de le contrôler en temps-réel. l interlocuteur a bien reçu les informations, (ii) que les informations reçues ne comportaient pas d erreur. Un logiciel de communication doit donc offrir un service de haut niveau, avec une qualité de service donnée, aux programmes d application en ce qui concerne la transmission de données en milieu hétérogène. L ensemble de ces contraintes fournit un logiciel assez gros et complexe. Pour résoudre les problèmes de fiabilité interne, assurer une conception modulaire des éléments (et donc les rendre plus facilement réutilisables), l ISO 1 a défini une architecture en sept couches (l OSI, pour Open System Interconnection ). Les tâches de contrôles et de reprises en cas d erreur sont donc réparties dans l ensemble des couches. Chaque couche est vue comme un fournisseur de services par les couches de niveau supérieur et le dialogue entre machines est réalisé par un ensemble de dialogues (suivant un protocole) entre entités de même niveau (figure 2). 1 International Standard Organisation 2

3 =? D E A ) =? D E A * + K? D A , 7 5, 7 2 H J? A + K? D A , 7 5, 7 5 ) 2 5, 7 + K? D A 5, 7 2, 7 2 H J? A 5 ) 2 5, 7 + K? D A 5, 7 2, 7 + = = Fig. 2 Principe de l organisation en couche des logiciels de communication Pour chaque couche, il faut donc définir avec précision : son rôle (analyse fonctionnelle) son protocole de communication avec sa couche appariée sur la machine distante, son interface avec la couche adjacente supérieure sur la machine considérée. Aussi avant de passer à la réalisation d un logiciel de communication, il importe de passer par un certain nombre d étapes permettant de concevoir un système fiable. 1.1 Brève description de la fonction de chaque couche Les rappels donnés ici doivent vous permettre de choisir quelles couches mettre en oeuvre pour réaliser votre logiciel de communication Couche physique Cette couche est chargée de réaliser l interface avec le matériel. Elle peut utiliser les services de drivers particuliers ainsi que ceux du moniteur d entrée/sortie. Elle traite pour le compte de la liaison de données (au niveau de l électronique) la détection des erreurs (contrôles de parité sur les caractères transmis, code cyclique...). La communication est toujours réalisée en série (pas d échange via des coupleurs parallèles). La transmission des caractères peut être assurée de manière : 3

4 arythmique (on re - synchronise l horloge pour chaque caractère à l aide de bits de départ et d arrêt 2 ) synchrone (les caractères sont émis par paquets et on synchronise l horloge en envoyant des caractères de synchronisation (SYNC) en début de paquets et éventuellement en cours de transmission d un paquet) isochrone (l horloge de transmission est calée une fois pour toute et des caractères sont transmis en permanence). Le choix de l un ou l autre de ces modes dépend : de la quantité d information à échanger, des débits de transmission, de facteurs économiques. La couche physique devant rendre ces choix transparents pour les couches supérieures, elle doit assurer : l initialisation convenable des coupleurs de communication, l émission et / ou la réception de données sur la ligne Couche liaison de données Cette couche doit garantir la fiabilité de transmission d unités de données (trames). En effet, la couche physique ne garantit pas un transfert sans erreur. Il faut également assurer un contrôle de flux (pour éviter de perdre ou dupliquer des informations), la correction des erreurs... Pour cela, elle met en oeuvre un protocole spécifique destiné à garantir la fiabilité de la liaison entre deux machines. Elle travaille souvent en mode CONNECTE ce qui permet de faire des initialisations Couche réseau Lorsque deux machines désirent communiquer, elles utilisent assez souvent les services d un réseau de communication. La couche réseau est alors chargée d assurer le routage des données, de sélectionner un chemin (en prenant éventuellement en compte une optimisation économique) et de transcrire l adresse logique d un utilisateur en une adresse physique sur le réseau Couche transport C est la couche charnière du modèle. Elle permet de garantir, quel que soit le choix des services inférieurs, une qualité de transmission donnée. Elle permet aussi d optimiser l acheminement des données, en utilisant parfois plusieurs connexions de réseau. Ceci implique donc que cette couche assure un contrôle de bout en bout et parfois des contrôles d erreur complémentaires (notamment dans le cas de réseaux locaux). Charnière entre les couches hautes et basses, elle 2 ce mode est souvent appelé mode asynchrone 4

5 doit également harmoniser la longueur des SDU (Service Data Unit) et PDU (Protocol Data Unit) qu elle transmet. On parle alors de fragmentation et de réassemblage Couche session Elle permet d organiser et synchroniser les dialogues dans le temps. En effet, certains échanges peuvent être particulièrement longs (gros transfert de fichiers, campagnes d acquisition...) et il peut être important en cas de problèmes de pouvoir faire des reprises automatiques. Cette couche permet de gérer des points de synchronisation et de repère qui permettent de progresser d états stables en états stables (Cf organisation des traitements en mode transactionnel) Couche présentation C est la couche qui permet le travail dans un environnement matériel hétérogène. En effet, sur des machines différentes, il n y a pas forcément le même codage, la même représentation des données, les mêmes modèles de terminaux... Il faut donc réaliser une adaptation. Pour cela, on a deux solutions : une des machines assure une traduction des informations dans une forme directement compréhensible par son interlocuteur, chaque machine utilise une représentation intermédiaire dans une syntaxe de transfert normalisée. Ceci présente un gros avantage par rapport à la solution précédente car, outre l ouverture qui lui est inhérente, si on désire connecter n machines différentes, il suffit d écrire n traducteurs au lieu des n(n-1) nécessaires avec la solution précédente. Enfin, cette couche peut aussi offrir des fonctions de compression et d encryptage des données Couche application C est l ensemble de services de haut niveau qui permettent d utiliser les services de communication entre deux machines : transfert de fichier, messagerie... Cette couche permet de gommer les différences logicielles entre machines hétérogènes. En particulier, le terminal virtuel permet de gommer les différences de matériel quand on travaille en mode transactionnel. Il convient de noter que les services de certains types d applications sont encore en cours de normalisation. 1.2 Méthodologie de conception La première étape consiste à faire une analyse fonctionnelle couche par couche, compte tenu du service à fournir. Dans cette analyse il faut non seulement tenir compte du cahier des charges actuel mais aussi envisager des extensions futures. Ensuite, pour chaque couche il faut définir un protocole (dialogue et ses règles strictes entre les deux couches appariées). 5

6 L incidence de ces éléments au niveau interne suppose de définir le format des données échangées avec l entité appariée et l organisation générale du dialogue. Pour cela, on élabore des scénarii et on réalise les dialogues correspondant. Dans le même temps, il faut prévoir les points d accès au service (Service Access Point : SAP) pour la couche supérieure. Deux entités appariées vont échanger des unités de données de protocole (Protocol Data Unit : PDU). Ces PDU sont composées : de données venant de la couche supérieure, ce sont des unités de données de service (Service Data Unit : SDU) de données de contrôle pour le protocole (Protocol Control Information : PCI). La PCI est traitée par l entité appariée et permet de traiter les données échangées. La partie SDU peut ensuite être transmise à la couche supérieure. L interface entre couches adjacentes est réalisée par les SAP. On aura différentes primitives : requête : ordre qu une couche de niveau N transmet à la couche de niveau inférieure (N-1), indication : signal (éventuellement porteur d une information) transmis par la couche de niveau N-1 à la couche de niveau N, réponse : réponse de la couche N distante vers la couche N qui a envoyé une requête. La réponse fait donc suite à l indication. Pour la couche N-1 de la machine distante, il s agit d un ordre à exécuter. confirmation : signal (éventuellement porteur d information) venant de la couche N-1 et indiquant à la couche N que la réponse est arrivée ou que le traitement dans l entité locale de niveau N-1 est terminée. Pour certaines fonctions, il suffit d utiliser des requêtes et des indications (service non confirmé) Une fois établis ces dialogues et communication entre couches, il ne reste plus qu à élaborer l algorithme interne de chaque couche. Pour cela, on s intéresse aux événements entrant dans une couche (requête, indication,...) et on s intéresse alors aux traitements à réaliser pour pouvoir produire le ou les événements sortant qui en résultent. La représentation des traitements internes d une couche pourra être définie selon les graphismes SDL (specification and description language) rappelés figure 3. 6

7 H A F I - J = J = J J A J A L A A J L A A J A J H = J L A A J I H J = J 6 A I J A? J K H A? = H =? J H A )? J E I G K A J E A A Fig. 3 Graphismes SDL Pour plus de clarté dans la suite, on utilisera des mnémoniques correspondant uniquement au mécanisme requête / indication. Les mnémoniques (N-XY) sont construits de la manière suivante : N = lettre représentant la couche à qui l ordre est donné ou la couche qui renvoie le compte rendu sur l exécution de l ordre. X = R pour une requête ou I pour une indication. Y = type de requête ou d indication : C : connexion, D : déconnexion, E : Emission, R : Réception, ER : Erreur, Par exemple on notera P-RC la requête de connexion transmise par la couche liaison de données et la couche physique. On notera qu une requête de connexion adressée à la couche physique signifie que la couche liaison de données donne l ordre à la couche physique de se connecter. De même une L-IE représente une indication d émission signalée par la couche liaison à la couche supérieure. On notera que cette L-IE constitue la confirmation de la couche liaison à une L-RE. 7

8 2 Réalisation du système de communication avec le khepera 2.1 Architecture du système Le protocole à concevoir est de type Maître / Esclave. Tout envoi de donnée du système de contrôle vers le khepera devra donc être précédé d une invitation à recevoir indiquant également vers quel périphérique (i.e. à quelle adresse) les informations reçues devront être écrites. De même, toute demande de données du système de contrôle vis à vis du khepera sera précédée par l envoi d un invitation à émettre précisant également où il faudra prendre les données à émettre. Votre étude sera faite en deux temps : Étude d un exemple simple, résolu (figures 4, 5, 6, 7 et 8) ; Cas réel guidé (figures 9, 10, 6, 11 et 12). 2.2 Protocole simple sans contrôle Dans ce protocole, on se borne à envoyer des trames au robot SANS se préoccuper de leur bonne réception par le khepera. Le système de contrôle se borne à envoyer, lorsque le ligne est en état, les données sur la liaison série (Cf dialogues et automates). Les invitations ont le format suivant : Wxx = invitation à recevoir des données à transmettre à l adresse xx Rxx = invitation à émettre les données (en l occurence l octet) se trouvant à l adresse xx. Toute trame se termine par un Retour Chariot (rc). 2.3 Protocole avec contrôle Dans ce type de protocole, le khepera renvoie en écho la trame d information qu il a reçu dès qu il l a comprise. Il comprend un trame lorsqu on a pu décoder convenablement l invitation et l adresse qui lui sont indiquées. Ensuite, tous les caractères de la trame sont renvoyés en écho dès que possible. Il faudra donc prévoir un système vous permettant de réaliser à la fois une émission et une réception. Compte rendu : décrire ce protocole : décrire le dialogue en complétant les figures 9 et 10, compléter les automates fournis (figures 11 et 12). version 3.3, 27 février 2007 rédigé avec L A TEX 8

9 N = J H A + = = 4 > J E = E I 2 D O I E G K A + = = 2 D O I E G K A E = E I E E J E = E I = J E 2 1, + 2,, 2 -, 5 2 ) -, , +, , H? 4 H? H? , 2 1, 1, Fig. 4 Dialogue de la phase de connexion en mode sans contrôle (protocole No. 1) 9

10 4 = J H A + = = 4 > J E = E I 2 D O I E G K A + = = 2 D O I E G K A E = E I 4-4 & I J H 9 4 & H? I J H & H? $ I J H 4 $ H? I J H , , $ H? N H? Fig. 5 Dialogue de la phase de transmission en mode sans contrôle (protocole No. 1) 10

11 H A F I ) 1, ) 1, ) 4 + 1, = J J? A? J ) J J A J A? A N E + K? D A E = E I 4 + 1, $ = J A?? A? J 1-4 ) J J A J A N E + K? D A E = E I 1 - ) 1 + ) 4, 4,!? A? J ) 4 4 ) 4-2 H A F * K B B A H 2 H A F * K B B A H 4 4 ) " E I I E # H? A F J E 1 4 = C A ) 1 - ) Fig. 6 Automate de la couche application 11

12 H A F I 1, 1, , = J J? A? J 2 1, ) J J A J A? A N E + K? D A F D O I E G K A , 2 4 4? A? J $ = J A? ) J J A J A N E + K? D A F D O I E G K A % = J A? A H H ) J J A J A N E + K? D A F D O I E G K A , 2 4,!? A? J 4, " E I I E # H? A F J E Fig. 7 Automate de la couche liaison pour le protocole No

13 2 1, H A F I 2 1, J E A K J + 6 5, +, = J J? A? J ) J J A J A E E J E = E I = J E 1 E J & #! H A I A J & #! 2 1 +? A? J 2 4, A L E? = H =? J H A A L E? = H =? J H A! E I I E " E L E J = J E B E E I I E B E E I I E 2 1-4? J E A K J # H? A F J E A H H A K H E C A J E A K J H? A F J E A H H A K H E C A A? J K H A I J = J K I 4 N A? J K H A? = H =? J H A Fig. 8 Automate de la couche physique pour le protocole No

14 14

15 Binome : Nom(s) : = J H A + = = 4 > J E = E I 2 D O I E G K A + = = 2 D O I E G K A E = E I 4 + Fig. 9 Dialogue de la phase de connexion en mode écho (protocole No. 2). À compléter 15

16 = J H A + = = 4 > J E = E I 2 D O I E G K A + = = 2 D O I E G K A E = E I 4-4 & 4 4 $ Fig. 10 Dialogue de la phase de transmission en mode écho (protocole No. 2). À compléter 16

17 % "! # Binome : Nom(s) : H A F I = J J? A? J $ = J A?? A? J = J A? A H H? A? J E I I E H? A F J E Fig. 11 Automate de la couche liaison pour le protocole No. 2. À compléter 17

18 ! $ " # H A F I = J J? A? J? A? J E I I E E L E J = J E B E? D H? A F J E Fig. 12 Automate de la couche physique pour le protocole No. 2. À compléter 18