Brevet FR3036243A1 — publié le 20161118

ORGANE MAÎTRE À MOYENS DE VÉRIFICATION DE CARACTÉRISTIQUES DE PROTOCOLE DE COMMUNICATION, POUR UN RÉSEAU VIDÉO BIDIRECTIONNEL L'invention concerne les organes maîtres destinés à être connectés à des réseaux de communication adaptés à la transmission bidirectionnelle de trames de données non vidéo et à la transmission unidirectionnelle de trames de données vidéo, et plus précisément la vérification du fonctionnement de tels organes maîtres. Dans certains réseaux de communication du type précités, et notamment dans ceux dits « à signalisation différentielle à basse tension » (ou LVDS - « Low Voltage Differential Signaling »), un organe maître et au moins un organe esclave sont agencés de manière à s'échanger des trames de données non vidéo de façon bidirectionnelle, dans des créneaux (ou tranches) temporel(le)s (ou « slots ») qui sont défini(e)s par une table de programmation (ou « schedule table »), et des trames de données vidéo de façon unidirectionnelle. Cette table (de programmation) permet avantageusement d'éviter que deux organes (ou noeuds) transmettent sensiblement simultanément des trames de données non vidéo, ce qui induirait leur perte. A titre d'exemple, la perte d'une trame de données non vidéo de paramétrage d'écran entre un calculateur multimédia et un écran tactile d'un véhicule pourrait, par exemple, induire une absence de prise compte d'un paramétrage commandé par un passager et donc un effet indésirable sur l'écran tactile. La transmission bidirectionnelle de trames de données non vidéo se fait selon un protocole de communication qui est défini par des caractéristiques, comme par exemple l'action qui est réalisée par l'organe maître consécutivement à la réception d'une trame de données non vidéo dite de lecture. Comme le sait l'homme de l'art, il est actuellement très difficile, voire 3036243 2 impossible, de vérifier si un organe maître est effectivement capable de prendre en compte (ou « consommer ») une caractéristique du protocole de communication, y compris avant qu'il ne soit connecté à un réseau de communication. De ce fait, on ne peut pas garantir le respect de certaines 5 exigences du réseau de communication. Par exemple, lorsqu'un organe esclave transmet une trame de lecture à un organe maître, on ne peut pas être certain que les données de commande qu'elle contient sont correctement reçues par cet organe maître (par exemple, cette trame de lecture peut-être ignorée ou mal interprétée). 10 L'invention a donc notamment pour but d'améliorer la situation. Elle propose notamment à cet effet un organe maître propre à être connecté à un réseau de communication adapté à la transmission bidirectionnelle de trames de données non vidéo, dans des créneaux temporels définis par une table, et à la transmission unidirectionnelle de 15 trames de données vidéo, selon un protocole défini par des caractéristiques. Cet organe maître se caractérise par le fait qu'il comprend des moyens de vérification agencés, en cas de réception d'une trame de configuration de test, pour s'activer et configurer l'organe maître dans un état qui permet la réalisation d'un test d'au moins une caractéristique choisie du 20 protocole, défini par au moins une trame de test transmise par un outil externe, puis pour contrôler la réalisation de ce test. Ainsi, on peut désormais vérifier si un organe maître peut effectivement prendre en compte (ou « consommer ») au moins une caractéristique du protocole, y compris avant qu'il ne soit connecté à un 25 réseau de communication. L'organe maître selon l'invention peut comporter d'autres caractéristiques qui peuvent être prises séparément ou en combinaison, et notamment : - chaque caractéristique du protocole peut être choisie parmi au moins une 30 première action réalisée par l'organe maître consécutivement à une réception d'une trame de données non vidéo dite de lecture, et une seconde action réalisée par l'organe maître à la fin d'une temporisation déclenchée au début d'un créneau temporel d'émission alloué à l'organe 3036243 3 maître ; - il peut être agencé, en cas de réception d'une trame de test simulant une trame de lecture contenant des données fonctionnelles de commande, pour générer, à destination de l'outil externe, une trame de 5 données non vidéo dite d'écriture contenant ces données fonctionnelles de commande ; - ses moyens de vérification peuvent être agencés, en cas de réception d'une trame de test relative à la temporisation, pour lui ordonner de transmettre, en réponse à cette trame de test, à destination de l'outil 10 externe et avec un décalage temporel défini dans cette trame de test, une trame de données non vidéo dite d'écriture dans le créneau temporel qui lui a été alloué ; - ses moyens de vérification peuvent être agencés, en cas de réception d'une trame de test relative à la temporisation, pour vérifier sa réaction à 15 la fin de cette temporisation, et enregistrer un résultat de cette réaction ; - ses moyens de vérification peuvent être agencés, en cas de réception d'une trame de fin de test, pour le reconfigurer dans un état de fonctionnement dit normal et pour se désactiver. L'invention propose également un véhicule, éventuellement de type 20 automobile et comprenant, d'une part, un réseau de communication adapté à la transmission bidirectionnelle de trames de données non vidéo, dans des créneaux temporels définis par une table, et à la transmission unidirectionnelle de trames de données vidéo, selon un protocole défini par des caractéristiques, et, d'autre part, au moins un organe maître du type de 25 celui présenté ci-avant et connecté au réseau de communication. L'invention est particulièrement bien adaptée, bien que non limitativement, au cas où le réseau de communication est de type LVDS. 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 30 lesquels : - la figure 1 illustre schématiquement et fonctionnellement un véhicule comprenant un réseau de communication auquel sont connectés des 3036243 4 organes maître et esclaves, et - la figure 2 illustre schématiquement un banc de test comprenant un outil externe destiné à tester des organes maîtres avant qu'ils n'équipent un système. 5 L'invention a notamment pour but de proposer un organe maître OM propre à être connecté à un réseau de communication RC adapté à la transmission bidirectionnelle de trames de données non vidéo, dans des créneaux temporels définis par une table (de programmation), et à la transmission unidirectionnelle de trames de données vidéo, selon un 10 protocole défini par des caractéristiques. Dans ce qui suit, on considère, à titre d'exemple non limitatif, que chaque organe maître OM est destiné à être connecté à un réseau de communication RC de type LVDS (« Low Voltage Differential Signaling »). Mais l'invention n'est pas limitée à ce type de réseau de communication. 15 D'une manière générale, l'invention concerne tout réseau de communication adapté à la transmission bidirectionnelle de trames de données non vidéo et à la transmission unidirectionnelle de trames de données vidéo. Par ailleurs, on considère dans ce qui suit, à titre d'exemple non limitatif, que le réseau de communication RC est destiné à être installé dans 20 un véhicule automobile V, comme par exemple une voiture. Mais l'invention n'est pas limitée à cette application. Elle concerne en effet tout système, installation ou appareil pouvant comprendre au moins un réseau de communication adapté à la transmission bidirectionnelle de trames de données non vidéo et à la transmission unidirectionnelle de trames de 25 données vidéo. Elle concerne donc notamment les véhicules, qu'ils soient de type terrestre, maritime (ou fluvial), ou aérien, les installations, éventuellement de type industriel, et les bâtiments. On a schématiquement représenté sur la figure 1 un véhicule comprenant un exemple non limitatif de réseau (de communication) RC. Dans 30 cet exemple, le réseau RC (de type LVDS) comprend un bus auquel sont connectés un organe (ou noeud) maître OM et trois organes (ou noeuds) esclaves 0E1 à 0E3 (j = 1 à 3). Mais le nombre d'organes esclaves OEj peut prendre n'importe quelle valeur supérieure ou égale à un (1). 3036243 5 L'organe maître OM et les organes esclaves OEj peuvent être de tout type, dès lors qu'ils sont impliqués dans l'acquisition ou l'utilisation de données vidéo. Par exemple, dans le cas d'une voiture il peut s'agir d'un calculateur multimédia ou d'un écran tactile. 5 Une fois connectés à un réseau RC, l'organe maître OM et les organes esclaves OEj peuvent transmettre des trames de données non vidéo dans des créneaux temporels (ou slots) qui sont prédéfinis dans une table (de programmation), connue de chacun d'entre eux. Il est rappelé que dans un réseau LVDS l'organe maître OM peut 10 transmettre soit des trames de données non vidéo dites d'écriture (ou « write frames ») TE, soit des trames de données non vidéo dites d'entête (ou « header frames ») TH, tandis que chaque organe esclave OEj peut transmettre des trames de données non vidéo dites de lecture (ou « read frames ») TL en réponse respectivement à des trames de données non vidéo 15 d'entête TH. Par ailleurs, une trame d'entête TH et la trame de lecture TL associée sont transmises dans un même créneau temporel défini par la table. Une trame d'écriture TE est destinée à transmettre des données non vidéo à un organe esclave OEj et contient les champs suivants, toujours transmis dans le même ordre : 20 - un champ de synchronisation (SYNC), indiquant le début de la trame, - un champ (DEV ADDR), indiquant à quel composant (sérialiseur, désérialiseur ou microcontrôleur esclave) la trame est adressée, - un identifiant (ID), permettant à l'application de l'organe esclave OEj récepteur de savoir comment décoder le champ de données fonctionnelles, 25 - une longueur de trame (DLC), indiquant la taille de la trame ou la taille du champ de données fonctionnelles (en octet), le champ de données fonctionnelles (Di), contenant des données de commandes (par exemple le réglage d'un écran), - une somme de contrôle (CRC), pour permettre à l'organe esclave OEj 30 récepteur de vérifier que la trame reçue n'a pas été altérée au cours de la transmission. 3036243 6 Une trame d'entête TH contient les champs suivants, toujours transmis dans le même ordre : - un champ de synchronisation (SYNC), indiquant le début de la trame, - un champ (DEV ADDR), indiquant à quel composant (sérialiseur, 5 désérialiseur ou microcontrôleur esclave) la trame est adressée, - un identifiant (ID), permettant à l'application de l'organe esclave OEj récepteur de savoir comment décoder le champ de données fonctionnelles, - une longueur de trame (DLC), indiquant la taille de la trame demandée (en octet). 10 Une trame de lecture TL contient les champs suivants, toujours transmis dans le même ordre : - un premier champ (ACK), indiquant le début de la trame, - un champ de données fonctionnelles (Di), contenant des données de commandes (par exemple des données générées par un écran tactile 15 indiquant quelle partie de l'écran est touchée par un utilisateur), - une somme de contrôle (CRC), pour permettre à l'organe maître OM récepteur de vérifier que la trame reçue n'a pas été altérée au cours de la transmission. Comme illustré sur les figures 1 et 2, un organe maître OM, selon 20 l'invention, comprend des moyens de vérification MV qui sont agencés, en cas de réception d'une trame de configuration de test, pour s'activer et le configurer dans un état permettant la réalisation d'un test d'au moins une caractéristique choisie du protocole (de communication), défini par au moins une trame de test transmise par un outil externe OX, puis pour contrôler la 25 réalisation de ce test. Ces moyens de vérification MV peuvent, par exemple, être réalisés sous la forme de modules logiciels (ou informatiques ou « software ») stockés dans une mémoire d'un organe maître OM. Mais dans une variante ils pourraient être réalisés sous la forme d'une combinaison de circuits 30 électroniques (ou « hardware ») et de modules logiciels, comme c'est par 3036243 7 exemple le cas d'un circuit intégré de type FPGA (« Field Programmable Gate Array »). On notera que ces moyens de vérification MV peuvent être considérés comme un automate. L'outil externe OX est, par exemple, un ordinateur portable. Dans 5 l'exemple illustré non limitativement sur la figure 2 l'outil externe OX fait partie d'un banc de test BT qui est propre à vérifier le fonctionnement d'organes maîtres OM, au moins, avant qu'ils ne soient implantés dans des véhicules V (ou systèmes). Mais dans une variante non illustré il pourrait être destiné à vérifier le fonctionnement d'organes maîtres OM, au moins, après qu'ils aient io été implantés dans des véhicules V (ou systèmes). Chaque caractéristique du protocole peut, par exemple, être choisie parmi au moins une première action réalisée par l'organe maître OM consécutivement à une réception d'une trame de lecture TL, et une seconde action réalisée par l'organe maître OM à la fin d'une temporisation déclenchée 15 au début d'un créneau temporel d'émission alloué à l'organe maître OM. La première action est associée au service de renvoi (ou « loopback ») décrit plus loin, et la seconde action est associée au service de différé de réponse (ou « master delay ») également décrit plus loin. Par exemple, l'outil externe OX peut initier un test d'un organe maître 20 OM en lui transmettant une trame de test d'initiation similaire à une trame de lecture. Cette trame de test d'initiation peut, par exemple, être définie comme indiqué dans le tableau suivant : Bit Signal Code 1.0 à 1.7 SERVICE TYPE 0x00 : désactivation du service de test 0x01 : activation du service de renvoi 0x02 : activation du service de différé de réponse autres : valeurs non valides 2.0 à 2.7 IDENTIFIER 0x00 à Ox3F : identifiant de la trame de test OxFF : toutes les trames sont traitées 3036243 8 comme des trames de test 3.0 to 8.7 Paramètres d'entrée de test défini pour chaque service Dans ce tableau, un service est une fonction qui est assurée par les moyens de vérification MV pendant un test. De préférence, si le service définit moins de six octets de paramètres 5 d'entrée de test, la trame est complétée jusqu'à huit octets de données avec des octets de bourrage OxFF. Le service de renvoi (ou « loopback ») est destiné à contraindre l'organe maître OM à renvoyer à l'outil externe OX des données contenues dans une trame de test correspondante transmise par ce dernier (OX). Ce 10 service, qui correspond à une caractéristique du protocole, est destiné à vérifier qu'un organe maître OM reçoit effectivement les trames de lecture qui lui sont transmises et qu'il est capable d'extraire de ces trames de lecture les données de commande qu'elles contiennent. Le service de différé de réponse (ou « master delay ») est destiné à 15 vérifier qu'un organe maître OM est effectivement capable de déclencher au début de chaque créneau temporel (d'une première durée dl et dédié à la transmission d'au moins une trame de données non vidéo) qui lui a été alloué, une temporisation d'une seconde durée d2 strictement inférieure à dl , et de terminer sa transmission lorsque la fin de cette temporisation survient alors 20 que la trame de données non vidéo n'a pas été intégralement transmise. Cette caractéristique du protocole permet d'éviter la collision entre une partie d'une première trame risquant d'être transmise dans le créneau temporel suivant et une seconde trame transmise dans ce créneau temporel suivant, grâce à l'interruption de la transmission de la fin de la première trame. Cela 25 permet de ne perdre que la première trame, et non plus également la seconde trame. Ainsi, les moyens de vérification MV peuvent être agencés pour activer leur service de renvoi et configurer leur organe maître OM dans un état 3036243 9 permettant la réalisation d'un test d'au moins une caractéristique du protocole relative à ce renvoi et/ou pour activer leur service de différé de réponse et configurer leur organe maître OM dans un état permettant la réalisation d'un test d'au moins une caractéristique du protocole relative à ce différé de 5 réponse. Bien entendu, d'autres caractéristiques du protocole peuvent faire l'objet d'un test, et dans ce cas les moyens de vérification doivent comporter un service activable dédié à chaque autre caractéristique. Par exemple, lorsque le service de renvoi a été activé et l'organe 10 maître OM configuré pour le test de renvoi, ce dernier (OM) peut être agencé, lorsqu'il reçoit une trame de test simulant une trame de lecture TL contenant des données fonctionnelles de commande, pour générer, à destination de l'outil externe OX, une trame d'écriture TE contenant ces données fonctionnelles de commande. On teste donc ici la caractéristique constituant 15 la première action précitée. Cette trame de test peut, par exemple, ne comporter aucun paramètre d'entrée de test, et la trame d'écriture que génère l'organe maître OM en réponse à cette trame de test peut, par exemple, être définie comme indiqué dans le tableau suivant : Octet Signal Code 1 SERVICE TYPE 0x01 : activation du service de renvoi _ (SERVICE TYPE de la dernière trame de test reçue) 2 IDENTIFIER identifiant de la dernière trame de test reçue 3 LENGTH longueur de la dernière trame de test reçue 4 DATA _0 données de l'octet 0 (DO) de la dernière trame de test reçue (OxFF en l'absence de données reçues) 5 DATA _1 données de l'octet 1 (D1) de la dernière trame de test reçue (OxFF en l'absence de 3036243 10 données reçues) ... N DATA_i données de l'octet N-4 (DN-4) de la dernière trame de test reçue (OxFF en l'absence de données reçues) Dans ce dernier tableau N est le nombre total d'octets de données de commande contenus dans la dernière trame de test reçue. Egalement par exemple, lorsque le service de différé de réponse a 5 été activé et l'organe maître OM configuré pour le test du différé de réponse, les moyens de vérification MV peuvent être agencés, lorsqu'ils reçoivent une trame de test relative à la temporisation, pour ordonner à leur organe maître OM de transmettre, en réponse à cette trame de test, à destination de l'outil externe OX et avec un décalage temporel défini dans cette trame de test, une 10 trame d'écriture dans le créneau temporel qui lui a été alloué. On teste donc ici la caractéristique constituant la seconde action précitée. En d'autres termes, les moyens de vérification MV forcent leur organe maître OM à débuter tardivement la transmission d'une trame d'écriture dans le créneau temporel qui lui a été alloué, de sorte qu'à la fin de la temporisation 15 associée à ce créneau temporel cette trame d'écriture n'ait pas été intégralement transmise et donc que l'organe maître OM interrompe sa transmission. Pour ce service, la trame de test peut, par exemple être une trame d'écriture ou une trame d'entête contenant comme paramètre d'entrée de test 20 une valeur de différé (« MASTER_DELAY »), par exemple. A titre d'exemple, si MASTER_DELAY = 2 et IDENTIFIER = 0x02, l'organe maître OM va différer la transmission de sa trame d'écriture de 200 ps (= 2*100 us). Cette trame d'écriture que génère l'organe maître OM en réponse à la trame de test peut, par exemple, être définie comme indiqué dans le tableau suivant : Octet Signal Code 3036243 11 1 SERVICE TYPE 0x02: activation du service de différé de réponse (SERVICE_TYPE de la dernière trame de test reçue) 2 IDENTIFIER identifiant de la dernière trame de test reçue 3 non utilisé OxFF ... N non utilisé OxFF Dans ce dernier tableau N est le nombre total d'octets de données de commande contenus dans la dernière trame de test reçue. Egalement par exemple, lorsque le service de différé de réponse a 5 été activé et l'organe maître OM configuré pour le test du différé de réponse, les moyens de vérification MV peuvent être agencés, lorsqu'ils reçoivent une trame de test relative à la temporisation, pour vérifier la réaction de leur organe maître OM à la fin de cette temporisation, et enregistrer un résultat de cette réaction. Ce résultat peut, par exemple, être représenté par un code 10 dont une première valeur représente un test réussi (dans le cas d'une prise en compte du différé de réponse), et une seconde valeur représente un test raté (dans le cas d'une absence de prise en compte du différé de réponse). Le résultat peut aussi, par exemple, être observé par l'analyse des trames émises par le maître OM. 15 On notera qu'un même test peut porter sur plusieurs caractéristiques. Dans ce cas, on teste une première caractéristique avec au moins une trame de test dédiée, puis on teste la deuxième caractéristique avec au moins une trame de test dédiée, et ainsi de suite. On notera également que les moyens de vérification MV peuvent être 20 éventuellement agencés, en cas de réception d'une trame de fin de test issue de l'outil externe OX, pour reconfigurer leur organe maître OM dans un état de fonctionnement dit normal et pour se désactiver. Par exemple, l'outil externe OX peut déclencher la désactivation des 3036243 12 moyens de vérification MV en transmettant à leur organe maître OM une trame de fin de test similaire à une trame de lecture. Cette trame de fin de test peut, par exemple, être définie comme indiqué dans le tableau suivant : Bit Signal Code 1.0 à 1.7 SERVICE TYPE 0x00 : désactivation du service de test 2.0 à 2.7 IDENTIFIER OxFF 3.0 to 8.7 données de octets de bourrage OxFF commande 5 L'invention permet avantageusement de tester n'importe quelle caractéristique du protocole de communication utilisé pour transmettre les trames de commande à l'organe maître et permettant à ce dernier de réaliser en interne certaines fonctions utiles à la gestion des transmissions au sein de son réseau de communication. Cela permet de réduire notablement les 10 durées des phases de validation des organes maîtres et les compétences nécessaires à l'analyse des résultats de test des organes maîtres. REVENDICATIONS1. Organe maître (OM) propre à être connecté à un réseau de communication (RC) adapté à la transmission bidirectionnelle de trames de données non vidéo, dans des créneaux temporels définis par une table, et à la transmission unidirectionnelle de trames de données vidéo, selon un protocole défini par des caractéristiques, caractérisé en ce qu'il comprend des moyens de vérification (MV) agencés, en cas de réception d'une trame de configuration de test, pour s'activer et configurer ledit organe maître (OM) dans un état permettant la réalisation d'un test d'au moins une caractéristique choisie dudit protocole, défini par au moins une trame de test transmise par un outil externe (OX), puis pour contrôler la réalisation dudit test. 2. Organe maître selon la revendication 1, caractérisé en ce que chaque caractéristique dudit protocole est choisie dans un groupe comprenant une première action réalisée par ledit organe maître (OM) consécutivement à une réception d'une trame de données non vidéo dite de lecture, et une seconde action réalisée par ledit organe maître (OM) à la fin d'une temporisation déclenchée au début d'un créneau temporel d'émission alloué audit organe maître (OM). 3. Organe maître selon la revendication 2, caractérisé en ce qu'il est agencé, en cas de réception d'une trame de test simulant une trame de lecture contenant des données fonctionnelles de commande, pour générer, à destination dudit outil externe (OX), une trame de données non vidéo dite d'écriture contenant lesdites données fonctionnelles de commande. 4. Organe maître selon l'une des revendications 2 et 3, caractérisé en ce que lesdits moyens de vérification (MV) sont agencés, en cas de réception d'une trame de test relative à ladite temporisation, pour ordonner audit organe maître (OM) de transmettre, en réponse à cette trame de test, à destination dudit outil externe (OX) et avec un décalage temporel défini dans ladite trame de test, une trame de données non vidéo dite d'écriture dans le créneau temporel qui lui a été alloué. 5. Organe maître selon l'une des revendications 2 à 4, caractérisé en 3036243 14 ce que lesdits moyens de vérification (MV) sont agencés, en cas de réception d'une trame de test relative à ladite temporisation, pour vérifier la réaction dudit organe maître (OM) à la fin de cette temporisation, et enregistrer un résultat de cette réaction. 5 6. Organe maître selon l'une des revendications 1 à 5, caractérisé en ce que lesdits moyens de vérification (MV) sont agencés, en cas de réception d'une trame de fin de test, pour reconfigurer ledit organe maître (OM) dans un état de fonctionnement dit normal et pour se désactiver. 7. Véhicule (V) comprenant un réseau de communication (RC) adapté 10 à la transmission bidirectionnelle de trames de données non vidéo, dans des créneaux temporels définis par une table, et à la transmission unidirectionnelle de trames de données vidéo, selon un protocole défini par des caractéristiques caractérisé en ce qu'il comprend au moins un organe maître (OM) selon l'une des revendications précédentes, connecté audit 15 réseau de communication (RC). 8. Véhicule selon la revendication 7, caractérisé en ce qu'il est de type automobile. 9. Véhicule selon l'une des revendications 7 et 8, caractérisé en ce que ledit réseau de communication (RC) est de type LVDS.