FR3142822A1 - System for deploying and testing a functional component of a software function on a set of hardware resources - Google Patents

Abstract

System for deploying and testing a functional component of a software function on a set of hardware resources The invention relates to a system for testing (St) of at least one software function comprising: a first set (ENS1) of components functional units configured to execute said software function; a set of hardware resources (RMn) each comprising at least one input and one output, said second set of hardware resources (RMn) being connected to a data network (NET); a data card communication interface for configuring physical links between the input and output of the hardware resources (RMn); a calculator (CLC1) configured to generate a hardware configuration of said second set of hardware resources (RMn); a module for managing a power supply of said second set of hardware resources (RMn); an anomaly management module configured to execute a first automatic restart function of at least one hardware resource (RMn) of the second set; an operating console comprising an interface user (INT1) and connected to a computer. Figure for abstract: Fig. 1

Description

System for deploying and testing a functional component of a software function on a set of hardware resources Field of the invention

The field of the invention relates to the field of software testing systems.

More particularly, the field of the invention relates to the field of software function testing systems in the field of embedded systems, particularly in the automotive field.

State of the art

Historically, automotive electronics were very distributed, and software functions were generally each executed on a different computer connected via CAN (Controlled Area Network) type data buses.

With the evolution of technologies, the electronics of motor vehicles, like those of on-board systems more generally, are undergoing a shift towards more centralized architectures, which include a reduced number of more powerful computers connected by a high-speed network, for example via Ethernet type connections. Such architectures advantageously make it possible to deploy new software functionalities by means of software updates of the computers, and no longer by adding new computers dedicated to new software functionalities.

Software deployment systems on virtual targets are known in the prior art. Such systems can implement machine emulators, for example Qemu.

We also know, in the prior art, software deployment systems on real/virtual hybrid targets. This is the case, for example, of the vpSIM (Virtual Patient Simulation) system, which allows the simulation of medical cases for training purposes.

Software deployment systems on real targets are also known in the prior art. This is the case, for example, of the “Samsung Remote Test Lab” system and the “DIGIX Lab Test Services” system allowing the implementation of application deployments on real targets remotely.

Prior art also describes systems for integrating hardware into a continuous development and testing loop, using approaches such as the “Hardware In the Loop” approach. However, such an approach has the disadvantages of most of the time requiring physical access to the hardware and of being limited to a single hardware target.

We also know in the prior art a solution developed by the company IoT.bzh under the name repdesk. This solution includes a suite of tools allowing a user to compile an application in a CI/CD environment, an acronym designating in English terminology "Continuous Integration / Continuous Delivery", to test its execution on a virtual or real target and to evaluate the execution performance on the target. However, this solution has several disadvantages, since its operation is limited to the repdesk operating system, the file system for testing on a remote target is not the native system of the platform, and the deployment of the solution is limit to only one hardware target at a time.

Target prototyping solutions are also known in the prior art, for example the solutions described in the articles (Chen, Song, & Zhang, 2010) and (Dawson, Martinez, & Taveras, 2019).

However, these solutions have the disadvantage of being applied in a web application context and not in a functional chain context deployable on embedded hardware.

The invention aims to limit the aforementioned drawbacks.

• 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 ;

According to a first aspect, the invention relates to a system for testing or deploying at least one functional component of a software function, said test or deployment system comprising:

• a first set of functional components configured to execute said software function, at least one functional component;
• a first set of hardware resources each comprising at least one input and one output defining data exchange interfaces, said first set of hardware resources being connected to a data network via a first communication interface;
• a communication interface device for configuring physical links between the input and output of the hardware resources of the first set;
• a first calculator configured to generate a hardware configuration of at least one hardware resource of the first set;
• an operating console comprising a user interface and connected to said first computer for:
  • selecting a second set of hardware resources from the first set of hardware resources;
  • associate each functional component with at least one hardware resource of the second set, said association leading to addressing of each hardware resource of the second set for:
    • transmit data specific to each functional component to each associated hardware resource;

said operating console comprising an actuator for deploying at least one functional component on at least one hardware resource, said test system comprising a communication interface for receiving data specific to events produced by said at least one hardware resource within which the software component is deployed.

The test or deployment system is more generally called the test system in the following.

• 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,

According to one embodiment, the test system comprises:

• An anomaly management module configured to execute a first automatic restart function of at least one hardware resource of the first or the second set of hardware resources,

said operating console comprises an actuator for launching a first execution test of at least one functional component on at least one hardware resource, said first execution test comprising an implementation of the first automatic restart function of said hardware resource, said test system comprising a communication interface for receiving data specific to events produced by said at least one hardware resource restarted during the first execution test.

• 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,

According to one embodiment, the test system comprises:

• An anomaly management module configured to execute a second power control function of at least one hardware resource of the first or second set of hardware resources,
• a module for managing a power supply of the hardware resources of the first or the second set, said module for managing a power supply making it possible to activate or deactivate a power supply of at least one hardware resource of the second set,

said anomaly management module being configured to execute a second function for controlling the power supply of at least one hardware resource of the second set, and the operating console comprising an actuator for launching a second execution test of said component functional, said second execution test comprising an implementation of the second function of controlling the electrical supply of at least one hardware resource of the second set, said system comprising a memory for recording or an interface for receiving data specific to events produced by the hardware resource controlled during the second test.

• 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.

According to one embodiment, the test system comprises:

• An anomaly management module configured to execute a third function for controlling the input and/or output of at least one hardware resource of the first or second set of hardware resources, said anomaly management module being configured to modify a value of said input and/or said output, said operating console comprising an actuator for launching a third execution test of said functional component, said third execution test comprising the implementation of the third function for controlling the input and/or output of at least one hardware resource, said system comprising a memory for recording data specific to events produced by the hardware resource controlled during the third test.

• 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.

According to one embodiment, the test system comprises:

• An anomaly management module configured to execute a fourth function for controlling the restart of a functional component of at least one hardware resource of the first or second set of hardware resources or of the second selected set, and in which the console d operation comprises an actuator for launching a fourth execution test of said functional component, said fourth execution test comprising an implementation of the fourth function for controlling the power supply of at least one hardware resource of the second set , said system comprising an interface for receiving or a memory for recording data specific to events produced by the hardware resource controlled during the fourth test.

• 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 ;

According to one embodiment, the test system comprises:

• An anomaly management module configured to execute a fifth safe mode control function for controlling the redeployment of a functional component on at least one hardware resource of the second set of hardware resources, said anomaly management module anomalies having previously detected an error on the hardware resource during the execution of at least one functional component;

the operating console comprising an actuator for launching a safe mode of said hardware resource, said safe mode comprising an implementation of the fifth function for controlling a safe mode of a functional component of at least one hardware resource of the second set, said system initiating the transfer of a new configuration to said associated hardware resource.

An advantage of the invention is to make it possible to carry out tests of a software function comprising different software components intended to be executed on different hardware resources thanks to a hardware environment faithful to the real deployment case while integrating a complex deployment configuration into the within a heterogeneous hardware architecture.

The invention therefore makes it possible to reduce the number of hardware and software integration errors and their complexity when putting a software solution into production.

According to one embodiment, the test system comprises a memory for recording data specific to events produced by said hardware resource restarted during or following the launch of at least one execution test.

According to one embodiment, at least one functional component has an associated operating frequency.

According to one embodiment, the test system comprises a memory comprising data representing a dependence graph of the functional components, said dependence graph defining possible interactions between the functional components.

According to one embodiment, the test system comprises a memory comprising data defining an overall operating frequency of the software function.

According to one embodiment, the test system comprises a firmware configured to collect data transmitted by a hardware resource, said data comprising useful data and header data, said header data being decoded by the firmware and re-encoded to integrate addressing data in order to readdress useful data to another hardware resource.

• 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.

According to one embodiment, the operating console comprises a user interface and connected to said first computer for:

• determine at least one global operating constraint of the software function;
• determine a set of local operating constraints between at least one subset of functional components,
• supply, via the power supply management module, the hardware resources of the second set.

According to one embodiment, the first calculator is configured to analyze the recorded or received data specific to the events produced by each hardware resource during the execution of at least one execution test, the first calculator generating an error notification when the analysis detects a sequence of events that does not comply with a reference sequence.

According to one embodiment, the operating console comprises a module for determining a communication protocol between two functional components, said test system comprising a memory for recording data exchanged by means of a communication interface between two addressed hardware resources during the association step, the computer being configured to analyze the presence of headers and data structuring data packets of said communication protocol to establish a communication diagnosis between said two functional components.

• 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₂),
• définir des paramètres d’entrée/sortie pour au moins un composant fonctionnel.

According to one embodiment, the operating console comprises a display, and in which the computer is configured to generate a command for displaying a settings menu on said display, said settings menu allowing, by means of least one user command, of:

• select at least one operating frequency for at least one functional component;
• configure the global operating constraint and the local operating constraints;
• configure at least one hardware resource from the second set (ENS ₂ ),
• define input/output parameters for at least one functional component.

According to one embodiment, the overall operating constraint comprises an execution time of the software function between a first event corresponding to the launch of the first execution test and a second event corresponding to an execution of said software function, the overall constraint of operation requiring that said execution time of the software function be less than a predetermined threshold value.

According to one embodiment, the overall operating constraint comprises a consumption of a global calculation resource of all the hardware resources of the second set, the overall operating constraint imposing that the calculation resource consumption of a hardware resource by a functional component associated with it is less than a predetermined percentage of said overall calculation resource of all the hardware resources of the second set.

According to one embodiment, the global operating constraint is determined automatically by the first calculator from all the local operating constraints and from the dependence graph.

• 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.

According to one embodiment, the first calculator is capable of:

• implement a step of compiling at least one functional component to make it compatible with the hardware resource associated with it, said compilation being carried out in a compilation environment adapted to said hardware resource associated with said functional component.

• 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.

According to another aspect, the invention relates to a method of deploying or testing at least one functional component of a software function, said method comprising:

• association (ASS), by the computer, of each functional component with at least one hardware resource of a set of hardware resources, said association comprising an addressing (ADR) of each hardware resource of the set of hardware resources for:
  • configure each hardware resource according to the functional component associated with it;
  • transmit data specific to each functional component to each hardware resource;
• supply, by a power supply management module, of the set of hardware resources;
• implementation, in response to the actuation of an actuator of the operating console, of a deployment or an execution test of at least one functional component, the method comprising reception of data specific to events produced by said at least one hardware resource within which the software component or the hardware resource is deployed or tested.

• 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.

According to one embodiment, the method of testing at least one functional component of a software function comprises:

• determination by a computer connected to an operating console, of an overall operating constraint of a software function;
• determination, by the computer, of a set of local operating constraints between at least one subset of a set of functional components executing the software function;
• association (ASS), by the computer, of each functional component with at least one hardware resource of a set of hardware resources, said association comprising an addressing (ADR) of each hardware resource of the set of hardware resources for:
  • configure each hardware resource according to the functional component associated with it;
  • transmit data specific to each functional component to each hardware resource;
• supply, by a power supply management module, of the set of hardware resources;
• implementation, in response to the actuation of an actuator of the operating console, of a first execution test of at least one functional component, said first execution test comprising an implementation of a first function for automatically restarting at least one hardware resource from the set of hardware resources;
• recording in a memory of data relating to events produced by said hardware resource restarted during the first execution test.

According to another aspect, the invention relates to a computer program product comprising instructions which, when the program is executed by the test system of the invention, lead it to implement the steps of the method of invention.

An advantage of the invention is to use the native memories of the hardware resources, which makes it possible to be representative of real conditions of use.

Brief description of the figures

Other characteristics and advantages of the invention will emerge on reading the detailed description which follows, with reference to the appended figures which illustrate:

: A schematic representation of the test system in a configuration in which it includes six hardware resources connected to a data network.

: A schematic representation of the step of selecting a second set of hardware resources from the first set of hardware resources.

: A schematic representation of the communications between the hardware resources of the second set with the computer, the power management module and the communication interface card, in an embodiment in which the computer comprises the power management module anomalies.

: A schematic representation of the step of determining an overall operating constraint.

: A schematic representation of the step of determining local operating constraints between the hardware resources of the second set.

A schematic representation of the step of associating functional components with the hardware resources of the second set, in an embodiment in which a single functional component is associated with each hardware resource.

: A schematic representation of the step of determining the global operating constraint, in an embodiment in which it is determined from the dependence graph and from a set of local operating constraints between the functional components.

: A schematic representation of different steps implemented by the operating console connected to the computer.

: A schematic representation of a hardware configuration of the test system of the invention.

Description of the invention

According to a first aspect, the invention relates to a test system S _t of at least one functional component CF _n of a software function LOG ₁ .

All of the characteristics described below can be linked to the system of the invention as well as to the process of the invention. However, the invention is described with regard to the test and/or deployment system without this being limiting to the object relating to the system. This description is also understood as a description of the testing and/or deployment process.

The term “deployment and/or test system” means a software testing system and/or a software deployment system on a platform comprising a set of hardware resources accessible from a data network. In the remainder of the description we will call such a system a test system. This nomination is also true for the testing process of the invention which can be understood as a deployment process.

Depending on the situation, the hardware resources can be co-located on the same site and accessible from one or more data server(s). According to another exemplary embodiment, certain material resources can be arranged at different sites. The different sites can be addressed from one or more data servers. In embodiments with strong real-time constraints or execution times that must be short, we prefer a configuration in which the different hardware resources are located on the same site.

One of the advantages of the invention is to make it possible to test together a software configuration intended to work with a set of resources by remotely configuring a set of hardware resources. Thus the invention takes the form of a modular addressable hardware resource platform to configure a set of functional components.

Software function

We define a “software function” as code executable by a set of hardware to implement a given function. For example, in the automotive sector, it may be an emergency braking function in response to the detection of a pedestrian.

Functional components

The S test system_tcomprises a first set of functional components CF_not. CF functional components_notare configured to perform the LOG software function₁. In other words, the CF functional components_not correspond to “fragments” of the LOG software function₁. According to one embodiment, these functional components each have associated parameters, such as an operating frequency F_i, or even an execution time.

Material resources

The test system S _t comprises a first set ENS ₁ of hardware resources RM _{n .}

By “hardware resource” we mean configurable physical hardware comprising an integrated calculator capable of executing a code. This is for example a processor or a microprocessor.

There illustrates an embodiment in which the system comprises a first set ENS ₁ of six hardware resources RM ₁ , RM ₂ , RM ₃ , RM ₄ , RM ₅ , RM ₆ . The RM _n hardware resources each include at least one input and one output. Each input and each output of each RM _n hardware resource defines data exchange interfaces.

Optionally, at least one hardware resource RM _n comprises a plurality of inputs/outputs.

The first set ENS ₁ of hardware resources RM _n is connected to a data network NET via a first communication interface. The first communication interface includes, for example, a network card, such as an Ethernet card or a WiFi card.

Communication interface card

The test system S _t includes a communication interface device COM ₁ . In one embodiment, this device is an electronic card thus defining a communication interface card. By “a communication interface card” we mean a card making it possible to configure physical links between the input and output of the RM _n hardware resources.

According to one embodiment, the communication interface device is a memory. In this case, a resource can record data that is read by another resource so as to exchange data between them.

According to another embodiment, the device is a data bus for example on which information is exchanged. The data bus can be read or written by different hardware resources having access to it.

According to one embodiment, the COM ₁ communication interface device is integrated within a selected hardware resource. This case is advantageous when a small number of hardware resources is selected, for example two electronic cards which would include communication interfaces allowing them to communicate directly.

Optionally, the COM ₁ communication interface card includes the first communication interface. The COM ₁ communication interface card includes for example a network card.

Optionally, the COM ₁ communication interface card makes it possible to configure at least one hardware resource RM _n to configure a maximum calculation capacity to be exploited during the execution of a functional component CF _n .

An advantage is to allow the execution of the functional components CF _n on the hardware resources RM _n .

Memory

The S _t test system includes a memory. The memory includes data representing a dependence graph GRD ₁ between the functional components CF _n . By “dependency graph” we mean a graph defining possible interactions, such as exchanges of information, between the functional components CF _n via logical links, and defining an overall operating frequency of the software function LOG ₁ .

First calculator

The test system S _t comprises a first calculator CLC ₁ . The first CLC calculator ₁ is configured to generate and deploy a hardware configuration of at least one hardware resource RM _n .

For example, for a hardware resource comprising a microprocessor, the deployed configuration includes the software(s) defining the operating system, also called "kernel" and the software(s) defining the file system(s) including the code executable of the functional component that must execute on the hardware resource. In the case of an FPGA, the deployed configuration may include firmware. In the case of a microcontroller, the configuration may include the ROM memory code including the system code and the application code.

Remember that “Firmware” is firmware, microprogram, microcode, internal software or even embedded software of a hardware resource. It is usually built into computer hardware so that it can function. In some cases, a hardware resource may have “Firmware”, in others it does not.

According to one embodiment, the configuration may include the cross compilation structure between the different software components, also called in English terminology “cross compilation framework”. It can take the form of executable code to put it in the image defining the configuration to be transferred.

According to one example, the configuration may include the source code which is transferred to the hardware resource and the compilation may be carried out within the hardware resource. According to another example, the compilation is carried out upstream and the compiled code is transferred within the hardware resource.

In order to generate and deploy a hardware configuration, according to one embodiment the calculator recovers all of the source codes for each functional component and, where applicable, the libraries necessary for the operation of each functional component. In the latter case, the computer can transmit the code to be compiled or previously compiled with the libraries to each addressed hardware resource.

According to one embodiment, the first CLC calculator ₁ is configured to implement a CMP compilation step of at least one functional component CF _n to make it compatible with at least one hardware resource RM _n .

Generating a configuration includes, for example, compiling the codes for each functional component. According to one embodiment, the generation includes the creation and/or compilation of the dependencies of each functional component with other software components and/or with hardware resources and/or libraries and/or communications interfaces. According to one embodiment, the generation also includes the compilation of the operating system of at least one hardware resource.

Advantageously, the compilations are carried out on the computer and are then transmitted to each hardware target.

Deployment includes transmitting compiled codes and dependencies to hardware targets accessible from a remote server. Software components are installed in memories of each hardware resource in order to be started and executed.

For each hardware resource, according to one embodiment, the deployment includes the transfer of a set of files on each hardware resource, for example the transfer of 1, 2, 3 file(s), or even up to 15 files, or even more depending on certain complex deployment cases. The files generated after compilation using the calculator are transmitted to the hardware resources according to the operation of association of the software components with the hardware resources which was carried out from the operating console.

According to an exemplary embodiment, the deployment includes the transmission of at least one automatic startup file such as a boot loader, or better known as a “bootloader” in English terminology. This boot loader can take the form of software allowing you to launch one or more programs or operating systems.

According to another example, the deployment includes the copy of a file produced/generated by the computer onto a memory of a hardware resource.

According to an exemplary embodiment, a configuration file, which can be included in the dependency graph, can include the transfer or deployment operations depending on the functional component, that is to say all of the operations to be carried out. on each material resource.

According to one embodiment, the deployment includes a transfer of a firmware or firmware, also called “Middleware” in English terminology into a memory of a hardware resource. Such a code file allows in particular the different data of each input/output of each hardware resource to be able to be interpreted according to different OSI layers to be subsequently exploited.

The Middleware can in particular be installed on the COM ₁ communication interface device.

According to one embodiment, the deployment operation comprises the implementation of an automatic verification of a setting of each file representing all or part of a functional component on their hardware resource in order to verify that they can actually be used by said hardware resource.

The deployment may include the deletion of a previous installation, that is to say the deletion of files already present and corresponding to a previous version of at least one functional component installed on a hardware resource or of a library already present or a file system of an operating system of the hardware resource

Power supply management module

The test system S _t includes a module for managing an electrical power supply ALIM ₁ of the set of hardware resources RM _n .

Optionally, the first calculator CLC ₁ includes the power supply management module ALIM ₁ .

According to an exemplary embodiment, the power supply management module makes it possible to cut off the power supply of a given hardware resource for a given period of time. According to another example, the power supply management module makes it possible to generate micro-cuts.

Anomaly management module

The test system S _t includes an anomaly management module M _A. The anomaly management module M _A can be configured to on the one hand control the launch of a test of a hardware resource or a set of hardware resources comprising the functional component(s) deployed (s) on each hardware resource and on the other hand recover the data produced by the different hardware and software entities at the end of the test. The anomaly management module may include hardware or software anomaly management or both.

According to one example, the anomaly management module is configured to implement a first function F ₁ for automatically restarting at least one hardware resource RM _n .

The first function F ₁ for automatically restarting a hardware resource RM _n is for example implemented following the execution of a test of the software function LOG ₁ by the test system St. The first function F ₁ is for example example implemented in the event of total or partial non-execution of the software function LOG ₁ . The first automatic restart function F ₁ is for example implemented following a problem in the execution of one or more functional components CF _n on one or more hardware resources RM _n .

Optionally, the anomaly management module M _A is configured to implement a second function F ₂ for controlling the power supply of at least one hardware resource RM _n .

Optionally, the anomaly management module M _A is configured to implement a third function F ₃ for controlling the inputs/outputs of at least one hardware resource RM _n . Controlling the inputs/outputs of a hardware resource RM _n makes it possible, for example, to modify a value of at least one input or output of said hardware resource.

According to one embodiment, the invention comprises the implementation of a fourth function F ₄ which can be launched from the operating console by a fourth test T _E4 . The fourth T _E4 test involves restarting a function without having to restart the hardware resource.

To this end, the anomaly management module makes it possible to launch the test and collect the data from the test.

The fourth function F ₄ can therefore be engaged on a software component or a plurality of software components. The system of the invention makes it possible to take into account all the data produced by each hardware resource and each functional component after the launch of the fourth test T _E4 .

According to one embodiment, the anomaly management module M _A is configured to execute a fifth function F ₅ for controlling a safe mode for controlling the redeployment of a functional component CLF on at least one hardware resource RM _n of the second set ENS ₂ of material resources RM _n .

According to one example, prior to launching the fifth function F ₅ , the anomaly management module M _A first detects an error on the hardware resource RM _n during the execution of at least one functional component CF _n . The launch of the fifth function can be automatic or manual following the detected error. To this end, the E _xp operating console includes an actuator for launching a safe mode of said hardware resource of the second set ENS ₂ .

Safe mode makes it possible in particular to initiate the transfer of a new configuration to said associated hardware resource.

There illustrates an embodiment in which three hardware resources are connected at the same time to the first CLC calculator ₁ , to the power management module ALIM ₁ and to the communication interface card COM ₁ , and in which the first CLC calculator ₁ includes the M _A anomaly management module.

Operating console: selection of hardware resources

The S _t test module includes an E _XP operating console. The E _XP operating console comprises a user interface INT ₁ and is connected to the first CLC calculator ₁ to select SEL ₁ a second set ENS ₂ of hardware resources RM _n from the first set ENS ₁ of hardware resources RM _n .

The second set ENS ₂ is for example a subset of the first set ENS ₁ . According to another example, it is the same set.

There illustrates an embodiment in which a subset ENS ₂ of three hardware resources RM ₁ , RM ₂ , RM ₆ is selected from a first set of hardware resources RM _n .

Operating console: definition of operating constraints

The E _XP operating console includes a user interface INT ₁ and is connected to the first calculator CLC ₁ to determine DET ₁ at least one global operating constraint Cgf of the software function LOG ₁ , as illustrated in . The overall operating constraint Cgf is for example periodic.

The E _XP operating console includes a user interface INT ₁ and is connected to the first calculator CLC ₁ to determine DET ₂ a set of local operating constraints Clf _n between at least one subset of functional components CF _{n ,} as illustrated in .

The second set of hardware resources RM _n is for example selected SEL ₁ according to the different functional components CF _n necessary for the execution of the first software function LOG ₁ , or even constraints intrinsic to the latter or to their interactions, for example local operating constraints Clf _n . The second set of hardware resources RM _n can also be selected SEL ₁ according to a global operating constraint Cgf of the test system S _t.

The global and local operating constraints Cgf, Clf _n include for example latency constraints, temporal constraints (for example a maximum execution time of a functional component), or even constraints relating to the computing power used by a functional component. An example of a local operating constraint Clf _n is that a given functional component CF _n does not consume more than a given percentage of the computing power of a hardware resource RM _n on which it is executed. An example of a global operating constraint Cgf is that all of the functional components CF _n which execute the software function LOG ₁ do not consume more than a given percentage of the maximum computing power of the test system S _t . This maximum computing power of the test system S _t corresponds for example to the computing power of the second set ENS ₂ of hardware resources RM _n .

Optionally, the overall operating constraint C_lf includes an execution time of the LOG software function₁between two given events. A first event corresponds for example to an actuation of an actuator by a user to launch an execution test of the software function LOG₁. A second event corresponds for example to the complete execution of said software function LOG₁by the S test system_t. The execution time is for example then compared with a threshold value, for example predetermined, to define at least partially the overall operating constraint Cgf. The global operating constraint Cgf imposes, for example, that the execution time of the software function LOG₁is lower than the predetermined threshold value.

To illustrate this embodiment, we place ourselves in a case of simulating emergency braking of a motor vehicle. In this example, the first event corresponds to the capture of an image including a pedestrian or an obstacle in the path of the vehicle by means of a sensor, for example a camera, and the second event corresponds to the issuance of the command automatic braking of the vehicle. In this example, the overall operating constraint Cgf requires that the execution time of the software function LOG ₁ be less than 100 milliseconds.

Optionally, the overall operating constraint Cgf includes a constraint on the consumption of a global calculation resource of the set of hardware resources RM _n of the second set. For example, the overall operating constraint Cgf imposes that the execution of the software function LOG ₁ does not consume more than a given percentage of the total calculation resource of all the hardware resources RM _n of the test system S _t . According to another example, the overall operating constraint Cgf imposes that the execution of the functional components CF _n does not consume more than a predetermined percentage of each hardware resource RM _n with which they are associated.

Optionally, the global operating constraint Cgf is determined automatically by the first calculator CLC ₁ from the local operating constraints Clf between several functional components CF _n and from a dependence graph between said functional components CF _n , as illustrated in .

An advantage of the method of the invention is to make it possible to measure the execution parameters of the functional components in their hardware environment so as to compare them to the constraints which are defined. Thus, the system includes a clock and a calculator to measure time intervals between messages or notifications or commands so as to generate indicators of compliance with the constraints.

Advantageously, the test system uses the native file system(s) and/or the memory of the hardware resource. This is, among other things, made possible thanks to the anomaly management module so as not to have to manipulate the hardware resource(s) manually but only automatically.

Operating console: User command

The steps implemented using the E _XP operating console are for example implemented using at least one user command.

The user command includes for example a command interacting with an input device, for example a mouse, a keyboard, or a push button in the case of a digital command, a microphone in the case of a voice command, or still a screen of the E _XP operating console in the case of touch control.

Operating console: association of functional components and hardware resources

_{The operating console E ​ ​} . According to one embodiment, the ASS association makes it possible to automatically generate an addressing of each hardware resource RM _n of the second set ENS ₂ . This addressing can be carried out automatically from the CLC ₁ calculator and the data contained in the files to be transmitted to each hardware resource.

By “addressing a hardware resource” is meant the fact of loading an executable code defining the functional component CF _n on the hardware resource RM _n at a memory resource address for example through a communication interface of said hardware resource. ADR addressing includes, for example, the configuration of each hardware resource RM _n according to the functional component associated with it.

For example, knowledge of other resources and the means of communicating with them can be defined during this association. These may be physical communication links and/or software communication links such as those with the firmware defined by the middleware or even communication APIs, API designating “Application program interface”. Addressing can include the association of physical addresses of resources, that is to say physical addresses of the communication interfaces of each resource, such as the Mac address, or even network addresses such as ports or IP addresses of these communication interfaces of each hardware resource.

Another example is the installation in the RMn hardware resources of the software libraries necessary for the proper functioning of the CFn software components.

According to another example, host names, protocol data, or data allowing data to be structured according to the different OSI layers can be automatically organized by the computer according to the association made between the functional component and the hardware resource. According to one example, the calculator sequences the data to be transmitted according to a predefined rule depending on the association made.

The computer can address a hardware resource by making a copy of files and initiating a restart of the hardware resource or even a restart of the functional component only. According to one example, all hardware resources are restarted after the association and addressing of a functional component to a hardware resource.

Optionally, the ASS association includes the association of a functional component CF _n with a plurality of hardware resources RM _n . In this case, the test system S _t is for example configured so that a first portion of the code of a given functional component CF _n is executed on a first hardware resource RM _n and that a second portion of the code is executed on another hardware resource RM _n .

Optionally, the association ASS includes the association of a plurality of functional components CF _n with a hardware resource RM _{n .}

Optionally, the ASS association includes the CMP compilation of at least one functional component CF _n to make it compatible with at least one hardware resource RM _n of the second set ENS ₂ . Indeed, each hardware resource RM _n has for example its own operating system, and the executable code must therefore be compiled in a compilation environment adapted to make it compatible with the operating system of the hardware resource RM _n .

The ASS association includes the transmission, to each hardware resource, of data specific to each functional component CF _n . This is for example an operating frequency, a language of a code to be executed, a size of a code to be executed, the code itself, the means of compiling it or even libraries software necessary for the correct execution of the code.

Operating console: power supply of hardware resources

The E _XP operating console includes a user interface INT ₁ and is connected to the first computer CLC ₁ to supply ALI, via the power supply management module ALIM ₁ , the hardware resources of the second set ENS ₂ .

Operating console: first execution test

The E _XP operating console includes an actuator for launching a first execution test T _E1 of at least one functional component CF _n . The objective of the first execution test T _E1 is to verify the execution of said functional component CF _n on the hardware resource(s) with which it is associated, while respecting the local and global operating constraints Clf, Cgf which have been defined .

The first execution test T _E1 includes the implementation of the first function F ₁ for automatic restart of at least one hardware resource RM _n of the second set ENS ₂ . The first function F ₁ is for example implemented in the event of at least partial failure in the execution of said functional component CF _n . This may be, for example, a problem in compiling the functional component CF _n , or even a problem due to the definition of local operating constraints Clf that are incompatible with each other, or incompatible with the global function constraint Cgf. It may also be a hardware problem on the hardware resource, for example a defective card or a communication problem between several cards, or even an association problem, for example a CF _n functional component associated with a hardware resource RM _n not having sufficient computing power to execute the code.

According to one embodiment, the test system S _t further comprises a memory for recording data specific to events produced by the hardware resource RM _n restarted during the first execution test T _E1 .

According to another embodiment, the data is transmitted to a remote entity such as a data server. This may, for example, be the server hosting the operating software allowing a command and configuration interface to be displayed on an operating console.

The data can be consumed in real time by an operator who controls the content of the test data, the cases of failure or error, the integrity of the data and the consistency of operation of the system.

According to another example, the data specific to the test results are displayed directly on a system display, or even a display of a remote system. The data is not necessarily saved to memory or at least can be temporarily saved.

According to one example, the test data includes times at which each of the software components received and/or sent data. These moments can correspond to time-stamped data such as logs. In another example, the data includes an error report file, for example during a system crash.

According to one example, the test is a conformity test, we then check that the data produced during the test(s) conform to the expected data. According to one example, the invention makes it possible to compare the execution of a functional component with a formal model.

According to another example, the test data corresponds to reports of use of a resource such as a memory or a calculator. In the latter case, the test can report a value relative to CPU time.

Optionally, the first execution test T _E1 includes the implementation of the first automatic restart function F ₁ , by the first computer CLC ₁ , to restart all of the hardware resources RM _n of the second set ENS ₂ .

In this case, the E _XP operating console includes for example a memory for recording data specific to events produced by each hardware resource RM _n of the second set ENS ₂ .

Optionally, the automatic restart of at least one hardware resource RM _n makes it possible to return to a state preceding the execution of a functional component on said hardware resource.

Optionally, the automatic restart of at least one functional component CF _n makes it possible to restart the execution of the software function. An advantage of the invention is to make it possible to perform restart tests of software components and restart tests of hardware resources in a dissociated or planned manner so as to generate an automatic test sequence and make it easier to isolate an anomaly. .

Optionally, the first calculator CLC ₁ is configured to analyze the data specific to the events produced by each hardware resource RM _n restarted during the first execution test T _E1 . The first CLC calculator ₁ is for example configured to generate an error notification when the analysis detects a sequence of events that does not comply with a reference sequence. According to an illustrative example, an event includes for example a communication between two cards of a hardware resource RM _n , for example a communication between a motherboard and a graphics card of a hardware resource. For example, the motherboard transmits its identifier to the graphics card. A non-compliant event with respect to a reference sequence corresponds for example to the case in which the graphics card fails to fully decode the motherboard identifier. In this case, the CLC ₁ calculator is for example configured to generate the error notification. The error notification is for example an alert displayed in the form of an error message on the operating console, or even an audible alert.

According to one embodiment, the test data collected by the execution of a test or a deployment can be used by an operating console, for example that which allowed the deployment or the test. The use of data emitted by the hardware resource(s) following the deployment of a functional component or following the launch of a test can be represented on a display. The data can be represented in the form of a graph, logs, or even saved in a database.

Operating console: second execution test

Optionally, the E _XP operating console includes an actuator for launching a second execution test T _E2 of at least one functional component CF _n . This is for example the same actuator as that used to launch the first execution test T _E1 , or even a different actuator. The second execution test T _E2 includes the implementation of the second function F ₂ for controlling at least one hardware resource RM _n . In this case, the test system S _t includes for example a memory for recording data specific to events produced by each hardware resource RM _n controlled during the second execution test T _E2 .

Operating console: third execution test

Optionally, the E _XP operating console includes an actuator for launching a third execution test T _E3 of at least one functional component CF _n . The third execution test T _E3 includes the implementation of the third function F ₃ to control a value of at least one input/output of a hardware resource RM _n . The control makes it possible, for example, to modify the value of an input or an output of the hardware resource RM _n . The test system S _t includes for example a memory for recording data specific to events produced by each hardware resource RM _n controlled during the second execution test T _E2 .

Optionally, the operating console includes an actuator for sequentially executing the first execution test T _E1 , the second execution test T _E2 and the third execution test T _E3 , as illustrated in .

Operating console: control of the communication s

Optionally, the E _XP operating console includes a module for selecting or choosing a communication protocol between at least two CF _n functional components. Such a module advantageously makes it possible to control the smooth running of communications between several functional components. The selection can for example be made from a list of communication protocols.

The test system S _t includes for example a memory for exchanging data exchanged between two hardware resources RM _n by means of a communication interface. The first CLC calculator ₁ is for example configured to analyze the presence of a header and data structuring data messages exchanged between the hardware resources to establish a communication diagnosis between said functional components CF _n .

Operating console: configuration of functional components

Optionally, the E _XP operating console is configured to display, by means of the first calculator CLC ₁ , a configuration menu for at least one functional component CF _n . The settings menu allows for example a user to configure input/output parameters such as value ranges, physical units, input/output frequencies, or even a software version number, a description of the software instructions such as a code language or code size.

Optionally, the settings menu allows a user to configure time constraints. This is for example a processing time of the functional component CF _n , or even a calculation load per unit of time consumed by the execution of said functional component CF _n on a hardware resource RM _n .

Optionally, the configuration menu allows a user to select at least one operating frequency for a functional component CF _n . Different operating frequencies can for example be configured or selected for each functional component CF _n .

Optionally, the settings menu allows a user to select at least one operating frequency for the LOG ₁ software function.

Optionally, the configuration menu allows a user to configure a set of local operating constraints Clf between several functional components CF _n .

Optionally, the settings menu allows a user to configure a global operating constraint for the LOG ₁ software function.

Method for testing a functional component

According to another aspect, the invention relates to a method for testing at least one functional component CF _n of a software function LOG ₁ .

The method further comprises a first step of determining DET ₁ , by a CLC calculator ₁ connected to an E _XP operating console, of an overall operating constraint of the software function LOG ₁ .

The method further comprises a second DET determination step₂, by the CLC calculator₁, of a set of local operating constraints Clf between at least one subset of a set of functional components CF_not executing said software function LOG₁.

The method further comprises an ASS association step, by the CLC calculator₁, of each functional component CF_not at least one RM hardware resource_notof a set of RM hardware resources_{not ,}said association comprising an ADR addressing of each RM hardware resource_notof said set, said ADR addressing making it possible to configure each RM hardware resource_notdepending on the functional component CF_not associated with it, and said addressing making it possible to transmit data specific to each CF functional component_notto each RM hardware resource_not.

The method further comprises a power supply step ALI, by an electrical power supply management module ALIM ₁ , of the set of hardware resources RM _n .

The method further comprises a step of implementing a first execution test T _E1 in response to an actuation of an actuator of the operating console C _EX . The first execution test T _E1 includes an implementation of a first function F ₁ for automatically restarting at least one hardware resource RM _n of the set of hardware resources RM _n .

The method further comprises a step of recording in a memory data relating to events produced by each hardware resource restarted during the first execution test T _E1 .

Computer program product

According to another aspect, the invention relates to a computer program product comprising instructions which, when the program is executed by the test system of the invention, lead it to implement the steps of the method of test of the invention.

Hardware configuration

There illustrates an example of hardware configuration of the test system S _t of the invention.

From a hardware point of view, the test system S _t can be seen as a calculator interacting with a computer program product.

The test system S _t comprises at least one computer, for example, a microcomputer, a network of computers, an electronic component, a tablet or a smartphone.

The test system S _t comprises a calculation module 110. The CLC calculator ₁ comprises for example the calculation module 110. This calculation module 110 comprises, for example, one or more processors capable of interpreting instructions in the form of a computer program , a programmable logic circuit, such as an application-specific integrated circuit (ASIC), field programmable gate array (FPGA), programmable logic device (PLD), and programmable logic arrays (PLA), system-on-chip ( SOC), an electronic card in which steps of the method according to the invention are implemented in hardware elements. The processing can be executed by a processor, or simultaneously or sequentially, or according to another method, by one or more processors.

The calculation module 110 comprises a data processing module 111 for carrying out calculations, a memory 112, operationally coupled to the data processing circuit 111, a computer-readable medium 114 and optionally a reader 113 adapted to read the computer-readable medium. computer 114.

The test system S _t also includes an input device, an output device and a communication device 132.

Each function of the test system S _t is executed by causing the data processing module 111 to read a predetermined program on hardware such as the memory 112 such that the data processing module 111 executes calculations, controls communications carried out by the communication device 132 and to read and/or write data in the memory 112 and the computer readable medium 114.

The process is executed on a single computer or on a system distributed between several computers (in particular via the use of cloud computing).

The memory 112 is a computer-readable recording medium, and can be configured with, for example, at least one of the following elements: a read-only memory (ROM), a read-only memory erasable and programmable (EPROM, from English Erasable Programmable Read-Only Memory), a programmable and electrically erasable read-only memory (ÉEPROM, from English Electrically Erasable Programmable Read-Only Memory), a random access memory (RAM, from English Random Access Memory) and another suitable storage medium. Memory 112 can include an operating system and load programs according to the invention. It includes registers suitable for recording parameter variables created and modified during the execution of the aforementioned programs.

Alternatively, program instructions are taken from an external source and downloaded over a network. This may particularly be the case for applications. In this case, the computer program product comprises a computer-readable data carrier on which the program instructions are stored or a data carrier signal on which the program instructions are encoded.

In one aspect, the invention relates to a computer program product comprising the computer readable medium 114 containing instructions which, when executed by the circuit 110, cause the test system S _t to implement the steps of the process according to the invention.

The form of the program instructions is, for example, a source code form, a computer executable form or any intermediate form between a source code and a computer executable form, such as the form resulting from the conversion of the source code via a interpreter, assembler, compiler, linker, or resource locator. We call a resource locator for example an address or a link or an identifier of a resource such as a memory space or another resource. This resource can be local or remote and can designate a resource across all OSI layers. For this purpose, we know the URLs for “Uniform Resource Locator” which means in French a uniform resource locator or the URIs for “Uniform Resource Identifier” which means in French a uniform resource identifier. An advantage is that the instructions can include data relating to the addressing of other resources across all OSI layers. Locators also support different protocols in which instructions can be integrated such as GIT, FTP, SVN, etc. Alternatively, the program instructions are microcode, firmware, state definition data, integrated circuit configuration data (e.g. VHDL), or object code. Program instructions are written in any combination of one or more programming languages, for example, object-oriented programming language (C++, JAVA, Python), procedural programming language (C language for example).

The test system S _t further comprises an operating console E _XP comprising a user interface INT ₁ comprising input device 121 and an output device 122.

The user interface INT ₁ comprises an input device 121 to allow the user to enter data or commands so as to be able to interact with the programs according to the invention. The input device 121 includes, for example, a keyboard or a pointing interface, such as a mouse, an optical pencil, a touchpad, a remote control, a voice recognition device, a haptic device.

The output device 122 is designed to return information to a user, sensory or electrical, such as, for example, visually or audibly. The output interface 122 includes, for example, a graphical interface. The output interface 122 can be the input device, for example, in the case of a touchscreen tablet.

The set of at least one communication device 132 allows communication between the elements of the test system S _t and possibly between at least one element of the system and a device external to the system S _t . This communication device 132 can establish a physical link between elements of the test system S _t and/or between an element of the test system S _t and a device external to the test system S _t and/or a remote communication link (wireless) between elements of the test system S _t and/or between an element of the system and a device external to the test system S _t .

Claims (21)

Test system (S_t) of at least one functional component (Cf_not) of a software function (LOG₁), said test system (S_t) comprising:

• a first set (ENS ₁ ) of functional components (CF _n ) configured to execute said software function (LOG ₁ ), at least one functional component (CFn);
• a first set (ENS ₁ ) of hardware resources (RM _n ) each comprising at least one input and one output defining data exchange interfaces, said first set (ENS ₁ ) of hardware resources (RM _n ) being connected to a data network (NET) via a first communication interface;
• a communication interface device (COM ₁ ) for configuring physical links between the input and output of the hardware resources (RM _n ) of the first set (ENS ₁ );
• a first calculator (CLC ₁ ) configured to generate a hardware configuration (CONF ₁ ) of at least one hardware resource (RM _n ) of the first set (ENS ₁ );
• an operating console (E _XP ) comprising a user interface (INT ₁ ) and connected to said first computer (CLC ₁ ) for:
  • select (SEL ₁ ) a second set (ENS ₂ ) of hardware resources (RM _n ) from the first set (ENS ₁ ) of hardware resources (RM _n );
  • associate (ASS) each functional component (CF _n ) with at least one hardware resource (RM _n ) of the second set (ENS ₂ ), said association (ASS) resulting in addressing (ADR) of each hardware resource (RM _n ) of the second together (ENS ₂ ) for:
    • transmit data specific to each functional component (CFn) to each associated hardware resource (RMn);

said operating console (E_XP) comprising an actuator for deploying at least one functional component (CF_not) on at least one hardware resource (RM_not), said test system (S_t) comprising a communication interface for receiving data specific to events produced by said at least one hardware resource (RM_not) within which the functional component (CFn) is deployed. Test system (S_t) according to claim 1, characterized in that the system comprises:

• An anomaly management module (M _A ) configured to execute a first function (F ₁ ) for automatically restarting at least one hardware resource (RM _n ) of the second set (ENS ₁ ) of hardware resources (RM _n ),

said operating console (E_XP) includes an actuator for launching a first execution test (T_E1) of at least one functional component (CF_not) on at least one hardware resource (RM_not), said first execution test (T_E1) comprising an implementation of the first function (F₁) automatic restart of said hardware resource (RM_not), said test system (S_t) comprising a communication interface for receiving data specific to events produced by said at least one hardware resource (RM_not) restarted during the first execution test (T_E1). Test system (S_t) according to claim 1, characterized in that the test system (S_t) understand :

• An anomaly management module (M _A ) configured to execute a second function (F ₂ ) for controlling the power supply of at least one hardware resource (RM _n ) of the second set (ENS ₁ ) of hardware resources (RM _not ),
• a power supply management module (ALIM ₁ ) of the hardware resources (RM _n ) of the second set (ENS ₁ ), said power supply management module (ALIM ₁ ) allowing activation or deactivation of a power supply of at least one material resource (RM _n ) of the second set (ENS ₂ ),

said anomaly management module (M_HAS) being configured to execute a second function (F₂) for controlling the power supply of at least one hardware resource (RM_not) of the second set (ENS₂), and in which the operating console (E_xp) comprising an actuator for launching a second execution test (T_E2) of said functional component (CF_not), said second execution test (T_E2) comprising an implementation of the second function (F₂) for controlling the power supply of at least one hardware resource (RM_not) of the second set (ENS₂), said system comprising a memory for recording or an interface for receiving data specific to events produced by the hardware resource (RM_not) piloted during the second test (T_E2). Test system (S_t) according to claim 1, characterized in that the test system (S_t) understand :

• An anomaly management module (M _A ) configured to execute a third function (F ₃ ) for controlling the input and/or output of at least one hardware resource (RM _n ) of the second set (ENS ₁ ) of hardware resources (RM _n ), said anomaly management module (M _A ) being configured to modify a value of said input and/or said output, said operating console (E _XP ) comprising an actuator for launching a third execution test (T _E3 ) of said functional component (CF _n ), said third execution test (T _E3 ) comprising the implementation of the third function (F ₃ ) for controlling the input and/or of the output of at least one hardware resource (RM _n ), said system comprising a memory for recording data specific to events produced by the hardware resource (RM _n ) controlled during the third test (TE ₃ ).

Test system (S_t) according to claim 1, characterized in that the test system (S_t) understand :

• An anomaly management module (M _A ) configured to execute a fourth function (F ₄ ) for controlling the restart of a functional component (CLF) of at least one hardware resource (RM _n ) of the second set (ENS2) selected, and in which the operating console (E _xp ) comprises an actuator for launching a fourth execution test (T _E4 ) comprising an implementation of the fourth function (F ₄ ) for controlling the restart of at least a functional component (CLF), said system comprising an interface for receiving or a memory for recording data specific to events produced by the hardware resource (RM _n ) controlled during the fourth test (T _E4 ).

Test system (S_t) according to claim 1, characterized in that the test system (S_t) understand :

• An anomaly management module (M _A ) configured to execute a fifth function (F ₅ ) for controlling a safe mode for controlling the redeployment of a functional component (CLF) on at least one hardware resource (RM _n ) of the second set (ENS ₂ ) of hardware resources (RM _n ), said anomaly management module (M _A ) having previously detected an error on the hardware resource (RM _n ) during the execution of at minus one functional component (CF _n );

the operating console (E_xp) comprising an actuator for launching a safe mode of said hardware resource of the second set (ENS₂), said system initiating the transfer of a new configuration to said associated hardware resource. Test system (S _t ) according to claim 1, characterized in that the system comprises a memory for recording data specific to events produced by said hardware resource (RM _n ) restarted during or following the launch of at least one test of execution (T _E1 ). Test system (S _t ) according to any one of the preceding claims, characterized in that at least one functional component (CFn) has an associated operating frequency. Test system (S _t ) according to any one of the preceding claims, characterized in that it comprises a memory comprising data representing a dependence graph (GRD ₁ ) of the functional components (CF _n ), said dependence graph ( GRD ₁ ) defining possible interactions between the functional components (CF _n ). Test system (S _t ) according to any one of the preceding claims, characterized in that it comprises a memory comprising data defining an overall operating frequency of the software function (LOG ₁ ). Test system (S _t ) according to any one of the preceding claims, characterized in that it comprises a firmware configured to collect data transmitted by a hardware resource, said data comprising useful data and header data, said header data being decoded by the firmware and re-encoded to integrate addressing data in order to re-address useful data to another hardware resource. Test system (S _t ) according to any one of claims 2 to 11, in which the first calculator (CLC ₁ ) is configured to analyze the recorded or received data specific to the events produced by each hardware resource (RM _n ) during the execution of at least one execution test (T _E1, T _E2, T _E3 ), the first computer (CLC ₁ ) generating an error notification when the analysis detects a sequence of events not compliant with the with respect to a reference sequence. Test system (S _t ) according to any one of the preceding claims, in which the operating console (E _{X p} ) comprises a module for determining a communication protocol between two functional components (CF _n ), said test system (S _t ) comprising a memory for recording data exchanged by means of a communication interface between two hardware resources (RM _n ) addressed (ADR) during the association step (ASS), the computer (CLC ₁ ) being configured to analyze the presence of headers and data structuring data packets of said communication protocol to establish a communication diagnosis between said two functional components (CF _n ). Test system (S_t) according to any one of claims 1 to 13, characterized in that the operating console (E_XP) including a user interface (INT₁) and connected to said first computer (CLC₁) For :

• determine (DET ₁ ) at least one global operating constraint (Cgf) of the software function (LOG ₁ );
• determine (DET ₂ ) a set of local operating constraints (Clf _n ) between at least one subset of functional components (CF _n ),
• supply (ALI), via the power supply management module (ALIM ₁ ), the material resources (RM _n ) of the second set (ENS ₂ ).

Test system (S_t) according to the preceding claim, in which the operating console (E_XP) includes a display (E₁), and in which the calculator (CLC₁) is configured to generate a display command for a settings menu on said display (E₁), said configuration menu allowing, by means of at least one user command, to:

• select at least one operating frequency for at least one functional component (CF _n );
• configure the global operating constraint (Cgf) and the local operating constraints (Clf);
• configure at least one hardware resource (RM _n ) of the second set (ENS ₂ ),
• define input/output parameters for at least one functional component (CF _n ).

Test system (S _t ) according to any one of claims 14 to 15, in which the overall operating constraint (Cgf) comprises an execution time of the software function (LOG ₁ ) between a first event corresponding to the launch of the first execution test (T _E1 ) and a second event corresponding to an execution of said software function (LOG ₁ ), the overall operating constraint (Cgf) requiring that said execution time of the software function (LOG ₁ ) be lower than a predetermined threshold value. Test system (S _t ) according to any one of claims 14 to 15, in which the overall operating constraint (Cgf) comprises a consumption of a global calculation resource of all the hardware resources (RM _n ) of the second set (ENS ₂ ), the overall operating constraint (Cgf) requiring that the calculation resource consumption of a hardware resource (RM _n ) by a functional component (CF _n ) associated with it be less than a predetermined percentage of said global calculation resource of all the hardware resources (RM _n ) of the second set (ENS ₂ ). Test system (S _t ) according to any one of claims 14 to 17, in which the global operating constraint (Cgf) is determined automatically by the first calculator (CLC ₁ ) from all of the local operating constraints (Clf) and from the dependence graph (GRD ₁ ). Test system (S_t) according to any one of the preceding claims, in which the first calculator (CLC₁) is able to:

• implement a compilation step (CMP) of at least one functional component (CF _n ) to make it compatible with the hardware resource (RM _n ) associated with it, said compilation (CMP) being carried out in a compilation environment adapted to said material resource (RM _n ) associated with said functional component (CF _n ).

Test method (S_t) of at least one functional component (CF_not) of a software function (LOG₁), said method comprising:

• determination (DET ₁ ), by a computer (CLC ₁ ) connected to an operating console (E _XP ), of an overall operating constraint (Cgf) of a software function (LOG ₁ );
• determination (DET ₂ ), by the computer (CLC ₁ ), of a set of local operating constraints (Clf) between at least one subset of a set of functional components (CF _n ) executing the software function (LOG ₁ );
• association (ASS), by the computer (CLC ₁ ), of each functional component (CF _n ) with at least one hardware resource (RM _n ) of a set of hardware resources (RM _n ), said association (ASS) comprising a addressing (ADR) of each hardware resource (RM _n ) of the set of hardware resources (RM _n ) for:
  • configure each hardware resource (RM _n ) according to the functional component (CF _n ) associated with it;
  • transmit data specific to each functional component (CF _n ) to each hardware resource (RM _n );
• power supply (ALI), by a power supply management module (ALIM ₁ ), of the set of hardware resources (RM _n );
• implementation, in response to the actuation of an actuator of the operating console (E _XP ), of a first execution test (T _E1 ) of at least one functional component (CF _n ), said first execution test (T _E1 ) comprising an implementation of a first function (F ₁ ) for automatically restarting at least one hardware resource (RM _n ) of the set of hardware resources (RM _n ),
• recording in a memory of data relating to events produced by said hardware resource (RM _n ) restarted during the first execution test (TE ₁ ).

Computer program product comprising instructions which, when the program is executed by the test system according to any one of claims 1 to 19, lead it to implement the steps of the method according to claim 20.