FR 3104355 A1 20210611 FR 1913777 A 20191205 Un dispositif de conversion de données (DC) comprend un processeur (PR) et une mémoire (MD) agencés pour effectuer les opérations consistant : - à identifier dans des trames reçues, comportant des octets de premières données agencées selon un premier format d’un premier protocole de description de communication, un type de trame défini dans chaque premier octet, puis - à identifier dans des octets suivant chaque premier octet un service parmi un ensemble de services, puis - à déterminer parmi les octets suivants d’une trame ou d’une trame associée suivante des données utiles du service identifié, puis - à convertir les type de trame et service identifiés et les données utiles déterminées en secondes données agencées selon un second format d’un second protocole de description de communication. Figure à publier avec l’abrégé : Fig. 1 CONVERSION DE DONNÉES D’UN PREMIER VERS UN SECOND PROTOCOLE DE DESCRIPTION DE COMMUNICATION Domaine technique de l’invention L’invention concerne les équipements communicants qui sont destinés à être couplés à d’autres équipements communicants s’échangeant des trames de données selon des protocoles de description de communication différents. Etat de la technique Dans certains domaines, certains systèmes comprennent des équipements communicants qui s’échangent via un réseau de communication des trames de données selon un protocole de communication dit à faible abstraction, comme par exemple CAN (« Controller Area Network »), LIN (« Local Interconnect Network ») ou FLEXRAY. C’est notamment le cas dans le domaine des véhicules, éventuellement automobiles. Certains de ces systèmes comprennent une prise de diagnostic à laquelle peut être connecté un équipement communicant chargé d’effectuer des diagnostics et/ou des mises à jour de l’un au moins de leurs équipements communicants. Ces équipements communicants de diagnostic, ci-après appelés « outils », peuvent être agencés différemment. Par exemple, un premier outil peut être agencé de manière à lire (ou écouter) et/ou enregistrer des communications selon un protocole de description de communication plus élaboré que le binaire (et donc décrites de façon notablement plus complexe que bit après bit ou octet après octet), alors qu’un autre (second) outil peut être agencé de manière à lire (ou écouter) et/ou enregistrer des communications selon un protocole de description de communication binaire (et donc décrites bit après bit ou octet après octet). Dans le premier cas le premier outil va être capable de comprendre les contenus de trames dans lesquelles l’agencement (ou format) des données est décrit par un protocole de description de communication tel que UDS (« Unified Diagnostic Services »), CDD (« CAN Diagnostic Description » - développé par la société Vector) ou ODX (« Open Diagnostic data eXchange »), par exemple. Dans le second cas le second (autre) outil va être capable de comprendre les contenus de trames dans lesquelles l’agencement (ou format) des données est décrit par un autre protocole de description de communication, souvent propriétaire, comme par exemple DBC (« DataBase CAN » - développé par la société Vector), FiBEx (« Field Bus Exchange ») ou ArXml (« Autosar xml »). Lorsque ce second outil écoute et stocke des trames de données agencées selon le protocole de description de communication qui n’est pas le sien, il est généralement dans l’incapacité de comprendre ce que valent ou représentent les données utiles de ces trames. Cette incompréhension est d’autant plus forte lorsque l’on a été préalablement obligé de segmenter le contenu d’une trame du premier protocole de description de communication en plusieurs trames du protocole de description de communication du second outil pour qu’elle puisse être transmise via un réseau de communication à faible abstraction. Pour certains systèmes on est donc contraint de disposer des deux outils car ils disposent respectivement de deux tables de correspondance (données utiles/valeurs de paramètres associés à des services) sans relations entre elles. L’invention a donc notamment pour but d’améliorer la situation. Présentation de l’invention Elle propose notamment à cet effet un dispositif de conversion de données comprenant au moins un processeur et au moins une mémoire agencés pour effectuer les opérations consistant : - à identifier dans des trames reçues, comportant des octets de premières données agencées selon un premier format d’un premier protocole de description de communication, un type de trame défini dans chaque premier octet, puis - à identifier dans des octets suivant chaque premier octet un service parmi un ensemble de services, puis - à déterminer parmi les octets suivants d’une trame ou d’une trame associée suivante des données utiles du service identifié, puis - à convertir les type de trame et service identifiés et les données utiles déterminées en secondes données agencées selon un second format d’un second protocole de description de communication. Grâce à l’invention, un équipement communicant de diagnostic, capable de comprendre des trames du second format reçues d’un système, peut aussi désormais comprendre des trames du premier format reçues de ce même système, grâce à la conversion du premier format vers le second format assurée par le dispositif de conversion qu’il comprend ou auquel il est couplé. Le dispositif de conversion de données selon l’invention peut comporter d’autres caractéristiques qui peuvent être prises séparément ou en combinaison, et notamment : - son processeur et sa mémoire peuvent être agencés pour effectuer les opérations consistant à déterminer dans une table de correspondance, établissant une correspondance entre des premières données et des valeurs de paramètres associés à des services, la valeur de paramètre correspondant à une seconde donnée résultant de la conversion d’une donnée utile ; - le premier protocole de description de communication peut être choisi parmi Unified Diagnostic Services (ou UDS), CDD (CAN Diagnostic Description), et Open Diagnostic data eXchange (ou ODX) ; - le second protocole de description de communication peut être choisi parmi DBC (ou DataBase CAN), Field Bus Exchange (ou FiBEx) et Autosar xml (ou ArXml). L’invention propose également un équipement communicant comprenant un module de communication et un dispositif de conversion de données du type de celui présenté ci-avant. L’invention propose également un procédé de conversion de données comprenant une étape dans laquelle : - on identifie dans des trames reçues, comportant des octets de premières données agencées selon un premier format d’un premier protocole de description de communication, un type de trame défini dans chaque premier octet, puis - on identifie dans des octets suivant chaque premier octet un service parmi un ensemble de services, puis - on détermine parmi les octets suivants d’une trame ou d’une trame associée suivante des données utiles du service identifié, puis - on convertit les type de trame et service identifiés et les données utiles déterminées en secondes données agencées selon un second format d’un second protocole de description de communication. L’invention propose également un produit programme d’ordinateur comprenant un jeu d’instructions qui, lorsqu’il est exécuté par des moyens de traitement, est propre à mettre en œuvre un procédé de conversion de données du type de celui présenté ci-avant pour convertir des premières données, agencées en octets selon un premier format d’un premier protocole de description de communication dans des trames reçues, en secondes données agencées selon un second format d’un second protocole de description de communication. Brève description des figures 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 : illustre schématiquement et fonctionnellement un système comprenant des équipements communicants couplés à un réseau de communication auquel est également couplé temporairement un équipement communicant de diagnostic comprenant un exemple de réalisation d’un dispositif de conversion de données selon l’invention, et illustre schématiquement un exemple d’algorithme mettant en œuvre un procédé de conversion de données selon l’invention. Description détaillée de l’invention L’invention a notamment pour but de proposer un dispositif de conversion de données DC, et un procédé de conversion de données associé, destinés à permettre la conversion de premières données, agencées selon un premier format d’un premier protocole de description de communication dans des trames reçues d’un système S, en secondes données agencées selon un second format d’un second protocole de description de communication. Dans ce qui suit, on considère, à titre d’exemple non limitatif, que le système S est un véhicule, éventuellement de type automobile. Mais l’invention n’est pas limitée à ce type de système. Elle concerne en effet tout type de système comprenant au moins un équipement communicant pouvant faire l’objet de diagnostics. Ainsi, elle concerne tous les véhicules (terrestres, maritimes (ou fluviaux) et aériens), les appareils électroniques (éventuellement électroménagers), les installations (éventuellement industrielles), les ensembles de grues ou de robots fonctionnant en même temps dans une même zone, et les bâtiments. On a schématiquement représenté sur la figure 1 un exemple de système S comprenant quatre équipements communicants EC’ couplés de façon permanente à un réseau de communication RC comprenant une prise de diagnostic PD, et un équipement communicant de diagnostic (ou outil) EC temporairement couplé via un câble informatique CI à cette prise de diagnostic PD. Dans l’exemple illustré non limitativement sur la figure 1, l’équipement communicant de diagnostic (ou outil) EC comprend un exemple de réalisation d’un dispositif de conversion de données DC selon l’invention. On notera qu’un tel dispositif de conversion de données DC pourrait être un équipement électronique externe à l’équipement communicant de diagnostic EC, mais couplé à ce dernier (EC). L’équipement communicant de diagnostic EC est chargé d’effectuer des diagnostics, ainsi qu’éventuellement des mises à jour, de l’un au moins des équipements communicants EC’ du système S. Il comporte à cet effet un module de communication MC pouvant communiquer avec le réseau de communication RC du système S. Ce réseau de communication RC est éventuellement de type multiplexé. A titre d’exemple, ce réseau de communication RC peut être de type CAN (Controller Area Network). Mais, il pourrait aussi être de type LIN (Local Interconnect Network) ou FLEXRAY, par exemple. Le réseau de communication RC peut notamment transmettre au système S, via la prise de diagnostic PD et le câble informatique CI, des trames comportant des octets de premières données agencées selon un premier format d’un premier protocole de description de communication. A titre d’exemple, ce premier protocole de description de communication peut être Unified Diagnostic Services (ou UDS). Mais il pourrait aussi s’agir de CDD (CAN Diagnostic Description) ou d’Open Diagnostic data eXchange (ou ODX), par exemple. Comme illustré, un dispositif de conversion de données DC, selon l’invention, comprend au moins un processeur PR et au moins une mémoire MD. Il peut donc être réalisé sous la forme d’une combinaison de circuits ou composants électriques ou électroniques (ou « hardware ») et de modules logiciels (ou « software »). Par exemple, le processeur PR peut être un processeur de signal numérique (ou DSP (« Digital Signal Processor »)). Ce processeur PR peut comprendre des circuits intégrés (ou imprimés), ou bien plusieurs circuits intégrés (ou imprimés) reliés par des connections filaires ou non filaires. On entend par circuit intégré (ou imprimé) tout type de dispositif apte à effectuer au moins une opération électrique ou électronique. La mémoire MD est vive afin de stocker des instructions pour la mise en œuvre par le processeur PR d’une partie au moins d’un procédé de conversion de données sur lequel on reviendra plus loin (et pour que la fonction de conversion de données décrite ci-après puisse être assurée). Le processeur PR et la mémoire MD sont tout d’abord agencés pour effectuer les opérations consistant à identifier dans des trames reçues (ici du système S), comportant des octets de premières données agencées selon le premier format, au moins un type de trame défini dans chaque premier octet. Le processeur PR et la mémoire MD sont également agencés pour effectuer les opérations consistant à identifier dans des octets suivant chaque premier octet un service parmi un ensemble de services. Par exemple, l’ensemble de services peut comprendre au moins une écriture de paramètre(s), une lecture de paramètre(s), un changement de session, un lancement de script (éventuellement de routine(s)), et un téléchargement (éventuellement d’une mise à jour). Le processeur PR et la mémoire MD sont également agencés pour effectuer les opérations consistant à déterminer parmi les octets suivants d’une trame ou d’une trame associée suivante des données utiles du service identifié. En effet, en raison d’une possible segmentation préalable, plusieurs (au moins deux) trames peuvent être complémentaires et donc associées. Dans ce cas, la trame reçue en second peut comporter tout ou partie des données utiles du service identifié dans la trame reçue en premier. Le processeur PR et la mémoire MD sont également agencés pour effectuer les opérations consistant à convertir les type de trame et service identifiés et les données utiles déterminées (dans une ou plusieurs trames associées) en secondes données agencées selon un second format d’un second protocole de description de communication. Ainsi, si un équipement communicant de diagnostic (ou outil) EC, capable de comprendre des trames au second format reçues d’un système S, comprend le dispositif de conversion de données DC, comme illustré, ou est couplé à ce dernier (DC), il peut aussi désormais comprendre des trames au premier format reçues de ce même système S, grâce à la conversion du premier format vers le second format qui est assurée par le dispositif de conversion de données DC. En outre cela ouvre la porte à de nombreuses applications nouvelles. Le dispositif de conversion de données DC peut être considéré, au moins en partie, comme comprenant plusieurs (au moins deux) interpréteurs (ou multiplexeurs). Un premier interpréteur peut identifier dans le premier octet d’une trame reçue (par exemple dans sa moitié gauche) s’il s’agit d’une trame simple (par exemple identifiable par une valeur de bits égale à 0 en hexadécimal), ou d’une première trame d’une suite d’au moins deux trames associées (par exemple identifiable par une valeur de bits égale à 1 en hexadécimal), ou d’une trame associée à une autre trame précédemment reçue (par exemple identifiable par une valeur de bits égale à 2 en hexadécimal), ou encore d’une trame de contrôle de flux (ou « flow control ») (par exemple identifiable par une valeur de bits égale à 3 en hexadécimal). Ce premier interpréteur peut aussi identifier dans ce premier octet de la trame reçue (par exemple dans sa moitié droite) le nombre d’octets de cette trame. Un deuxième interpréteur peut identifier dans les octets qui suivent le premier octet de la trame reçue un service parmi un ensemble de services. Par exemple, ce service peut être identifié par un identifiant de service qui est placé dans le deuxième octet (ainsi qu’éventuellement le troisième octet) situé juste après le premier octet (par exemple identifiable par une valeur de bits égale à 22 en hexadécimal). Un troisième interpréteur peut identifier dans les octets qui suivent le premier octet de la trame reçue un identifiant de données utiles parmi un ensemble d’identifiants de données utiles du service identifié par le deuxième interpréteur. Par exemple, cet identifiant de données utiles peut être placé dans les troisième et quatrième octets (ou quatrième et cinquième octets) situés juste après le deuxième octet (par exemple identifiable par une valeur de bits égale à F0 80 en hexadécimal). Cet identifiant de données utiles est ensuite suivi de données utiles faisant intégralement partie de cette trame ou faisant partie de cette trame et d’au moins une trame suivante associée. On notera que l’on peut avoir des trames dans lesquelles on désigne un sous-service d’un service. Dans ce cas, on utilise encore un autre interpréteur pour identifier un identifiant de sous-service qui est placé dans le troisième octet (ainsi qu’éventuellement le quatrième octet) ou dans le quatrième octet (ainsi qu’éventuellement le cinquième octet). Les données utiles déterminées constituent au final les secondes données du service ou sous-service identifié. On notera que le processeur PR et la mémoire MD peuvent être aussi agencés pour effectuer les opérations consistant à déterminer dans une table de correspondance, établissant une correspondance entre des premières données et des valeurs de paramètres associés à des services (ou sous-services), la valeur de paramètre correspondant à une seconde donnée résultant de la conversion d’une donnée utile. Ainsi, une fois que des secondes données d’un service identifié ont été déterminées par conversion, le dispositif de conversion de données DC peut aussi fournir les valeurs de paramètre qui leurs correspondent respectivement. Par exemple, le second protocole de description de communication peut être DBC (DataBase CAN). Mais il pourrait aussi s’agir de Field Bus Exchange (ou FiBEx) ou d’Autosar xml (ou ArXml), par exemple. On notera également, comme illustré non limitativement sur la figure 1, que le dispositif de conversion de données DC, qui comprend déjà la mémoire vive MD et le processeur PR, peut aussi comprendre une mémoire de masse MM, notamment pour le stockage de l’éventuelle table de correspondance (entre les secondes données et les valeurs de paramètres associés aux services (ou sous-services)), les contenus (ou octets) des trames reçues, et les secondes données résultant des conversions, et de données intermédiaires intervenant dans tous ses calculs et traitements. Par ailleurs, ce dispositif de conversion de données DC peut aussi comprendre une interface d’entrée IE pour la réception d’au moins les trames précitées (ici reçues par le module de communication MC de l’équipement communicant de diagnostic EC), pour les utiliser dans des calculs ou traitements, éventuellement après avoir les mises en forme et/ou démodulées et/ou amplifiées, de façon connue en soi, au moyen d’un processeur de signal numérique PR’. De plus, ce dispositif de conversion de données DC peut aussi comprendre une interface de sortie IS, notamment pour délivrer des trames à destination des équipements communicants EC’ du système S et les résultats de ses conversions (secondes données ou valeurs des paramètres correspondant respectivement aux secondes données). L’invention peut aussi être considérée sous la forme d’un procédé de conversion de données destiné à permettre la conversion de premières données, agencées selon un premier format d’un premier protocole de description de communication dans des trames reçues du système S, en secondes données agencées selon un second format d’un second protocole de description de communication. Ce procédé de conversion de données comprend une étape 10-60 dans laquelle on commence par identifier dans des trames reçues, comportant des octets de premières données agencées selon un premier format d’un premier protocole de description de communication, au moins un type de trame défini dans chaque premier octet. Puis, l’étape 10-60 se poursuit par l’identification dans des octets suivant chaque premier octet d’un service parmi un ensemble de services. Puis, l’étape 10-60 se poursuit par la détermination parmi les octets suivants d’une trame ou d’une trame associée suivante des données utiles du service identifié. Puis, l’étape 10-60 se poursuit par la conversion des type de trame et service identifiés et des données utiles déterminées en secondes données agencées selon le second format du second protocole de description de communication. On a schématiquement illustré sur la figure 2 un exemple d’algorithme mettant en œuvre un procédé de conversion de données selon l’invention. Cet algorithme comprend une sous-étape 10 dans laquelle on reçoit des trames. Puis, dans une sous-étape 20, on identifie dans les trames reçues ce que définissent leur premier octet afin de déterminer le type de chaque trame et le nombre d’octets de chaque trame. Puis, dans une sous-étape 30, on identifie dans chaque trame ce que définissent les octets qui suivent son premier octet et notamment un service (ou sous-service) parmi un ensemble de services. Puis, dans une sous-étape 40, on détermine parmi les octets suivants de chaque trame ou d’une trame associée suivant la trame considérée des données utiles du service (ou sous-service) identifié. Puis, dans une sous-étape 50, on convertit les type de trame et service identifiés et les données utiles déterminées en secondes données agencées selon le second format du second protocole de description de communication. Puis, dans une sous-étape 60, on détermine dans la table de correspondance les valeurs des paramètres qui sont associés aux services (ou sous-services) identifiés et qui correspondent respectivement à des secondes données résultant de la conversion de données utiles. On notera qu’une ou plusieurs sous-étapes de l’étape du procédé de conversion de données peuvent être effectuées par des composants différents. Ainsi, le procédé de conversion de données peut être mis en œuvre par une pluralité de processeurs de signal numérique, mémoire vive, mémoire de masse, interface d’entrée, interface de sortie. On notera également que l’invention propose aussi un produit programme d’ordinateur (ou programme informatique) comprenant un jeu d’instructions qui, lorsqu’il est exécuté par des moyens de traitement de type circuits électroniques (ou hardware), comme par exemple le processeur PR, est propre à mettre en œuvre le procédé de conversion de données décrit ci-avant pour convertir des premières données, agencées en octets selon un premier format d’un premier protocole de description de communication dans des trames reçues, en secondes données agencées selon un second format d’un second protocole de description de communication. Dispositif de conversion de données (DC), caractérisé en ce qu’il comprend au moins un processeur (PR) et au moins une mémoire (MD) agencés pour effectuer les opérations consistant i) à identifier dans des trames reçues, comportant des octets de premières données agencées selon un premier format d’un premier protocole de description de communication, un type de trame défini dans chaque premier octet, puis ii) à identifier dans des octets suivant chaque premier octet un service parmi un ensemble de services, puis iii) à déterminer parmi les octets suivants d’une trame ou d’une trame associée suivante des données utiles dudit service identifié, puis iv) à convertir lesdits type de trame et service identifiés et lesdites données utiles déterminées en secondes données agencées selon un second format d’un second protocole de description de communication. Dispositif selon la revendication 1, caractérisé en ce que ledit processeur (PR) et ladite mémoire (MD) sont agencés pour effectuer les opérations consistant à déterminer dans une table de correspondance, établissant une correspondance entre des premières données et des valeurs de paramètres associés à des services, la valeur de paramètre correspondant à une seconde donnée résultant de la conversion d’une donnée utile. Dispositif selon la revendication 1 ou 2, caractérisé en ce que ledit premier protocole de description de communication est choisi parmi Unified Diagnostic Services, CDD, et Open Diagnostic data eXchange. Dispositif selon l’une des revendications 1 à 3, caractérisé en ce que ledit second protocole de description de communication est choisi parmi DBC, Field Bus Exchange et Autosar xml. Equipement communicant (EC) comprenant un module de communication (MC) caractérisé en ce qu’il comprend en outre un dispositif de conversion de données (DC) selon l’une des revendications précédentes. Procédé de conversion de données, caractérisé en ce qu’il comprend une étape (10-60) dans laquelle i) on identifie dans des trames reçues, comportant des octets de premières données agencées selon un premier format d’un premier protocole de description de communication, un type de trame défini dans chaque premier octet, puis ii) on identifie dans des octets suivant chaque premier octet un service parmi un ensemble de services, puis iii) on détermine parmi les octets suivants d’une trame ou d’une trame associée suivante des données utiles dudit service identifié, puis iv) on convertit lesdits type de trame et service identifiés et lesdites données utiles déterminées en secondes données agencées selon un second format d’un second protocole de description de communication. Produit programme d’ordinateur comprenant un jeu d’instructions qui, lorsqu’il est exécuté par des moyens de traitement, est propre à mettre en œuvre le procédé de contrôle selon la revendication 6 pour convertir des premières données, agencées en octets selon un premier format d’un premier protocole de description de communication dans des trames reçues, en secondes données agencées selon un second format d’un second protocole de description de communication.