Brevet FR3142822A1 — publié le 20240607

Système de déploiement et de test d’un composant fonctionnel d’une fonction logiciel sur un ensemble de ressources matérielles L’invention concerne un système de test (St) d’au moins une fonction logicielle comportant : un premier ensemble (ENS 1 ) de composants fonctionnels configurés pour exécuter ladite fonction logicielle ; un ensemble de ressources matérielles (RM n ) comprenant chacune au moins une entrée et une sortie, ledit deuxième ensemble de ressources matérielles (RM n ) étant connecté à un réseau de données (NET) ; une carte d’interface de communication pour configurer des liens physiques entre l’entrée et la sortie des ressources matérielles (RM n ) ; un calculateur (CLC 1 ) configuré pour générer une configuration matérielle dudit deuxième ensemble de ressources matérielles (RM n ) ; un module de gestion d’une alimentation électrique dudit deuxième ensemble de ressources matérielles (RM n ) ; un module de gestion d’anomalies configuré pour exécuter une première fonction de redémarrage automatique d’au moins une ressource matérielle (RM n ) du deuxième ensemble, une console d’exploitation comprenant une interface utilisateur (INT 1 ) et connectée à un calculateur. Figure pour l’abrégé : Fig. 1 Système de déploiement et de test d’un composant fonctionnel d’une fonction logiciel sur un ensemble de ressources matérielles Domaine de l’invention Le domaine de l’invention se rapporte au domaine des systèmes de test de logiciels. Plus particulièrement, le domaine de l’invention se rapporte au domaine des systèmes de test de fonctions logicielles dans le domaine des systèmes embarqués, notamment dans le domaine l’automobile. État de la technique Historiquement, l’électronique des véhicules automobiles était très distribuée, et les fonctions logicielles étaient généralement exécutées chacune sur un calculateur différent connectés via des bus de données de type CAN (de l’anglais “Controlled Area Network”). Avec l’évolution des technologies, l’électronique des véhicules automobiles, comme plus généralement celles des systèmes embarqués, connaît une mutation vers des architectures davantage centralisées, qui comprennent un nombre réduit de calculateurs plus puissants et connectés par un réseau haut débit, par exemple via des connexions type Ethernet. De telles architectures permettent avantageusement de déployer de nouvelles fonctionnalités logicielles au moyen de mises à jour logicielles des calculateurs, et non plus en ajoutant de nouveaux calculateurs dédiés aux nouvelles fonctionnalités logicielles. On connait dans l’art antérieur des systèmes de déploiement logiciel sur cible virtuelle. De tels systèmes peuvent mettre en œuvre des émulateurs machines, par exemple Qemu. On connait également, dans l’art antérieur, des systèmes de déploiement logiciel sur des cibles hybrides réelles/virtuelles. C’est le cas par exemple du système vpSIM (Virtual Patient Simulation), qui permet la simulation de cas médicaux dans un objectif de formation. On connait également, dans l’art antérieur, des systèmes de déploiement logiciel sur des cibles réelles. C’est le cas par exemple du système “Samsung Remote Test Lab” et du système “DIGIX Lab Test Services” permettant la mise en œuvre de déploiements applicatifs sur des cibles réelles de manière distante. L’art antérieur décrit également des systèmes permettant d’intégrer du matériel dans une boucle de développement et de test continu, au moyen d’approches telles que l’approche “Hardware In the Loop”. Toutefois, une telle approche présente les inconvénients de nécessiter la plupart du temps un accès physique au matériel et de se limiter à une seule cible matérielle. On connait également dans l’art antérieur une solution développée par la société IoT.bzh sous le nom de repdesk. Cette solution comprend une suite d’outils permettant à un utilisateur de compiler un applicatif dans un environnement CI/CD, acronyme désignant dans la terminologie anglosaxonne « Continuous Integration / Continuous Delivery », de tester son exécution sur une cible virtuelle ou réelle et d’évaluer les performances d’exécution sur la cible. Cependant, cette solution présente plusieurs inconvénients, puisque son fonctionnement se limite au système d’exploitation repdesk, que le système de fichiers pour le test sur cible distante n’est pas le système natif de la plateforme, et que le déploiement de la solution se limite à une seule cible matérielle à la fois. On connaît également dans l’art antérieur des solutions de prototypage sur cibles, par exemple les solutions décrites dans les articles (Chen , Song , & Zhang, 2010) et (Dawson, Martinez, & Taveras, 2019). Toutefois, ces solutions présentent l’inconvénient de s’appliquer dans un contexte d’application web et non pas dans un contexte de chaîne fonctionnelle déployable sur du matériel embarqué. L’invention vise à limiter les inconvénients précités. Selon un premier aspect, l’invention concerne un système de test ou de déploiement d’au moins un composant fonctionnel d’une fonction logicielle, ledit système de test ou de déploiement comportant : un premier ensemble de composants fonctionnels configurés pour exécuter ladite fonction logicielle, au moins un composant fonctionnel ; un premier ensemble de ressources matérielles comprenant chacune au moins une entrée et une sortie définissant des interfaces d’échange de données, ledit premier ensemble de ressources matérielles étant connecté à un réseau de données par l’intermédiaire d’une première interface de communication ; un dispositif d’interface de communication pour configurer des liens physiques entre l’entrée et la sortie des ressources matérielles du premier ensemble ; un premier calculateur configuré pour générer une configuration matérielle d’au moins une ressource matérielle du premier ensemble ; une console d’exploitation comprenant une interface utilisateur et connectée audit premier calculateur pour : sélectionner un deuxième ensemble de ressource matérielles parmi le premier ensemble de ressources matérielles ; associer chaque composant fonctionnel à au moins une ressource matérielle du deuxième ensemble, ladite association entrainant un adressage de chaque ressource matérielle du deuxième ensemble pour : transmettre des données propres à chaque composant fonctionnel à chaque ressource matérielle associée ; ladite console d’exploitation comportant un actionneur pour déployer au moins un composant fonctionnel sur au moins une ressource matérielle, ledit système de test comportant une interface de communication pour recevoir des données propres à des évènements produits par ladite au moins une ressource matérielle au sein de laquelle est déployée le composant logiciel. Le système de test ou de déploiement est plus généralement appelé le système de test dans la suite. Selon un mode de réalisation, le système de test comprend : Un module de gestion d’anomalies configuré pour exécuter une première fonction de redémarrage automatique d’au moins une ressource matérielle du premier ou du second ensemble de ressources matérielles, ladite console d’exploitation comporte un actionneur pour lancer un premier test d’exécution d’au moins un composant fonctionnel sur au moins une ressource matérielle, ledit premier test d’exécution comportant une mise en œuvre de la première fonction de redémarrage automatique de ladite ressource matérielle, ledit système de test comportant une interface de communication pour recevoir des données propres à des évènements produits par ladite au moins une ressource matérielle redémarrée lors du premier test d’exécution. Selon un mode de réalisation, le système de test comprend : Un module de gestion d’anomalies configuré pour exécuter une seconde fonction de pilotage de l’alimentation d’au moins une ressource matérielle du premier ou du second ensemble de ressources matérielles, un module de gestion d’une alimentation électrique des ressources matérielles du premier ou du second ensemble, ledit module de gestion d’une alimentation électrique permettant d’activation ou la désactivation d’une alimentation d’au moins une ressource matérielle du deuxième ensemble, ledit module de gestion d’anomalies étant configuré pour exécuter une deuxième fonction de pilotage de l’alimentation d’au moins une ressource matérielle du deuxième ensemble, et la console d’exploitation comportant un actionneur pour lancer un deuxième test d’exécution dudit composant fonctionnel, ledit deuxième test d’exécution comportant une mise en œuvre de la deuxième fonction de pilotage de l’alimentation électrique d’au moins d’une ressource matérielle du deuxième ensemble, ledit système comportant une mémoire pour enregistrer ou une interface pour recevoir des données propres à des évènements produits par la ressource matérielle pilotée lors du deuxième test. Selon un mode de réalisation, le système de test comprend : Un module de gestion d’anomalies configuré pour exécuter une troisième fonction de pilotage de l’entrée et/ou de la sortie d’au moins une ressource matérielle du premier ou du second ensemble de ressources matérielles, ledit module de gestion d’anomalies étant configuré pour modifier une valeur de ladite entrée et/ou de ladite sortie, ladite console d’exploitation comportant un actionneur pour lancer un troisième test d’exécution dudit composant fonctionnel, ledit troisième test d’exécution comportant la mise en œuvre de la troisième fonction de pilotage de l’entrée et/ou de la sortie d’au moins une ressource matérielle, ledit système comportant une mémoire pour enregistrer des données propres à des évènements produits par la ressource matérielle pilotée lors du troisième test. Selon un mode de réalisation, le système de test comprend : Un module de gestion d’anomalies configuré pour exécuter une quatrième fonction de pilotage du redémarrage d’un composant fonctionnel d’au moins une ressource matérielle du premier ou du second ensemble de ressources matérielles ou du second ensemble sélectionné, et dans lequel la console d’exploitation comporte un actionneur pour lancer un quatrième test d’exécution dudit composant fonctionnel, ledit quatrième test d’exécution comportant une mise en œuvre de la quatrième fonction de pilotage de l’alimentation d’au moins d’une ressource matérielle du deuxième ensemble, ledit système comportant une interface pour recevoir ou une mémoire pour enregistrer des données propres à des évènements produits par la ressource matérielle pilotée lors du quatrième test. Selon un mode de réalisation, le système de test comprend : Un module de gestion d’anomalies configuré pour exécuter une cinquième fonction de pilotage d’un mode sans échec pour le pilotage du redéploiement d’un composant fonctionnel sur au moins une ressource matérielle du second ensemble de ressources matérielles, ledit module de gestion d’anomalies ayant détecté au préalable une erreur sur la ressource matérielle lors de l’exécution d’au moins un composant fonctionnel ; la console d’exploitation comportant un actionneur pour lancer un mode sans échec de ladite ressource matérielle , ledit mode sans échec comportant une mise en œuvre de la cinquième fonction de pilotage d’un mode sans échec d’un composant fonctionnel d’au moins une ressource matérielle du deuxième ensemble, ledit système engageant le transfert d’une nouvelle configuration sur ladite ressource matérielle associée. Un avantage de l’invention est de permettre de réaliser des tests d’une fonction logicielle comportant différents composants logiciels destinés à être exécutés sur différentes ressources matérielles grâce à un environnement matériel fidèle au cas de déploiement réel tout en intégrant une configuration complexe de déploiement au sein d’une architecture matérielle hétérogène. L’invention permet donc de réduire le nombre d’erreurs d’intégration matérielles et logicielles et leur complexité lors de la mise en production d’une solution logicielle. Selon un mode de réalisation, le système de test comprend une mémoire pour enregistrer des données propres à des évènements produits par ladite ressource matérielle redémarrée lors ou consécutivement au lancement d’au moins un test d’exécution. Selon un mode de réalisation, au moins un composant fonctionnel a une fréquence de fonctionnement associée. Selon un mode de réalisation, le système de test comprend une mémoire comportant des données représentant un graphe de dépendance des composants fonctionnel, ledit graphe de dépendance définissant des interactions possibles entre les composants fonctionnels. Selon un mode de réalisation, le système de test comprend une mémoire comportant des données définissant une fréquence de fonctionnement globale de la fonction logicielle. Selon un mode de réalisation, le système de test comporte un microprogramme configuré pour collecter les données émises par une ressource matérielle, les dites données comportant des données utiles et des données d’entête, lesdites données d’entête étant décodées par le microprogramme et réencodées pour intégrer des données d’adressage afin de réadresser des données utiles vers une autre ressource matérielle. Selon un mode de réalisation, la console d’exploitation comprend une interface utilisateur et connectée audit premier calculateur pour : déterminer au moins une contrainte globale de fonctionnement de la fonction logicielle ; déterminer un ensemble de contraintes locales de fonctionnement entre au moins un sous-ensemble de composants fonctionnels, alimenter, via le module de gestion d’une alimentation électrique, les ressources matérielles du deuxième ensemble. Selon un mode de réalisation, le premier calculateur est configuré pour analyser les données enregistrées ou reçues propres aux évènements produits par chaque ressource matérielle lors de l’exécution d’au moins un test d’exécution, le premier calculateur générant une notification d’erreur lorsque l’analyse détecte une séquence d’évènements non conforme vis-à-vis d’une séquence de référence. Selon un mode de réalisation, la console d’exploitation comprend un module pour déterminer un protocole de communication entre deux composants fonctionnels, ledit système de test comportant une mémoire pour enregistrer des données échangées au moyen d’une interface de communication entre deux ressources matérielles adressées lors de l’étape d’association, le calculateur étant configuré pour analyser une présence d’ entêtes et de données structurant des paquets de données dudit protocole de communication pour établir un diagnostic de communication entre lesdits deux composants fonctionnels. Selon un mode de réalisation, la console d’exploitation comprend un afficheur, et dans lequel le calculateur est configuré pour générer une commande d’affichage d’un menu de paramétrage sur ledit afficheur, ledit menu de paramétrage permettant, au moyen d’au moins une commande utilisateur, de : sélectionner au moins une fréquence de fonctionnement pour au moins un composant fonctionnel ; paramétrer la contrainte globale de fonctionnement et les contraintes locales de fonctionnement ; paramétrer au moins une ressource matérielle du deuxième ensemble (ENS 2 ), définir des paramètres d’entrée/sortie pour au moins un composant fonctionnel. Selon un mode de réalisation, la contrainte globale de fonctionnement comprend un temps d’exécution de la fonction logicielle entre un premier évènement correspondant au lancement du premier test d’exécution et un deuxième évènement correspondant à une exécution de ladite fonction logicielle, la contrainte globale de fonctionnement imposant que ledit temps d’exécution de la fonction logicielle soit inférieur à une valeur seuil prédéterminée. Selon un mode de réalisation, la contrainte globale de fonctionnement comprends une consommation d’une ressource de calcul globale de l’ensemble des ressources matérielles du deuxième ensemble, la contrainte globale de fonctionnement imposant que la consommation de ressource de calcul d’une ressource matérielle par un composant fonctionnel qui lui est associé soit inférieure à un pourcentage prédéterminé de ladite ressource de calcul globale de l’ensemble des ressources matérielles du deuxième ensemble. Selon un mode de réalisation, la contrainte globale de fonctionnement est déterminée automatiquement par le premier calculateur à partir de l’ensemble des contraintes locales de fonctionnement et à partir du graphe de dépendance. Selon un mode de réalisation, le premier calculateur est apte à : mettre en œuvre une étape de compilation d’au moins un composant fonctionnel pour le rendre compatible de la ressource matérielle qui lui est associée, ladite compilation étant réalisée dans un environnement de compilation adapté à ladite ressource matérielle associée audit composant fonctionnel. Selon un autre aspect, l’invention concerne un procédé de déploiement ou de test d’au moins un composant fonctionnel d’une fonction logicielle, ledit procédé comprenant : association (ASS), par le calculateur, de chaque composant fonctionnel à au moins une ressource matérielle d’un ensemble de ressources matérielles, ladite association comportant un adressage (ADR) de chaque ressource matérielle de l’ensemble de ressources matérielles pour : paramétrer chaque ressource matérielle en fonction du composant fonctionnel qui lui est associée ; transmettre des données propres à chaque composant fonctionnel à chaque ressource matérielle ; alimentation, par un module de gestion d’une alimentation électrique, de l’ensemble de ressources matérielles ; mise en œuvre, en réponse à l’actionnement d’un actionneur de la console d’exploitation, d’un déploiement ou d’un test d’exécution d’au moins un composant fonctionnel, le procédé comportant une réception de données propres à des évènements produits par ladite au moins une ressource matérielle au sein de laquelle est déployée ou testée le composant logiciel ou la ressource matérielle. Selon un mode de réalisation le procédé de test d’au moins un composant fonctionnel d’une fonction logicielle, comprend : détermination par un calculateur connecté à une console d’exploitation, d’une contrainte globale de fonctionnement d’une fonction logicielle ; détermination, par le calculateur, d’un ensemble de contraintes locales de fonctionnement entre au moins un sous-ensemble d’un ensemble de composants fonctionnels exécutant la fonction logicielle ; association (ASS), par le calculateur, de chaque composant fonctionnel à au moins une ressource matérielle d’un ensemble de ressources matérielles, ladite association comportant un adressage (ADR) de chaque ressource matérielle de l’ensemble de ressources matérielles pour : paramétrer chaque ressource matérielle en fonction du composant fonctionnel qui lui est associée ; transmettre des données propres à chaque composant fonctionnel à chaque ressource matérielle ; alimentation, par un module de gestion d’une alimentation électrique, de l’ensemble de ressources matérielles ; mise en œuvre, en réponse à l’actionnement d’un actionneur de la console d’exploitation, d’un premier test d’exécution d’au moins un composant fonctionnel, ledit premier test d’exécution comportant une mise en œuvre d’une première fonction de redémarrage automatique d’au moins une ressource matérielle de l’ensemble de ressources matérielles ; enregistrement dans une mémoire de de données relatives à des évènements produits par ladite ressource matérielle redémarrée lors du premier test d’exécution. Selon un autre aspect, l’invention concerne un produit programme d’ordinateur comportant des instructions qui, lorsque le programme est exécuté par le système de test de l’invention, conduisent celui-ci à mettre en œuvre les étapes du procédé de l’invention. Un avantage de l’invention est d’utiliser les mémoires natives des ressources matérielles ce qui permet d’être représentatif des conditions réelles d’utilisation. Brève description des figures D’autres caractéristiques et avantages de l’invention ressortiront à la lecture de la description détaillée qui suit, en référence aux figures annexées qui illustrent : : Une représentation schématique du système de test dans une configuration dans laquelle il comprend six ressources matérielles connectées à un réseau de données. : Une représentation schématique de l’étape de sélection d’un deuxième ensemble de ressources matérielles dans le premier ensemble de ressources matérielles. : Une représentation schématique des communications entre les ressources matérielles du deuxième ensemble avec le calculateur, le module de gestion de l’alimentation et la carte d’interface de communication, dans un mode de réalisation dans lequel le calculateur comprend le module de gestion d’anomalies. : Une représentation schématique de l’étape de détermination d’une contrainte globale de fonctionnement. : Une représentation schématique de l’étape de détermination de contraintes locales de fonctionnement entre les ressources matérielles du deuxième ensemble. Une représentation schématique de l’étape d’association de composants fonctionnels avec les ressources matérielles du deuxième ensemble, dans un mode de réalisation dans lequel un unique composant fonctionnel est associé à chaque ressource matérielle. : Une représentation schématique de l’étape de détermination de la contrainte globale de fonctionnement, dans un mode de réalisation dans lequel elle est déterminée à partir du graphe de dépendance et à partir d’un ensemble de contraintes locales de fonctionnement entre les composants fonctionnels. : Une représentation schématique de différentes étapes mises en œuvre par la console d’exploitation connectée au calculateur. : Une représentation schématique d’une configuration matérielle du système de test de l’invention. Description de l’invention Selon un premier aspect, l’invention concerne un système de test S t d’au moins un composant fonctionnel CF n d’une fonction logicielle LOG 1 . L’ensemble des caractéristiques décrites ci-après peuvent aussi bien être rattaché au système de l’invention qu’au procédé de l’invention. Toutefois, l’invention est décrite au regard du système de test et/ou de déploiement sans que cela soit limitatif à l’objet relatif au système. Cette description est également entendue comme une description du procédé de test et ou de déploiement. On entend par un « système de déploiement et/ou test », un système de test d’un logiciel et/ou un système de déploiement d’un logiciel sur une plateforme comportant un ensemble de ressources matériels accessible depuis un réseau de données. Dans la suite de la description on nommera un tel système, un système de test. Cette nomination est également vraie pour le procédé de test de l’invention qui peut être entendu comme un procédé de déploiement. Les ressources matérielles peuvent selon un cas de figures colocalisées dans un même site et accessible depuis un ou plusieurs serveur(s) de données. Selon un autre exemple de réalisation, certaines ressources matérielles peuvent être agencées en différents sites. Les différents sites peuvent être adressage depuis un ou plusieurs serveurs de données. Dans les modes de réalisation comportant de fortes contraintes temps réels ou des temps d’exécution devant être courts, on préféra une configuration dans laquelle les différentes ressources matérielles sont situées sur le même site. Un des avantages de l’invention est de permettre de tester ensemble une configuration logicielle destinées à fonctionner avec un ensemble de ressource en configurant à distance un ensemble de ressource matérielle. Ainsi l’invention prend la forme d’une plateforme modulaire de ressource matérielle adressable pour configurer un ensemble de composants fonctionnels. Fonction logicielle On définit une « fonction logicielle » comme un code exécutable par un ensemble de matériels pour mettre en œuvre une fonction donnée. Par exemple, dans le domaine de l’automobile, il peut s’agir d’une fonction de freinage d’urgence en réponse à la détection d’un piéton. Composants fonctionnels Le système de test S t comprend un premier ensemble de composants fonctionnels CF n . Les composants fonctionnels CF n sont configurés pour exécuter la fonction logicielle LOG 1 . En d’autres termes, les composants fonctionnels CF n correspondent à des « fragments » de la fonction logicielle LOG 1 . Selon un mode de réalisation, ces composants fonctionnels ont chacun des paramètres associés, tels qu’une fréquence de fonctionnement F i , ou encore un temps d’exécution. Ressources matérielles Le système de test S t comprend un premier ensemble ENS 1 de ressources matérielles RM n . On entend par « ressource matérielle » un matériel physique paramétrable comprenant un calculateur intégré apte à exécuter un code. Il s’agit par exemple d’un processeur ou d’un microprocesseur. La illustre un mode de réalisation dans lequel le système comprend un premier ensemble ENS 1 de six ressources matérielles RM 1 , RM 2 , RM 3 , RM 4 , RM 5 , RM 6 . Les ressources matérielles RM n comprennent chacune au moins une entrée et une sortie. Chaque entrée et chaque sortie de chaque ressources matérielle RM n définissent des interfaces d’échange de données. Optionnellement, au moins une ressource matérielle RM n comprend une pluralité d’entrées/sorties. Le premier ensemble ENS 1 de ressources matérielles RM n est connecté à un réseau de données NET par l’intermédiaire d’une première interface de communication. La première interface de communication comprend par exemple une carte réseau, telle qu’une carte Ethernet ou une carte WiFi. Carte d’interface de communication Le système de test S t comprend un dispositif d’interface de communication COM 1 . Dans un mode de réalisation, ce dispositif est une carte électronique définissant ainsi une carte d’interface de communication. On entend par « une carte d’interface de communication » une carte permettant de configurer des liens physiques entre l’entrée et la sortie des ressources matérielles RM n . Selon un mode de réalisation, le dispositif d’interface de communication est une mémoire. Dans ce cas, une ressource peut enregistrer des données qui sont lues par une autre ressource de manière à échanger des données entre elles. Selon un autre mode de réalisation, le dispositif est un bus de données par exemple sur lequel est échangé des informations. Le bus de données peut être lu ou être inscrit par différentes ressources matérielles ayant un accès à ce dernier. Selon un mode de réalisation, le dispositif d’interface de communication COM 1 est intégré au sein d’un ressource matérielle sélectionnée. Ce cas est avantageux lorsqu’un faible nombre de ressources matérielles est sélectionné, par exemple deux cartes électroniques qui comporterait des interfaces de communication leur permettant de communiquer directement. Optionnellement, la carte d’interface de communication COM 1 comprend la première interface de communication. La carte d’interface de communication COM 1 comprend par exemple une carte réseau. Optionnellement, la carte d’interface de communication COM 1 permet de configurer au moins une ressource matérielle RM n pour configurer une capacité de calcul maximale à exploiter lors de l’exécution d’un composant fonctionnel CF n . Un avantage est de permettre l’exécution des composants fonctionnels CF n sur les ressources matérielles RM n . Mémoire Le système de test S t comprend une mémoire. La mémoire comporte des données représentant un graphe de dépendance GRD 1 entre les composants fonctionnels CF n . On entend par « graphe de dépendance » un graphe définissant des interactions possibles, tels que des échanges d’informations, entre les composants fonctionnels CF n via des liens logiques, et définissant une fréquence de fonctionnement globale de la fonction logicielle LOG 1 . Premier calculateur Le système de test S t comprend un premier calculateur CLC 1 . Le premier calculateur CLC 1 est configuré pour générer et déployer une configuration matérielle d’au moins une ressource matérielle RM n . Par exemple, pour une ressource matérielle comprenant un microprocesseur, la configuration déployée comporte le ou les logiciel(s) définissant le système d'exploitation, également appelé « kernel » et le ou les logiciels définissant le système de fichier(s) comprenant le code exécutable du composant fonctionnel qui doit s'exécuter sur la ressource matérielle. Dans le cas d’un FPGA, la configuration déployée peut comprendre un Firmware. Dans le cas d'un microcontrôleur, la configuration peut comprendre le code de la mémoire ROM comprenant le code système et le code applicatif. On rappelle qu’un « Firmware » est un micrologiciel, microprogramme, un microcode, un logiciel interne ou encore un logiciel embarqué d’une ressource matérielle. Il est généralement intégré dans un matériel informatique pour qu'il puisse fonctionner. Dans certain cas, une ressource matérielle peut avoir un « Firmware », dans d’autres il n’en comprend pas. Selon un mode de réalisation, la configuration peut comprendre le la structure de compilation croisée entre les différents composants logiciels, également appelé dans la terminologie anglosaxonne « cross compilation framework ». Il peut prendre la forme d’un code exécutable pour le mettre dans l’image définissant la configuration à transférer. Selon un exemple, la configuration peut comprendre le code source qui est transférée sur la ressource matérielle et la compilation peut être réalisée au sein de la ressource matérielle. Selon autre exemple, la compilation est réalisée en amont et le code compilé est transféré au sein de la ressource matérielle. Afin de générer et déployer une configuration matérielle, selon un mode de réalisation le calculateur récupère l’ensemble des codes sources de chaque composant fonctionnel et le cas échéant les librairies nécessaires au fonctionnement de chaque composant fonctionnel. Le calculateur peut dans ce dernier cas transmettre le code à compiler ou compilé préalablement avec les librairies à chaque ressource matérielle adressée. Selon un mode de réalisation, le premier calculateur CLC 1 est configuré pour mettre en œuvre une étape de compilation CMP d’au moins un composant fonctionnel CF n pour le rendre compatible d’au moins une ressource matérielle RM n . La génération d’une configuration comprend par exemple la compilation des codes de chaque composant fonctionnel. Selon un mode de réalisation, la génération comprend la création et/ou la compilation des dépendances de chaque composant fonctionnel avec d’autres composants logiciels et/ou avec des ressources matérielles et/ou des librairies et/ou des interfaces de communications. Selon un mode de réalisation, la génération comprend également la compilation du système d’exploitation de au moins une ressource matérielle. Avantageusement, les compilations sont réalisées sur le calculateur et sont transmises ensuite sur chaque cible matérielle. Le déploiement comprend la transmission des codes compilés et des dépendances sur les cibles matérielles accessibles depuis un serveur distant. Les composants logiciels sont installés dans des mémoires de chaque ressource matérielle afin d’être démarrés et exécutés. Pour chaque ressource matérielle, selon un mode de réalisation, le déploiement comprend le transfert d’un ensemble de fichiers sur chaque ressource matérielle par exemple le transfert de 1, 2, 3 fichier(s), voire jusqu’à 15 fichiers, voire plus selon certains cas complexes de déploiement. Les fichiers générés après la compilation grâce au calculateur sont transmis aux ressources matérielles en fonction de l’opération d’association des composants logiciels avec les ressources matérielles qui a été faite à partir de la console d’exploitation. Selon un exemple de réalisation, le déploiement comprend la transmission d’au moins un fichier de démarrage automatique tel qu’un chargeur d'amorçage, ou plus connu sous la terminologie de « bootloader » dans la terminologie anglosaxonne. Ce chargeur d’amorçage peut prendre la forme d’un logiciel permettant de lancer un ou plusieurs programmes ou systèmes d'exploitation. Selon un autre exemple, le déploiement comprend la copie d’un fichier produit/généré par le calculateur sur une mémoire d’une ressource matérielle. Selon un exemple de réalisation, un fichier de configuration, qui peut être inclus dans le graph de dépendance, peut comprendre les opérations de transfert ou de déploiement en fonction du composant fonctionnel, c’est-à-dire l’ensemble des opérations à réaliser sur chaque ressource matérielle. Selon un mode de réalisation, le déploiement comprend un transfert d’un microprogramme ou d’un micrologiciel, encore appelé « Middleware » dans la terminologie anglosaxonne dans une mémoire d’une ressource matérielle. Un tel fichier de codes permet notamment aux différentes données de chaque entrée/sortie de chaque ressource matérielle de pouvoir être interprétées selon différentes couches OSI pour être exploitées ensuite. Le Middleware peut être notamment installé sur le dispositif d’interface de communication COM 1 . Selon un mode de réalisation, l’opération de déploiement comprend la mise en œuvre d’une vérification automatique d’un paramétrage de chaque fichier représentant tout ou partie d’un composant fonctionnel sur leur ressource matérielle afin de vérifier qu’ils peuvent être effectivement utilisés par ladite ressource matérielle. Le déploiement peut comprendre la suppression d’une précédente installation, c’est-à-dire la suppression de fichiers déjà présents et correspondant à une précédente version d’au moins un composant fonctionnel installé sur une ressource matérielle ou d’une librairie déjà présente ou encore d’un système de fichiers d’un système d’exploitation de la ressource matérielle Module de gestion d’alimentation électrique Le système de test S t comprend un module de gestion d’une alimentation électrique ALIM 1 de l’ensemble de ressources matérielles RM n . Optionnellement, le premier calculateur CLC 1 comprend le module de gestion d’une alimentation électrique ALIM 1 . Selon un exemple de réalisation, le module de gestion d’alimentation électrique permet de couper une alimentation d’une ressource matérielle donnée pendant un laps de temps donné. Selon un autre exemple, le module de gestion d’alimentation électrique permet de générer des microcoupures. Module de gestion d’anomalies Le système de test S t comprend un module de gestion d’anomalies M A . Le module de gestion d’anomalies M A peut être configuré pour d’une part piloter le lancement d’un test d’une ressource matérielle ou d’un ensemble de ressources matérielles comportant le ou les composant(s) fonctionnel(s) déployé(s) sur chaque ressource matérielle et d’autre part récupérer les données produites par les différentes entités matérielles et logicielles à l’issue du test. Le module de gestion d’anomalies peut comprendre une gestion des anomalies matérielles ou logicielles ou les deux. Selon un exemple, le module de gestion d’anomalies est configuré pour mettre en œuvre une première fonction F 1 de redémarrage automatique d’au moins une ressource matérielle RM n . La première fonction F 1 de redémarrage automatique d’une ressource matérielle RM n est par exemple mise en œuvre consécutivement à l’exécution d’un test de la fonction logicielle LOG 1 par le système de test St. La première fonction F 1 est par exemple mise en œuvre en cas d’inexécution totale ou partielle de la fonction logicielle LOG 1 . La première fonction F 1 de redémarrage automatique est par exemple mise en œuvre suite à un problème d’exécution d’un ou plusieurs composants fonctionnels CF n sur une ou plusieurs ressources matérielles RM n . Optionnellement, le module de gestion d’anomalies M A est configuré pour mettre en œuvre une deuxième fonction F 2 de pilotage de l’alimentation d’au moins une ressource matérielle RM n . Optionnellement, le module de gestion d’anomalies M A est configuré pour mettre en œuvre une troisième fonction F 3 de pilotage des entrées/sorties d’au moins une ressource matérielle RM n . Le pilotage des entrées/sorties d’une ressource matérielle RM n permet par exemple de modifier une valeur d’au moins une entrée ou d’une sortie de ladite ressource matérielle. Selon un mode de réalisation, l’invention comprend la mise en œuvre d’une quatrième fonction F 4 qui peut être lancée depuis la console d’exploitation par un quatrième test T E4 . Le quatrième test T E4 consiste à redémarrer une fonction sans avoir à redémarrer la ressource matérielle. A cette fin le module de gestion d’anomalies permet de lancer éventuellement le test et de recueillir les données issues du test. La quatrième fonction F 4 peut donc être engagée sur un composant logiciel ou une pluralité de composants logiciels. Le système de l’invention permet de prendre en compte l’ensemble des données produites par chaque ressource matérielle et chaque composant fonctionnel après le lancement du quatrième test T E4 . Selon un mode de réalisation, le module de gestion d’anomalies M A est configuré pour exécuter une cinquième fonction F 5 de pilotage d’un mode sans échec pour le pilotage du redéploiement d’un composant fonctionnel CLF sur au moins une ressource matérielle RM n du second ensemble ENS 2 de ressources matérielles RM n . Selon un exemple, préalablement au lancement de la cinquième fonction F 5 , le module de gestion d’anomalies M A détecte au préalable une erreur sur la ressource matérielle RM n lors de l’exécution d’au moins un composant fonctionnel CF n . Le lancement de la cinquième fonction peut être automatique ou manuel suite à l’erreur détectée. A cette fin, la console d’exploitation E xp comporte un actionneur pour lancer un mode sans échec de ladite ressource matérielle du deuxième ensemble ENS 2 . Le mode sans échec permet notamment d’engager le transfert d’une nouvelle configuration sur ladite ressource matérielle associée. La illustre un mode de réalisation dans lequel trois ressources matérielles sont connectées à la fois au premier calculateur CLC 1 , au module de gestion de l’alimentation ALIM 1 et à la carte d’interface de communication COM 1 , et dans lequel le premier calculateur CLC 1 comprend le module de gestion d’anomalies M A . Console d’exploitation : sélection des ressources matérielles Le module de test S t comprend une console d’exploitation E XP . La console d’exploitation E XP comprend une interface utilisateur INT 1 et est connectée au premier calculateur CLC 1 pour sélectionner SEL 1 un deuxième ensemble ENS 2 de ressources matérielles RM n parmi le premier ensemble ENS 1 de ressources matérielles RM n . Le deuxième ensemble ENS 2 est par exemple un sous-ensemble du premier ensemble ENS 1 . Selon un autre exemple, il s’agit du même ensemble. La illustre un mode de réalisation dans lequel un sous-ensemble ENS 2 de trois ressources matérielles RM 1 , RM 2 , RM 6 est sélectionné parmi un premier ensemble de ressources matérielles RM n . Console d’exploitation : définition des contraintes de fonctionnement La console d’exploitation E XP comprend une interface utilisateur INT 1 et est connectée au premier calculateur CLC 1 pour déterminer DET 1 au moins une contrainte globale de fonctionnement Cgf de la fonction logicielle LOG 1 , comme illustré en . La contrainte globale de fonctionnement Cgf est par exemple périodique. La console d’exploitation E XP comprend une interface utilisateur INT 1 et est connectée au premier calculateur CLC 1 pour déterminer DET 2 un ensemble de contraintes locales de fonctionnement Clf n entre au moins un sous ensemble de composants fonctionnels CF n , comme illustré en . Le deuxième ensemble de ressources matérielles RM n est par exemple sélectionné SEL 1 en fonction des différents composants fonctionnels CF n nécessaires à l’exécution de la première fonction logicielle LOG 1 , ou encore de contraintes intrinsèques à ces derniers ou à leurs interactions, par exemple les contraintes locales de fonctionnement Clf n . Le deuxième ensemble de ressources matérielles RM n peut également être sélectionné SEL 1 en fonction d’une contrainte globale de fonctionnement Cgf du système de test S t. Les contraintes globales et locales de fonctionnement Cgf, Clf n comprennent par exemple des contraintes de latence, des contraintes temporelles (par exemple un temps d’exécution maximum d’un composant fonctionnel), ou encore des contraintes relatives à la puissance de calcul utilisée par un composant fonctionnel. Un exemple d’une contrainte locale de fonctionnement Clf n est qu’un composant fonctionnel CF n donné ne consomme par plus d’un pourcentage donné de la puissance de calcul d’une ressource matérielle RM n sur laquelle il est exécuté. Un exemple d’une contrainte globale de fonctionnement Cgf est que l’ensemble des composant fonctionnels CF n qui exécutent la fonction logicielle LOG 1 ne consomment pas plus d’un pourcentage donné de la puissance de calcul maximale du système de test S t . Cette puissance de calcul maximale du système de test S t correspond par exemple à la puissance de calcul du deuxième ensemble ENS 2 de ressources matérielles RM n . Optionnellement, la contrainte globale de fonctionnement C lf comprend un temps d’exécution de la fonction logicielle LOG 1 entre deux évènements donnés. Un premier évènement correspond par exemple à un actionnement d’un actionneur par un utilisateur pour lancer un test d’exécution de la fonction logicielle LOG 1 . Un deuxième évènement correspond par exemple à l’exécution complète de ladite fonction logicielle LOG 1 par le système de test S t . Le temps d’exécution est par exemple comparé ensuite avec une valeur seuil, par exemple prédéterminée, pour définir au moins partiellement la contrainte globale de fonctionnement Cgf. La contrainte globale de fonctionnement Cgf impose par exemple que le temps d’exécution de la fonction logicielle LOG 1 soit inférieure à la valeur seuil prédéterminée. Pour illustrer ce mode de réalisation, on se place dans un cas de simulation d’un freinage d’urgence d’un véhicule automobile. Dans cet exemple, le premier évènement correspond à la capture d’une image comprenant un piéton ou un obstacle sur la trajectoire du véhicule au moyen d’un capteur, par exemple une caméra, et le deuxième évènement correspond à l’émission de la commande de freinage automatique du véhicule. Dans cet exemple, la contrainte globale de fonctionnement Cgf impose que le temps d’exécution de la fonction logicielle LOG 1 soit inférieure à 100 millisecondes. Optionnellement, la contrainte globale de fonctionnement Cgf comprend une contrainte sur la consommation d’une ressource de calcul globale de l’ensemble de ressource matérielles RM n du deuxième ensemble. Par exemple, la contrainte globale de fonctionnement Cgf impose que l’exécution de la fonction logicielle LOG 1 ne consomme par plus d’un pourcentage donné de la ressource de calcul totale de l’ensemble des ressources matérielles RM n du système de test S t . Selon un autre exemple, la contrainte globale de fonctionnement Cgf impose que l’exécution des composant fonctionnels CF n ne consomment par plus d’un pourcentage prédéterminé de chaque ressource matérielle RM n auxquelles ils sont associés. Optionnellement, la contrainte globale de fonctionnement Cgf est déterminée automatiquement par le premier calculateur CLC 1 à partir des contraintes locales de fonctionnement Clf entre plusieurs composants fonctionnels CF n et à partir d’un graphe de dépendance entre lesdits composants fonctionnels CF n , comme illustré en . Un intérêt du procédé de l’invention est de permettre de mesurer les paramètres d’exécution des composants fonctionnels dans leur environnement matériel de manière à les comparer aux contraintes qui sont définies. Ainsi, le système comprend une horloge et un calculateur pour mesurer des intervalles de temps entre des messages ou des notifications ou des commandes de sorte générer des indicateurs de conformité à aux contraintes. Avantageusement, le système de test utilise le système de fichier(s) natif(s) et/ou la mémoire de la ressource matérielle. Ceci est entre autres rendu possible grâce au module de gestion d’anomalies pour ne pas avoir à manipuler la ou les ressource(s) matérielle(s) manuellement mais uniquement de manière automatique. Console d’exploitation : Commande utilisateur Les étapes mises en œuvre au moyen de la console d’exploitation E XP sont par exemple mises en œuvre au moyen d’au moins une commande utilisateur. La commande utilisateur comprend par exemple une commande en interaction avec un périphérique d’entrée, par exemple une souris, un clavier, ou un bouton poussoir dans le cas d’une commande digitale, un microphone dans le cas d’une commande vocale, ou encore un écran de la console d’exploitation E XP dans le cas d’une commande tactile. Console d’exploitation : association des composants fonctionnels et des ressources matérielles La console d’exploitation E XP comprend une interface utilisateur INT 1 et est connectée au premier calculateur CLC 1 pour associer ASS chaque composant fonctionnel CF n à au moins une ressource matérielle RM n du deuxième ensemble ENS 2 , comme illustré en . Selon un mode de réalisation, l’association ASS permet de générer automatiquement un adressage de chaque ressource matérielle RM n du deuxième ensemble ENS 2 . Cet adressage peut être réalisé automatiquement à partir du calculateur CLC 1 et des données contenues dans les fichiers à transmettre à chaque ressource matérielle. On entend par « adresser une ressource matérielle » le fait de charger un code exécutable définissant le composant fonctionnel CF n sur la ressource matérielle RM n à une adresse ressource mémoire par exemple au travers d’une interface de communication de ladite ressource matérielle. L’adressage ADR comprend par exemple le paramétrage de chaque ressource matérielle RM n en fonction du composant fonctionnel qui lui est associé. Par exemple la connaissance des autres ressources et le/les moyens de communiquer avec peut être défini lors de cette association. Il peut s’agir des liens de communication physique et/ou des liens de communication logicielle telles que ceux avec le microprogramme défini par le middleware ou encore des API de communication, API désignant « Applicative programme interface ». L’adressage peut comprendre l’association des adresses physiques des ressources, c’est-à-dire des adresses physiques des interfaces de communication de chaque ressource, telle que l’adresse mac, ou encore des adresses réseaux telles que des ports ou des adresses IP de ces interfaces de communication de chaque ressource matérielle. Un autre exemple, est l'installation dans les ressources matérielles RMn des librairies logicielles nécessaires au bon fonctionnement des composants logiciels CFn. Selon un autre exemple, les noms d’hôte, les données protocolaires, ou les données permettant de structurer des données selon les différentes couches OSI peuvent être automatiquement organisées par le calculateur selon l’association réalisée entre le composant fonctionnel et la ressource matérielle. Selon un exemple, le calculateur séquence les données à transmettre selon une règle prédéfinie en fonction de l’association réalisée. Le calculateur peut adresser une ressource matérielle en réalisant une copie de fichiers et engageant un redémarrage de la ressource matérielle ou encore un redémarrage du composant fonctionnel uniquement. Selon un exemple, l’ensemble des ressources matérielles est redémarré après l’association et l’adressage d’un composant fonctionnel vers une ressource matérielle. Optionnellement, l’association ASS comprend l’association d’un composant fonctionnel CF n à une pluralité de ressources matérielles RM n . Dans ce cas, le système de test S t est par exemple paramétré de sorte qu’une première portion du code d’un composant fonctionnel CF n donné soit exécuté sur une première ressource matérielle RM n et qu’une seconde portion du code soit exécutée sur une autre ressource matérielle RM n . Optionnellement, l’association ASS comprend l’association d’une pluralité de composants fonctionnels CF n à une ressource matérielle RM n . Optionnellement, l’association ASS comprend la compilation CMP d’au moins un composant fonctionnel CF n pour le rendre compatible d’au moins une ressource matérielle RM n du deuxième ensemble ENS 2 . En effet, chaque ressource matérielle RM n dispose par exemple de son propre système d’exploitation, et le code exécutable doit donc être compilé dans un environnement de compilation adapté pour le rendre compatible du système d’exploitation de la ressource matérielle RM n . L’association ASS comprends la transmission, à chaque ressource matérielle, de données propres à chaque composant fonctionnel CF n . Il s’agit par exemple d’une fréquence de fonctionnement, d’un langage d’un code à exécuter, d’une taille d’un code à exécuter, du code lui-même, des moyens de le compiler ou encore des librairies logicielles nécessaires à la bonne exécution du code. Console d’exploitation : alimentation électrique des ressources matérielles La console d’exploitation E XP comprend une interface utilisateur INT 1 et est connectée au premier calculateur CLC 1 pour alimenter ALI, via le module de gestion d’une alimentation électrique ALIM 1 , les ressources matérielles du deuxième ensemble ENS 2 . Console d’exploitation : premier test d’exécution La console d’exploitation E XP comporte un actionneur pour lancer un premier test d’exécution T E1 d’au moins un composant fonctionnel CF n . L’objectif du premier test d’exécution T E1 est de vérifier l’exécution dudit composant fonctionnel CF n sur la ou les ressources matérielles auxquelles il est associé, tout en respectant les contraintes locales et globales de fonctionnement Clf, Cgf qui ont été définies. Le premier test d’exécution T E1 comporte la mise en œuvre de la première fonction F 1 de redémarrage automatique d’au moins une ressource matérielle RM n du deuxième ensemble ENS 2 . La première fonction F 1 est par exemple mise en œuvre en cas d’échec au moins partiel de l’exécution dudit composant fonctionnel CF n . Il peut s’agir par exemple d’un problème de compilation du composant fonctionnel CF n , ou encore d’un problème dû à la définition de contraintes locales de fonctionnement Clf incompatibles entre elles, ou incompatibles de la contrainte globale de fonction Cgf. Il peut également s’agir d’un problème matériel sur la ressource matérielle, par exemple une carte défectueuse ou un problème de communication entre plusieurs cartes, ou encore d’un problème d’association, par exemple un composant fonctionnel CF n associé à une ressource matérielle RM n ne disposant pas d’une puissance de calcul suffisante pour exécuter le code. Selon un mode de réalisation, le système de test S t comporte en outre une mémoire pour enregistrer des données propres à des évènements produits par la ressource matérielle RM n redémarrée lors du premier test d’exécution T E1 . Selon un autre mode de réalisation, les données sont émises vers une entité distante telle qu’un serveur de données. Il peut s’agir par exemple du serveur hébergeant le logiciel d’exploitation permettant d’afficher une interface de commande et de configuration sur une console d’exploitation. Les données peuvent être consommées en temps réel par un opérateur qui contrôle le contenu des données de tests, les cas d’échec ou d’erreur, l’intégrité des données et la cohérence de fonctionnement du système. Selon un autre exemple, les données propres aux résultats des tests sont affichées directement sur un afficheur du système, voir un afficheur d’un système déporté. Les données ne sont pas nécessairement enregistrées sur une mémoire ou du moins peuvent l’être temporairement. Selon un exemple, les données des tests comprennent des instants auxquels chacun des composants logiciels a reçu et/ou envoyé des données. Ces instants peuvent correspondre à des données horodatées telles que des logs. Selon un autre exemple, les données comprennent un fichier de rapport d’erreur, par exemple lors d’un crash système. Selon un exemple, le test est un test de conformité, on contrôle alors que les données produites lors du ou des tests sont conformes à des données attendues. Selon un exemple, l’invention permet de comparer l’exécution d’un composant fonctionnel avec un model formel. Selon un autre exemple, les données de tests correspondent à des rapports d’utilisation d’une ressource telle qu’une mémoire ou un calculateur. Dans ce dernier cas, le test peut rapporter une valeur relative à un temps CPU. Optionnellement, le premier test d’exécution T E1 comprend la mise en œuvre de la première fonction F 1 de redémarrage automatique, par le premier calculateur CLC 1 , pour redémarrer l’ensemble des ressources matérielles RM n du deuxième ensemble ENS 2 . Dans ce cas, la console d’exploitation E XP comporte par exemple une mémoire pour enregistrer des données propres à des évènements produits par chaque ressource matérielle RM n du deuxième ensemble ENS 2 . Optionnellement, le redémarrage automatique d’au moins une ressource matérielle RM n permet de revenir à un état précédent l’exécution d’un composant fonctionnel sur ladite ressource matériel. Optionnellement, le redémarrage automatique d’au moins un composant fonctionnel CF n permet de recommencer l’exécution de la fonction logicielle. Un avantage de l’invention est de permettre d’effectuer des tests de redémarrage de composants logiciels et des tests de redémarrage de ressources matérielles de manière dissociée ou planifiée de manière à générer une séquence de tests automatique et permettant d’isoler plus facilement une anomalie. Optionnellement, le premier calculateur CLC 1 est configuré pour analyser les données propres aux évènements produits par chaque ressource matérielle RM n redémarrée lors du premier test d’exécution T E1 . Le premier calculateur CLC 1 est par exemple configuré pour générer une notification d’erreur lorsque l’analyse détecte une séquence d’évènements non conforme vis-à-vis d’une séquence de référence. Selon un exemple illustratif, un évènement comprend par exemple une communication entre deux cartes d’une ressource matérielle RM n , par exemple une communication entre une carte mère et une carte graphique d’une ressource matérielle. La carte mère transmet par exemple son identifiant à la carte graphique. Un évènement non conforme vis-à-vis d’une séquence de référence correspond par exemple au cas dans lequel la carte graphique ne parvient pas à décoder totalement l’identifiant de la carte mère. Dans ce cas, le calculateur CLC 1 est par exemple configuré pour générer la notification d’erreur. La notification d’erreur est par exemple une alerte affichée sous forme d’un message d’erreur sur la console d’exploitation, ou encore une alerte sonore. Selon un mode de réalisation, les données de tests recueillis par l’exécution d’un test ou d’un déploiement peuvent être exploitées par une console d’exploitation, par exemple celle ayant permise le déploiement ou le test. L’exploitation des données émises par la ou les ressources matérielles suite au déploiement d’un composant fonctionnel ou suite au lancement d’un test peut être représentées sur un afficheur. Les données peuvent être représentées sous la forme de graphique, de logs, ou encore être enregistrées dans une base de données. Console d’exploitation : deuxième test d’exécution Optionnellement, la console d’exploitation E XP comprend un actionneur pour lancer un deuxième test d’exécution T E2 d’au moins un composant fonctionnel CF n . Il s’agit par exemple du même actionneur que celui permettant de lancer le premier test d’exécution T E1 , ou encore d’un actionneur différent. Le deuxième test d’exécution T E2 comporte la mise en œuvre de la deuxième fonction F 2 de pilotage d’au moins une ressource matérielle RM n . Dans ce cas, le système de test S t comporte par exemple une mémoire pour enregistrer des données propres à des évènements produits par chaque ressource matérielle RM n pilotée lors du deuxième test d’exécution T E2 . Console d’exploitation : troisième test d’exécution Optionnellement, la console d’exploitation E XP comporte un actionneur pour lancer un troisième test d’exécution T E3 d’au moins un composant fonctionnel CF n . Le troisième test d’exécution T E3 comporte la mise en œuvre de la troisième fonction F 3 pour piloter une valeur d’au moins une entrée/sortie d’une ressource matérielle RM n . Le pilotage permet par exemple de modifier la valeur d’une entrée ou d’une sortie de la ressource matérielle RM n . Le système de test S t comporte par exemple une mémoire pour enregistrer des données propres à des évènements produits par chaque ressource matérielle RM n pilotée lors du deuxième test d’exécution T E2 . Optionnellement, la console d’exploitation comprend un actionneur pour exécuter de manière séquentielle le premier test d’exécution T E1 , le deuxième test d’exécution T E2 et le troisième test d’exécution T E3 , comme illustré en . Console d’exploitation : contrôle des communication s Optionnellement, la console d’exploitation E XP comprend un module pour sélectionner ou choisir un protocole de communication entre au moins deux composants fonctionnels CF n . Un tel module permet avantageusement de contrôler le bon déroulement des communications entre plusieurs composants fonctionnels. La sélection peut par exemple être réalisée à partir d’une liste de protocole de communication. Le système de test S t comprend par exemple une mémoire pour échanger des données échangées entre deux ressources matérielles RM n au moyen d’une interface de communication. Le premier calculateur CLC 1 est par exemple configuré pour analyser la présence d’un entête et de données structurant des messages de données échangés entre les ressources matérielles pour établir un diagnostic de communication entre lesdits composants fonctionnels CF n . Console d’exploitation : paramétrage des composants fonctionnels Optionnellement, la console d’exploitation E XP est configurée pour afficher, au moyen du premier calculateur CLC 1 , un menu de paramétrage d’au moins un composant fonctionnel CF n . Le menu de paramétrage permet par exemple à un utilisateur de paramétrer des paramètres d’entrées/sorties telles que des gammes de valeurs, des unités physiques, des fréquences d’entrées/sortie, ou encore un numéro de version du logiciel, un descriptif des instructions logicielles comme un langage de code ou une taille du code. Optionnellement, le menu de paramétrage permet à un utilisateur de paramétrer des contraintes temporelles. Il s’agit par exemple d’un temps de traitement du composant fonctionnel CF n , ou encore d’une charge de calcul par unité de temps consommée par l’exécution dudit composant fonctionnel CF n sur une ressource matérielle RM n . Optionnellement, le menu de paramétrage permet à un utilisateur de sélectionner au moins une fréquence de fonctionnement pour un composant fonctionnel CF n . Des fréquences de fonctionnement différentes peuvent par exemple être paramétrées ou sélectionnées pour chaque composant fonctionnel CF n . Optionnellement, le menu de paramétrage permet à un utilisateur de sélectionner au moins une fréquence de fonctionnement pour la fonction logicielle LOG 1 . Optionnellement, le menu de paramétrage permet à un utilisateur de paramétrer un ensemble de contraintes locales de fonctionnement Clf entre plusieurs composants fonctionnels CF n . Optionnellement, le menu de paramétrage permet à un utilisateur de paramétrer une contrainte globale de fonctionnement de la fonction logicielle LOG 1 . Procédé de test d’un composant fonctionnel Selon un autre aspect, l’invention se rapporte à un procédé de test d’au moins un composant fonctionnel CF n d’une fonction logicielle LOG 1 . Le procédé comprend en outre une première étape de détermination DET 1 , par un calculateur CLC 1 connecté à une console d’exploitation E XP , d’une contrainte globale de fonctionnement de la fonction logicielle LOG 1 . Le procédé comprend en outre une deuxième étape de détermination DET 2 , par le calculateur CLC 1 , d’un ensemble de contraintes locales de fonctionnement Clf entre au moins un sous-ensemble d’un ensemble de composants fonctionnels CF n exécutant ladite fonction logicielle LOG 1 . Le procédé comprend en outre une étape d’association ASS, par le calculateur CLC 1 , de chaque composant fonctionnel CF n à au moins une ressource matérielle RM n d’un ensemble de ressources matérielles RM n , ladite association comprenant un adressage ADR de chaque ressource matériel RM n dudit ensemble, ledit adressage ADR permettant de paramétrer chaque ressource matérielle RM n en fonction du composant fonctionnel CF n qui lui est associé, et ledit adressage permettant de transmettre des données propres à chaque composant fonctionnel CF n à chaque ressource matérielle RM n . Le procédé comprend en outre une étape d’alimentation ALI, par un module de gestion d’une alimentation électrique ALIM 1 , de l’ensemble de ressources matérielles RM n . Le procédé comprend en outre une étape de mise en œuvre d’un premier test d’exécution T E1 en réponse à un actionnement d’un actionneur de la console d’exploitation C EX . Le premier test d’exécution T E1 comprend une mise en œuvre d’une première fonction F 1 de redémarrage automatique d’au moins une ressource matérielle RM n de l’ensemble de ressources matérielles RM n . Le procédé comprend en outre une étape d’enregistrement dans une mémoire de données relatives à des évènements produits par chaque ressource matérielle redémarrée pendant le premier test d’exécution T E1 . Produit programme d’ordinateur Selon un autre aspect, l’invention se rapporte à un produit programme d’ordinateur comprenant des instructions qui, lorsque le programme est exécuté par le système de test de l’invention, conduisent celui-ci à mettre en œuvre les étapes du procédé de test de l’invention. Configuration matérielle La illustre un exemple de configuration matérielle du système de test S t de l’invention. D’un point de vue matériel, le système de test S t peut être vu comme un calculateur interagissant avec un produit programme d’ordinateur. Le système de test S t comprend au moins un ordinateur, par exemple, un micro-ordinateur, un réseau d’ordinateurs, un composant électronique une tablette ou un smartphone. Le système de test S t comprend un module de calcul 110. Le calculateur CLC 1 comprend par exemple le module de calcul 110. Ce module de calcul 110 comprend, par exemple, un ou plusieurs processeur aptes à interpréter des instructions sous forme de programme informatique, une circuit logique programmable, comme un circuit intégré spécifique à une application (ASIC), un réseau de portes programmables in situ (FPGA), un dispositif logique programmable (PLD) et des réseaux logiques programmables (PLA), un système sur puce (SOC), une carte électronique dans laquelle des étapes du procédé selon l’invention sont implémentées dans des éléments matériels. Le traitement peut être exécuté par un processeur, ou de façon simultanée ou séquentielle, ou selon un autre procédé, par un ou plusieurs processeurs. Le module de calcul 110 comprend, un module de traitement de données 111 pour effectuer des calculs, une mémoire 112, couplée opérationnellement au circuit traitement de données 111, un support lisible par ordinateur 114 et éventuellement un lecteur 113 adapté à lire le support lisible par ordinateur 114. Le système de test S t comprend également un dispositif d’entrée, un dispositif de sortie et un dispositif de communication 132. Chaque fonction du système de test S t est exécutée en amenant le module de traitement de données 111 à lire un programme prédéterminé sur un matériel tel que la mémoire 112 de telle sorte que le module de traitement de données 111 exécute des calculs, commande des communications effectuées par le dispositif de communication 132 et à lire et/ou écrire des données dans la mémoire 112 et le support lisible par ordinateur 114. Le procédé est exécuté sur un ordinateur unique ou sur un système distribué entre plusieurs ordinateurs (notamment via l’utilisation de l’informatique en nuage). La mémoire 112 est un support d'enregistrement lisible par ordinateur, et peut être configurée avec, par exemple, au moins l'un des éléments suivants : une mémoire morte (ROM, de l'anglais Read-Only Memory), une mémoire morte effaçable et programmable (EPROM, de l'anglais Erasable Programmable Read-Only Memory), une mémoire morte programmable et effaçable électriquement (ÉEPROM, de l'anglais Electrically Erasable Programmable Read-Only Memory), une mémoire vive (RAM, de l'anglais Random Access Memory) et un autre support de stockage adéquat. La mémoire 112 peut comporter un système d’exploitation et charger les programmes selon l’invention. Elle comporte des registres adaptés à enregistrer des variables de paramètres créés et modifiés eu cours de l’exécution des programmes précités. En variante, les instructions du programme sont issues d’une source externe et téléchargées via un réseau. Cela peut notamment être le cas pour les applications. Dans ce cas, le produit programme d'ordinateur comprend un support de données lisible par ordinateur sur lequel sont stockées les instructions de programme ou un signal de support de données sur lequel sont codées les instructions de programme. Selon un aspect, l’invention se rapporte à un produit programme d’ordinateur comprenant le support lisible par ordinateur 114 contenant des instructions qui, lorsqu'elles sont exécutées par le circuit 110, amènent le système de test S t à mettre en œuvre les étapes du procédé selon l’invention. La forme des instructions de programme est, par exemple, une forme de code source, une forme exécutable par ordinateur ou toute forme intermédiaire entre un code source et une forme exécutable par ordinateur, telle que la forme résultant de la conversion du code source via un interpréteur, un assembleur, un compilateur, un éditeur de liens ou un localisateur de ressource. On nomme un localisateur de ressource par exemple une adresse ou un lien ou un identifiant d’une ressource telle qu’un espace mémoire ou une autre ressource. Cette ressource peut être locale ou distante et peut désigner une ressource sur l’ensemble des couches OSI. On connait à cet effet, les URL, pour « Uniform Resource Locator » qui désigne en français un localisateur uniforme de ressource ou encore les URI pour « Uniform Ressource Identifier » qui signifie en français un identifiant de ressource uniforme. Un intérêt est que les instructions peuvent comprendre des données relatives à l’adressage d’autres ressources sur l’ensemble des couches OSI. Les localisateurs permettent également de supporter différents protocoles dans lesquels les instructions peuvent être intégrées telles que GIT, FTP, SVN, etc. En variante, les instructions de programme sont un microcode, un firmware, des données de définition d’état, des données de configuration pour circuit intégré (par exemple du VHDL) ou un code objet. Les instructions de programme sont écrites dans n’importe quelle combinaison d’un ou de plusieurs langages de programmation, par exemple un langage de programmation orienté objet (C++, JAVA, Python), un langage de programmation procédural (langage C par exemple). Le système de test S t comprend en outre une console d’exploitation E XP comprenant une interface utilisateur INT 1 comprenant dispositif d’entrée 121 et un dispositif de sortie 122. L'interface utilisateur INT 1 comprend un dispositif d'entrée 121 pour permettre à utilisateur de saisir des données ou des commandes de façon à pouvoir interagir avec les programmes selon l’invention. Le dispositif d’entrée 121 comprend, par exemple, un clavier ou un une interface de pointage, tel qu’une souris, un crayon optique, un pavé tactile, une télécommande, un dispositif de reconnaissance vocale, un dispositif haptique. Le dispositif de sortie 122 est conçu pour restituer des informations à un utilisateur, de façon sensorielle ou électrique, comme, par exemple de façon visuelle ou sonore. L’interface de sortie 122 comprend, par exemple, une interface graphique. L’interface de sortie 122 peut être le dispositif d’entrée, par exemple, dans le cas d’une tablette tactile. L’ensemble d’au moins un dispositif de communication 132 permet une communication entre les éléments du système de test S t et éventuellement entre au moins un élément du système et un dispositif extérieur au système S t . Ce dispositif de communication 132 peut établir un lien physique entre des éléments du système de test S t et/ou entre un élément du système de test S t et un dispositif extérieur au système de test S t et/ou un lien en communication à distance (sans fil) entre des éléments du système de test S t et/ou entre un élément du système et un dispositif extérieur au système de test S t . Système de test (S t ) d’au moins un composant fonctionnel (Cf n ) d’une fonction logicielle (LOG 1 ), ledit système de test (S t ) comportant : un premier ensemble (ENS 1 ) de composants fonctionnels (CF n ) configurés pour exécuter ladite fonction logicielle (LOG 1 ), au moins un composant fonctionnel (CFn) ; un premier ensemble (ENS 1 ) de ressources matérielles (RM n ) comprenant chacune au moins une entrée et une sortie définissant des interfaces d’échange de données, ledit premier ensemble (ENS 1 ) de ressources matérielles (RM n ) étant connecté à un réseau de données (NET) par l’intermédiaire d’une première interface de communication ; un dispositif d’interface de communication (COM 1 ) pour configurer des liens physiques entre l’entrée et la sortie des ressources matérielles (RM n ) du premier ensemble (ENS 1 ) ; un premier calculateur (CLC 1 ) configuré pour générer une configuration matérielle (CONF 1 ) d’au moins une ressource matérielle (RM n ) du premier ensemble (ENS 1 ) ; une console d’exploitation (E XP ) comprenant une interface utilisateur (INT 1 ) et connectée audit premier calculateur (CLC 1 ) pour : sélectionner (SEL 1 ) un deuxième ensemble (ENS 2 ) de ressource matérielles (RM n ) parmi le premier ensemble (ENS 1 ) de ressources matérielles (RM n ) ; associer (ASS) chaque composant fonctionnel (CF n ) à au moins une ressource matérielle (RM n ) du deuxième ensemble (ENS 2 ), ladite association (ASS) entrainant un adressage (ADR) de chaque ressource matérielle (RM n ) du deuxième ensemble (ENS 2 ) pour : transmettre des données propres à chaque composant fonctionnel (CFn) à chaque ressource matérielle (RMn) associée ; ladite console d’exploitation (E XP ) comportant un actionneur pour déployer au moins un composant fonctionnel (CF n ) sur au moins une ressource matérielle (RM n ), ledit système de test (S t ) comportant une interface de communication pour recevoir des données propres à des évènements produits par ladite au moins une ressource matérielle (RM n ) au sein de laquelle est déployée le composant fonctionnel (CFn). Système de test (S t ) selon la revendication 1, caractérisé en ce que le système comprend : Un module de gestion d’anomalies (M A ) configuré pour exécuter une première fonction (F 1 ) de redémarrage automatique d’au moins une ressource matérielle (RM n ) du second ensemble (ENS 1 ) de ressources matérielles (RM n ), ladite console d’exploitation (E XP ) comporte un actionneur pour lancer un premier test d’exécution (T E1 ) d’au moins un composant fonctionnel (CF n ) sur au moins une ressource matérielle (RM n ), ledit premier test d’exécution (T E1 ) comportant une mise en œuvre de la première fonction (F 1 ) de redémarrage automatique de ladite ressource matérielle (RM n ), ledit système de test (S t ) comportant une interface de communication pour recevoir des données propres à des évènements produits par ladite au moins une ressource matérielle (RM n ) redémarrée lors du premier test d’exécution (T E1 ). Système de test (S t ) selon la revendication 1, caractérisé en ce que le système de test (S t ) comprend : Un module de gestion d’anomalies (M A ) configuré pour exécuter une seconde fonction (F 2 ) de pilotage de l’alimentation d’au moins une ressource matérielle (RM n ) du second ensemble (ENS 1 ) de ressources matérielles (RM n ), un module de gestion d’une alimentation électrique (ALIM 1 ) des ressources matérielles (RM n ) du second ensemble (ENS 1 ), ledit module de gestion d’une alimentation électrique (ALIM 1 ) permettant d’activation ou la désactivation d’une alimentation d’au moins une ressource matérielle (RM n ) du deuxième ensemble (ENS 2 ), ledit module de gestion d’anomalies (M A ) étant configuré pour exécuter une deuxième fonction (F 2 ) de pilotage de l’alimentation d’au moins une ressource matérielle (RM n ) du deuxième ensemble (ENS 2 ), et dans lequel la console d’exploitation (E xp ) comportant un actionneur pour lancer un deuxième test d’exécution (T E2 ) dudit composant fonctionnel (CF n ), ledit deuxième test d’exécution (T E2 ) comportant une mise en œuvre de la deuxième fonction (F 2 ) de pilotage de l’alimentation d’au moins d’une ressource matérielle (RM n ) du deuxième ensemble (ENS 2 ), ledit système comportant une mémoire pour enregistrer ou une interface pour recevoir des données propres à des évènements produits par la ressource matérielle (RM n ) pilotée lors du deuxième test (T E2 ). Système de test (S t ) selon la revendication 1, caractérisé en ce que le système de test (S t ) comprend : Un module de gestion d’anomalies (M A ) configuré pour exécuter une troisième fonction (F 3 ) de pilotage de l’entrée et/ou de la sortie d’au moins une ressource matérielle (RM n ) du second ensemble (ENS 1 ) de ressources matérielles (RM n ), ledit module de gestion d’anomalies (M A ) étant configuré pour modifier une valeur de ladite entrée et/ou de ladite sortie, ladite console d’exploitation (E XP ) comportant un actionneur pour lancer un troisième test d’exécution (T E3 ) dudit composant fonctionnel (CF n ), ledit troisième test d’exécution (T E3 ) comportant la mise en œuvre de la troisième fonction (F 3 ) de pilotage de l’entrée et/ou de la sortie d’au moins une ressource matérielle (RM n ), ledit système comportant une mémoire pour enregistrer des données propres à des évènements produits par la ressource matérielle (RM n ) pilotée lors du troisième test (TE 3 ). Système de test (S t ) selon la revendication 1, caractérisé en ce que le système de test (S t ) comprend : Un module de gestion d’anomalies (M A ) configuré pour exécuter une quatrième fonction (F 4 ) de pilotage du redémarrage d’un composant fonctionnel (CLF) d’au moins une ressource matérielle (RM n ) du second ensemble (ENS2) sélectionné, et dans lequel la console d’exploitation (E xp ) comporte un actionneur pour lancer un quatrième test d’exécution (T E4 ) comportant une mise en œuvre de la quatrième fonction (F 4 ) de pilotage du redémarrage d’au moins un composant fonctionnel (CLF), ledit système comportant une interface pour recevoir ou une mémoire pour enregistrer des données propres à des évènements produits par la ressource matérielle (RM n ) pilotée lors du quatrième test (T E4 ). Système de test (S t ) selon la revendication 1, caractérisé en ce que le système de test (S t ) comprend : Un module de gestion d’anomalies (M A ) configuré pour exécuter une cinquième fonction (F 5 ) de pilotage d’un mode sans échec pour le pilotage du redéploiement d’un composant fonctionnel (CLF) sur au moins une ressource matérielle (RM n ) du second ensemble (ENS 2 ) de ressources matérielles (RM n ), ledit module de gestion d’anomalies (M A ) ayant détecté au préalable une erreur sur la ressource matérielle (RM n ) lors de l’exécution d’au moins un composant fonctionnel (CF n ) ; la console d’exploitation (E xp ) comportant un actionneur pour lancer un mode sans échec de ladite ressource matérielle du deuxième ensemble (ENS 2 ), ledit système engageant le transfert d’une nouvelle configuration sur ladite ressource matérielle associée. Système de test (S t ) selon la revendication 1, caractérisé en ce que le système comprend une mémoire pour enregistrer des données propres à des évènements produits par ladite ressource matérielle (RM n ) redémarrée lors ou consécutivement au lancement d’au moins un test d’exécution (T E1 ). Système de test (S t ) selon l’une quelconque des revendications précédentes, caractérisé en ce qu’au moins un composant fonctionnel (CFn) a une fréquence de fonctionnement associée. Système de test (S t ) selon l’une quelconque des revendications précédentes, caractérisé en ce qu’il comprend une mémoire comportant des données représentant un graphe de dépendance (GRD 1 ) des composants fonctionnel (CF n ), ledit graphe de dépendance (GRD 1 ) définissant des interactions possibles entre les composants fonctionnels (CF n ). Système de test (S t ) selon l’une quelconque des revendications précédentes, caractérisé en ce qu’il comprend une mémoire comportant des données définissant une fréquence de fonctionnement globale de la fonction logicielle (LOG 1 ). Système de test (S t ) selon l’une quelconque des revendications précédentes, caractérisé en ce qu’il comporte un microprogramme configuré pour collecter les données émises par une ressource matérielle, les dites données comportant des données utiles et des données d’entête, lesdites données d’entête étant décodées par le microprogramme et réencodées pour intégrer des données d’adressage afin de réadresser des données utiles vers une autre ressource matérielle. Système de test (S t ) selon l’une quelconque des revendications 2 à 11, dans lequel le premier calculateur (CLC 1 ) est configuré pour analyser les données enregistrées ou reçues propres aux évènements produits par chaque ressource matérielle (RM n ) lors de l’exécution d’au moins un test d’exécution (T E1, T E2, T E3 ), le premier calculateur (CLC 1 ) générant une notification d’erreur lorsque l’analyse détecte une séquence d’évènements non conforme vis-à-vis d’une séquence de référence. Système de test (S t ) selon l’une quelconque des revendications précédentes, dans laquelle la console d’exploitation (E X p ) comprend un module pour déterminer un protocole de communication entre deux composants fonctionnels (CF n ), ledit système de test (S t ) comportant une mémoire pour enregistrer des données échangées au moyen d’une interface de communication entre deux ressources matérielles (RM n ) adressées (ADR) lors de l’étape d’association (ASS), le calculateur (CLC 1 ) étant configuré pour analyser une présence d’ entêtes et de données structurant des paquets de données dudit protocole de communication pour établir un diagnostic de communication entre lesdits deux composants fonctionnels (CF n ). Système de test (S t ) selon l’une quelconque des revendications 1 à 13, caractérisé en ce que la console d’exploitation (E XP ) comprenant une interface utilisateur (INT 1 ) et connectée audit premier calculateur (CLC 1 ) pour : déterminer (DET 1 ) au moins une contrainte globale de fonctionnement (Cgf) de la fonction logicielle (LOG 1 ) ; déterminer (DET 2 ) un ensemble de contraintes locales de fonctionnement (Clf n ) entre au moins un sous-ensemble de composants fonctionnels (CF n ), alimenter (ALI), via le module de gestion d’une alimentation électrique (ALIM 1 ), les ressources matérielles (RM n ) du deuxième ensemble (ENS 2 ). Système de test (S t ) selon la revendication précédente, dans lequel la console d’exploitation (E XP ) comprend un afficheur (E 1 ), et dans lequel le calculateur (CLC 1 ) est configuré pour générer une commande d’affichage d’un menu de paramétrage sur ledit afficheur (E 1 ), ledit menu de paramétrage permettant, au moyen d’au moins une commande utilisateur, de : sélectionner au moins une fréquence de fonctionnement pour au moins un composant fonctionnel (CF n ) ; paramétrer la contrainte globale de fonctionnement (Cgf) et les contraintes locales (Clf) de fonctionnement ; paramétrer au moins une ressource matérielle (RM n ) du deuxième ensemble (ENS 2 ), définir des paramètres d’entrée/sortie pour au moins un composant fonctionnel (CF n ). Système de test (S t ) selon l’une quelconque des revendications 14 à 15, dans lequel la contrainte globale de fonctionnement (Cgf) comprend un temps d’exécution de la fonction logicielle (LOG 1 ) entre un premier évènement correspondant au lancement du premier test d’exécution (T E1 ) et un deuxième évènement correspondant à une exécution de ladite fonction logicielle (LOG 1 ), la contrainte globale de fonctionnement (Cgf) imposant que ledit temps d’exécution de la fonction logicielle (LOG 1 ) soit inférieur à une valeur seuil prédéterminée. Système de test (S t ) selon l’une quelconque des revendications 14 à 15, dans lequel la contrainte globale de fonctionnement (Cgf) comprends une consommation d’une ressource de calcul globale de l’ensemble des ressources matérielles (RM n ) du deuxième ensemble (ENS 2 ), la contrainte globale de fonctionnement (Cgf) imposant que la consommation de ressource de calcul d’une ressource matérielle (RM n ) par un composant fonctionnel (CF n ) qui lui est associé soit inférieure à un pourcentage prédéterminé de ladite ressource de calcul globale de l’ensemble des ressources matérielles (RM n ) du deuxième ensemble (ENS 2 ). Système de test (S t ) selon l’une quelconque des revendications 14 à 17, dans lequel la contrainte globale de fonctionnement (Cgf) est déterminée automatiquement par le premier calculateur (CLC 1 ) à partir de l’ensemble des contraintes locales de fonctionnement (Clf) et à partir du graphe de dépendance (GRD 1 ). Système de test (S t ) selon l’une quelconque des revendications précédentes, dans lequel le premier calculateur (CLC 1 ) est apte à : mettre en œuvre une étape de compilation (CMP) d’au moins un composant fonctionnel (CF n ) pour le rendre compatible de la ressource matérielle (RM n ) qui lui est associée, ladite compilation (CMP) étant réalisée dans un environnement de compilation adapté à ladite ressource matérielle (RM n ) associée audit composant fonctionnel (CF n ). Procédé de test (S t ) d’au moins un composant fonctionnel (CF n ) d’une fonction logicielle (LOG 1 ), ledit procédé comprenant : détermination (DET 1 ), par un calculateur (CLC 1 ) connecté à une console d’exploitation (E XP ), d’une contrainte globale de fonctionnement (Cgf) d’une fonction logicielle (LOG 1 ) ; détermination (DET 2 ), par le calculateur (CLC 1 ), d’un ensemble de contraintes locales de fonctionnement (Clf) entre au moins un sous-ensemble d’un ensemble de composants fonctionnels (CF n ) exécutant la fonction logicielle (LOG 1 ) ; association (ASS), par le calculateur (CLC 1 ), de chaque composant fonctionnel (CF n ) à au moins une ressource matérielle (RM n ) d’un ensemble de ressources matérielles (RM n ), ladite association (ASS) comportant un adressage (ADR) de chaque ressource matérielle (RM n ) de l’ensemble de ressources matérielles (RM n ) pour : paramétrer chaque ressource matérielle (RM n ) en fonction du composant fonctionnel (CF n ) qui lui est associée ; transmettre des données propres à chaque composant fonctionnel (CF n ) à chaque ressource matérielle (RM n ) ; alimentation (ALI), par un module de gestion d’une alimentation électrique (ALIM 1 ), de l’ensemble de ressources matérielles (RM n ) ; mise en œuvre, en réponse à l’actionnement d’un actionneur de la console d’exploitation (E XP ), d’un premier test d’exécution (T E1 ) d’au moins un composant fonctionnel (CF n ), ledit premier test d’exécution (T E1 ) comportant une mise en œuvre d’une première fonction (F 1 ) de redémarrage automatique d’au moins une ressource matérielle (RM n ) de l’ensemble de ressources matérielles (RM n ), enregistrement dans une mémoire de de données relatives à des évènements produits par ladite ressource matérielle (RM n ) redémarrée lors du premier test d’exécution (TE 1 ). Produit programme d’ordinateur comportant des instructions qui, lorsque le programme est exécuté par le système de test selon l’une quelconque des revendications 1 à 19, conduisent celui-ci à mettre en œuvre les étapes du procédé selon la revendication 20.