FR3060151A1

FR3060151A1 - Protocole d'execution de commandes d'une entite hote sur une entite cible

Info

Publication number: FR3060151A1
Application number: FR1662159A
Authority: FR
Inventors: Cedric Autie; Francois LEROY
Original assignee: Safran Electronics and Defense SAS
Current assignee: Safran Electronics and Defense SAS
Priority date: 2016-12-08
Filing date: 2016-12-08
Publication date: 2018-06-15
Anticipated expiration: 2036-12-08
Also published as: FR3060151B1

Abstract

Procédé d'exécution de commandes d'une entité hôte sur une entité cible, les étapes suivantes étant mises en œuvre par l'entité cible : 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 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 ; d) Envoi à l'entité hôte du deuxième datagramme.

Description

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 (Windows, 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 coûteux.

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.

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 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 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..

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 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 :

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 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 ;

d) Envoi à l’entité hôte du deuxième datagramme.

Un tel procédé permet, dans le cadre d’une mise en œuvre avec des senseurs inertiels, 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.

En outre, il permet d’assurer la pérennité des moyens de communication et production pour le calibrage et l’expertise des senseurs inertiels.

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 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 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 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 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 ;

- 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 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 U DP 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 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.

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 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 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 à destination de l’entité cible.

L’invention concerne en outre une entité cible comprenant :

Une interface de communication avec une entité hôte ;

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 :

Une interface de communication avec une entité cible ;

Une unité de traitement configurée pour mettre en œuvre 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 mise en œuvre 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 à 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 œuvre d’un procédé d’exécution de commandes d’une entité hôte sur une entité cible selon l’invention ;

la figure 2 représente un protocole de communication pour la mise en œuvre 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.

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 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.

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 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.

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 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 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 UDP d’un paquet Ethernet. Sa décomposition est la suivante :

Octets (Big Endian)
3 i 2 ΐ i 0
Bits (Littie Endian)
: : - ⁷ : ^- : : : i : - :	: - : : - - -- - -
	content
seq nupiber	dest
arg2 arg6	argl .............

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.

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.

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 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 :

- 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 ;

- 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 :

: ' CA Z . . ? e —:-;=- + ; -; sa : : -. .-^ -=. -: _-,' [i37 RD/WR G· .ectu e I : Ecrr^re ; :^: af : · = = : -<: .*

ΓΙ R ; :< «, .- Z: *··.·« - : .- = - -=:[Ëï I I OFF-'I ON I G : isochrone c'f1 : isochrone on

N'B

-- : :::::, [3-0]

CONFJSO

0000 : simple 0001 : multî

0010 : fbw (fi/li bandwidth}

Autres : réservés pour de 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 reconnue. Elle indique alors dans «status1[7]» (bit numéro 7 du mot statusl) une erreur (« cmd_err »). « Statutl » 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. « Statusl [7] » est remis à 0 après l’envoi de « statusl ».

Dans le cas où le paquet est ignoré à cause du bit 15 ou si une commande n’est pas reconnue, le mot « statusl » 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), et les champs arguments associés à chaque commande.

	Ai_H1	Aru2	4·_Η2	Aru-4	A-!j5	α·ηϊ
READ Cmd		-				-
WRITE Cmd						-
WRITE_FAST Cmd	adr base [31:16]	adr base [15:0]	adr Inc : - .		-
WRiTE FIFO ISO Cmd			ίΚΚβββΙΙΙϊΙΙΙίβ
START_ISO_SIMPLE Cmd	Iso simple rd adr [31:15]	iso simple rd adr [15:0]	iso_sîmpie_w r adr [31:16]	iso simple wr adr [15:0]	-	-
START_1SO_MULT1 Cmd	· : : ::	...... .. :	-	-	-	-
STARTJSO_FBW Cmd	iso multî fbw nb rd [15:0]	iso multî fbw nb wr [15:0]	-		-
STOPJSO Cmd

La cible 10 peut se trouver dans 2 modes de fonctionnement différents en 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 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.

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.

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.

II 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 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 WRITE_FIFO_ISO.

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 sousmode, 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 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 START_ISO_SIMPLE, ίο 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 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 « 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.

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) 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 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 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, chaque élément représentant une adresse de lecture, et 2 fois plus 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 arrête l’exécution des commandes de lectures et d’écriture pour le top 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 status1[6] une erreur (htr_overflow) et continue l’exécution des commandes du top temps réel courant. Status1[6] est remis à 0 après l’envoi de statusl.

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 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.

Isochrone Full Bandwidth :

o en mode non bouclé si la cible 10 reçoit une commande START_ISO_FBW, o en mode bouclé si la cible 10 reçoit une commande START_ISO_LOOP_FBW.

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.

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.

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.

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, 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.

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 STOPJSO est alors émis lorsque la cible n’est plus en mode isochrone. Le champ « arg3 » ne représente donc pas la valeur du compteur HTR.

Si la cible 10 reçoit une commande STOPJSO, 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 STOPJSO en émettant un acknowledge STOPJSO 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.

Egalement, la cible 10 doit indiquer dans • status1[5] (iso_on) si elle est en mode non isochrone (0) ou en mode isochrone (1).

• status1[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 status1[4] doit être mis à 0.

• status1[3:0] (iso_mode) si elle est en mode isochrone simple (0000), en mode isochrone multi (0001) ou en mode isochrone fbw (0010). Si la cible 10 est en mode non isochrone, alors status1[3:0] doit être mis à 0000.

Mode asynchrone

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.

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 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 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.

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).

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 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 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.

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, 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 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 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 10. Cependant, la commande d’écriture nommée WRITE_FIFO_ISO diffère des 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 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

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 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 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 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 MMIPoE 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 statusl et le champ « 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 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 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. 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.

Lors du 1er 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 reçu est incohérent de la valeur de ce même champ du paquet Ethernet MMIPoE précédent. Status1[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 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 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 MMIPoE avec la valeur de ce même champ de l’entête MMIPoE de la 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.

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 nombre de mots qui auraient dû être transmis, saturé à 65535.

Le récepteur 11 indique dans status1[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. status1[10] et status1[9] sont remis à 0 après l’envoi de statusl.

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.

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 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.

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 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 U DP permet de transmettre des données de manière simple entre deux entités, diminuant ainsi la complexité et donc le coup de 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.

II 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 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.

II 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 ensemble de composants électroniques. A titre d'exemple supplémentaire, un composant électronique est un composant logique programmable, également appelé FPGA (Field Programmable Gâte Array), ou encore un circuit intégré dédié, également appelé ASIC (Application Spécifie Integrated Circuit) ou tout autre composant électronique, programmable ou non.

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 implémenté dans la cible 10 mais pour un autre type de lien (Bittware, SPI, UART, I2C, 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 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’à 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 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.

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.

Claims

REVENDICATIONS

1. Procédé d’exécution de commandes d’une entité hôte (20) sur une entité cible (10), les étapes suivantes étant mises en œuvre 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 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 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 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).
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).
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.
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.
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).
12. Procédé d’exécution de commandes selon l’une des revendications précédentes, dans lequel le premier et deuxième datagramme sont au format du protocole U DP 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 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 œuvre par l’entité hôte (20) :

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 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 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) ;

Une unité de traitement configurée pour mettre en œuvre le procédé selon l’une des revendications 1 à 13.
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).

1/3