Brevet FR2984537A1 — publié le 20130621

SYSTEME DE TEST ET PROCEDE DE PRODUCTION D'UN LOGICIEL EMBARQUE L'invention concerne un système de test de logiciel 5 embarqué dans un contrôleur, comprenant une boucle matérielle d'essai en temps réel du logiciel embarqué et une station de pilotage de la boucle matérielle. L'invention concerne aussi un procédé qui comprend une étape d'utilisation du système de l'invention à la 10 suite d'une première séquence d'étapes de programmation et de chargement du logiciel embarqué dans le contrôleur. De nombreux secteurs industriels utilisent aujourd'hui des logiciels embarqués dans des contrôleurs montés sur des machines, par exemple dans des usines, sur 15 des véhicules de déplacement en mer, dans l'espace ou sur terre, ou sur d'autres types d'appareils dans d'autres domaines techniques. Le logiciel embarqué détermine le comportement de la machine, du véhicule ou plus généralement de l'appareil 20 sur lequel le contrôleur est monté, pendant toute sa durée de vie. C'est pourquoi la production d'un logiciel embarqué, souvent dupliqué en de nombreux exemplaires, nécessite de vérifier que le logiciel embarqué détermine un 25 comportement qui satisfait tous les critères de conformité (législatifs, économiques, confort, etc.). Dans le domaine des véhicules automobiles, on connaît déjà des méthodes qui consistent à employer des véhicules d'essai comme par exemple des prototypes, des 30 mulets (spare car en anglais) ou des véhicules de présérie. Ces méthodes permettent la validation des logiciels embarqués en effectuant des tests statiques, de roulage sur piste ou sur route libre. On leur reconnaît des qualités de bonne représentativité du moyen d'essai qui résulte d'une prise en compte de tous les phénomènes physiques par la nature réelle du système. Cette représentativité n'est en fait valable qu'en fin de cycle du développement du véhicule et peut être diminuée si la totalité des pièces à utiliser en vie série n'est pas disponible. Cependant ces méthodes ont plusieurs inconvénients. Le caractère unique des prototypes et des mulets, fabriqués en nombre limité, hors bande, induit un coût de fabrication très élevé. Sachant que dans le cadre d'un cycle complet de développement d'un nouveau logiciel au minimum trois prototypes ou mulets différents peuvent être nécessaire, l'impact de ce coût est encore plus prégnant. La réalité physique des essais a pour contrepartie une insuffisance de contrôle des facteurs externes parmi lesquels on peut noter les conditions climatiques en termes de températures, de pressions ou autres, ou encore la maitrise du pilote d'essai. La mise en oeuvre de ce type de méthode est restreinte au lieu de présence physique du véhicule d'essai et de la personne humaine qui, pour effectuer les roulages et les tests lui permettant de valider les essais, est obligée de venir à proximité, voire dans le véhicule. On notera aussi les contraintes liées au gabarit et à la portabilité des instruments de mesure de type multimètre, oscilloscope ou autre. Dans le contexte actuel de l'endurcissement des normes de dépollution et de l'augmentation continue des exigences client, la complexité des logiciels embarqués pour le contrôle du GMP (groupe motopropulseur) est en croissance continue. Le même contexte amène à une très forte évolution des GMPs : nouveaux moteurs thermiques, nouvelles boites de vitesses, éléments qui, avec l'apparition des véhicules électriques, multiplient encore le nombre d'adaptations/évolutions à faire sur les logiciels. On connait aussi depuis quelques années des méthodes qui permettent la validation des logiciels embarqués en effectuant quasiment les mêmes tests que sur un véhicule d'essai, mais sur des véhicules virtuels, au moyen de la technique HIL (Hardware In the Loop). Ces méthodes ont pour avantage d'offrir la possibilité de faire des validations même si les composants ne sont pas disponibles. Elles sont aussi moins chères que celles utilisant un prototype. S'il est vrai que le coût d'achat d'un nouveau système HIL est approximativement le double de celui d'un prototype, son amortissement, même à la fin d'un développement, est bien plus rentable car le même banc peut être réutilisé pour d'autres projets et les éventuelles évolutions peuvent se faire à un coût réduit. Le contrôle élevé sur les paramètres externes, procuré par les méthodes HIL, rend ces méthodes adaptées pour des tests répétitifs et même automatiques, par exemple dans le cadre de roulages automatiques ou de lancement en fin du programme de travail avec la possibilité de récupérer les résultats le jour suivant. En permettant la réalisation des validations sur un ordinateur au lieu d'effectuer des roulages sur piste ou sur route libre, les méthodes HIL sont plus sures que les 30 méthodes basées sur des véhicules d'essai. Cependant, de nombreux besoins se font encore sentir dans l'utilisation de la technique HIL. La représentativité du système virtuel peut être limitée par les hypothèses nécessaires à la modélisation mathématique du système. Il peut s'avérer difficile de concilier une atteinte d'objectif d'un niveau de représentativité suffisant pour la prise d'une décision sur la conformité du logiciel embarqué, avec la nécessité de faire un compromis entre précision souhaitée et puissance de calcul. L'évolution permanente des technologies de calcul améliore évidement cet inconvénient. Parmi les développements les plus récents de cette technique, on peut citer celui du brevet EP1806636B1 d'octobre 2010 qui divulgue un système HIL destiné à tester des boîtiers de commande d'un système de commande de véhicule. Le système connu auquel s'applique l'enseignement divulgué, comprend un dispositif de simulation capable de fonctionner en temps réel, actionnable par au moins un calculateur central pour réaliser une simulation système, et relié à plusieurs modules de test pour la connexion de boîtiers de commande respectivement associés su système de commande. La centralisation du calculateur précédemment divulguée, n'est pas approprié pour attribuer une ou plusieurs tâches relatives au test à des utilisateurs répartis sur des sites distants, chacun avec sa spécialité ou affecté à un site particulier. De manière générale, les méthodes connues permettent uniquement une utilisation locale. Pour valider le logiciel embarqué, l'utilisateur du banc doit être présent à côté du banc en employant l'IHM (Interface Homme Machine), via l'ordinateur connecté au banc HIL. La mondialisation de nombreux marchés, notamment du marché de l'automobile, impose une adaptation des applications pour chaque climat et pour chaque contrainte spécifique à un pays ou à une région donnée. La multiplicité des applications qui doivent être prises en compte dans le développement des logiciels embarqués, amplifie le problème lorsqu'on prend en compte les différents membres d'un groupe international, répartis dans différentes sociétés et sur des lieux géographiques, souvent éloignés les uns des autres. Un constructeur automobile par exemple, peut voir ses équipes ayant besoin d'effectuer des validations de logiciel, être localisées dans plusieurs pays à travers le monde. Les éléments mentionnés ci-dessus déterminent un fort besoin des moyens de tests fiables, évolutifs, capables de répondre aux problèmes présentés par l'état antérieur de la technique, tout en gardant l'aspect réduction des coûts en ligne de mire. En vue de remédier aux problèmes de l'état antérieur de la technique, l'invention a pour objet un système de test de logiciel embarqué dans un contrôleur, comprenant une boucle matérielle d'essai en temps réel du logiciel embarqué et une station locale de pilotage de ladite boucle matérielle, dans lequel la station locale comprend des moyens de communication avec au moins une station distante de façon à permettre à au moins un utilisateur distant de piloter la boucle matérielle. De préférence, la boucle matérielle comporte un banc d'essai relié à la station locale et comprenant au moins un premier connecteur standard destiné à échanger des signaux avec le contrôleur, et un boîtier qui comprend au moins un deuxième connecteur standard semblable au premier connecteur standard et un adaptateur de câblage agencé pour y brancher ledit contrôleur de manière à aiguiller les signaux transmis par le deuxième connecteur standard spécifiquement audit contrôleur. Particulièrement, l'adaptateur de câblage comprend une réglette sur laquelle sont ramenés d'un côté des fils provenant du deuxième connecteur standard et sont ramenés d'un autre côté des fils en provenance d'un connecteur spécifique pour recevoir des broches de connexion du contrôleur. Avantageusement, la station locale de pilotage comporte un ordinateur qui comprend au moins un logiciel de communication réseau pour effectuer des opérations sur la boucle matérielle ordonnées à partir de la ou des stations distantes. Particulièrement, le système de test de logiciel embarqué comprend un oscilloscope qui comporte une ou plusieurs sondes pour relever des signaux de mesure en différents points de la boucle matérielle d'essai et qui est relié à l'ordinateur pour lui communiquer les signaux de mesure. Plus particulièrement, l'ordinateur comprend au moins un logiciel non embarqué pour effectuer localement 20 une ou plusieurs procédures de test supervisées à partir de la ou des stations distantes. L'invention a aussi pour objet un procédé de production d'un logiciel embarqué comprenant une étape de programmation et une étape de chargement du logiciel 25 embarqué dans un contrôleur. De manière remarquable, le procédé comprend au moins une étape de test du logiciel embarqué au moyen d'une boucle matérielle d'essai en temps réel du logiciel embarqué à distance, et une étape de modification ou de validation en fonction d'un 30 résultat de l'étape de test à distance. L'invention sera mieux comprise à l'aide d'exemples de réalisation d'un dispositif conforme à l'invention en référence aux dessins annexés, dans lesquels : la figure 1 est une vue schématique d'un dispositif du domaine technique de l'invention ; la figure 2 est une vue schématique d'un dispositif conforme à l'invention ; la figure 3 est une vue d'un composant utilisé dans la technique antérieure ; la figure 4 est une vue du composant de la figure 3 modifié de manière conforme à l'invention. La figure 1 présente un schéma de principe habituel d'architecture HIL (acronyme de l'expression anglaise « Hardware In the Loop » qui signifie matériel dans la boucle) pour tester un ou des logiciels embarqués. Un logiciel embarqué comprend une ou plusieurs structures de données et un ou plusieurs programmes résidant sur un contrôleur monté ou destiné à être monté dans un véhicule terrestre, maritime, aérien ou spatial, notamment dans un véhicule automobile. Le contrôleur, généralement nommé ECU (acronyme de l'expression anglaise « Electronic Control Unit » qui signifie unité de contrôle-commande électronique), est par exemple, à titre purement illustratif et non exhaustif, de type ECM (acronyme de l'expression anglaise « Engine Control Module » qui signifie module de contrôle-commande du moteur), TCU (acronyme de l'expression anglaise « Transmission Control Unit » qui signifie unité de contrôle-commande de transmission), EVC (acronyme de l'expression anglaise « Electrical Vehicle Controller » qui signifie contrôleur de véhicule électrique) ou autre. Un exemplaire réel de contrôleur 20 tel qu'il est programmé avec le logiciel embarqué en vue d'être monté sur un véhicule, est relié à un banc d'essai 10 de type HIL pour être testé. Le banc d'essai 10 a pour fonction de reproduire, en d'autres termes de simuler, un environnement avec lequel le contrôleur 20 et son logiciel embarqué sont destinés à interagir. L'environnement reproduit est celui du contrôleur 20 et de son logiciel embarqué lorsqu'ils sont montés sur le véhicule. Le banc d'essai 10 reproduit l'environnement de manière HIL en combinant une simulation numérique temps-réel et des composantes physiques, de façon à obtenir un niveau de représentativité physique, notamment mécanique et électrique suffisant pour une prise de décision sur la conformité des stratégies de contrôle mises en oeuvre par le contrôleur 20 et son logiciel embarqué. Des signaux de consigne envoyés sous forme analogique, numérique ou logique à des actionneurs réels ou virtuels du banc d'essai 10 par le contrôleur 20 sur une ou plusieurs liaisons 70, provoquent des signaux en retour de capteurs réels ou virtuels du banc d'essai 10 transmis au contrôleur 20 sur une ou plusieurs liaisons 80. Par les signaux qu'ils échangent, le banc d'essai 10 et le contrôleur 20 constituent une boucle matérielle 100 d'essai en temps réel du logiciel embarqué sur le contrôleur 20 qui émule le comportement du contrôleur 20 dans et sur l'environnement dans lequel il est appelé à fonctionner. Un ordinateur 30 de type PC (acronyme de l'expression anglaise « Personal Computer » qui signifie ordinateur personnel) permet à un utilisateur d'interagir avec un véhicule virtuel ainsi qu'avec de nombreux paramètres externes relatifs à des températures, des pressions, une pente de la route, et de manière générale tout paramètre lié à une grandeur physique qui intervient sur un comportement de véhicule. L'ordinateur 30 est localisé à proximité d'un ou plusieurs bancs d'essai 10 à chacun desquels il est connecté au moyen d'un ou plusieurs câbles de communication 60 de façon à retranscrire chaque interaction de l'utilisateur avec le véhicule virtuel et les paramètres externes sur l'ordinateur 30, en une ou plusieurs interactions avec le banc d'essais 10. Une interface 40 de calibration et de diagnostic est reliée au contrôleur 20 par une liaison 69 qui permet d'intervenir directement dans les couches basses du logiciel embarqué, voire en mode observation sur certains éléments de la couche micrologicielle et matérielle du contrôleur 20. D'autre part, l'interface 40 est connectée par une liaison 99 à l'ordinateur 30 sur lequel l'utilisateur dispose également de logiciels non embarqués qui permettent d'effectuer divers validations du logiciel embarqué. A titre purement illustratif et non exhaustif de logiciels non embarqués, on indique les outils d'étalonnage ou encore de calibration comme par exemple ceux du logiciel INCA commercialisé par le groupe ETAS, et les outils de diagnostic et de reprogrammation comme par exemple ceux du logiciel DDT2000 produit par le groupe Renault. Ainsi connectés, l'ordinateur 30 et l'interface 40 constituent une station locale 101 de pilotage de la boucle matérielle 100. La figure 2 présente un mode de réalisation de l'invention dans lequel le système de test de logiciel embarqué dans le contrôleur 20, comprend comme précédemment une boucle matérielle 100 d'essai en temps réel du logiciel embarqué et une station locale 101 de pilotage de la boucle matérielle. Cependant la station locale comprend à présent des moyens de communication avec des stations distantes 51, 52. Dans l'exemple illustré par la figure 2, les moyens de communication sont matérialisés par un logiciel de communication réseau 36 installé avec une carte réseau dans l'ordinateur 30, laquelle est reliée à un réseau local lui-même relié à un réseau étendu, l'ensemble des réseaux interconnectés étant ici symbolisé par l'anneau 50. La boucle matérielle comporte un banc d'essai 10 10 relié à la station locale et plus précisément dans la station locale à l'ordinateur 30 et au châssis de calibration 40. Dans le mode de réalisation de l'invention représenté sur la figure 2, le banc d'essai 10 de type 15 HIL comprend un processeur industriel 11 agencé pour exécuter un ou plusieurs programmes de simulation en temps-réel du véhicule, de divers conditions environnementales parmi lesquelles on peut citer à titre purement illustratif et non exhaustif, une inclinaison de 20 la route, une température et une pression atmosphérique ambiante, voire d'un être humain qui conduit le véhicule ainsi simulé. Le processeur industriel 11 confère au banc d'essai 10, représentativité logicielle temps réel de paramètres physiques interagissant à partir de et sur les 25 différents organes du véhicule. La part essentielle du ou des programmes exécutés par le processeur industriel 11 constituent un modèle numérique du véhicule sur lequel le contrôleur 20 et son logiciel embarqué sont prévus d'être montés. 30 Un tiroir 14 de charges physiques (Load Rack en anglais) contient des composantes réelles, comme par exemple des injecteurs de carburation, un volet d'admission, une vanne EGR (acronyme de l'expression anglaise Exhaust Gas Recirculation qui signifie recirculation des gaz d'échappement), tout autre organe réel du véhicule sur lequel le contrôleur 20 est prévu d'être monté, ou comme par exemple encore des arrangements matériels de résistances électriques, de bobines d'induction et de mécanismes qui permettent d'émuler un ou des organes précédemment mentionnés. Les composantes réelles contenues dans le tiroir 14, constituent des charges de consommation et de génération de courant électrique qui sont nécessaires pour assurer une bonne représentativité électrique du système. Il suffit alors de changer le modèle numérique et le tiroir de charges pour utiliser le même banc dans différents projets relatifs à une combustion interne essence ou diesel, à une boîte de vitesse automatique ou robotisée, ou à un véhicule électrique. Une ou plusieurs cartes 12 d'entrée/sortie et de conditionnement du signal équipent le processeur industriel 11 pour assurer l'interaction entre un univers virtuel obtenu par le modèle de simulation numérique et un univers réel par nature analogique. L'univers réel comprend bien entendu les composantes réelles contenues dans le tiroir 14 mais non seulement. Il comprend aussi le contrôleur 20 avec son logiciel embarqué et un bus système 13 de même nature que celui qui est prévu d'être monté dans le véhicule. Parmi les bus systèmes connus de véhicules automobiles, on peut citer les bus système série (acronyme de l'expression comme par exemple le bus CAN anglaise Controller Area Network) le bus LIN (acronyme de l'expression anglaise Local Interconnect Network) ou encore les bus multiplexés comme par exemple le bus FlexRay en multiplexage TDMA (acronyme de l'expression anglaise Time-Division Multiple Access). Des boitiers 16 d'éclatement (BoB pour Brake-out Box en anglais), permettent d'effectuer des mesures, par exemple à l'aide d'un multimètre ou d'un oscilloscope, sur chacun des signaux échangés entre le banc 10 et le contrôleur 20, ou d'effectuer des manipulations physiques, par exemple relative à un ré-routage des signaux, à des défauts électriques, ou autres. Des cartes 15 d'insertion de défauts électriques (FIU pour electrical Failure Insertion Unit en anglais), permettent de réaliser à distance ou de manière automatique, des circuits ouverts ou des courts-circuits, par exemple à la masse, à la batterie, ou entre différents signaux. On note sur la figure 2 que la boucle matérielle comporte un boîtier 21 qui comprend un adaptateur de câblage 22 agencé pour y brancher à une première extrémité le contrôleur 20 et à une deuxième extrémité un faisceau 18 de câbles qui relie le boîtier 21 au banc 10, de manière à aiguiller les signaux transmis par le faisceau de câble 18 spécifiquement au contrôleur 20.En d'autres termes, le boîtier 21 (ECU Box en anglais), assure un routage des signaux à partir des broches de connexion du contrôleur 20 vers les bonnes voies d'entrée/sortie du banc 10. En référence à la figure 3, la solution utilisée précédemment pour interconnecter le contrôleur 20 au banc HIL 10, comportait une bretelle 71 personnalisée pour l'application spécifique du test au contrôleur 20. Le câblage de la bretelle 71 spécifique à chaque application, aboutit d'un côté sur des connecteurs génériques 81, 82, 83 pour branchement au banc 10. Les connecteurs génériques sont par exemple des connecteurs Hypertac® qui sont garantis à plusieurs milliers d'opérations de connexion/déconnexion grâce à leurs contacts hyperboloïdes. Le câblage aboutit de l'autre côté sur des connecteurs 25, 26 spécifiques ECU qui sont identiques aux connecteurs qui sur le véhicule, permettent de brancher les broches 23, 24 du contrôleur 20 et qui peuvent varier d'un type de contrôleur à l'autre. La solution illustrée par la figure 3, présente au 10 moins deux inconvénients majeurs. La fiabilité de l'interconnexion souffre fortement du petit nombre de branchements et débranchements supportés par les connecteurs côté ECU rapporté au grand nombre de modifications permises par le banc HIL 10 de 15 l'invention. Le besoin de démonter tout ou partie des connecteurs 25, 26, 81 à 83 pour effectuer toute modification du routage limite fortement l'évolutivité du câblage, par exemple pour ajouter de nouveaux signaux ou ré-router des 20 signaux existants. La solution illustrée par la figure 4 palie notamment les deux inconvénients listés ci-dessus. Le boîtier 21 (ECU Box) en matériau diélectrique, à faible poids et haute résistance aux chocs, a pour 25 principale fonctionnalité de protéger le contrôleur 20. Une réglette 28 de connexion, fixée à l'intérieur du boîtier 21, permet de modifier facilement le routage des signaux entre les broches 23, 24 du contrôleur 20 et celles des connecteurs 81, 82, 83 du banc HIL 10. Comme 30 on peut le voir sur la figure 4, les fils en correspondance avec les broches de l'ECU sur les connecteurs 25, 26, sont branchés sur la réglette 28 dans l'adaptateur de câblage 22 en câblage électrique 1:1 à l'intérieur du boîtier 21. Une zone 27 de l'adaptateur de câblage permet de jouer avec les fils entre la réglette 28 et des connecteurs Hypertac® 85, 87 en correspondance directe avec les connecteurs 81, 83. La réglette donne une très grande flexibilité au câblage ECU - Banc HIL. Des bretelles 18 à présent standardisées 1:1 assurent la connexion entre le banc 10 et le boîtier 21. Dotée de connecteurs génériques aux deux bouts, les bretelles 18 câblées 1:1, prennent sur elles la fonction de branchement/débranchement à chaque changement de contrôleur 20, améliorant ainsi la sureté de fonctionnement du système. Il suffit d'un nombre de bretelles 18 limité à un jeu (set en anglais) par banc HIL. L'ordinateur 30 représenté sur la figure 2 est de type PC (acronyme de Personal Computer en anglais qui signifie ordinateur personnel) ou autre. L'ordinateur 30 comprend un module 32 de contrôle qui, connecté au processeur industriel 11, de préférence par fibre optique, et aux cartes 15 d'insertion de défauts électriques, permet à un utilisateur d'interagir avec le véhicule simulé par le modèle numérique. Le module 32 exécute par exemple le logiciel ControlDesk® édité par le groupe dSPACE. L'ordinateur 30 comprend aussi d'autres modules qui contiennent des outils logiciels (SW Tool en anglais) utiles pour effectuer les validations relatives à la calibration, au diagnostic, aux mesures ou autres. Le module 33 est relié au bus système 13 par un câble de diagnostic, identique au câble, par exemple de type USB, habituellement utilisé sur les véhicules d'essai ou dans les concessions pour interroger l'ECU et/ou reprogrammer le logiciel embarqué. Le module 33 exécute par exemple l'outil logiciel de diagnostic que le constructeur utilise par ailleurs sur d'autres véhicules. Le module 34 est relié au bus système 13 pour 5 exécuter un outil logiciel d'analyse réseau généralement obtenu auprès du fournisseur de la technologie réseau employée. Le module 31 est relié à un oscilloscope 17, par exemple de type numérique à connexion USB. Une équipe de 10 support HIL présente sur place ayant branché l'oscilloscope 17 sur les bornes requises, par exemple des boitiers 16 d'éclatement, l'oscilloscope 17 est utilisable et configurable directement à partir de l'ordinateur 30. Le module 31 exécute par exemple l'outil 15 logiciel de mesure fourni avec l'oscilloscope 17. Le module 35 est relié au châssis de calibration 40 qui offre plus de fonctionnalités que les cartes d'interconnexion habituellement utilisées lors des tests sur véhicule. Le châssis de calibration 40 offre la 20 possibilité d'échanger des informations sur quatre canaux différents du bus CAN et une grande flexibilité de mise en oeuvre de protocole de communication avec l'ECU parmi lesquels on peut citer à titre purement illustratif et non exhaustif le protocole ETK du groupe ETAS, le 25 protocole CCP (Acronyme de l'expression anglaise « CAN Calibration Protocol » qui signifie protocole de calibration de bus série), ou encore le protocole de transport XCP, (Acronyme de l'expression anglaise « eXplicit Control Protocol » qui signifie protocole de 30 contrôle-commande explicite du routage) pour l'interconnexion de réseaux haut-débit hétérogènes. Le châssis de calibration 40 offre aussi la possibilité d'effectuer l'acquisition de seize signaux analogiques et de les enregistrer de manière synchrone avec les variables du logiciel embarqué. Un de ces seize canaux est utilisé fréquemment pour déclencher les enregistrements INCA® au bon moment, dans le cadre des tests automatiques. Le châssis de calibration 40 est aussi agencé pour permettre d'ajouter des modules spécifiques sans avoir à changer de châssis, comme par exemple des modules pour le prototypage rapide. L'ordinateur 30 comprend de manière connue en soi un 10 système d'APIs 37 (acronyme de l'expression anglaise Application Programming Interface qui signifie interface de programmation), ou de scripts qui permettent aux modules 31 à 35 d'interagir entre eux. Ces scripts sont transparents aux utilisateurs du moyen de test. 15 L'architecture présentée ci-dessus permet d'assurer au moins trois fonctionnalités essentielles. Une première fonctionnalité est celle d'un contrôle total à distance du véhicule virtuel et des conditions environnementales relatives notamment aux températures, 20 aux pressions, à la pente de la route, etc. Ce contrôle se fait par connexion à distance sur l'ordinateur 30 en utilisant un réseau informatique local et/ou étendu de préférence sécurisé par exemple par VPN, des applications et des protocoles spéciaux afin de garantir la stabilité 25 de fonctionnement et la vitesse de réaction. De plus, une gestion stricte des profils des utilisateurs permet d'assurer la confidentialité des données. Une deuxième fonctionnalité est celle d'un choix d'applications possibles pour effectuer la connexion à 30 distance des utilisateurs sur les moyens d'essai HIL. L'application « Remote Desktop Connection », disponible sous MS Windows permet la connexion à distance d'un seul utilisateur à la fois avec un taux de rafraîchissement élevé. L'application « VNC » (acronyme de l'expression anglaise « Virtual Network Computing » qui autorise une prise le contrôle d'un ordinateur distant) permet la connexion à distance de plusieurs utilisateurs en même temps, avec un taux de rafraichissement moins élevée, en d'autres termes de manière moins rapide. Une troisième fonctionnalité est celle d'un contrôle total à distance des outils de calibration et de diagnostic afin de permettre la réalisation des validations envisagées. Ce contrôle est obtenu de la même manière, avec les outils suivants connectés à l'ordinateur 30. L'outil de calibration INCA® par exemple, nécessite l'emploi d'un châssis d'acquisition 40 fourni par le groupe ETAS, propriétaire du logiciel INCA® connecté avec l'ordinateur 30 via Ethernet. De l'autre côté du châssis, la connexion est directe avec le contrôleur 20 via un port spécial d'émulation. L'outil de diagnostic DDT2000 par exemple, nécessite 20 l'utilisation d'un câble USB-DIAG exactement comme sur un véhicule réel. Ce câble est branché à l'ordinateur via un port USB et au banc via un connecteur OBD (acronyme de l'expression anglaise « On-Board Diagnostic » qui signifie diagnostic par l'ordinateur de bord). 25 Une fonctionnalité supplémentaire est celle du contrôle total à distance des instruments de mesure de type multimètre, oscilloscope ou autre, afin de pouvoir mesurer et visualiser en temps réel les signaux échangés entre le banc HIL et l'ECU à tester. 30 Des outils bien adaptés pour répondre aux contraintes de commande à distance d'appareils de mesure, ont été recherchés. Ces recherches ont mené à une préférence pour l'oscilloscope 17 avec connectique USB, utilisable et configurable directement à partir de l'ordinateur 30 et par voie de conséquence à partir de l'un des ordinateurs distants 51, 52. L'oscilloscope 17 permet de visualiser des tensions et des courants prélevés par des pinces ampérométriques sur quatre canaux simultanément. Il dispose également d'une fonctionnalité supplémentaire de générateur de signal. Une autre possibilité pour visualiser les signaux échangés entre le banc 10 et l'ECU 20 est d'utiliser les seize entrées analogiques du châssis ETAS. Cette méthode permet entre autres l'acquisition et l'enregistrement des signaux en synchronisme avec d'autres variables internes de l'ECU. Le banc HIL contrôlé et commandé à distance, conformément à l'invention, présente tous les avantages de la solution HIL en local, notamment en termes de flexibilité plus élevée que pour un véhicule réel. On peut utiliser le même banc HIL pour valider quasiment tous les systèmes, que ce soit essence, diesel, boites de vitesses automatiques ou robotisées, véhicules électriques, simplement en chargeant le bon modèle numérique de véhicule et en mettant la bonne configuration matérielle spécifique comprenant un ensemble de composants physiques et un câblage entre banc ECU personnalisé. En outre, au lieu de modifier un prototype ou même d'en créer un autre, il suffit de faire évoluer une partie du modèle ou une petite partie du banc. Le banc HIL contrôlé et commandé à distance, conformément à l'invention, présente des avantages supplémentaires par rapport à la solution HIL en local, notamment en termes de localisation unique des bancs permettant une meilleure gestion des outils : support à l'utilisation, maintenance, expertise de développement HIL, etc. Le système de l'invention permet une localisation multiple des personnes en charge de la validation, voire du développement, tout membre d'un même groupe industriel pouvant effectuer des essais sur HIL. Ceci conduit à une optimisation des coûts d'utilisation et de gestion. L'agencement des éléments du système que nous venons de décrire, permet ainsi à au moins un utilisateur distant de piloter la boucle matérielle 100 pour effectuer des opérations sur la boucle matérielle 100 ordonnées à partir d'une ou plusieurs stations distantes 51, 52. Cet agencement permet aussi d'effectuer des téléchargements à distance d'un nouveau modèle numérique de simulation dans le processeur industriel 11 ou d'un nouveau logiciel embarqué dans le contrôleur 20. REVENDICATIONS1. Système de test de logiciel embarqué dans un contrôleur (20), comprenant une boucle matérielle (100) 5 d'essai en temps réel du logiciel embarqué et une station locale (101) de pilotage de ladite boucle matérielle, caractérisé en ce que ladite station locale comprend des moyens de communication avec au moins une station distante (51, 52) de façon à permettre à au moins un 10 utilisateur distant de piloter ladite boucle matérielle (100). 2. Système de test de logiciel embarqué selon la revendication 1, caractérisé en ce que la boucle 15 matérielle (100) comporte : - un banc d'essai (10) relié à la station locale (101) et comprenant au moins un premier connecteur standard (81, 83) destiné à échanger des signaux avec ledit contrôleur (20) ; et 20 - un boîtier (21) qui comprend au moins un deuxième connecteur standard (85, 87) semblable au dit premier connecteur standard (81, 83) et un adaptateur de câblage (22) agencé pour y brancher ledit contrôleur (20) de manière à aiguiller les signaux transmis par ledit 25 deuxième connecteur standard (85, 87) spécifiquement audit contrôleur (20). 3. Système de test de logiciel embarqué selon la revendication 2 caractérisé en ce que l'adaptateur de 30 câblage (22) comprend une réglette (28) sur laquelle sont ramenés d'un côté des fils provenant du deuxième connecteur standard (85, 87) et sont ramenés d'un autre côté des fils en provenance d'un connecteur spécifique(25, 26) pour recevoir des broches de connexion du contrôleur (20). 4. Système de test de logiciel embarqué selon l'une des revendications précédentes, caractérisé en ce que la station locale (101) de pilotage comporte un ordinateur (30) qui comprend au moins un logiciel de communication réseau (36) pour effectuer des opérations sur la boucle matérielle (100) ordonnées à partir de la ou des stations distantes (51, 52). 5. Système de test de logiciel embarqué selon la revendication 4, caractérisé en ce qu'il comprend un oscilloscope (17) qui comporte une ou plusieurs sondes pour relever des signaux de mesure en différents points de la boucle matérielle d'essai et qui est relié à l'ordinateur (30) pour lui communiquer les signaux de mesure. 6. Système de test de logiciel embarqué selon l'une des revendications 4 ou 5, caractérisé en ce que l'ordinateur (30) comprend au moins un logiciel non embarqué pour effectuer localement une ou plusieurs procédures de test supervisées à partir de la ou des stations distantes (51,52). 7. Procédé de production d'un logiciel embarqué comprenant une étape de programmation et une étape de chargement du logiciel embarqué dans un contrôleur, 30 caractérisé en ce qu'il comprend : une étape de test à distance dudit logiciel embarqué au moyen d'une boucle matérielle d'essai en temps réel du logiciel embarqué ;- une étape de modification ou de validation en fonction d'un résultat de l'étape de test à distance.