Brevet FR3085513A1 — publié le 20200306

Description Titre de l'invention : Outil et procédé de conception et de validation d'un système flots de données par un modèle formel La présente invention concerne un outil de conception et de validation d'un système comportant un ensemble d'acteurs interconnectés entre eux par des canaux de communication unidirectionnels. État de la technique antérieure La présente invention s'applique à des systèmes communément appelés «systèmes flots de données » comportant un ensemble d'acteurs logiciels et/ou matériels s'échangeant entre eux des informations quantifiables, à travers des canaux de communication unidirectionnels. Chaque acteur attend d'avoir reçu une quantité de données spécifiée statiquement sur ses canaux d'entrée dans le but de consommer cette quantité de donnée, d'effectuer un traitement de ces données, et de produire une quantité de données spécifiée statiquement sur ses canaux de sortie à destination de nouveaux acteurs. Ce comportement est répété indéfiniment par chacun des acteurs. Un exemple d'un tel système de flots de données est un système embarqué temps réel pouvant être utilisé dans un véhicule autonome ou avec conducteur. La spécification de ces systèmes, prenant en compte toutes les contraintes, est un problème technique complexe en soi. Vient ensuite le travail d'allocation des ressources pour une implémentation du système spécifié, et la vérification que ces ressources sont suffisantes pour que l'implémentation fonctionne en accord avec sa spécification. Enfin, pour une implémentation donnée, il faut tester cette implémentation et s'assurer qu'elle respecte le comportement spécifié. 2 On utilise des outils automatiques pour réaliser ces différentes tâches de spécification et de vérification d'un système flot de données pouvant comprendre un grand nombre d'acteurs avec de nombreuses contraintes et reconfigurations possibles. Actuellement, il existe des algorithmes basés sur des modèles formels pour spécifier 5 des systèmes flot de données temps-réel reconfigurables. Une telle méthode est par exemple décrite dans le document M. Cette méthode permet de vérifier les ressources nécessaires à l'implémentation ainsi que l'absence d'inter-blocage entre les acteurs. Toutefois, elle ne permet pas de vérifier la conformité du comportement d'une implémentation du système spécifié vis-à-vis de sa spécification et ne permet pas de vérifier l'absence d'état inconnu dans 10 le système pour toutes les reconfigurations spécifiées. Il existe d'autres méthodes de spécification à base de modèle formel pour tester la conformité des implémentations de flots de données. Une telle méthode est par exemple décrite dans le document [2]. Toutefois, les seules contraintes que cette méthode prend en compte sont celles de temps-réel. De plus, elle ne donne un verdict que sur la conformité des 15 valeurs de sortie du système et non pas sur la conformité du comportement du système. Or dans certains cas, un système peut fournir une valeur de sortie correcte sans respecter le comportement spécifié pour autant. Actuellement, il n'existe pas de méthodes à base de modèle formel qui prennent en compte à la fois les contraintes de temps-réel et les contraintes de reconfigurations. Chacune 20 des méthodes connues ne couvre que partiellement une partie des étapes et propriétés nécessaires à la spécification et à la vérification d'un système. Aucune de ces méthodes ne couvre de manière complète la conception et la validation d'un système en prenant en compte toutes les contraintes pouvant exister dans le système. En outre, il n'y a actuellement pas de méthodes connues permettant de faire fonctionner des acteurs dans le système selon des fréquences différentes. En effet, les méthodes selon l'état de l'art ne permettent pas la vérification formelle de la faisabilité du 3 dimensionnement d'un canal de connexion entre deux acteurs fonctionnant selon des fréquences différentes sans perte de données de communication. L'objet de la présente invention est de proposer un outil et un procédé de conception et de validation d'un système flot de données remédiant aux inconvénients précités, en 5 particulier en prenant en compte l'ensemble complet de propriétés comportementales du système permettant ainsi une conception et une validation minutieuses et précises du système quelle que soit la reconfiguration tout en optimisant les ressources de calcul et de mémoire du système. Présentation de l'invention 10 La présente invention concerne un outil de conception et de validation d'un système flots de données comportant un ensemble d'acteurs logiciels et/ou matériels interconnectés entre eux par des canaux de communication unidirectionnels, ledit outil comportant : - une interface de modélisation configurée pour générer une instance dudit système en spécifiant de manière formelle un flot de données temps-réel et reconfigurable, la 15 reconfiguration du flot de données étant réalisée de manière dynamique par la propagation de données de reconfiguration d'un acteur à un autre à travers les canaux de communication, - un module d'analyse configuré pour prouver un ensemble prédéterminé de propriétés comportementales dudit système par une analyse statique de ladite instance, - une interface de raffinement adaptée pour allouer des ressources à ladite instance 20 établissant ainsi une instance configurée, l'allocation de ressource étant réalisée de manière à ce qu'une implémentation du système respecte ladite instance configurée, et - un module de test de conformité configuré pour vérifier la conformité du comportement d'une implémentation dudit système vis-à-vis de ladite instance configurée. Ce mode de réalisation par un modèle formel permet d'automatiser une conception 25 et une validation minutieuses et précises d'un système flots de données quelle que soit la reconfiguration et sans la nécessité d'avoir un contrôle centralisé. Plus particulièrement, la 4 reconfiguration de manière distribuée selon l'invention permet de prendre en compte l'ensemble complet de propriétés comportementales tout en optimisant les ressources de calcul et de mémoire du système minimisant ainsi le temps de calcul et les erreurs, et facilite les processus de certification. 5 Avantageusement, l'instance du système comporte des rythmes rationnels de consommation et d'émission de données. Ceci donne la possibilité de prendre en compte des acteurs qui doivent fonctionner selon des fréquences différentes sans aucune perte de données de communication entre ces acteurs. Ainsi, la vérification de faisabilité de la communication sans perte, et le cas échéant l'ordonnancement des opérations et la 10 synchronisation entre les tâches, peuvent être facilement réalisés quelles que soient les contraintes sur les fréquences associées aux acteurs. Avantageusement, l'instance du système comporte : - des contraintes de fréquence maximales pour certains acteurs, - des contraintes de fréquence minimales pour certains acteurs. 15 Ainsi, contrairement à l'état de l'art, on peut prendre en compte des contraintes de fréquence dans le modèle formel et dans la vérification des propriétés. Avantageusement, l'instance du système comporte : - l'ensemble des acteurs comprenant des acteurs génériques configurés pour traiter des données et des acteurs de mode configurés pour traiter des données et/ou sélectionner 20 des modes de configurations, - l'ensemble de canaux de communication unidirectionnels connectant l'ensemble des acteurs entre eux, chaque acteur étant associé à au moins un canal d'entrée ou de sortie, - le nombre rationnel ou entier de données produites ou consommées par acteur pour chacun de ses canaux d'entrée et de sortie, et 5 - l'ensemble de modes associés à chaque acteur de mode, chaque acteur de mode étant configuré pour choisir dynamiquement pour chacune de ses activations un et un seul mode parmi ledit ensemble de modes. Ceci permet d'optimiser la topologie du système et plus particulièrement, le choix 5 dynamique des configurations permet de minimiser le nombre des acteurs de mode et des canaux de connexion. Avantageusement, l'instance du système comporte en outre pour chaque acteur générique un ensemble correspondant de modes d'exécutions dans lesquels il s'exécute ainsi qu'un ensemble implicite de tous les autres modes dans lesquels il passe, un mode d'exécution 10 pouvant être soit un mode nominal commun à tout le système, soit un mode spécifique choisi par un acteur de mode. Ceci permet de faciliter la propagation de modes d'acteur en acteur. Avantageusement, l'instance du système comporte en outre un ensemble implicite de canaux de rétroaction, un canal de rétroaction étant un canal connectant un acteur 15 générique producteur de données à un acteur générique consommateur de données s'exécutant chacun dans au moins un des modes choisis par un même acteur de mode, et en ce qu'il existe un chemin sans répétition partant dudit même acteur de mode et terminant par l'acteur générique producteur en passant par l'acteur générique consommateur. Les canaux de rétroaction permettent à un acteur d'une chaine de traitement 20 d'envoyer le résultat à un précédent acteur de la chaîne pour que ce précédent acteur puisse faire un nouveau traitement en prenant en compte l'ancien résultat. L'identification de ces canaux de rétroaction permet ainsi de décrire des processus itératifs dans le système sans introduire des modes indéterminés dû à la propagation de modes. Avantageusement, l'instance du système comporte en outre un état initial du 25 système composé par canal d'un nombre rationnel et d'une séquence de modes de longueur 6 égale à une arrondie inférieure dudit nombre rationnel, et par acteur générique de son mode initial. Ceci permet d'éviter l'inter-blocage dans certaines situations comme par exemple dans le cas d'une boucle de rétroaction et permet également d'initialiser des délais pour 5 permettre le démarrage de certains types de traitement par les acteurs comme par exemple le calcul d'un produit de convolution. Avantageusement, l'ensemble prédéterminé de propriétés comportementales comporte des première, deuxième, troisième et quatrième propriétés suivantes : - la première propriété vérifie que les ressources nécessaires à l'implémentation des 10 communications entre acteurs sans perte de données sont bornées pour une exécution périodique du système spécifié, - la deuxième propriété vérifie que les contraintes de fréquence et/ou de période peuvent être respectées sans remettre en cause la première propriété, - la troisième propriété vérifie la non-existence d'inter-blocage pour tout nombre 15 d'activations des acteurs, et - la quatrième propriété vérifie la non-existence d'état inconnu dans le système pour toutes les reconfigurations spécifiées et aucune des autres propriétés n'étant remise en cause par des changements dynamiques de configuration. Ainsi, en vérifiant les quatre propriétés de manière complète, l'outil selon la présente 20 invention s'assure que le système est dans un état connu et cohérent pour toutes les reconfigurations et pour toutes les contraintes de fréquence, de période et de dimensionnement de ressources. Contrairement à l'état de l'art, la présente invention exprime la reconfiguration de manière à pouvoir prouver de manière exhaustive que les quatre propriétés soient vérifiées. 25 Selon un mode de réalisation de la présente invention, ledit système est un système embarqué temps-réel d'un équipement, configuré pour recevoir des mesures spécifiques audit 7 équipement et pour délivrer des résultats actionnant des opérations pour le bon fonctionnement dudit équipement. La présente invention vise également un système embarqué temps-réel d'un équipement, conçu et validé par l'outil selon l'une quelconque des caractéristiques 5 précédentes, ledit système embarqué étant configuré pour recevoir des mesures spécifiques audit équipement et son environnement, et pour délivrer des résultats actionnant des opérations pour le bon fonctionnement dudit équipement. Avantageusement, ledit équipement est un véhicule autonome ou non autonome de type terrestre, ferroviaire, aérospatial ou naval. 10 La présente invention vise aussi un système d'un processus industriel temps-réel, conçu et validé par l'outil selon l'une quelconque des caractéristiques précédentes, ledit système étant configure pour la fabrication industrielle des objets selon des contraintes de débit particulières et selon un processus reconfigurable. La présente invention vise également un procédé de conception et de validation d'un 15 système flots de données comportant un ensemble d'acteurs logiciels et/ou matériels interconnectés entre eux par des canaux de communication unidirectionnels, ledit procédé comportant les étapes suivantes : - générer une instance dudit système en spécifiant de manière formelle un flot de données temps-réel et reconfigurable, la reconfiguration du flot de données étant réalisée de 20 manière dynamique par la propagation de données de reconfiguration d'un acteur à un autre à travers les canaux de communication, - prouver un ensemble prédéterminé de propriétés comportementales dudit système par une analyse statique de ladite instance, - allouer des ressources à ladite instance établissant ainsi une instance configurée, 25 l'allocation de ressource étant réalisée de manière à ce qu'une implémentation du système respecte ladite instance configurée, et 8 - vérifier la conformité du comportement d'une implémentation dudit système vis-à-vis de ladite instance configurée. Brève description des figures D'autres particularités et avantages du dispositif et du procédé selon l'invention 5 ressortiront mieux à la lecture de la description faite ci-après, à titre indicatif mais non limitatif, en référence aux dessins annexés sur lesquels : La Fig.1 illustre de manière schématique des moyens matériels mis en oeuvre dans l'outil de conception et de validation d'un système flots de données, selon un mode de réalisation de l'invention ; 10 Les Fig.2A-2C montrent des exemples de flots de données ne respectant pas les propriétés comportementales telles que définies selon la présente invention ; La Fig.3 illustre de manière schématique un procédé de conception et de validation d'un système flots de données, selon un mode de réalisation de l'invention ; et La Fig.4 illustre de manière schématique un exemple d'un système flots de données 15 modélisé par un graphe selon un mode de réalisation de l'invention. Description détaillée de l'invention L'invention s'appuie sur un modèle formel pour décrire des contraintes temps-réel et des reconfigurations dynamiques dans un système flot de données, permettant la vérification d'un ensemble de propriétés nécessaires au bon fonctionnement du système. Le résultat de 20 cette analyse statique couplé à des données de configuration pour une implémentation du système permet une allocation automatique des ressources nécessaires à son exécution, tant qu'une telle allocation est faisable. Enfin, une relation de conformité formelle et un environnement de test permettent d'obtenir un verdict sur la conformité d'une telle implémentation au modèle initialement spécifié. 9 Cette invention peut s'appliquer à tout système flot de données comportant des acteurs indépendants s'échangeant entre eux des informations quantifiables, à travers des canaux de communication unidirectionnels. Les acteurs peuvent être des entités logicielles (par exemple, des applications) et/ou matérielles (par exemple, des capteurs, caméras, 5 sondes, microprocesseurs, etc.). Chaque acteur est configuré pour attendre d'avoir reçu une quantité de données spécifiée statiquement sur ses canaux d'entrée dans le but de consommer cette quantité de données, d'effectuer (ou pas) un traitement de ces données, et de produire une quantité de données spécifiée statiquement sur ses canaux de sortie à destination de nouveaux acteurs, et chacun répétant ce comportement indéfiniment. Le 10 processus de consommation/traitement/émission est communément appelé une activation. Chaque activation se déroule selon des reconfigurations prédéfinies, et pour une reconfiguration donnée, l'activation va soit consommer/traiter/produire (on dit alors s'exécuter), soit rien faire (on dit alors passer), et le choix de changer de configuration est imprédictible. 15 Chaque acteur s'active selon les reconfigurations prédéfinies dans des fenêtres temporelles (dites temps-réel) avec éventuellement des contraintes de fréquence (ou de manière équivalente avec des contraintes de période). En particulier, l'invention s'applique à un système embarqué dans un équipement où le respect du comportement attendu est considéré comme très important pour la sécurité et 20 le bon fonctionnement de l'équipement pourvu d'un tel système. Les récents systèmes embarqués temps-réels pour les véhicules autonomes sont un exemple de tels systèmes où des entités offrent des interfaces génériques pour permettre à des applications concrètes de s'échanger des données entre elles, chaque application étant indépendante et s'exécutant sur un calculateur d'une architecture distribuée. Les connexions 25 entre applications peuvent être reconfigurées en fonction du mode de fonctionnement courant du véhicule, et/ou de la disponibilité des services. Enfin, pour le bon fonctionnement du véhicule, des contraintes de temps sont imposées au fonctionnement des applications. 10 La Fig. 1 illustre de manière schématique des moyens matériels mis en oeuvre dans l'outil de conception et de validation d'un système flots de données, selon un mode de réalisation de l'invention. L'outil 1 de conception et de validation d'un système 3 flots de données met en oeuvre 5 des moyens matériels comportant une machine de traitement de l'information tel un calculateur ou ordinateur 5 comportant un microprocesseur 7 et des mémoires 9. Le microprocesseur 7 est configuré pour exécuter un ou plusieurs programmes d'ordinateur comprenant des instructions de code de programme, stockés dans les mémoires 9 de l'ordinateur 5 et conçus pour mettre en oeuvre l'outil de conception et de validation d'un 10 système 3 flot de données. L'outil 1 de conception et de validation comporte une interface de modélisation 11, un module d'analyse 13, une interface de raffinement 15, et un module de test de conformité 17. L'interface de modélisation 11 est un logiciel graphique qui est configuré pour 15 interagir avec un logiciel décrivant le système 3 flot de données. Le logiciel graphique et le logiciel décrivant le système 3 sont adaptés pour être exécutés par l'ordinateur 5. L'interface de modélisation 11 est configurée pour générer une instance du système 3 en spécifiant de manière formelle un flot de données temps-réel et reconfigurable. Par « instance », on entend la spécification du flot de données décrite dans l'interface de 20 modélisation 11. L'interface de modélisation 11 est ainsi utilisée pour spécifier le flot de données en se basant sur un modèle de calcul formel, indépendamment de toute implémentation de ce flot de données. En outre, la reconfiguration du flot de données est réalisée de manière dynamique par la propagation de données de reconfiguration d'un acteur a, à un autre a1 à travers des 25 canaux c, de communication. Cette manière d'exprimer la reconfiguration permet de vérifier 11 de manière exhaustive toutes les propriétés comportementales (décrites ci-après) du système 3. La spécification réalisée par l'interface de modélisation 11 a pour but de pouvoir prouver les propriétés comportementales du système. En effet, le module d'analyse 13 5 comporte des outils de vérifications 131 qui sont configurés pour prouver un ensemble prédéterminé de propriétés comportementales du système par une analyse statique de l'instance. L'interface de raffinement 15 est configurée pour allouer des ressources à l'instance établissant ainsi une instance appelée dans la suite « instance configurée ». L'allocation de 10 ressource est réalisée de manière à ce qu'une implémentation du système 3 respecte l'instance configurée. L'interface de raffinement 15 est ainsi utilisée pour spécifier des contraintes temporelles supplémentaires pour l'instance. On notera que l'interface de raffinement 15 peut spécifier plusieurs instances configurées pour une même instance. Un outil de conversion 19 15 adapte le résultat de l'analyse statique d'une instance pour fournir des entrées permettant l'allocation de ressources pour une instance configurée. Le module de test de conformité 17 est configuré pour vérifier la conformité du comportement d'une implémentation du système 3 de flot de données vis-à-vis de l'instance configu rée. 20 Plus particulièrement, pour un acteur a, d'une instance configurée, on appelle une « implémentation de cet acteur » toute entité concrète qui réalise le comportement spécifié pour cet acteur ai. On notera qu'il peut y avoir plusieurs implémentations pour un même acteur. En outre, pour une instance configurée, on appelle une « implémentation de cette instance configurée » toute collection d'implémentations des acteurs composant l'instance, 25 associée aux moyens concrets leur permettant de réaliser le comportement spécifié pour cette instance. On notera également qu'il peut y avoir plusieurs implémentations pour une même 12 instance configurée. Par ailleurs, pour une implémentation d'une instance configurée, on appelle « trace » une séquence d'événements signifiants survenus lors d'une exécution de cette implémentation. Avantageusement, le module de test de conformité 17 est composé d'un outil de test 5 unitaire 171 et d'un outil de test d'intégration 173. L'outil de test unitaire 171 simule la production de données sur les canaux d'entrée de l'implémentation d'un acteur a,, et vérifie que les quantités consommées et produites par cette implémentation correspondent à celles spécifiées pour l'acteur implémenté, en respectant toutes les contraintes. L'outil de test d'intégration 173 construit l'ensemble des traces qui correspondent au comportement 10 attendu de l'instance configurée et s'assure que la trace fournie appartient à cet ensemble valide. Selon un mode de réalisation avantageux de la présente invention, l'instance du système 3 comporte des rythmes rationnels de consommation et d'émission de données. Ainsi, l'instance comporte un nombre rationnel ou entier de données produites ou 15 consommées par chaque acteur a, et pour chacun de ses canaux c, d'entrée et de sortie. Ce mode de réalisation permet d'intégrer des contraintes de fréquence au niveau du modèle formel et dans la vérification des propriétés et, par conséquent, permet à deux acteurs a, et a, communiquant entre eux via un canal c, de fonctionner selon des fréquences différentes sans aucune perte de données de communication entre ces deux acteurs (voir l'exemple de la 20 Fig. 4). L'outil 1 de conception et de validation selon la présente invention garantit la faisabilité et la cohérence du système 3 flot de données en permettant la vérification de l'ensemble prédéterminé de propriétés comportementales couvrant toutes les reconfigurations et toutes les contraintes de fréquence, de période et de dimensionnement 25 de ressources. Cet ensemble prédéterminé de propriétés comportementales comporte les quatre propriétés suivantes. 13 La première propriété P1 vérifie que les ressources nécessaires à l'implémentation des communications entre acteurs sans perte de données sont bornées pour une exécution périodique du système spécifié. Ceci permet par exemple de dimensionner les mémoires nécessaires pour stocker les données sans perte. 5 La Fig. 2A montre un exemple d'un flot de données ne respectant pas la première propriété. Cet exemple montre un système comportant des premier et second acteurs ai et az s'échangeant mutuellement des données à travers les canaux ci et cz. Le premier acteur ai spécifie qu'il produit et consomme une donnée à chaque activation. Le deuxième acteur az spécifie qu'il produit deux données et en consomme une à chaque activation. Toutefois, les 10 ressources nécessaires pour stocker les données sur le canal de sortie cz du deuxième acteur az ne peuvent pas être bornées pour un nombre indéfini d'activations de ces acteurs. Ainsi, dans cette situation la première propriété P1 n'est pas vérifiée. La deuxième propriété P2 vérifie le fait que les contraintes de fréquence et/ou de période peuvent être respectées sans que la première propriété soit remise en cause. 15 La Fig. 2B montre un exemple d'un flot de données ne respectant pas la deuxième propriété. Cet exemple montre également un système à deux acteurs a1 et az, le premier acteur produisant une donnée par activation qui sera consommée par chaque activation du deuxième acteur. Les contraintes de fréquence sont telles que le premier acteur ai doit s'activer à 100Hz et le deuxième az à 10Hz. Toutefois, les ressources nécessaires pour stocker 20 les données sur le canal ci connectant les deux acteurs ai et az ne peuvent pas être bornées pour un nombre indéfini d'activations, bien qu'elles soient bornées si on retire les contraintes de fréquence. La troisième propriété P3 vérifie la non-existence d'inter-blocage pour tout nombre d'activations des acteurs. Un inter-blocage peut résulter dans une situation où un ensemble 25 d'acteurs s'échangent des données de manière cyclique. En reprenant l'exemple de la Fig. 2A, en l'absence d'une donnée présente initialement sur un des deux canaux ci et cz, aucun des 14 acteurs ai et az ne peut s'activer. Ainsi, la troisième propriété P3 permet de prendre en compte le cas de flot de données cyclique. La quatrième propriété P4 vérifie la non-existence d'état inconnu dans le système pour toutes les reconfigurations spécifiées, il n'y a pas d'acteur dans le système qui ne 5 s'exécute dans aucune des reconfigurations spécifiées, et aucune des autres propriétés n'étant remise en cause par des changements dynamiques de configuration. La Fig. 2C montre un exemple d'un flot de données ne respectant pas la quatrième propriété. Cet exemple montre un système à trois acteurs ai, az et a3 et selon deux reconfigurations possibles. Un premier acteur ai produit une donnée par activation, qui est 10 consommée par chaque activation d'un deuxième acteur az, et ce deuxième acteur az produit lui-même une donnée par activation, consommée par chaque activation d'un troisième acteur a3. Dans une première configuration Ri, seuls les premier et deuxième acteurs ai et a2 s'exécutent et le troisième acteur a3 passe. Dans une deuxième configuration R2 seuls les deuxième et troisième acteurs a2 et a3 s'exécutent et le premier acteur ai passe. Dans un tel 15 système, si le mode de reconfiguration choisi est toujours la première configuration Ri, alors les ressources nécessaires pour stocker les données sur le canal cz entre le deuxième acteur az et le troisième acteur a3 ne sont pas bornées pour un nombre indéterminé d'activations. A l'inverse, il y a un inter-blocage si la deuxième configuration R2 est toujours choisie. Enfin, si on modifie l'exemple tel que n'importe lequel de ces acteurs ai, az et a3 ne s'active dans aucune 20 configuration, on aboutit à des situations similaires. Ainsi, la quatrième propriété P4 permet de vérifier la cohérence du système pour tous les modes de reconfigurations spécifiés en s'assurant qu'il n'y ait aucune information contradictoire. On notera que contrairement aux méthodes de l'état de l'art, la manière dont la notion de reconfiguration est exprimée selon la présente invention permet de prouver de 25 manière exhaustive les quatre propriétés P1-P4. La Fig. 3 illustre de manière schématique un procédé de conception et de validation d'un système flots de données, selon un mode de réalisation de l'invention. 15 On notera que les étapes qui se trouvent sur un même niveau peuvent s'enchainer parallèlement à la suite de l'étape précédente. En outre, les étapes illustrées avec une spirale (i.e. les étapes E22, E41-E43, et E52) dénotent la possibilité d'appliquer plusieurs fois cette étape pour des configurations différentes d'une même instance, ou des implémentations 5 différentes d'une même instance configurée, ou des traces différentes d'une même implémentation. L'étape El concerne la génération d'une instance par la spécification d'un système 3 flot de données reconfigurable temps-réel dans le but de pouvoir prouver l'ensemble des quatre propriétés comportementales P1-P4 de ce système 3 définies ci-dessus. 10 L'instance du système 3 comporte tous les éléments définissant le formalisme du modèle de calcul. Ces éléments comportent l'ensemble des acteurs a,, a, comprenant les acteurs dits génériques qui traitent des données et des acteurs dits de mode qui sont en charge de signaler des reconfigurations et/ou de traiter des données ; l'ensemble des canaux c,, connectant ces acteurs entre eux ; le nombre de données produites ou consommées par 15 acteur pour chacun de ses canaux d'entrée ou de sortie, avec la possibilité pour un canal d'avoir un seul de ces nombres qui soit un nombre rationnel ; l'ensemble de modes de reconfigurations ; les contraintes de fréquence maximales pour certains acteurs génériques ou de mode ; les contraintes de fréquence minimales pour certains acteurs génériques ou de mode ; et l'état initial du système. 20 L'étape E21 concerne la vérification par une analyse statique de l'ensemble de propriétés comportementales P1-P4 pour cette instance. Ceci permet de vérifier la faisabilité du système indépendamment des ressources allouées. L'étape E22 concerne l'obtention des contraintes temporelles pour cette instance. L'étape E3 concerne la construction des contraintes d'ordonnancement et les traces 25 valides (i.e. ensemble des états valides) pour l'instance configurée dans les étapes 16 précédentes. Cette étape permet de définir l'ordre dans lequel les acteurs doivent faire leurs opérations en fonction des données et des contraintes temporelles. A l'étape E41 des ressources sont allouées pour respecter les contraintes d'ordonnancement de l'instance configurée. 5 A l'étape E42, on obtient une implémentation d'un acteur de l'instance configurée. A l'étape E43, on obtient une implémentation de l'instance configurée. A l'étape E51, on teste la conformité de l'implémentation de l'étape E42. A l'étape E52, on obtient une trace de l'implémentation de l'étape E43. Finalement, à l'étape E6, on teste la conformité de la trace obtenue à l'étape E43 10 permettant ainsi de vérifier la conformité de l'implémentation au modèle spécifié. Le procédé selon la Fig. 3 couvre ainsi la spécification d'un système 3 flot de données reconfigurable temps-réel, la configuration d'une allocation de ressources et la vérification de la conformité du comportement d'une implémentation du système, en prenant en compte les quatre propriétés P1-P4 ci-dessus dans leur ensemble. 15 La Fig. 4 illustre de manière schématique un exemple d'un système flots de données modélisé par un graphe selon un mode de réalisation de l'invention. Le graphe modélise un flot de données avec des contraintes de fréquence, différents modes de reconfigurations et des données initiales disponibles pour une consommation initiale. Les cercles ai-as représentent des acteurs dits génériques qui effectuent des 20 traitements sur les données. Ces acteurs génériques aras sont ainsi adaptés pour consommer des données, faire des calculs pour transformer les données et produire des résultats. Les triangles a6 et a7 représentent des acteurs dits « horloge » a6 ou « échéance » a7qui produisent et consomment des données avec des contraintes de fréquence. Le carré as représente un acteur dit de mode as en charge de signaler des reconfigurations. Les arcs dirigés ci-cie sont 25 des canaux unidirectionnels indiquant chacun un flot de données entre deux acteurs et les 17 valeurs numériques associées donnant la quantité de données produite ou consommée sur le canal. Selon cet exemple, le système 3 modélisé est composé de cinq acteurs génériques ai-as, deux acteurs temporels as et a7 (horloge et échéance) et d'un acteur de mode as. Un 5 premier acteur générique ai (acteur d'acquisition) fait l'acquisition de données fournies par un acteur horloge as à 30Hz. Un deuxième acteur générique az (acteur de commande) envoie une commande à un acteur actuateur a7 à 10Hz. La commande est déterminée selon le résultat d'une chaîne de traitement reconfigurable constituée d'un troisième acteur générique a3 (acteur de prétraitement) effectuant un prétraitement de la donnée produite par l'acteur 10 d'acquisition ai dans toutes les reconfigurations possibles. Dans une première configuration (mode noté par Al), un quatrième acteur générique a4 (acteur rapide) effectue un traitement rapide et basse définition de la donnée prétraitée par l'acteur de prétraitement a3. Dans la deuxième reconfigu ration (mode noté par A2), un cinquième acteur générique as (acteur lent) effectue un traitement lent mais de haute définition. Ainsi, le chemin de traitement des 15 données de la première configuration .1.1 est le chemin reliant l'acteur d'acquisition ai à l'acteur de prétraitement a3, à l'acteur de traitement rapide a4 et puis finalement à l'acteur de commande az. La deuxième configuration .12 est définie par le chemin reliant l'acteur d'acquisition ai à l'acteur de prétraitement a3, à l'acteur de traitement lent as et puis finalement à l'acteur de commande a2. Ainsi, la configuration se propage d'un acteur à un autre 20 et par conséquent, aucune synchronisation centralisée sur ces modes de reconfigurations n'est nécessaire. Chaque acteur va communiquer à son voisin le mode de configuration dans lequel il doit fonctionner. Le choix de la configuration courante est effectué par l'acteur de mode a8 qui utilise de préférence le traitement haute définition lorsqu'il est disponible. Selon cet exemple, l'acteur de traitement rapide a4 à chaque fois qu'il s'active 25 consomme une donnée sur son canal d'entrée c3 (représenté sur le canal c3 par un « 1 ») et produit une donnée sur son canal de sortie c4 (représenté sur le canal c4 par un « 1 »). De même pour l'acteur de traitement lent as qui consomme une donnée sur son canal d'entrée cs et 18 produit une donnée sur son canal de sortie cs. L'acteur de commande az à chaque fois qu'il s'active consomme une donnée sur son premier canal d'entrée c4 ou sur son deuxième canal d'entrée c4 (selon le mode de configuration) et produit une donnée sur son canal de sortie cz. L'acteur de prétraitement a3à chaque fois qu'il s'active consomme une donnée sur son premier 5 canal d'entrée ci et une donnée sur son deuxième canal d'entrée cg et produit une donnée sur son premier canal de sortie c3 ou sur son deuxième canal de sortie cs (selon le mode de configuration). En revanche, l'acteur d'acquisition ai consomme un nombre rationnel de données sur son canal d'entrée cz (représenté sur le canal d'entrée cz par la valeur « 1/3 ») et produit un 10 nombre rationnel de données sur son canal de sortie ci (représenté sur le canal de sortie c1 par la valeur « 1/3 »). Ceci veut dire que l'acteur d'acquisition ai consomme ou produit une donnée toutes les trois activations. L'exemple de la Fig. 4 montre qu'à l'état initial, il y a un jeton T1 (i.e. une donnée) disponible sur le canal cz (entre l'acteur de commande az et l'acteur d'acquisition ai. Alors, l'acteur d'acquisition al va consommer cette donnée existante sur ce 15 canal cz et va produire une donnée sur son canal de sortie ci (i.e. le canal ci reliant l'acteur d'acquisition ai à l'acteur de prétraitement a3). Ainsi, l'acteur d'acquisition a1 a consommée une donnée et a produit une donnée. En revanche, sur ses deux prochaines activations, il va consommer zéro donnée et produire zéro donnée. Autrement dit, l'acteur d'acquisition ai consomme une donnée et produit une donnée toutes les trois activations. Ceci permet de 20 synchroniser les données entre deux acteurs fonctionnant selon des fréquences différentes sans aucune perte de données. En effet, selon cet exemple, l'acquisition apparait trois fois pour chaque commande permettant ainsi le transfert de données entre l'acteur d'acquisition ai fonctionnant à 30 Hz et l'acteur de commande az fonctionnant à 10 Hz sans aucune perte de données. 25 Dans la suite, on résume les éléments essentiels de la définition formelle du modèle de calcul (i.e. formalisme) en faisant référence à titre d'exemple au système 3 de la Fig. 4. Selon ce formalisme, la spécification d'un flot de données se compose des éléments F1-F9 suivants : 19 F1 : On définit l'ensemble des acteurs génériques ai-as qui traitent des données, ainsi que l'ensemble des acteurs de mode a6 et a7 qui traitent des données et/ou sélectionnent des modes de configurations. F2 : On définit, l'ensemble des canaux crcio connectant les acteurs entre eux, chaque 5 acteur étant associé à au moins un canal d'entrée ou de sortie. F3 : On définit le nombre de données produites ou consommées par acteur pour chacun de ses canaux d'entrée ou de sortie, avec avantageusement la possibilité pour un canal d'avoir un seul de ces nombres qui soit un nombre rationnel. Ces nombres sont représentés par les valeurs sur les arcs ci-cio connectant les acteurs de l'exemple de la Fig. 4. 10 F4: Pour chaque acteur de mode as d'un ensemble non vide de modes, l'acteur de mode as étant en charge de choisir dynamiquement pour chacune de ses activations un et un seul de ces modes (Ces modes sont notés .1.1 et/12). Le choix de la configuration courante est avantageusement fait par un acteur de mode as unique et cette configuration courante se propage de manière distribuée d'un acteur à un autre. 15 F5 : Pour chaque acteur générique ai-as, on définit l'ensemble des modes dans lesquels il s'exécute, et l'ensemble implicite de tous les autres modes dans lesquels il passe. On notera que l'ensemble des modes dans lesquels un acteur générique s'exécute est soit un mode nominal commun à tout le système, soit un sous-ensemble des modes choisis par des acteurs de mode. Dans l'exemple de la Fig. 4, tous les acteurs à l'exception des acteurs de 20 prétraitement a3, de traitement rapide a4 et traitement lent as s'exécutent dans le mode nominal sachant que l'acteur de prétraitement a3 s'exécute dans les modes Ai et À2, l'acteur de traitement rapide a4 s'exécute dans le mode .11, et l'acteur de traitement lent as s'exécute dans le mode 2.2. F6 : Étant donnés les différents modes, on définit un ensemble implicite de canaux de 25 rétroaction comme l'ensemble des canaux connectant deux acteurs génériques s'exécutant chacun dans au moins un des modes choisis par un même acteur de mode, et tels qu'il existe 20 un chemin sans répétition partant de l'acteur de mode et se terminant par l'acteur producteur sur ce canal, en passant par un acteur consommateur. F7 : On définit des contraintes de fréquence maximale pour certains acteurs génériques ou de mode. Une manière possible de les exprimer est par des acteurs dits 5 d'horloge as auxquels on associe une fréquence. Dans l'exemple de la Fig. 4, l'acteur d'acquisition ai a une contrainte de fréquence maximale de 30Hz, exprimée par l'acteur horloge as avec pour fréquence 30Hz, l'arc c7 les connectant, et les quantités de données associées. F8 : On définit des contraintes de fréquence minimale pour certains acteurs 10 génériques ou de mode. Une manière possible de les exprimer est par des acteurs dits d'échéance a7 auxquels on associe une fréquence. Dans l'exemple de la Fig. 4, l'acteur de commande a2 a une contrainte de fréquence minimale de 10Hz, exprimée par l'acteur échéance a7 avec pour fréquence 10Hz, l'arc c8 les connectant, et les quantités de données associées. On notera qu'un même acteur peut être contraint de fonctionner à une fréquence 15 minimale et maximale, dans ce cas c'est une contrainte de fréquence exacte. Autrement dit, une contrainte de fréquence est soit maximale (pas plus que tant de fois par seconde), soit minimale (au moins tant de fois par seconde), soit exacte (exactement tant de fois par seconde). F9 : Un état initial du système composé par canal d'un nombre rationnel et d'une 20 séquence de modes de longueur égale à l'arrondi inférieur de ce nombre rationnel, et par acteur générique de son mode initial. Dans l'exemple de la Fig. 4, tous les acteurs ont pour mode initial le mode nominal, et les canaux marqués par un petit cercle T1 et T2 ont un état initial de valeur « 1 ». Bien entendu, l'état initial peut être exprimé par un nombre rationnel quelconque (par exemple, 2/5 ; 4/3 ;etc.) et ceci découle du fait que les rythmes de production 25 et consommation sont rationnels selon un mode de réalisation avantageux de l'invention. En outre, pour une spécification donnée, le comportement spécifié pour le système comporte les caractéristiques C1-C7 suivantes : 21 Cl : La politique de production dans les canaux est une politique de premier-entrépremier-sorti (FIFO) non-bloquante. C2 : La politique de consommation depuis les canaux est FIFO bloquante. Ainsi, quand un acteur va produire une donnée sur un canal, il ne va pas être bloqué par l'acteur 5 consommateur. C3 : Les canaux contiennent des quantités élémentaires de données (i.e. jetons T1, T2). Un jeton est une unité arbitraire qui indique le nombre de données sur un canal à un moment donné. Les jetons sont tous constitués d'un mode et soit de données signifiantes produites par une exécution, soit d'aucune donnée. Ces derniers jetons représentent 10 avantageusement l'absence de données produites lorsque le producteur ou le consommateur passe dans un mode donné. Avantageusement, ceci permet de préserver la synchronisation entre les tâches sans le besoin d'envoyer des données effectives. C4 : A tout instant, l'état d'un canal est un nombre rationnel, et le nombre entier de jetons qu'il contient est l'arrondi inférieur de ce nombre. Avantageusement, ceci permet de 15 déterminer à quel moment le jeton va être consommé. Dans l'exemple de la Fig. 4, on a initialement un jeton T1 (i.e. le nombre rationnel 1/1) sur un canal c2. L'acteur d'acquisition ai va consommer 1/3 ce qui va transformer l'état du canal c2 de 1/1 à 2/3 (i.e. 1-1/3) arrondi à la valeur zéro. Toutefois, l'état du canal c2 est 2/3 qui va permettre à l'acteur d'acquisition ai lorsqu'il est activé de retirer à nouveau 1/3 ce qui va transformer l'état du canal c2 de 2/3 à 1/3 20 (i.e. 2/3 -1/3) arrondi à la valeur zéro. Finalement, sur sa troisième activation l'acteur d'acquisition ai retire à nouveau 1/3 ce qui va transformer l'état du canal c2 de 1/3 à zéro. Ainsi, un jeton T1 est consommé par l'acteur d'acquisition ai toute les trois activations. C5 : L'activation atomique de chaque acteur (peu importe qu'il s'exécute ou qu'il passe), retire le nombre rationnel spécifié de l'état de chacun de ses canaux d'entrée et ajoute 25 le nombre rationnel spécifié à l'état de chacun de ses canaux de sortie. On notera qu'un processus atomique est un processus indivisible de production et de consommation qui a un début et une fin bien identifiés. Le nombre de jetons consommés ou produits est la valeur 22 absolue de la différence entre l'arrondi inférieur de l'état du canal avant activation et l'arrondi inférieur de l'état du canal après activation. C6 : A chaque activation d'un acteur de mode, il s'exécute et choisit un et un seul des modes qui lui sont associés d'une manière arbitraire. Il associe à chaque jeton produit le mode 5 choisi par cette activation. Pour ses consommateurs qui vont potentiellement s'exécuter dans ce mode choisi, et seulement pour ceux-là, il associe à chaque jeton des données signifiantes. On notera que dans l'état de l'art, on change la quantité de données produites pour empêcher l'activation d'un successeur. En revanche, le mode de propagation selon l'invention, permet de produire systématiquement des jetons, potentiellement vides selon le mode choisi, ce qui 10 n'empêche pas l'activation du successeur, et permet donc de préserver les propriétés (voir ci- après). C7 : Avant chaque activation d'un acteur générique, son mode courant est déterminé par l'ensemble L des modes associés à un jeton qui sera consommé pour chaque canal, les canaux pour lesquels aucun jeton n'est consommé dans cette activation étant ignorés. Le jeton 15 considéré (par exemple le dernier consommé) sur chaque canal est choisi de manière déterministe. Dans une réalisation possible, la règle de détermination peut être réalisée selon les points (a)-(f) suivants : (a) : si l'ensemble L est vide (i.e. l'acteur n'a pas de prédécesseurs), le mode courant est systématiquement nominal ; 20 (b) : si l'ensemble est un singleton, le mode courant est alors cet unique élément de L; (c) : si l'ensemble a plus d'un élément, et qu'il contient le mode indéterminé (voir ci-dessous), le mode est indéterminé ; (d) : si l'ensemble a plus d'un élément, et que l'acteur s'exécute uniquement en mode nominal, le mode courant est le mode nominal ; et 25 (e) : si l'ensemble a plus d'un élément, et que l'acteur s'exécute dans un ou plusieurs des modes A sélectionnés par un acteur de mode, alors si L n A est vide, le mode courant ne 23 change pas, si L n A est un singleton, le mode courant est l'unique élément de L n A, et le mode est indéterminé dans tous les autres cas. L'activation de chaque acteur générique se fait dans son mode courant. Le mode courant est associé à tous les jetons produits par cette activation, sauf ceux produits sur un 5 canal de rétroaction, auxquels est associé le mode nominal. Les données associées aux jetons produits sont déterminées par le mode courant. Si l'acteur passe dans son mode courant, les jetons produits ne contiennent aucune donnée. Si l'acteur s'exécute dans son mode courant, pour ses consommateurs qui vont potentiellement s'exécuter dans ce mode choisi, ses consommateurs qui sont connectés à lui par un canal de rétroaction, et seulement pour ceux- 10 là, il associe à chaque jeton produit des données signifiantes. Pour tous ses autres consommateurs il n'associe aucune donnée. Si un acteur a une contrainte de fréquence maximale, alors deux activations successives ne peuvent pas avoir lieu plus vite que cette fréquence. Si un acteur a une contrainte de fréquence minimale, alors deux activations 15 successives ne peuvent pas avoir lieu moins vite que cette fréquence. Dans la suite, on donne à titre d'exemple, des méthodes pour prouver les quatre propriétés P1-P4. Première propriété Pl: Une façon possible de prouver la première propriété pour n'importe quelle instance se base sur des méthodes connues pour les flots de données. 20 Toutefois, la présente preuve se démarque en prenant en compte les quantités rationnelles: Cette preuve est définie par les deux étapes suivantes P11 et P12: Première étape Pll : Construire une matrice, notée I', avec une ligne par canal et une colonne par acteur, et pour chaque entrée de cette matrice on a : el : la valeur 0 si l'acteur n'est pas connecté à ce canal ; 25 e2 : le nombre (potentiellement rationnel) ajouté à l'état du canal pour chaque activation de l'acteur s'il est producteur sur ce canal ; 24 e3 : l'opposé du nombre (potentiellement rationnel) retranché à l'état du canal pour chaque activation de l'acteur s'il est consommateur sur ce canal ; et e4 : la différence entre les nombres (dont un potentiellement rationnel) ajoutés et retranchés à l'état du canal pour chaque activation de l'acteur si il est à la fois producteur et 5 consommateur sur ce canal. Deuxième étape P12 : Résoudre le système d'équations permettant de trouver un vecteur d'entiers naturels x # 0 tel que T. x = O. Trouver un tel vecteur x prouve la première propriété P1. Ce vecteur est ensuite utilisé pour prouver les autres propriétés. Deuxième propriété P2 : Dans une réalisation dans laquelle les contraintes de temps 10 sont décrites comme dans la Fig. 4, la capacité de vérifier la deuxième propriété pour des instances peut se faire selon les étapes innovantes P21-P25 suivantes : Première étape P21 : Vérifier que si un acteur a des contraintes de fréquence maximale et minimale, elles sont égales. Deuxième étape P22 : Calculer le plus grand commun diviseur t de toutes les 15 contraintes de fréquence dans le système, et leur plus petit commun multiple 7r. Troisième étape P23 : Etant donné le vecteur x, de manière arbitraire, choisir un acteur de colonne i dans I' avec une contrainte de fréquence notée 60, et avec l'élément xL de x. Quatrième étape P24 : Calculer le nombre entier suivant: 20 Lx; k = Cinquième étape P25 : Vérifier que pour tout acteur de colonne i dans I" avec une contrainte de fréquence notée w, et avec l'élément x, de x on a: k. ait = 25 Troisième propriété P3 : Une manière possible de prouver la troisième propriété P3 se base sur une méthode connue pour les flots de données en général mais en se démarquant par la prise en compte des quantités rationnelles. Étant donné x et l'état initial des canaux, cette méthode consiste à effectuer une activation symbolique du système dans laquelle 5 chaque acteur de colonne é dans F est activé au moins xt fois, et s'assurer que cette exécution termine. Quatrième propriété P4 : La méthode de prouver la quatrième propriété P4 découle de la manière dont les modes et les données sont associés aux jetons pour propager les modes selon le mode de réalisation innovant de la présente invention. La méthode qui suit est un 10 exemple non limitatif de la vérification de cette propriété P4 selon les étapes P41-P47 suivantes : Première étape P41 : Vérifier que les ensembles de modes choisis par les acteurs de mode sont disjoints deux à deux (un mode est choisi par un et un seul acteur de mode). Deuxième étape P42 : Vérifier également que l'ensemble des modes associés à 15 chaque acteur générique est soit le singleton contenant le mode nominal du système, soit un sous-ensemble de l'ensemble de modes choisis par un acteur de mode. On notera que les modes associés à un acteur générique sont tous sélectionnés par le même acteur de mode. Troisième étape P43 : Vérifier que si un acteur générique a un ensemble de modes associé qui est un sous-ensemble de ceux choisis par un acteur de mode, alors : soit cet acteur 20 de mode est un prédécesseur direct de cet acteur générique ; soit il y a au moins un des prédécesseurs directs de cet acteur tel que l'ensemble des modes associés à ce prédécesseur est un sous-ensemble de l'ensemble des modes choisis par cet acteur de mode. Quatrième étape P44 : Pour tous les acteurs de colonne i dans F qui s'exécutent dans au moins un mode choisi par un même acteur de mode de colonne j dans F, et qui sont sur un 25 chemin partant de cet acteur de mode, et passant uniquement par des acteurs qui s'exécutent dans au moins un des modes choisis par cet acteur de mode, alors : 26 (a) Etant donné l'état initial des canaux, calculer le délai initial noté d, tel que pour les d, premières activations de l'acteur i son mode courant est connu ; (b) Pour chaque canal d'entrée (sauf canal de rétroaction) avec pour producteur un acteur de colonne k dans I' qui soit s'exécute dans un mode choisi par l'acteur de mode de 5 colonne j dans I', soit est l'acteur de mode de colonne j dans I', calculer la période de changement de mode locale notée pik telle que : Xk Pik = - xi (c) Calculer la période de changement de mode notée p, comme étant le maximum des périodes locales calculées précédemment : 10 Pi = max(Pik) Vk (d) Vérifier que pour toute période locale calculée précédemment la période de changement de mode est un multiple de cette période locale : Vp,k, ink E N, nk. pu, = Pi Cinquième étape P45: Etant donné x, et le plus grand commun diviseur des 15 composantes de x noté g, calculer un vecteur y = (-g).x avec k un entier naturel tel que pour chacun des acteurs considérés à l'étape précédente, on a : y, cl, + g Sixième étape P46: Effectuer une exécution symbolique du flot de données avec au moins y, activations pour tous les acteurs, en considérant que la manière dont les acteurs de 20 mode choisissent un mode à chaque activation est une sélection tourniquet (round-robin) de tous les modes qu'ils choisissent. 2x, Septième étape P47 : S'assurer qu'aucun mode n'était indéterminé dans l'exécution symbolique. 27 Les contraintes temporelles pour une instance sont composées des éléments suivants : un budget de temps pour tous les acteurs ; un délai initial pour tous les acteurs ; un symbole associé à chaque acteur le déclarant comme étant soit persistant soit éphémère ; un symbole associé à chaque acteur avec une contrainte de fréquence minimale déclarant sa 5 contrainte comme étant stricte ou relâchée ; et une échéance initiale associée à chaque acteur avec une contrainte de fréquence minimale. Pour une instance configurée, le comportement spécifié est le même que décrit précédemment pour une instance seule, mais avec les contraintes suivantes en plus : Une horloge mesure l'écoulement du temps à partir d'une date initiale. Le temps écoulé entre le 10 début et la fin de l'activation de n'importe quel acteur est inférieur ou égal au budget associé à cet acteur. Aucune activation d'un acteur ne commence avant que son délai initial ne soit écoulé. Le début d'une activation d'un acteur éphémère a toujours lieu après le début de la précédente activation de ce même acteur. Le début d'une activation d'un acteur persistant a toujours lieu après la fin de la précédente activation de ce même acteur. Pour un acteur avec 15 une contrainte de fréquence minimale, à chacune de ses activations est associée une échéance. Pour la première activation, cette échéance est égale à l'échéance initiale, et pour les suivantes, leur échéance est égale à l'échéance de la précédente activation de ce même acteur plus l'inverse de la fréquence minimale (i.e. la période minimale). La fin de l'activation d'un acteur avec une contrainte de fréquence minimale a toujours lieu avant son échéance. 20 Pour un acteur avec une contrainte de fréquence maximale, à chacune de ses activations est associé un délai ; pour la première activation, cette échéance est égale au délai initial, et pour les suivantes, leur délai est égal au délai de la précédente activation de ce même acteur plus l'inverse de la fréquence maximale (i.e. la période maximale). Le début de l'activation d'un acteur avec une contrainte de fréquence maximale a toujours lieu après son délai. 25 Le procédé de construction des contraintes d'ordonnancement (entrées pour des méthodologies existantes d'allocation de ressources) comporte les étapes suivantes : 28 Étape 1 : Étant donné x, associer à chaque acteur de colonne i dans I' une séquence d'au moins 2. xi éléments où le jème élément est défini par : une variable su pour la date de début de la jème activation de i; une variable eu pour la date de fin de la jème activation de i; et une variable du pour l'échéance de la »me activation de i. 5 Étape 2 : Définir un ensemble de contraintes linéaires telles que : Si d'après la matrice I' et l'état initial des canaux la jème activation d'un acteur i consomme au moins un jeton depuis un canal et que ce même jeton est produit par la jème activation d'un acteur k alors on a eki S3 : Observer les productions résultantes de cette implémentation. S4: Vérifier que les quantités consommées par cette implémentation sont celles prévues par la spécification, à savoir pour les exemples de scenarios donnés précédemment : (a) Sous-production : cette implémentation ne s'active pas et ne consomme rien. (b) 5 Production exacte : cette implémentation s'active exactement une fois et consomme les quantités spécifiées sur chaque canal d'entrée. (c) Sur-production : cette implémentation s'active exactement le nombre de fois successives prévu par le scenario, et consomme à chaque fois les quantités spécifiées sur chaque canal d'entrée. 55 : Vérifier que les quantités produites par cette implémentation sont celles prévues 10 par la spécification, à savoir pour les exemples de scenarios donnés précédemment : (a) Sous- production : cette implémentation ne s'active pas et ne produit rien. (b) Production exacte : cette implémentation s'active exactement une fois et produit les quantités spécifiées sur chaque canal de sortie. (c) Sur-production : cette implémentation s'active exactement le nombre de fois successives prévu par le scenario, et produit à chaque fois les quantités 15 spécifiées sur chaque canal de sortie. S6: Vérifier que le temps d'activité est correct vis-à-vis de la configuration de l'instance, à savoir pour les exemples de scenarios donnés précédemment : (a) Sous-production : cette implémentation ne s'active pas et son temps d'activité est nul. (b) Production exacte : cette implémentation s'active exactement une fois et son temps d'activité 20 est inférieur ou égal au budget de temps de l'acteur correspondant à l'implémentation testée, et se produit dans les bornes définies par les variables su et eu correspondantes. (c) Surproduction : cette implémentation s'active exactement le nombre de fois successives prévu par le scenario, et pour chacune de ces activations, son temps d'activité est inférieur ou égal au budget de temps de l'acteur correspondant à l'implémentation testée, et se produit dans 25 les bornes définies par les variables st./ et eu correspondantes. Pour vérifier la conformité d'une implémentation d'une instance configurée, on peut utiliser par exemple les « Timed Input Output Transition Systems » (TIOTS) comme décrit dans 31 [4]. La présente invention se différencie par le fait qu'au lieu de considérer les valeurs des données produites en réponse à des valeurs d'entrée, on considère l'état des canaux de communication. Par exemple, si un acteur produit un jeton contenant une chaîne de caractères comme donnée, dans l'état de l'art on observerait la chaîne de caractères, en revanche dans 5 la présente invention, on observera la valeur « 1 », étant le nombre de jetons disponibles dans le canal. Ainsi le procédé pour construire les traces valides est le suivant : Construire un automate pour chaque acteur correspondant au comportement spécifié de cet acteur dans le formalisme décrit dans [4], dans lequel les valeurs produites/consommées sur les canaux sont 10 des valeurs numériques indiquant l'état du canal. Ensuite, évaluer tous les chemins possibles dans une exécution symbolique du système comme décrit dans [4] de sorte à observer le comportement périodique décrit par le vecteur x. Les traces d'une exécution d'une implémentation d'une instance peuvent être fournies par un observateur d'une exécution de l'implémentation. Chaque entrée d'une trace 15 fournit les informations sur l'état de l'implémentation à chaque modification de cet état. Par exemple : la date courante de l'horloge de l'implémentation de l'instance configurée, le nombre de jetons disponibles à la consommation pour tous les canaux, et le mode associé aux jetons disponibles à la consommation. Etant donnée une telle trace, on peut vérifier la conformité de l'exécution de 20 l'implémentation vis-à-vis du comportement spécifié de l'instance correspondante, comme décrit dans [4]. La présente invention s'applique à tous les systèmes à flot de données. Une première application concerne les systèmes distribués temps-réel critiques. En particulier, un système embarqué temps-réel d'un équipement, configuré pour recevoir des mesures spécifiques de 25 l'équipement et son environnement et pour délivrer des résultats actionnant des opérations pour le bon fonctionnement de cet équipement. L'équipement peut être un véhicule autonome ou non autonome de type terrestre, ferroviaire, aérospatial ou naval. 32 En particulier, dans le cadre d'un système de flot de données d'un véhicule, on peut avantageusement avoir selon la présente invention, des capteurs et processeurs fonctionnant selon des fréquences différentes et selon plusieurs configurations. Par exemple, le système du véhicule peut comporter des caméras pour détecter des piétons. La fréquence 5 d'échantillonnage des caméras peut être différente de celle du microprocesseur qui va traiter les signaux et le traitement doit être suffisamment rapide pour prévenir le conducteur ou l'automate suffisamment tôt afin de déclencher un freinage ou une autre action pour éviter le piéton. Cette consommation et production à des fréquences différentes sans perte de données est possible grâce à l'utilisation des nombres rationnels des données sur les canaux selon 10 l'invention. En outre, on peut considérer à titre d'exemple que pour une voiture avec conducteur, la détection de piétons est intéressante à partir d'une certaine vitesse. Ainsi, on peut utiliser différents modes de reconfigurations de sorte que le traitement de détection de piéton se déroule à partir d'une certaine vitesse ou sur une certaine plage de vitesses permettant au microprocesseur de ne pas consommer des ressources d'exécution inutilement 15 en dehors de cette plage. Une deuxième application concerne les systèmes FPGA pour le temps-réel critique : un système FPGA est un flot de données cadencé par des horloges qui déclenchent les unités de traitement, et dans lesquels le routage des données peut changer dynamiquement. Une troisième application concerne un système d'un processus industriel configuré 20 pour la fabrication industrielle des objets selon des contraintes de débit particulières et selon un processus reconfigurable. En effet, un procédé de fabrication industriel peut être vu comme un flot de données, avec des contraintes de débit pour des raisons techniques. En outre, la présente invention permet la reconfiguration du procédé pour s'adapter par exemple à l'évolution du carnet de commandes. 25 33 REFERENCES BIBLIOGRAPHIQUES 1. X. K. Do, S. Louise and A. Cohen, Transaction Parameterized Dataflow: A mode) for context-dependent streaming applications, 2016 Design, Automation & Test in Europe Conference & Exhibition (DATE), Dresden, 2016, pp. 960-965. 5 2. 0. N. Timo, H. Marchand and A. Rollet, Automatic test generation for data-flow reactive systems modeled by variable driven timed a utomata, Research report HAL-00503000, 2010. 3. R. Henia and R. Ernst, Scenario Aware Analysis for Complex Event Models and Distributed Systems, 28th IEEE International Real-Time Systems Symposium (RTSS 2007), 10 Tucson, AZ, 2007, pp. 171-180. 4. Boutheina Bannour, Jose Escobedo, Christophe Gaston, Pascale Gall. Off-Line Test Case Generation for Timed Symbolic Model-Based Conformance Testing. Brian Nielsen; Carsten Weise. 24th International Conference on Testing Software and Systems (ICTSS), Nov 2012, Aalborg, Denmark. Springer, Lecture Notes in Computer Science, LNCS-7641, pp.119- 15 135, 2012, REVENDICATIONS1. Outil de conception et de validation d'un système flots de données comportant un ensemble d'acteurs (a,, ai) logiciels et/ou matériels interconnectés entre eux par des canaux (c,, c) de communication unidirectionnels, ledit outil étant caractérisé en ce qu'il comporte : - une interface de modélisation (11) configurée pour générer une instance dudit système en spécifiant de manière formelle un flot de données temps-réel et reconfigurable, la reconfiguration du flot de données étant réalisée de manière dynamique par la propagation de données de reconfiguration d'un acteur à un autre à travers les canaux de communication, - un module d'analyse (13) configuré pour prouver un ensemble prédéterminé de propriétés comportementales dudit système par une analyse statique de ladite instance, - une interface de raffinement (15) adaptée pour allouer des ressources à ladite instance établissant ainsi une instance configurée, l'allocation de ressource étant réalisée de manière à ce qu'une implémentation du système respecte ladite instance configurée, et - un module de test de conformité (17) configuré pour vérifier la conformité du comportement d'une implémentation dudit système vis-à-vis de ladite instance configurée. 2. Outil selon la revendication 1, caractérisé en ce que l'instance du système comporte des rythmes rationnels de consommation et d'émission de données. 3. Outil selon la revendication 1 ou 2, caractérisé en ce qu'en outre l'instance du système comporte : - des contraintes de fréquence maximales pour certains acteurs, - des contraintes de fréquence minimales pour certains autres acteurs. 35 4. Outil selon l'une quelconque des revendications précédentes, caractérisé en ce que l'instance du système comporte : - l'ensemble des acteurs comprenant des acteurs génériques configurés pour traiter des données et des acteurs de mode configurés pour traiter des données et/ou sélectionner 5 des modes de configurations, - l'ensemble de canaux de communication unidirectionnels connectant l'ensemble des acteurs entre eux, chaque acteur étant associé à au moins un canal d'entrée ou de sortie, - le nombre rationnel ou entier de données produites ou consommées par acteur pour chacun de ses canaux d'entrée et de sortie, et 10 - l'ensemble de modes associés à chaque acteur de mode, chaque acteur de mode étant configuré pour choisir dynamiquement pour chacune de ses activations un et un seul mode parmi ledit ensemble de modes. 5. Outil selon l'une quelconque des revendications précédentes, caractérisé en ce 15 qu'en outre l'instance du système comporte pour chaque acteur générique un ensemble correspondant de modes d'exécutions dans lesquels il s'exécute ainsi qu'un ensemble implicite de tous les autres modes dans lesquels il passe, un mode d'exécution pouvant être soit un mode nominal commun à tout le système, soit un mode spécifique choisi par un acteur de mode. 20 6. Outil selon l'une quelconque des revendications précédentes, caractérisé en ce qu'en outre l'instance du système comporte un ensemble implicite de canaux de rétroaction, un canal de rétroaction étant un canal connectant un acteur générique producteur de données à un acteur générique consommateur de données s'exécutant chacun dans au moins un des modes choisis par un même acteur de mode, et en ce qu'il existe un chemin sans répétition 36 partant dudit même acteur de mode et terminant par l'acteur générique producteur en passant par l'acteur générique consommateur. 7. Outil selon l'une quelconque des revendications précédentes, caractérisé en ce 5 qu'en outre l'instance du système comporte un état initial du système composé par canal d'un nombre rationnel et d'une séquence de modes de longueur égale à une arrondie inférieure dudit nombre rationnel, et par acteur générique de son mode initial. 8. Outil selon l'une quelconque des revendications précédentes, caractérisé en ce 10 que ledit ensemble prédéterminé de propriétés comportementales comporte des première, deuxième, troisième et quatrième propriétés suivantes : - la première propriété vérifie que les ressources nécessaires à l'implémentation des communications entre acteurs sans perte de données sont bornées pour une exécution périodique du système spécifié, 15 - la deuxième propriété vérifie que les contraintes de fréquence et/ou de période peuvent être respectées sans remettre en cause la première propriété, - la troisième propriété vérifie la non-existence d'inter-blocage pour tout nombre d'activations des acteurs, et - la quatrième propriété vérifie la non-existence d'état inconnu dans le système pour 20 toutes les reconfigu rations spécifiées et aucune des autres propriétés n'étant remise en cause par des changements dynamiques de configuration. 9. Outil selon l'une quelconque des revendications précédentes, caractérisé en ce que ledit système est un système embarqué temps-réel d'un équipement, configuré pour 37 recevoir des mesures spécifiques audit équipement et pour délivrer des résultats actionnant des opérations pour le bon fonctionnement dudit équipement. 10. Système embarqué temps-réel d'un équipement, conçu et validé par l'outil 5 selon l'une quelconque des revendications précédentes, caractérisé en ce que ledit système embarqué est configuré pour recevoir des mesures spécifiques audit équipement et son environnement et pour délivrer des résultats actionnant des opérations pour le bon fonctionnement dudit équipement. 10 11. Système selon la revendication 10, caractérisé en ce que ledit équipement est un véhicule autonome ou non autonome de type terrestre, ferroviaire, aérospatial ou naval. 12. Système d'un processus industriel temps-réel, conçu et validé par l'outil selon l'une quelconque des revendications 1 à 9, caractérisé en ce que ledit système est configuré 15 pour la fabrication industrielle des objets selon des contraintes de débit particulières et selon un processus reconfigurable. 13. Procédé de conception et de validation d'un système flots de données comportant un ensemble d'acteurs logiciels et/ou matériels interconnectés entre eux par des 20 canaux de communication unidirectionnels, ledit procédé étant caractérisé en ce qu'il comporte les étapes suivantes : - générer une instance dudit système en spécifiant de manière formelle un flot de données temps-réel et reconfigurable, la reconfiguration du flot de données étant réalisée de manière dynamique par la propagation de données de reconfiguration d'un acteur à un autre 25 à travers les canaux de communication, 38 - prouver un ensemble prédéterminé de propriétés comportementales dudit système par une analyse statique de ladite instance, - allouer des ressources à ladite instance établissant ainsi une instance configurée, l'allocation de ressource étant réalisée de manière à ce qu'une implémentation du système 5 respecte ladite instance configurée, et - vérifier la conformité du comportement d'une implémentation dudit système vis-à-vis de ladite instance configurée.