Brevet FR3060151A1 — publié le 20180615

DOMAINE TECHNIQUE GENERAL La présente invention concerne un protocole de communication temporellement déterministe utilisant le standard Ethernet et son protocole UDP. Plus précisément, elle concerne un procédé d'exécution de commandes d'une entité hôte sur une entité cible. ETAT DE L'ART Dans le cadre du passage en production de nouvelles gammes de capteurs et du développement de banc de calibrage, il a été identifié le besoin d'un lien de communication temporellement déterministe entre une entité hôte pilotant le calibrage et une entité cible à calibrer. Il existe également le besoin d'un lien de communication permettant d'assurer une bande passante importante afin de calibrer une pluralité de capteurs, tels que du type senseurs inertiels L'état de l'art consiste aujourd'hui à utiliser une hôte (PC) avec un système d'exploitation non temps réel (VVindows, Linux...) et d'y ajouter une carte électronique dédiée pour assurer les aspects de déterminismes temporels. Dans ce cas précis, c'est le lien de communication et son protocole géré par la carte électronique qui assure le temps réel, et non l'hôte et son système d'exploitation. Cependant, la mise en oeuvre de cette solution nécessite d'ajouter à l'hôte (PC) une carte électronique dont la pérennité est difficile à assurer. De plus, ces cartes électroniques répondent bien souvent à un besoin spécifique et sont difficiles à faire évoluer pour assurer les besoins croissants en bandes passantes et en fonctionnalités. Chaque évolution du besoin peut alors nécessiter le développement d'une nouvelle carte et/ou d'un nouveau protocole. De plus, la partie applicative sur l'hôte (PC) étant pour une grosse partie dépendante du protocole et de ses capacités, le changement de protocole demande par conséquent de redévelopper en partie l'applicatif sur l'hôte, ce qui est très couteux. L'autre solution connue consiste à utiliser un hôte (PC) avec un système d'exploitation temps réel et d'utiliser des liens dits « classiques » de la machine (Ethernet, PCI, USB...). La fonctionnalité temps réel du système d'exploitation permet en théorie d'assurer le déterminisme temporel sur le lien de communication choisi. 3060151 2 Cependant, dans le cadre de l'utilisation des systèmes d'exploitation temps réel, ceux-ci demandent une maîtrise importante de leur environnement et ils ne supportent pas les logiciels de calculs type Matlab nécessaires au calibrage des senseurs inertiels. Il est alors nécessaire de développer de nouveaux outils pour 5 assurer, en plus de la partie applicative, tous les calculs nécessaires au calibrage des senseurs. Il est ainsi souhaitable d'améliorer les solutions existantes de sorte à pouvoir proposer une solution utilisant un hôte (PC) avec un système d'exploitation 10 non temps réel et une interface de communication pérenne, évolutive et non orienté temps réel, tout en assurant le temps réel par l'ajout de fonctionnalités protocolaires dédiées permettant la compatibilité avec un ensemble de produits, tels que des capteurs de types senseurs inertiels par exemple.. 15 PRESENTATION DE L'INVENTION Un but de l'invention est de proposer un procédé d"exécution de commandes d'une entité hôte sur une entité cible temporellement déterministe utilisant le standard Ethernet et son protocole UDP. Un autre but de l'invention est de proposer un procédé d"exécution de 20 commandes d'une entité hôte sur une entité cible, générique et permettant la gestion d'erreurs. Notamment, selon un premier aspect l'invention propose un procédé d'exécution de commandes d'une entité hôte sur une entité cible, les étapes suivantes étant mises en oeuvre par l'entité cible : 25 a) Réception d'un premier datagramme émis par l'entité hôte comprenant au moins une commande d'accès en lecture/écriture à une adresse mémoire de l'entité cible ; b) Accès à l'adresse mémoire en fonction de la commande, ledit accès étant selon un premier ou deuxième mode de commande 30 respectivement synchrone ou non synchrone à un signal périodique émis sur l'entité cible ; c) Génération d'un deuxième datagramme comprenant au moins une donnée écrite ou lue à ladite adresse mémoire et un statut d'acquittement du premier datagramme ; 3060151 3 d) Envoi à l'entité hôte du deuxième datagramme. Un tel procédé permet, dans le cadre d'une mise en oeuvre avec des senseurs inertiels, le calibrage d'un plus grand nombre de senseurs en parallèle 5 permettant de réduire les temps de production et les coûts associés. En outre, il permet d'assurer la pérennité des moyens de communication et production pour le calibrage et l'expertise des senseurs inertiels. 10 Un tel procédé est en outre avantageusement complété par les différentes caractéristiques suivantes : le second mode de commande est le mode par défaut ; - dans ledit premier mode de commande : o l'étape a) de réception comprend le stockage dans une zone mémoire de la 15 commande d'accès en lecture/écriture ; et o l'étape b) d'accès à l'adresse mémoire comprend au préalable le retrait de la zone mémoire de la commande d'accès en lecture/écriture ; - le retrait de la zone mémoire de la donnée représentant une commande d'écriture et/ou de lecture est suivie par l'ajout de ladite donnée dans la 20 zone mémoire ; - ledit deuxième datagramme comporte une donnée représentant la capacité libre de la zone mémoire ; la zone mémoire est une pile de type FIFO ; - le signal périodique est émis par une horloge temps réel comprise dans 25 l'entité cible ; le procédé comporte-une étape de réception d'une commande d'activation ou de désactivation de la synchronisation de l'étape d'exécution b) à un signal périodique émis sur l'entité cible ; - le procédé comporte la réception d'une donnée représentant le nombre de 30 commandes d'écriture et/ou lecture à exécuter à chaque signal périodique émis sur l'entité cible ; - le deuxième datagramme comporte au moins une adresse mémoire de la au moins une donnée écrite et/ou lue ; 3060151 4 l'entité cible comporte un compteur incrémenté à chaque envoi de datagramme à l'entité hôte et dans lequel chaque dit datagramme comporte une donnée représentant l'état courant du compteur ; l'entité hôte comporte un compteur incrémenté à chaque envoi de 5 datagramme à l'entité cible et dans lequel chaque dit datagramme comporte une donnée représentant l'état courant du compteur ; le datagramme est au format UDP et encapsulé dans un paquet Ethernet. l'entité cible compare, à chaque réception de datagramme depuis l'entité hôte, l'état courant du compteur à la donnée représentant l'état courant du 10 compteur dudit datagramme, et dans le cas où ladite comparaison est différente, émet une donnée signalant un datagramme manquant à destination de l'entité hôte ; l'entité cible comporte au moins un senseur inertiel. 15 Selon un autre aspect encore, l'invention propose un procédé d'exécution de commandes entre une entité hôte et une entité cible, les étapes suivantes étant mises en oeuvre par l'entité hôte : a) Transmission à l'entité cible d'un premier datagramme comprenant au moins une commande d'accès en 20 lecture/écriture à une adresse mémoire de l'entité cible ; b) Réception d'un deuxième datagramme émis par l'entité cible comprenant au moins une donnée écrite ou lue à ladite adresse mémoire et un statut d'acquittement du premier datagramme ; et dans lequel l'entité hôte comporte un compteur incrémenté à chaque envoi de 25 datagramme cible à l'entité et dans lequel chaque dit datagramme comporte une donnée représentant l'état courant du compteur, à chaque réception de datagramme depuis l'entité cible, l'état courant du compteur à la donnée représentant l'état courant du compteur dudit datagramme, et dans le cas où ladite comparaison est différente, émet une donnée signalant un datagramme manquant 30 à destination de l'entité cible. L'invention concerne en outre une entité cible comprenant : - Une interface de communication avec une entité hôte ; 3060151 5 - Une unité de traitement configurée pour mettre en oeuvre un procédé d"exécution de commandes tel que décrit ci-dessus. L'invention concerne également une entité hôte comprenant : 5 - Une interface de communication avec une entité cible ; - Une unité de traitement configurée pour mettre en oeuvre un procédé d"exécution de commandes tel que décrit ci-dessus. Elle concerne en outre un produit programme d'ordinateur comprenant des instructions de code pour l'exécution du procédé proposé lorsque le dit procédé est 10 mise en oeuvre par un microprocesseur de l'entité cible ou de l'entité hôte. PRESENTATION DES FIGURES D'autres caractéristiques et avantages de la présente invention apparaîtront 15 à la lecture de la description qui va suivre d'un mode de réalisation préférentiel. Cette description sera donnée en référence aux figures suivantes : - la figure 1 représente schématiquement un système pour la mise en oeuvre d'un procédé d'exécution de commandes d'une entité hôte sur une entité cible selon l'invention ; 20 - la figure 2 représente un protocole de communication pour la mise en oeuvre du procédé selon l'invention ; - La figure 3 représente certaines étapes d'un procédé d'exécution de commandes d'une entité hôte sur une entité cible selon l'invention. 25 DESCRIPTION DETAILLEE La figure 1 représente un système pour la mise en procédé d'exécution de commandes entre une cible 10 et un hôte 20, permettant à ce dernier l'accès en 30 lecture/écriture sur la cible 10. La cible 10 comporte un récepteur 11 qui réceptionne des paquets de données 30 depuis un émetteur 21 de l'hôte 20. 3060151 6 La cible 10 comporte également un émetteur 12 qui réceptionne des paquets de données 30 comportant des commandes d'accès à destination d'un récepteur 22 de l'hôte 20. Les paquets de données 30 sont préférentiellement des paquets Ethernet 5 composés de datagrammes, par exemple définis dans le format du protocole UDP. La cible 10 comprend des composants 13 et 14 respectivement pour le décodage des paquets réceptionnés et l'exécution des commandes reçues. La cible 10 peut également comporter un espace mémoire 15 permettant le stockage de commandes comprises dans les paquets réceptionnés et décodés. 10 L'hôte 20 peut également comporter un composant de pilote de protocole 23 permettant l'interface avec la cible 10. La figure 2 illustre un protocole de communication désigné ci -après sous le nom de protocole MMIPoE (Memory Mapped Isochronous Protocol Over 15 Ethernet). Ce dernier utilisant le protocole standard Ethernet et son protocole UDP, il assure à minima l'ensemble des fonctionnalités réalisées par cette dernière. Le protocole MMIPoE étant basé sur le protocole UDP de l'Ethernet, les aspects SFD+Preambule, entête Ethernet (adresses MAC), entête IP, entête UDP 20 et FCS sont conservés. Le protocole MMIPoE est alors encapsulé directement dans la partie « données » des paquets Ethernet. Il est composé d'une partie entête et d'une partie payload (données utiles). Par exemple, l'entête MMIPoE est composé de 24 octets et suit l'entête 25 UDP d'un paquet Ethernet. Sa décomposition est la suivante : Octets (Big Endian) Octet 3 2 11 0 3::3 ,_: 'le Endian) Offset octet Bit 011 12131-151 171819 r,011111211?1,Jr,5 'H'71,,:,' 1202' r22r23124125126127128129303' 0 con...ent 4 32 seq_n.in-irer dest 8 64 -irgi 12 z -I- 16 a,-g6 ar^7.5 20 c 3060151 7 Le bit de poids fort (MSB) du champ « content » représente la version du protocole MMIPoE, le bit de poids faible (LSB) représente le nombre de mots de 32 bits qui composent l'entête MMIPoE. Le champ « content » de l'entête MMIPoE est par exemple égal à la constante 0x0106. 5 L'hôte 20 positionne le champ « dest » à 0x00 afin d'indiquer que le destinataire est la cible 10 de calibration. En réponse, la cible 10 positionne le champ « dest » à 0x80 pour indiquer que le destinataire est l'hôte 20 de calibration. 10 L'émetteur 12 ou 21 indique dans le champ « size » de l'entête MMIPoE le nombre de mots 32 bits de la payload MMIPoE qui suit l'entête MMIPoE. En référence à la figure 3, le procédé d'exécution de commandes entre une cible 10 et un hôte 20 comporte une étape E10 dans laquelle l'hôte 20 encapsule 15 au moins une commande d'accès en lecture\écriture dans un message défini dans un format du protocole MMIPoE et encapsulé dans un datagramme UDP. Ledit datagramme est envoyé à la cible 10, qui le réceptionne et le décode dans une étape E20. Le récepteur cible 11 ignore le paquet Ethernet reçu si : 20 le champ « dest » de l'entête MMIPoE a son MSB à 1 ; le champ « marker » de l'entête MMIPoE est différent d'une constante préalablement définie ; le champ « content » de l'entête MMIPoE est différent de la constante 0x0106 ; 25 le paquet implémente une version différente du protocole MMIPoE de l'entité cible. Le champ « cmd/ack » de l'entête MMIPoE est constitué de la façon suivante : 3060151 8 tint I No ptio [15] C/A 0 : Commande 1 : Acknowledge [14] SIA 0 : Synchrone I 1 : Asynchrone [13] RD/WR 0 : Lecture I 1 : Ecriture [12] A/F 0 : Adressé / 1 : FIFO isochrone [11] N/R 0 : Normal " 1 : Rapide [10-6] réseNés Doivent être mis à 0 lors de l'émission et ignorés lors de la réception. [5] I OFF1 ON 0 : isochrone off/ 1 : isochrone on [4] ri/13 0 : non bouclé / 1 : bouclé [3-ol CONF_ISO 00:0 : simpe DO.:1 : trul:i 0010 : fbv.. :V band,» .., Autres : réserves pc..[ Je, futurs usages La cible 10 ignore les paquets Ethernet reçus si le bit 15 du champ « cmd/ack » de l'entête MMIPoE est différent 0 ou si la commande n'est pas 5 reconnue. Elle indique alors dans « status1[7] » (bit numéro 7 du mot status1) une erreur (« cmd_err »). « Statut1 » est un mot (donnée de 16 bits) envoyé par la cible 10 à l'hôte 20, pour signifier à ce dernier le statut de la commande reçue par la cible 10. « Status1[7] » est remis à 0 après l'envoi de « status1 ». Dans le cas où le paquet est ignoré à cause du bit 15 ou si une commande 10 n'est pas reconnue, le mot « status1 » ne sera évidemment transmis à l'hôte 20 que lorsque la cible 10 aura reçu une commande valide. Le tableau ci-dessous illustre les commandes de lecture et d'écriture, d'activation et de désactivation du passage en mode isochrone (décrit ci-dessous), 15 et les champs arguments associés à chaque commande. Ww-M2ra - READ Cmd WRITE Cmd - WRITE_FAST Cmd adr base adr base adr Inc [31:16] [re'0] [1:01 WRITE FIFO 150 Cmd START ISO SIMPLE Cmd iscp-siniPle,rd-adr sHiple rd_adr [15: - . -21e wr_adr j- 5:CT1 _ _ [31:1.1 iso '_ r _simole [3T iacr 7] START ISO MULTI Cmd Iso_multi_fbw_nb_rd 115D1 iso_muMibei_nb,24- - - [15:0] START2S0 FEN/ Cmd o midi fb,,_nb rd tso_multi_fly,_nb_,T [1-510] [15:0] STOFISO Cmd La cible 10 peut se trouver dans 2 modes de fonctionnement différents en 20 fonction des commandes reçues : Mode isochrone C'est le mode qui assure l'aspect déterministe temporel du protocole MMIPoE. Dans une étape E30, la cible 10 stocke les commandes reçues dans un 3060151 9 espace mémoire 15, préférentiellement de type pile FIFO nommée FIFO isochrone. La cible 10 empile dans la FIFO isochrone les données contenues dans la payload MMIPoE dans l'ordre de leurs positionnements dans ladite payload. 5 Dans une étape E40, les commandes sont extraites de l'espace mémoire pour être exécutées par la cible 10. L'exécution des commandes à lieu à un instant déterminé, dit top temps réel. Ledit top est préférentiellement périodique et défini par la cible 10. Celle-ci peut comporter une horloge temps réel (HTR) qui définit le top temps réel. 10 Le nombre de lectures et d'écritures à exécuter, et par conséquent le nombre d'éléments à dépiler de la FIFO isochrone à chaque top temps réel, est connu de la cible 10 par la commande de démarrage (décrite plus loin) du mode isochrone envoyé par l'hôte 20. En effet, un argument de la commande précise le nombre de lectures, un autre le nombre d'écritures. 15 Il existe 3 commandes de démarrage du mode isochrone qui permettent pour chacune d'elles de passer la cible 10 dans l'un des deux sous modes suivants : Sous mode non bouclé : Dans ce mode, à chaque fois qu'un élément de la FIFO isochrone est dépilé par la cible 10, il n'est pas rempilé. La FIFO 20 isochrone se vide donc à chaque dépilage mais l'hôte 20 peut néanmoins continuer à la remplir par l'envoi de commandes WRITE_FIFO_ISO (cf. Mode asynchrone décrit ci-dessous). Si la FIFO isochrone est pleine au moment de l'empilage d'une donnée, alors la cible 10 arrête l'empilage des données et terminer l'exécution de la commande VVRITE FIFO_ISO. 25 - Sous mode bouclé : Dans ce mode, et par opposition au mode décrit précédemment, à chaque fois qu'un élément de la FIFO isochrone est dépilé par la cible 10, il est alors automatiquement rempilé. Dans ce sous-mode, l'hôte 20 n'a donc plus besoin de continuer à alimenter la FIFO isochrone en commandes de lecture et/ou d'écriture (cf. Mode asynchrone 30 décrit ci-dessous). Les commandes de passage en mode isochrone sont les suivantes : Isochrone simple : o en mode non bouclé si la cible 10 reçoit une commande 35 START_ISO_SIMPLE, 3060151 10 o en mode bouclé si la cible 10 reçoit une commande START_ISO_LOOP_SIMPLE. Dans ce mode isochrone, dans une étape E50, la cible 10 exécute à chaque top temps réel une lecture suivie d'une écriture dont les adresses 5 sont définies lors de l'envoi par l'hôte 20 de la commande de démarrage de l'isochrone simple. Dans l'étape E40, la cible 10 va alors dépiler à chaque top temps réel un seul élément de la FIFO isochrone qui va correspondre à la donnée à écrire et exécuter une commande de lecture à l'adresse iso_simple_rd_adr (où est stockée la concaténation des champs « arg1 » et 10 « arg2), suivi d'une commande d'écriture à l'adresse iso_simple_wr_adr (où est stocké la concaténation des champs « arg3 » et « arg4 ») avec une donnée correspondant au dépilage d'un élément de la FIFO isochrone. Si la FIFO isochrone est vide au moment du dépilage,alors la cible 10 arrête l'exécution de la commande d'écriture pour le top temps réel courant. 15 Une fois la commande de lecture et d'écriture exécutée, dans une étape E60, la cible 10 répond en retournant un paquet MMIPoE contenant l'adresse de lecture, la donnée lue, l'adresse d'écriture et la donnée écrite, et ce à chaque top temps réel. Egalement, la cible 10 émet un acquittement (acknowledge) 20 START_ISO_SIMPLE si elle est en mode non bouclé ou un acquittement START_ISO_LOOP_SIMPLE. Isochrone multi : o en mode non bouclé si la cible 10 reçoit une commande 25 START_ISO_MULTI, o en mode bouclé si la cible 10 reçoit une commande START_ISO_LOOP_MULTI, Dans ce mode isochrone, dans une étape E50, la cible 10 exécute à chaque top temps réel des lectures suivies d'écritures dont leurs nombres 30 sont définis lors de l'envoi par l'hôte 20 de la commande de démarrage de l'isochrone multi respectivement par les valeurs des champs « arg1 » (stocké dans la donnée iso_multi_fbw_nb_rd) et « arg2 » (stocké dans la donnée iso_multi_fbw_nb_wr). Dans l'étape E40, la cible 10 va alors dépiler à chaque top temps réel autant d'éléments qu'il y a de lectures à effectuer, 35 chaque élément représentant une adresse de lecture, et 2 fois plus 3060151 11 d'éléments qu'il y a d'écritures à effectuer, chaque pair d'éléments représentant l'adresse et la donnée à écrire. Si la FIFO isochrone est vide au moment du dépilage, alors la cible 10 arrête l'exécution des commandes de lectures et d'écriture pour le top 5 temps réel courant. Si la cible 10 est en train d'exécuter les commandes de lectures et/ou d'écritures du top temps réel courant et qu'un nouveau top temps réel arrive, alors la cible 10 ignore ce dernier, indique dans statusl[6] une erreur (htr_overflow) et continue l'exécution des commandes du top temps réel 10 courant. Statusl[6] est remis à 0 après l'envoi de status1. Une fois les commandes de lecture et d'écriture exécutées, dans une étape E60, la cible 10 répond en retournant un paquet MMIPoE contenant les adresses de lecture avec les données lues associées ainsi que les adresses d'écriture avec les données écrites, et ce à chaque top 15 temps réel. Egalement, la cible émet un acquittement START_ISO_MULTI si elle est en mode non bouclé ou un acquittement START _I SO_LOOP_M U LTI. 20 - Isochrone Full Bandwidth : o en mode non bouclé si la cible 10 reçoit une commande START _ISO_FBVV, o en mode bouclé si la cible 10 reçoit une commande START_ISO_LOOP_FBW. 25 Il s'agit du même fonctionnement que l'isochrone multi à la différence que dans l'étape E60 la cible 10 ne retourne que les données lues et écrites, sans les adresses, afin d'augmenter la bande passante. Egalement, la cible 10 émet un acquittement START_ISO_FBW si elle est en mode non bouclé ou un acquittement START_ISO_LOOP_FBW. 30 Dans tous les modes isochrones, lors de la réponse de la cible 10 à l'hôte 20, lors de chaque top temps réel, à l'étape E60 les champs « arg1 » et « arg2 » de l'entête MMIPoE prennent respectivement les bits 31 à 16 et 15 à 0 de la version de la cible 10. 3060151 12 Egalement, si les commandes de lecture ou d'écriture n'ont pas pu être exécutées à cause d'un problème de FIFO isochrone vide, alors la payload MMIPoE est nulle. 5 A chaque envoi, l'émetteur cible 12 met le champ « cmd/ack » de son entête MMIPoE avec la valeur de ce même champ de l'entête MMIPoE de la commande à laquelle il répond tout en forçant le bit 15 à 1. La cible 10 met également à chaque émission le champ « arg3 » de son entête MMIPoE avec la valeur du compteur HTR, celui-ci étant initialisé à 0, 10 s'incrémentant de 1 en 1 à chaque top temps réel et repassant à 0 s'il vaut OxFFFF au moment de l'incrémentation. Dans une étape E70, les données envoyées dans un paquet UDP par la cible 10 et définies dans le protocole MMIPoE sont réceptionnées par l'hôte 20. 15 La sortie du mode isochrone se fait simplement par l'envoi depuis l'hôte 20 d'une commande d'arrêt, faisant alors automatiquement basculer la cible 10 en mode asynchrone (cf description ci-dessous). L'acquittement STOP_ISO est alors émis lorsque la cible n'est plus en 20 mode isochrone. Le champ « arg3 » ne représente donc pas la valeur du compteur HTR. Si la cible 10 reçoit une commande STOP_ISO, elle termine alors l'envoi en cours puis quitter le mode isochrone pour entrer en mode non-isochrone. La cible 10 répond après l'exécution d'une commande STOP_ISO en 25 émettant un acknowledge STOP_ISO avec les champs « arg1 » et « arg2 » de l'entête MMIPoE qui prennent respectivement les bits 31 à 16 et 15 à 0 de la version de la cible. En mode asynchrone, la cible 10 vide complètement sa FIFO isochrone lorsqu'elle reçoit une nouvelle commande d'arrêt. 30 Egalement, la cible 10 doit indiquer dans - status1[5] (iso_on) si elle est en mode non isochrone (0) ou en mode isochrone (1). 3060151 13 - statusl[4] (iso_boucle) si elle est en mode isochrone non bouclé (0) ou en isochrone bouclé (1). Si la cible 10 est en mode non isochrone, alors statusl[4] doit être mis à 0. - statusl[3:0] (iso_mode) si elle est en mode isochrone simple (0000), en 5 mode isochrone multi (0001) ou en mode isochrone fbw (0010). Si la cible 10 est en mode non isochrone, alors statusl[3:0] doit être mis à 0000. Mode asynchrone 10 Dans ce mode, la cible 10 exécute toutes les commandes de lecture et d'écriture qu'elle reçoit du protocole MMIPoE, mais ne garantit pas leur moment d'exécution. En effet, aucune contrainte temporelle ne s'applique sur celle-ci. A la différence du mode synchrone décrit ci-dessus, les étapes E30 et E40 de stockage et de déstockage des commandes dans la pile FIFO ne sont pas exécutées. 15 Dans le cas de commandes de lecture, l'hôte 20 indique dans le paquet MMIPoE toutes les adresses de lecture. Ces commandes de lecture s'appellent des commandes READ et ne sont exécutées par la cible 10 qu'en mode asynchrone. Une fois les lectures effectuées, la cible 10 répond à la commande en 20 retournant toutes les adresses et les données lues associées à chacune d'entre elles. Ainsi, la cible 10 répond après l'exécution d'une commande READ en émettant un acknowledge READ avec les champs « arg1 » et « arg2 » de l'entête MMIPoE qui prennent respectivement les bits 31 à 16 et 15 à 0 de la version de la cible 10, et dont la payload MMIPoE est égale à la payload de la commande 25 READ. Une commande READ dont le champ « size » est égal à 0 est une commande de lecture valide et dont la cible 10 répond avec juste l'entête MMIPoE et sans sa payload. C'est équivalent à une commande de lecture de statut de la cible 10. 30 Le champ « size » est pair ou nul car une adresse est associée avec le mot réservé suivant. Si le champ « size » est impair, la cible 10 indique alors dans status1[7] une erreur (cmd_err). 3060151 14 Dans le cas de commandes d'écriture, l'hôte 20 indique dans le paquet MMIPoE toutes les adresses d'écriture et les données associées. Ces commandes d'écriture s'appellent des commandes WRITE. Il est également possible d'exécuter des commandes nommées WRITE_FAST qui permettent de n'indiquer que 5 l'adresse de base de la première écriture et un offset fixe à appliquer à chaque accès, permettant par conséquent d'exécuter un plus grand nombre d'écritures avec un seul paquet MMIPoE. Ainsi, l'adresse de base de base est : o adr_base[31:16] = « arg1 » de l'entête MMIPoE o adr_base[15:0] = « arg2 » de l'entête MMIPoE et l'incrément d'adresse en 10 complément à 2 signé est : o adr_inc[15:0] = « arg3 » de l'entête MMIPoE Ces deux commandes d'écriture ne sont exécutées par la cible 10 qu'en mode asynchrone. 15 Une fois les écritures effectuées, la cible 10 répond à la commande en retournant toutes les adresses et les données. La cible 10 répond après l'exécution d'une commande WRITE en émettant un acknowledge WRITE avec les champs « arg1 » et « arg2 » de l'entête MMIPoE qui prennent respectivement les bits 31 à 16 et 15 à 0 de la version de la cible 10, 20 et dont la payload MMIPoE est égale à la payload de la commande WRITE à laquelle la cible répond. Une commande WRITE dont le champ « size » est égal à 0 est une commande d'écriture valide et dont la cible 10 répond avec juste l'entête MMIPoE et sans sa payload. C'est équivalent à une commande de lecture de statut de la 25 cible 10. Dans le cas de la commande WRITE, le champ « size » est pair ou nul car une adresse est associée avec le mot réservé suivant. La cible 10répond après l'exécution d'une commande WRITE_FAST en émettant un acknowledge WRITE_FAST avec les champs « arg1 », « arg2 » et « arg3 » de l'entête MMIPoE ainsi que la payload MMIPoE qui prennent les mêmes 30 valeurs que ceux de la commande WRITE_FAST à laquelle la cible 10 répond. Les commandes décrites précédemment sont donc toutes mappées mémoires puisque l'hôte 20 fournit l'adresse d'exécution de la commande à la cible 35 10. Cependant, la commande d'écriture nommée WRITE_FIFO_ISO diffère des 3060151 15 autres commandes puisque celle-ci ne fournit aucune adresse. Cette commande permet de venir écrire dans la FIFO Isochrone (cf Mode Isochrone décrit ci-dessus) de la cible 10 sans connaître son adresse. Ainsi, l'hôte 20 n'a pas besoin de connaître l'adresse d'implémentation de la FIFO dans la cible 10, cette FIFO étant 5 un élément indispensable au mode isochrone décrit ci-dessus. Cette commande d'écriture dans la FIFO est exécutée en mode asynchrone mais également en mode isochrone. Capacité FIFO 10 La capacité de la FIFO implémentée sur la cible 10 dépend des ressources disponibles et va donc permettre de définir le nombre maximal de commandes de lecture et/ou d'écriture empilables, mais aussi le temps maximal que l'hôte 20 peut rester sans envoyer de nouvelles commandes pour alimenter la FIFO, à condition que celle-ci soit préalablement remplie. Ainsi, plus la FIFO est grande, et plus les 15 contraintes temps réel sur la machine sont relâchées (à titre d'exemple sur Windows, il a été mesuré des durées de plusieurs millisecondes pendant lesquelles Windows n'envoie rien sur l'Ethernet pour ensuite envoyer toutes les données qu'il aurait dû envoyer précédemment). Le protocole MMIPoE n'impose pas de taille minimale pour cette FIFO qui va donc dépendre des ressources 20 disponibles sur une carte électronique de la cible 10. En exemple, une carte électronique avec peu de ressource et implémentant une FIFO de 32 commandes ne disposera que d'une autonomie de 4ms si le mode isochrone demande d'exécuter 4 lectures à 2kHz. Une autre carte électronique avec beaucoup de mémoire pourra implémenter une FIFO de 32768 commandes 25 offre alors une autonomie de plus de 4 secondes dans les mêmes conditions de mode isochrone que l'exemple précédent. A chaque envoi, l'émetteur cible 12 met le champ « arg4 » de son entête MM IPoE avec la valeur de la capacité restante de la FIFO isochrone en nombre de mots 32 bits saturé à 65535, le champ « arg5 » avec la valeur status1 et le champ 30 « arg6 » avec une valeur status2 (spécifiée selon un choix de conception). Gestion des erreurs L'UDP a l'avantage d'être simple à utiliser et à implémenter, mais souffre de manques en termes de gestions d'erreurs. En effet, il n'est pas possible de 3060151 16 savoir lorsque l'on envoie un paquet si la cible 10 l'a correctement reçu. Ceci pose un véritable problème, plus particulièrement dans le cadre du mode isochrone où il est important d'avoir cette information, sous peine de potentiellement perdre un top temps réel sans le savoir. Pour pallier à ce manque de l'UDP, le protocole MMIPoE 5 implémente des mécanismes de gestions d'erreurs : - A chaque fois qu'un paquet est émis, l'émetteur insère dans le paquet MMIPoE un champ seq_number qui correspond toujours au dernier seq_number qu'il a émis +1. La cible 10 et l'hôte 20 ont donc chacun leur seq_number qu'ils incrémentent chacun de leur côté à chaque envoi. 10 Lorsque la cible 10 détecte que le champ seq_number reçu n'est pas égal au précédent +1, cela signifie donc qu'elle a manqué un paquet MMIPoE et l'indique alors dans un statut qui est retourné à l'hôte 20. Ce dernier est également capable par le même mécanisme de savoir si elle a manqué un paquet MMIPoE émis par la cible 10. 15 Lors du ler envoi, le champ « seq_number » envoyé est égal à 0. Si la dernière valeur était OxFFFF, alors « seq_number » repasse automatiquement à 0. Le récepteur indique dans status1[15] une erreur (seq_number_err) si le champ « seq_number » de l'entête MMIPoE du paquet Ethernet valide 20 reçu est incohérent de la valeur de ce même champ du paquet Ethernet MMIPoE précédent. Statusl [15] est remis à 0 après l'envoi de statusl. - Afin que l'hôte 20 ait constamment connaissance du statut de la FIFO isochrone, la capacité restante de celle-ci est retournée par la cible 10 à chaque envoi, avec les informations de dépassement de capacité, de FIFO 25 pleine, de FIFO vide ainsi qu'une erreur lorsqu'en mode isochrone la FIFO est vide alors que la cible 10 avait besoin de dépiler un élément. Toutes ces informations sont indispensables au monitoring du temps réel. - Si l'hôte 20 démarre le mode isochrone de la cible 10 avec un trop grand nombre de commandes de lectures et/ou écriture à exécuter à chaque top 30 temps réel, alors la cible 10 retourne une erreur pour indiquer le dépassement de capacité temps réel. Elle le détecte lorsqu'elle est en train d'exécuter les commandes du top temps réel courant et qu'un nouveau top temps réel est déclenché. - A chaque envoi, l'émetteur cible 12 met le champ « id » de son entête 35 MMIPoE avec la valeur de ce même champ de l'entête MMIPoE de la 3060151 17 commande à laquelle il répond. L'intérêt du champ « id » est de permettre au récepteur hôte 22 de s'assurer que la cible 10 lui répond bien. Sa valeur est sans importance et peut changer d'une trame à l'autre. Il s'agit simplement d'un identifiant de trame. 5 De plus, si l'émetteur cible 12 envoie un acknowledge dont la payload MMIPoE est de taille supérieure à 362 mots (1448 octets), alors l'émetteur cible 11 ne transmet pas les mots après le 362ème et indique une erreur dans status1[10] (mmipoe_payload_overflow). Cependant, le champ « size » est représentatif du 10 nombre de mots qui auraient dû être transmis, saturé à 65535. Le récepteur 11 indique dans statusl[9] une erreur (size_err) si le champ « size » de l'entête MMIPoE du paquet Ethernet valide reçu est supérieur à 362 ou s'il est incohérent de la taille de la payload MMIPoE. Dans un tel cas, il ignore le paquet. statusl[10] et statusl[9] sont remis à 0 après l'envoi de status1. 15 CONCLUSION Le protocole MMIPoE offre la possibilité de communiquer avec un déterminisme temporel sur le bus Ethernet entre un hôte 20 et une cible 10 embarquée. 20 Il permet d'accéder directement à l'espace mémoire de la cible 10 par des commandes (asynchrones ou isochrone) de lectures/écritures. Il ne possède par conséquent pas de commandes spécifiques qui demanderaient à la cible 10 des ressources dédiées à leur décodage et leur exécution. Il est ainsi suffisamment souple et générique pour permettre sa réutilisation sur tout type de système, sans 25 pour autant avoir à implémenter de nouvelles commandes ou nouvelles fonctionnalités protocolaires. L'Ethernet équipant un nombre important de produits embarqués et étant de plus en plus utilisé en remplacement des liaisons RS de maintenance et de téléchargement, le protocole MMIPoE devient un lien générique du produit. 30 Utiliser le standard Ethernet permet de garantir la pérennité du standard de communication. Ethernet est largement déployé et totalement démocratisé à travers le monde. C'est un standard évolutif en terme de bande passante (10M, 100M, 1G, 10G...) sans pour autant remettre en question à chaque évolution la 3060151 18 partie protocolaire de l'UDP. Tous les PC en sont aujourd'hui équipés, évitant ainsi d'avoir une machine et du matériel dédié pour assurer la communication. Utiliser le protocole UDP permet de transmettre des données de manière simple entre deux entités, diminuant ainsi la complexité et donc le coup de 5 l'implémentation sur la cible 10. Le protocole MMIPoE est pensé pour une mise en oeuvre par une ou plusieurs fonctions logicielles, mais également 100% matérielles. Il est entendu par fonction logicielle, toute fonction mise en oeuvre par un composant logiciel, qu'il s'agisse d'un logiciel de base ou encore d'un logiciel 10 applicatif. Une fonction logicielle s'entend ainsi au sens large comme un ensemble d'instructions logicielles aptes à mettre en oeuvre ladite fonction logicielles lorsque les instructions logicielles sont exécutées par un processeur. Il est entendu par fonction matérielle, toute fonction mise en oeuvre par un composant matériel, c'est-à-dire par un composant électronique ou par un 15 ensemble de composants électroniques. A titre d'exemple supplémentaire, un composant électronique est un composant logique programmable, également appelé FPGA (Field Programmable Gate Array), ou encore un circuit intégré dédié, également appelé ASIC (Application Specific Integrated Circuit) ou tout autre composant électronique, programmable ou non. 20 L'hôte faisant des accès en lecture/écriture dans l'espace mémoire de la cible 10, et non pas avec des commandes dédiées, il est alors tout à fait possible d'utiliser le protocole MMIPoE pour communiquer directement avec un driver 25 implémenté dans la cible 10 mais pour un autre type de lien (Bittware, SPI, UART, 12C, ARINC, USB, Ethernet, ULIS...). La cible 10 n'a donc plus qu'à exécuter les commandes de lecture et d'écriture aux adresses demandées par l'utilisateur, c'est-à-dire vers le driver concerné. A titre d'exemple, il devient alors possible de communiquer directement avec un contrôleur de mémoire Flash et donc 30 d'implémenter le protocole de téléchargement, de vérification ou d'effacement des données directement sur l'hôte (PC) et non plus sur la cible 10 qui n'a plus à se soucier du décodage et de l'exécution de commandes dédiées à une fonctionnalité particulière. De même, et toujours à titre d'exemple, il est possible d'envoyer une trame périodique sur une liaison RS en configurant la FIFO isochrone pour qu'à 3060151 19 chaque top temps réel la cible 10 communique avec le driver RS afin que celui-ci procède à l'envoi des données. Dans le cadre d'une mise en oeuvre du protocole MMIPoE pour le calibrage 5 et l'expertise de senseurs inertiels par exemple, ledit protocole permet d'assurer la pérennité des moyens de communication et production. De plus, grâce à sa bande passante élevée, le protocole MMIPoE permet le calibrage d'un plus grand nombre de senseurs en parallèle permettant de réduire les temps de production et les coûts associés. 10 La généricité du protocole MMIPoE permet sa réutilisation systématique de sur différents projets/produits, permettant ainsi de diminuer les coûts. Particulièrement pour des applications à haute criticité comme en aéronautique civile pour la communication entre équipements. 15 REVENDICATIONS1. Procédé d'exécution de commandes d'une entité hôte (20) sur une entité cible (10), les étapes suivantes étant mises en oeuvre par l'entité cible (10) : a) Réception d'un premier datagramme émis par l'entité hôte (20) comprenant au moins une commande d'accès en lecture/écriture à une adresse mémoire de l'entité cible (10) ; b) Accès à l'adresse mémoire en fonction de la commande, ledit accès étant selon un premier ou deuxième mode de commande respectivement synchrone ou non synchrone à un signal périodique émis sur l'entité cible (10); c) Génération d'un deuxième datagramme comprenant au moins une donnée écrite ou lue à ladite adresse mémoire et un statut d'acquittement du premier datagramme ; d) Envoi à l'entité hôte (20) du deuxième datagramme. 2. Procédé d'exécution de commandes selon la revendication précédente, dans lequel le procédé comporte-une étape de réception d'une commande d'activation ou de désactivation du premier mode de commande synchrone, le second mode de commande étant le mode par défaut. 3. Procédé d'exécution de commandes selon l'une des revendications précédentes, dans lequel dans ledit premier mode de commande : - l'étape a) de réception comprend le stockage dans une zone mémoire (15) de la commande d'accès en lecture/écriture ; et - l'étape b) d'accès à l'adresse mémoire comprend au préalable le retrait de la zone mémoire (15) de la commande d'accès en lecture/écriture. 4. Procédé d'exécution de commandes selon la revendication précédente, dans lequel le retrait de la zone mémoire de la commande 3060151 21 d'accès est suivi par l'ajout de ladite commande dans la zone mémoire (15). 5. Procédé d'exécution de commandes selon l'une des 5 revendications 3 à 4, dans lequel dans ledit deuxième datagramme comporte une donnée représentant la capacité libre de la zone mémoire. 6. Procédé d'exécution de commandes selon l'une des revendications 3 à 4, dans lequel la zone mémoire (15) est une pile de type 10 FIFO. 7. Procédé d'exécution de commandes selon l'une des revendications précédentes, dans lequel le signal périodique est émis par une horloge temps réel comprise dans l'entité cible (10). 15 8. Procédé d'exécution de commandes selon l'une des revendications précédentes, dans lequel le procédé comporte la réception d'une donnée représentant le nombre de commandes d'écriture et/ou lecture à exécuter à chaque signal périodique émis sur l'entité cible (10). 20 9. Procédé d'exécution de commandes selon l'une des revendications précédentes, dans lequel le deuxième datagramme comporte une adresse mémoire associée à la donnée écrite et/ou lue. 25 10. Procédé d'exécution de commandes selon l'une des revendications précédentes, dans lequel l'entité cible (10) comporte un compteur incrémenté à chaque envoi de datagramme à l'entité hôte (20) et dans lequel chaque dit datagramme comporte une valeur représentant l'état courant du compteur. 30 11. Procédé d'exécution de commandes selon la revendication précédente, dans lequel l'entité cible (10) compare, à chaque réception de datagramme depuis l'entité hôte (20), l'état courant du compteur à la valeur du compteur dudit datagramme, et dans le cas où ladite comparaison est différente, émet une donnée signalant un datagramme manquant à destination de l'entité hôte (20). 3060151 22 12. Procédé d'exécution de commandes selon l'une des revendications précédentes, dans lequel le premier et deuxième 5 datagramme sont au format du protocole UDP et encapsulés dans un paquet Ethernet. 13. Procédé d'exécution de commandes selon l'une des revendications précédentes, dans lequel l'entité cible comporte au moins un 10 senseur inertiel. 14. Procédé d'exécution de commandes entre une entité hôte 20 et une entité cible (10), les étapes suivantes étant mises en oeuvre par l'entité hôte (20) : 15 a) Transmission à l'entité cible (10) d'un premier datagramme comprenant au moins une commande d'accès en lecture/écriture à une adresse mémoire de l'entité cible (10) ; b) Réception d'un deuxième datagramme émis par l'entité cible (10) comprenant au moins une donnée écrite ou lue à ladite 20 adresse mémoire et un statut d'acquittement du premier datagramme ; et dans lequel l'entité hôte (20) comporte un compteur incrémenté à chaque envoi de datagramme à l'entité cible (10) et dans lequel l'entité hôte (20) compare à chaque réception de datagramme depuis l'entité hôte (20), l'état 25 courant du compteur à la valeur du compteur dudit datagramme, et dans le cas où ladite comparaison est différente, émet une donnée signalant un datagramme manquant à destination de l'entité cible (10). 15. Entité cible (10) comprenant : - Une interface de communication avec une entité hôte (20) ; 30 - Une unité de traitement configurée pour mettre en oeuvre le procédé selon l'une des revendications 1 à 13. 3060151 23 16. Entité hôte (20) comprenant : - Une interface de communication avec une entité cible (10) ; - Une unité de traitement configurée pour mettre en oeuvre le procédé 5 selon la revendication 14. 17. Produit programme d'ordinateur comprenant des instructions de code pour l'exécution d'un procédé selon l'une des revendications 1 à 14 lorsque ledit procédé est mise en oeuvre par un microprocesseur de 10 l'entité cible (10) ou de l'entité hôte (20).