FR 3116170 A1 20220513 FR 2011438 A 20201106 L’invention concerne la transmission d’une trame sur un réseau interne d’un véhicule selon un protocole hybride, d’un premier composant (ECU1) vers un deuxième composant (ECU2). FIG. 1 Protocole hybride pour un réseau interne à un véhicule La présente invention appartient au domaine de l’électronique embarquée dans un véhicule terrestre à moteur. En particulier, il concerne l’adaptation de trames CAN, pour Controller Area Network soit réseau de contrôle de zone en français, en un signal transmissible avec le protocole Ethernet. On entend par « véhicule terrestre à moteur » tout type de véhicule tel qu’un véhicule automobile, un cyclomoteur, une motocyclette, un robot de stockage dans un entrepôt, etc. Les architectures électroniques des véhicules comprennent différents réseaux internes. Un protocole très largement utilisé est le protocole CAN. Ce protocole a permis de réduire le nombre de fils utilisés pour les transmissions au sein du véhicule à partir d’un multiplexage des données. Il existe différentes versions du protocole, visant notamment à augmenter son débit. Toutefois, les différentes évolutions du protocole CAN ne conduisent pas à ce que des débits suffisants soient proposés. En particulier, les débits maximums actuels sont limités à 10 mégabits par seconde. En outre, les étapes protocolaires d’émission / réception des trames CAN impliquent notamment des mécanismes de détection d’erreur et de signalisation d’erreur consommateurs de ressources de calcul, en particulier pour les composants en charge des couches basses. Aussi, l’utilisation d’autres protocoles a pu être proposé pour les réseaux internes des véhicules. Ainsi, des protocoles à commutation de paquets comme les Ethernet, wifi ou encore cellulaire ont pu être utilisés dans les véhicules. Toutefois, le protocole Ethernet ayant été conçu pour des échanges entre ordinateurs, il implique un traitement haut niveau (couches applicatives) difficile à mettre en œuvre sur tous les calculateurs (lave glace, clignotants, etc.) bas niveaux du véhicule. Il existe donc un besoin pour un protocole capable de gérer des débits importants tout en étant compatible avec une grande diversité de composants. La présente invention vient améliorer la situation. A cet effet, un premier aspect de l’invention concerne un procédé d’émission d’une trame par un premier composant électronique d’un véhicule terrestre à moteur vers un deuxième composant électronique du véhicule, le format de la trame étant configuré pour être compatible avec un mécanisme de détection d’erreur mis en œuvre dans une couche inférieure ou égale à la couche liaison et pour être compatible avec un mécanisme de signalisation d’erreur mis en œuvre dans une couche inférieure ou égale à la couche liaison, le procédé comportant les étapes de : génération d’un signal à partir de la trame, le format du signal étant conforme aux règles définies pour la couche physique d’un protocole à commutation de paquet ; émission du signal selon ledit protocole à commutation de paquet. Ainsi, l’interface entre la couche liaison et la couche physique est modifiée pour rendre possible une hybridation d’un protocole bas niveau type CAN vers une couche physique plus performante en débit type Ethernet. En effet, les mécanismes de détection et signalisation d’erreur sont mis en œuvre au niveau de la couche liaison pour les protocoles bas niveau (en particulier à cause de l’absence de couches hautes pour ces protocoles). Au contraire, pour les protocoles à commutation de paquets, ces mécanismes sont mis en œuvre au-dessus de la couche liaison (couche réseau pour le protocole Ethernet). Ainsi, la trame à émettre est compatible avec tout composant, tel qu’un calculateur d’essuie-glace, tout en étant effectivement transmise par un protocole à commutation de paquet performant. Un autre effet technique est lié à la réduction des risques de cyber-attaques car les trames bas-niveau ne sont pas ouvertes au monde internet et donc moins susceptibles d’être détournées. Dans un mode de réalisation, l’étape de génération du signal comporte une sous-étape d’ajout d’un nombre prédéterminé de bits de préambule à la trame. Dans un mode de réalisation, l’étape de génération du signal comporte les sous-étapes de : si le nombre de bits de la trame n’est pas un multiple de quatre, ajouts de bits de bourrage pour que le nombre de bits de la trame soit un multiple de quatre ; regroupement des bits, quatre par quatre, dans des signaux intermédiaires compris dans le signal. Dans un mode de réalisation, l’étape de génération du signal comporte les sous-étapes de : si le nombre de bits de la trame n’est pas un multiple de deux, ajouts de bits de bourrage pour que le nombre de bits de la trame soit un multiple de deux ; regroupement des bits, deux par deux, dans des signaux intermédiaires compris dans le signal. Un deuxième aspect de l’invention concerne un procédé de réception d’une trame par un premier composant électronique d’un véhicule terrestre à moteur depuis un deuxième composant électronique du véhicule, le procédé comportant les étapes de : réception d’un signal ; traitement du signal selon les règles définies pour la couche physique d’un protocole à commutation de paquet ; extraction d’une trame à partir du signal traité, le format de la trame étant configuré pour être compatible avec un mécanisme de détection d’erreur mis en œuvre dans une couche inférieure ou égale à la couche liaison et pour être compatible avec un mécanisme de signalisation d’erreur mis en œuvre dans une couche inférieure ou égale à la couche liaison. Dans un mode de réalisation du deuxième aspect de l’invention, l’étape d’extraction de la trame comporte une sous-étape de suppression d’un nombre prédéterminé de bits de préambule du signal traité. Dans un mode de réalisation du deuxième aspect de l’invention, l’étape d’extraction de la trame comporte les sous-étapes de : extraction de bits compris dans des signaux intermédiaires compris dans le signal, les signaux intermédiaires regroupant les bits quatre par quatre ; si des bits de bourrage sont présents dans les bits extraits, suppression des bits de bourrage. Dans un mode de réalisation du deuxième aspect de l’invention, l’étape d’extraction de la trame comporte les sous-étapes de : extraction de bits compris dans des signaux intermédiaires compris dans le signal, les signaux intermédiaires regroupant les bits deux par deux ; si des bits de bourrage sont présents dans les bits extraits, suppression des bits de bourrage. Dans un mode de réalisation du premier ou du deuxième aspect de l’invention, le format de la trame est conforme à un protocole CAN, pour Controller Area Network et/ou le protocole à commutation de paquet est un protocole Ethernet. Un troisième aspect de l’invention concerne un programme informatique comportant des instructions pour la mise en œuvre du procédé selon le premier ou le deuxième aspect de l’invention, lorsque ces instructions sont exécutées par un processeur. Un quatrième aspect de l’invention concerne un dispositif comprenant une mémoire associée à au moins un processeur configuré pour mettre en œuvre le procédé selon le premier ou le deuxième aspect de l’invention. Un cinquième aspect de l’invention concerne un véhicule configuré pour comprendre le dispositif selon le quatrième aspect de l’invention. D’autres caractéristiques et avantages de l’invention apparaîtront à l’examen de la description détaillée ci-après, et des dessins annexés sur lesquels : est un diagramme illustrant les étapes d’un procédé selon un mode de réalisation de l’invention ; illustre la structure des composants électroniques selon un mode de réalisation de l’invention ; illustre la structure d’un dispositif selon un mode de réalisation de l’invention. L’invention est décrite ci-après dans son application, non limitative, au cas d’un véhicule automobile comprenant deux composants électroniques. Une telle application est purement illustrative et réduite à deux composants pour la clarté du propos mais, en pratique, l’invention est utilisée par plusieurs dizaines ou centaines de composants, calculateurs en particulier, présents dans le véhicule. Par ailleurs, l’invention peut être mise en œuvre sur tout type de véhicule terrestre à moteur tel qu’une motocyclette, un autocar ou encore un robot dans une usine. La illustre un procédé, selon un mode de réalisation de l’invention. Le procédé est mis en œuvre, à l’émission, au niveau d’un premier composant électronique ECU1. Le procédé est mis en œuvre, à la réception, au niveau d’un deuxième composant électronique ECU2. Le procédé est ici décrit dans un mode de réalisation où une trame FRM est transmise de ECU1 à ECU2. Le format de la trame est configuré pour être compatible avec un mécanisme de détection d’erreur mis en œuvre dans une couche inférieure ou égale à la couche liaison. Il est en outre configuré pour être compatible avec un mécanisme de signalisation d’erreur mis en œuvre dans une couche inférieure ou égale à la couche liaison. Un mécanisme de détection d’erreur est par exemple un mécanisme de monitoring (surveillance des nœuds du réseau) ou de bit stuffing (bourrage). Un mécanisme de signalisation d’erreur est par exemple un mécanisme de contrôle de redondance cyclique (CRC), un test de trame (vérification du format de la trame reçue, et génération d’un form error si format incorrect) ou encore les mécanismes d’acquittement (ACK). En particulier, dans un mode de réalisation où le protocole de la trame FRM est le protocole CAN, la trame comporte sept champs : le début de trame ou SOF (Start Of Frame) matérialisé par 1 bit dominant ; le champ d'arbitrage (identificateur) composé de 12 ou 32 bits ; le champ de commande (ou de contrôle) composé de 6 bits et comportant un DLC, Data Length Code pour code de longueur de données en français, indiquant la longueur des données (payload) ; le champ de données composé de 0 à 64 bits (de 0 à 8 octets) ; le champ de CRC composé de 16 bits ; le champ d'acquittement composé de 2 bits ; la fin de trame ou EOF (End of Frame) matérialisée par 7 bits récessifs. Des variantes d’un tel format sont possibles. Ainsi, la trame peut être conforme au protocole CAN XL et notamment aux spécifications CiA 610-1 et CiA 610-3 proposées par le Special Interest Group CAN. A une étape 4, un signal TxD0, TxD1, TxD2, TxD3 est généré à partir de la trame FRM. Le format du signal étant conforme aux règles définies pour la couche physique d’un protocole à commutation de paquet. Dans un mode de réalisation, le protocole à commutation de paquet est le protocole Ethernet. En particulier, le protocole peut être le protocole Ethernet 802 tel que fonctionnant avec des transceivers Ethernet 100Base-T1 capables de proposer des débits de 100 mégabits par seconde. Ainsi, l’étape de génération du signal rend la trame CAN compatible avec la couche physique d’Ethernet. Autrement dit, un composant CAN peut parler avec un transceiver Ethernet. Il est important que chaque module appartenant à une couche du modèle OSI respecte l'interface du module situé dans la couche inférieure. Les transceivers 100Base-T1 ont une interface MII, pour Media-Independent Interface soit interface indépendante du média en français, ou RMII, pour Reduced Media-Independent Interface soit interface réduite indépendante du média en français, avec les contrôleurs 100Base-T1. Or, le Special Interest Group CAN a retenu l'interface MICI comme interface entre les contrôleurs XL et les transceivers XL. L'interface MICI n'est pas compatible des interfaces MII ou RMII, ce qui rend impossible l'association d'un contrôleurs XL avec un transceiver 100Base-T1. Aussi, l’étape 4 peut consister à : - Récupérer la spécification du contrôleur CAN XL ; - Remplacer son interface MICI par une interface MII ou RMII : on obtient alors le contrôleur CAN 100 Mbps, le détail dudit remplacement est détaillé ci-après aux sous-étapes 6 et 8 ; - L'associer à un transceiver 100Base-T1. Physiquement, comme représenté à la , l’étape 4 de génération du signal peut être mise en œuvre dans le contrôleur CAN modifié 22 (le contrôleur CAN 100 Mbps) pour générer le signal TxD0, TxD1, TxD2, TxD3 compatible avec un transceiver 26 Ethernet 100Base-T1. Le signal est ensuite transmis via des connecteurs 28 et 30. Ensuite, de manière symétrique et comme expliqué ci-après en référence à l’étape 14, le signal est traité par un transceiver 32 puis la trame FRM est extraite par le contrôleur CAN modifié 24. En particulier, dans un mode de réalisation de mise en œuvre de l’étape 4, l’étape 4 comporte les sous-étapes 6 et 8. A une sous-étape 6, un nombre prédéterminé de bits de préambule PRMBL est ajouté à la trame FRM pour générer la trame intermédiaire FRM_I. Dans un mode de réalisation, le nombre prédéterminé est de 9 bits. Dans un autre mode de réalisation, le nombre prédéterminé est compris entre 6 et 14 bits. Cet ajout rend compatible la trame avec la couche physique du protocole Ethernet dans la mesure où, à défaut d’ajout de ce préambule, la couche physique Ethernet remplacera les premiers bits par un champ SSD, Start-of-Stream Delimiter soit délimiteur de début de flux en français, (qui est une séquence de 3 ternaires (0,0), (0,0), (0,0)) et cassera les 9 premiers bits de la trame FRM. Dans le format CAN, ces 9 premiers bits correspondent au SOF et à l’identificateur et la trame cassé serait donc difficilement compréhensible par un calculateur CAN. Dans un mode de réalisation trivial, il est toutefois possible de se passer de la sous-étape 6, la couche physique Ethernet étant modifiée pour gérer le problème. A une sous-étape 10, et pour un mode de réalisation avec l’interface MII, les opérations suivantes sont mises en œuvre : si le nombre de bits de la trame FRM_I n’est pas un multiple de quatre, ajouts de bits de bourrage pour que le nombre de bits de la trame soit un multiple de quatre ; regroupement des bits, quatre par quatre, dans des signaux intermédiaires TxD0, TxD1, TxD2, TxD3 compris dans le signal. Pour un mode de réalisation avec l’interface RMII (non représenté), les opérations suivantes sont mises en œuvre : si le nombre de bits de la trame FRM_I n’est pas un multiple de deux, ajouts de bits de bourrage pour que le nombre de bits de la trame soit un multiple de deux ; regroupement des bits, deux par deux, dans des signaux intermédiaires TxD0, TxD1, compris dans le signal. Pour MII et RMII, les bits de bourrage ne perturberont pas le récepteur qui connaît le format de la trame CAN, interprètera le champ DLC qui indique la longueur de la trame et pourra ainsi calculer le nombre de bits utiles. Les bits restants ne seront pas traités par le récepteur. Ensuite, à une étape 10, le signal, comprenant les signaux intermédiaires TxD0, TxD1, TxD2, TxD3, est traité par la couche physique Ethernet 100Base-T1 26 pour être envoyé via les connecteurs 28 et 30 à ECU2. A une étape 12, ECU2 reçoit le signal, la couche physique (notamment transceiver 32 Ethernet 100Base-T1) traite le signal et le soumet au contrôleur CAN modifié 24. Ainsi, le signal est traité selon les règles définies pour la couche physique du protocole à commutation de paquet, ici Ethernet 100Base-T1. A la , il est noté le signal, comprenant les signaux intermédiaires TxD0, TxD1, TxD2, TxD3, et les trames FRM_I et FRM, comme au niveau de l’émission dans ECU1. Bien sûr, le signal peut être bruité ou perturbé lors de la transmission et donc ne pas exactement correspondre à TxD0, TxD1, TxD2, TxD3, FRM_I et FRM mais ces notations ont tout de même été utilisées pour clarifier le propos. A une étape 14, une trame est extraite à partir du signal traité par la couche physique Ethernet 100Base-T1. L’extraction ci-après décrite est configuré pour le trame extraite soit conforme à un protocole bas-niveau type CAN, c’est-à-dire que le format de la trame extraite est configuré pour être compatible avec un mécanisme de détection d’erreur mis en œuvre dans une couche inférieure ou égale à la couche liaison et pour être compatible avec un mécanisme de signalisation d’erreur mis en œuvre dans une couche inférieure ou égale à la couche liaison. Le gros avantage de l'utilisation du transceiver 100Base-T1 en réception est qu'il a réalisé l'interprétation du signal CAN reçu de la paire torsadée UTP ou STP et qu'il fournit au controller des bits directement utilisables : les mécanismes d'échantillonnage, de resynchronisation et de bit de stuffing sont devenus inutiles. A une sous-étape 16, et pour un mode de réalisation avec l’interface MII, les opérations suivantes sont mises en œuvre : extraction de bits compris dans des signaux intermédiaires TxD0, TxD1, TxD2, TxD3 compris dans le signal, les signaux intermédiaires regroupant les bits quatre par quatre ; si des bits de bourrage sont présents dans les bits extraits, suppression des bits de bourrage. Une trame intermédiaire FRM_I est ainsi générée. Pour un mode de réalisation avec l’interface RMII (non représenté), les opérations suivantes sont mises en œuvre : extraction de bits compris dans des signaux intermédiaires TxD0, TxD1, compris dans le signal, les signaux intermédiaires regroupant les bits deux par deux ; si des bits de bourrage sont présents dans les bits extraits, suppression des bits de bourrage. A une sous-étape 18, l’étape d’extraction 14 de la trame comporte une sous-étape 18 de suppression d’un nombre prédéterminé de bits de préambule du signal traité. En particulier, dans le mode de réalisation où la sous-étape 16 est mise en œuvre, le préambule PRMBL est supprimé de la trame intermédiaire FRM_I pour générer la trame FRM. La trame FRM est alors disponible à une étape 20 pour le calculateur ECU2. Le procédé décrit ci-avant a différents impacts sur le traitement des trames FRM, et notamment : Disparition de l'arbitrage L'autre avantage de l'utilisation du transceiver 100Base-T1 est que cette couche physique est full duplex. Il n'y a donc plus besoin d'arbitrage : deux nœuds peuvent émettre chacun un message en même temps. Suppression de l'acquittement des trames En s'inspirant du fonctionnement des réseaux ETHERNET (qui est de type 'fire and forget') et dans le but de supprimer les contraintes temporelles contenu dans les trames CAN XL, le mécanisme d'acquittement des trames est supprimé mais le champ ACK avec ses différents bits est conservé pour : - simplifier la gestion des cellules CAN chez les fabricants de contrôleurs CAN, - alimenter le module de détection d'erreur— cas de Form error Les bits du champ ACK ne sont gérés ni en émission ni en réception au sens acquittement. Par contre, ils sont tous positionnés à l'état Dominant. Cela permet au module gestion d'erreur du nœud récepteur de tester leur état et de générer en interne une Form Error si un Recessif est détecté. Débit constant pendant tout le message La disparition de l'arbitrage et de l'acquittement des trames supprime les deux contraintes temporelles qui obligeaient le CAN XL à utiliser deux débit pour émettre des trames à 10 Mbps. Le CAN 100 Mbps peut donc utiliser le même débit de 100 Mbps pour toute la trame. Les changements de bit rate et de mode de transceiver sont inutiles mais le champ ADS (détection d’anomalies) avec ses différents bits est conservé pour : - simplifier la gestion des cellules CAN chez les fabricants de controllers CAN, - alimenter le module de détection d'erreur— cas de Form error Les bits du champ ADS ne sont gérés ni en émission ni en réception au sens acquittement. Par contre, ils sont tous positionnés à l'état Dominant. Cela permet au module gestion d'erreur du nœud récepteur de tester leur état et de générer en interne une Form Error si un Recessif est détecté. Simplification du module 'détection d'erreur' Dans le module 'détection d'erreur' décrit dans la spécification CiA 610-1, le bit error, le stuff error, et l'ACK error sont supprimés. Une détection d'erreur est ajoutée : le LINK DOWN. Une panne matérielle ou un niveau de bruit trop important sur la paire torsadée peut provoquer ce que la couche physique 100Base-T1 appelle 'LINK DOWN'. Dans ce cas, le transceiver 100Base-T1 génère une interruption spécifique que doit traiter le contrôleur CAN 100 Mbps pour générer un link down error. Optionnellement, un transceiver 100Base-T1 peut gérer d'autre type d'erreur et/ou proposer certains mécanismes de diagnostic de la paire torsadée. Le contrôleur CAN 100 Mbps doit alors, optionnellement, proposer les mécanismes correspondant. La signalisation d'erreur avec la configuration par logiciel de l'émission ou non de l'erreur flag, décrite dans le paragraphe 'Error signaling' de la spécification CiA 610-1 est conservée. Conservation du format de la trame CAN XL Le format de la trame CAN XL décrit dans le paragraphe 'Specification of MAC frame in XL frame format' de la spécification CiA 610-1 est conservé, même si certains mécanismes sont devenus inutiles (ex : acquitement), comme il a été décrit dans les paragraphes précédents. Conservation du transceiver 100Base-T1 Le transceiver 100Base-T1 est utilisé sans modification. La représente un exemple de dispositif D tel que compris dans l’un des sous-composants, par exemple les contrôleurs CAN modifiés 22 et 24, les transceivers 26 et 32 ou encore les connecteurs 28 et 30 compris dans ECU1 et/ou ECU2. Ce dispositif D peut prendre la forme d’un boitier comprenant des circuits imprimés, de tout type de composant électronique tel que puces, circuits imprimés, etc. Le dispositif D comprend une mémoire vive 100 pour stocker des instructions pour la mise en œuvre par un processeur 200 d’au moins une étape des procédés tels que décrits ci-avant. Dans un mode de réalisation, le dispositif comporte aussi une mémoire de masse 300 pour le stockage de données destinées à être conservées après la mise en œuvre du procédé. Le dispositif D peut en outre comporter un processeur de signal numérique (DSP) 400. Ce DSP 400 reçoit des données pour mettre en forme, démoduler et amplifier, de façon connue en soi ces données. Le dispositif comporte également une interface d’entrée 500 pour la réception des données mises en œuvre par des procédés selon l’invention et une interface de sortie 600 pour la transmission des données mises en œuvre par le procédé. La présente invention ne se limite pas aux formes de réalisation décrites ci-avant à titre d’exemples ; elle s’étend à d’autres variantes. Ainsi, il a été décrit un mode de réalisation correspondant à une architecture électronique exemplatif (des composants ECU, etc.) pour un véhicule automobile. La présente invention est également applicable à d’autres architectures électroniques (nombre différent de calculateurs, etc.). En outre, il a été décrit un mode de réalisation fondé sur une hybridation entre un réseau CAN et un réseau Ethernet. D’autres protocoles bas-niveau (détection/signalisation d’erreur couche liaison ou moins) peuvent également être hybridés selon la présente invention avec d’autres protocoles à commutation de paquet (wifi, etc.). Procédé d’émission d’une trame par un premier composant électronique (ECU1) d’un véhicule terrestre à moteur vers un deuxième composant électronique (ECU2) du véhicule, le format de la trame étant configuré pour être compatible avec un mécanisme de détection d’erreur mis en œuvre dans une couche inférieure ou égale à la couche liaison et pour être compatible avec un mécanisme de signalisation d’erreur mis en œuvre dans une couche inférieure ou égale à la couche liaison, le procédé comportant les étapes de : génération (4) d’un signal à partir de la trame, le format du signal étant conforme aux règles définies pour la couche physique d’un protocole à commutation de paquet ; émission (10) du signal selon ledit protocole à commutation de paquet. Procédé selon la revendication 1, dans lequel l’étape de génération du signal comporte une sous-étape d’ajout (6) d’un nombre prédéterminé de bits de préambule à la trame. Procédé selon l’une des revendications précédentes, dans lequel l’étape de génération du signal comporte les sous-étapes (8) de : si le nombre de bits de la trame n’est pas un multiple de quatre, ajouts de bits de bourrage pour que le nombre de bits de la trame soit un multiple de quatre ; regroupement des bits, quatre par quatre, dans des signaux intermédiaires compris dans le signal. Procédé selon l’une des revendications 1 ou 2, dans lequel l’étape de génération du signal comporte les sous-étapes de : si le nombre de bits de la trame n’est pas un multiple de deux, ajouts de bits de bourrage pour que le nombre de bits de la trame soit un multiple de deux ; regroupement des bits, deux par deux, dans des signaux intermédiaires compris dans le signal. Procédé de réception d’une trame par un premier composant électronique (ECU1) d’un véhicule terrestre à moteur depuis un deuxième composant électronique (ECU2) du véhicule, le procédé comportant les étapes de : réception (12) d’un signal ; traitement (12) du signal selon les règles définies pour la couche physique d’un protocole à commutation de paquet ; extraction (14) d’une trame à partir du signal traité, le format de la trame étant configuré pour être compatible avec un mécanisme de détection d’erreur mis en œuvre dans une couche inférieure ou égale à la couche liaison et pour être compatible avec un mécanisme de signalisation d’erreur mis en œuvre dans une couche inférieure ou égale à la couche liaison. Procédé selon la revendication 5, dans lequel l’étape d’extraction de la trame comporte une sous-étape de suppression (16) d’un nombre prédéterminé de bits de préambule du signal traité. Procédé selon l’une des revendications précédentes, dans lequel un format de la trame est conforme à un protocole CAN, pour Controller Area Network et/ou le protocole à commutation de paquet est un protocole Ethernet. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une quelconque des revendications précédentes, lorsque ces instructions sont exécutées par un processeur (200). Dispositif (D) comprenant une mémoire (100 ; 300) associée à au moins un processeur (200) configuré pour mettre en œuvre le procédé selon l’une des revendication 1 à 7. Véhicule terrestre à moteur comportant le dispositif selon la revendication 9.