FR 3091106 A1 20200626 FR 1873585 A 20181220 Description Titre de l'invention : Système de supervision formelle de commu- nications [0001] La présente invention concerne un système de supervision formelle de commu- nications (l'un ensemble d'applications concrètes, et plus particulièrement dans une architecture orientée-service. Technique antérieure [0002] La présente invention s'applique à des systèmes dans lesquels des applications concrètes utilisent des fonctions d'interface prédéfinies pour s'échanger des données entre elles. En particulier, l'invention s'applique à de tels systèmes dans lesquels le respect du comportement attendu de certaines tâches est considéré comme critique, à savoir qu'en cas de non-respect, il peut y avoir des conséquences très négatives. D'une manière générale, l'invention s'applique à des systèmes dans lesquels cohabitent des tâches de niveaux de criticité différents, certaines tâches étant considérées comme devant respecter strictement le comportement attendu, d'autres pour lesquels des écarts de comportement sont acceptables temporairement, ou d'autres encore sans garantie sur le comportement. On parle alors de systèmes à criticité mixte. [0003] Les récents systèmes embarqués temps-réels pour les véhicules autonomes sont un exemple de tels systèmes. Les nouvelles architectures embarquées pour les véhicules sont distribuées et hétérogènes, et le paradigme utilisé pour les programmer est orienté-service. Dévier du comportement attendu pour une tâche critique pourrait causer un dysfonctionnement qui peut être assez hasardeux. En revanche, certaines tâches liées au confort ou à l'expérience de conduite n'ont pas vraiment de contraintes sur leur comportement, il s'agit donc de systèmes à criticité mixte. 100041 11 est ainsi important d'avoir un outil qui permet de réaliser une spécification formelle d'un tel système, et de faire une vérification formelle de la conformité d'une implémentation du système spécifié. 100051 Toutefois, la spécification de ces systèmes, prenant en compte toutes les contraintes, est un problème technique très complexe. 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. 100061 11 existe des algorithmes basés sur des modèles formels pour spécifier des systèmes flot de données temps-réel reconfigurables. Une telle méthode est par exemple décrite dans le document I 1 I. 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 2 ne permet pas de vérifier pendant son exécution la conformité du comportement d'une implémentation du système spécifié vis-à-vis de sa spécification. [0007] Un autre problème est l'implémentation d'un système spécifié dans la méthodologie formelle. Il s'agit de développer un logiciel implémentant l'application concrète modélisée par chaque acteur, et d'utiliser dans ces logiciels les interfaces de communication pour réaliser les communications spécifiées formellement. Cette implémentation requiert de configurer les éléments logiciels mis en oeuvre pour la communication entre les interfaces de manière à ce que ces communications soient conformes à la spécification formelle. [0008] Il existe de nombreux langages et interfaces de programmation pour écrire des logiciels pour ce genre de systèmes et en particulier pour des systèmes orientés-services. Toutefois, tous se basent sur des concepts similaires à savoir la publication de données par un serveur et la souscription à ces données par un ou plusieurs clients, ou l'émission de requêtes par un ou plusieurs clients à destination d'un serveur en charge d'effectuer le traitement requis. Les connexions entre clients et serveurs peuvent changer au cours de la vie du système, et dès contraintes de temps sont parfois imposées pour assurer le bon fonctionnement du système. [0009] Les documents [2, 3] décrivent des langages qui permettent d'écrire des logiciels im- plémentant des acteurs flot de données, et des compilateurs associés qui génèrent du code de manière à réaliser le comportement du système spécifié. [0010] Toutefois, ces logiciels sont limités dans le contexte considéré parce qu'ils ne permettent pas d'exprimer toutes les contraintes d'une spécification formelle et que pour la plupart, les architectures logicielles ciblées ne sont pas adaptées pour des systèmes à criticité mixte. De plus, dans le cadre d'un modèle de développement où divers producteurs de logiciel implémentent des spécifications d'acteurs, pour les fournir à un même intégrateur, il est extrêmement difficile pour l'intégrateur d'imposer l'utilisation d'un langage spécifique. [0011] L'objet de la présente invention est par conséquent de proposer un système de su- pervision formelle de communications d'un ensemble d'applications remédiant aux inconvénients précités, en particulier en permettant d'intégrer des implémentations logicielles écrites dans un langage quelconque sur une plateforme distribuée hétérogène. Exposé de l'invention [0012] La présente invention concerne un système de supervision formelle de commu- nications d'un ensemble d'applications concrètes d'une plateforme, comportant : -un module d'acquisition configuré pour acquérir un modèle formel d'un flot de données décrivant le comportement d'un ensemble d'acteurs modélisant ledit ensemble d'applications concrètes, et une spécification de communication décrivant des implé- 3 mentations logicielles implémentant les applications modélisées par lesdits acteurs, lesdites implémentations logicielles étant configurécs pour faire des appels à des fonctions de communication prédéterminées, et -un module de supervision configure pour vérifier qu'une séquence d'appel auxdites fonctions de communication est conforme au comportement attendu dudit ensemble d'acteurs. [0013] Ce système permet d'intégrer des implémentations logicielles écrites dans un langage quelconque sur une plateforme distribuée hétérogène présentant un comportement de communication conforme à celui spécifié dans le modèle formel, sans besoin de modifier les logiciels implémentant les acteurs. [0014] Selon un mode de réalisation préféré de la présente invention, le module de su- pervision est configuré pour construire un automate pour chaque implémentation logicielle correspondant à un acteur, chaque automate comportant un ensemble d'états dont la transition d'un état à un autre est déclenchée par un appel de l'implémentation logicielle d'une fonction parmi lesdites fonctions de communication, ledit automate se basant sur le comportement attendu par le modèle formel pour tracer les séquences d'appel valides auxdites fonctions de communication de l'implémentation logicielle. [0015] Avantageusement, chaque automate comporte une première partie associée à r initialisation de l'implémentation logicielle et une seconde partie associée au fonctionnement de l'implémentation logicielle, la transition d'un état final de ladite première partie à un état initial de ladite seconde partie est déclenchée lorsqu'un signal de synchronisation est reçu par l'implémentation logicielle, indiquant l'exécution d'une application concrète sur la plateforme. [0016] Avantageusement, le module de supervision est configuré pour générer des éléments logiciels configurés pour capturer les appels de fonctions de communication et pour s'assurer que la séquence des appels effectués à l'exécution d'une application concrète correspond à la séquence définie par l'automate. [0017] Avantageusement, les éléments logiciels comportent une fonction étendue pour chacune des fonctions de communication, une fonction de gestion d'échéance de données d'entrée, et une fonction de gestion d'une activation courante. [0018] Avantageusement, la spécification de communication est une spécification d'une im- plémentation orientée-service. [0019] Avantageusement, les fonctions de communication sont orientées-service et comportent une fonction d'offre de service, une fonction de publication d'interface, une fonction de souscription à une interface publiée, une fonction d'émission, une fonction de réception, une fonction de requête, et une fonction de traitement sur une interface. [0020] Avantageusement, le modèle formel comporte un ensemble de données de confi- guration requises pour l'implémentation desdits acteurs permettant ainsi de décrire le comportement attendu d'un système embarqué. [0021] Avantageusement, les données de configuration comportent pour chacun des acteurs: des données de budget, de délai initial, d'échéance initiale, d'échéance d'entrées, de politique d'entrées par défaut, d'indicateur persistant/éphémère, et d'indicateur strict/ relâché. [0022] Avantageusement, la spécification de communication comporte des liens entre les implémentations logicielles et les acteurs du modèle formel. [0023] L'invention vise également un équipement embarqué temps-réel, conçu en utilisant le système de supervision selon l'une quelconque des caractéristiques précédentes, ledit équipement embarqué étant configuré pour recevoir des mesures spécifiques à son environnement et pour délivrer des résultats actionnant des opérations de fonctionnement. [0024] Avantageusement, ledit équipement est un véhicule autonome ou non autonome de type terrestre, ferroviaire, aérospatial ou naval. [0025] L'invention vise aussi un procédé de supervision formelle de communications d'un ensemble d'applications concrètes, comportant les étapes suivantes : - acquérir un modèle formel d'un flot de données décrivant le comportement d'un ensemble d'acteurs modélisant ledit ensemble d'applications concrètes, et une spécification de communication décrivant des implémentations logicielles implémentant les applications modélisées par lesdits acteurs, lesdites implémentations logicielles étant configurées pour faire des appels à des fonctions de communication prédéterminées, et - vérifier qu'une séquence d'appel auxdites fonctions de communication est conforme au comportement attendu dudit ensemble d'acteurs. Brève description des dessins [0026] D'autres particularités et avantages du dispositif et du procédé selon l'invention res- sortiront mieux à la lecture dc la description faite ci-après, à titre indicatif mais non limitatif, en référence aux dessins annexés sur lesquels : [0027] [ig.1] illustre dc manière schématique un système de supervision formelle dc com- munications d'un ensemble d'applications concrètes d'une plateforme, selon un mode de réalisation de l'invention ; [0028] [fig.2] illustre de manière schématique un exemple d'un modèle formel défini par un graphe selon un mode de réalisation de l'invention ; [0029] [fig.3A] [0030] [fig.3B] et [0031] [fig.3C] illustrent de manière schématique la correspondance entre des acteurs du modèle formel et la description des interfaces orientées-service de la spécification de communication, selon un mode de réalisation de l'invention ; et [0032] [fig.4À] et [0033] [fig.4B] illustrent de manière schématique la construction d'un automate, selon un mode de réalisation de l'invention. Description des modes de réalisation [0034] Le principe de la présente invention est de superviser les échanges de données entre des taches de calcul implémentant des composants spécifiés dans une méthodologie formelle dans le but d'observer des échanges de données conformes à la spécification formelle. [0035] La Fig. 1 illustre de manière schématique un système de supervision formelle de communications d'un ensemble d'applications concrètes d'une plateforme, selon un mode de réalisation de l'invention. [0036] Lc système de supervision formelle 1 est mis en oeuvre par des moyens matériels comportant une machine de traitement de l'information tel un calculateur ou ordinateur 3 comportant un microprocesseur 5 et des mémoires 7. Le microprocesseur 5 est configuré pour exécuter un ou plusieurs programmes d'ordinateur comprenant des instructions de code de programme, stockés dans les mémoires 7 de l'ordinateur et conçus pour mettre en oeuvre le système de supervision formelle de communications d'un ensemble d'applications. [0037] Lc système de supervision vise à réaliser une supervision formelle de commu- nications d'un ensemble d'applications concrètes d'une plateforme. Conformément à l'invention, le système de supervision comporte un module d'acquisition 9 et un module de supervision 11. [0038] Lc module d'acquisition est configuré pour acquérir un modèle formel 13 d'un flot de données décrivant le comportement d'un ensemble d'acteurs modélisant l'ensemble d'applications concrètes. En outre, le module d'acquisition 9 est configuré pour acquérir une spécification de communication 15 décrivant des implémentations logicielles implémentant les applications modélisées par les acteurs. Les implémentations logicielles sont configurées pour faire des appels à des fonctions de communication prédéterminées. [0039] Le module de supervision 11 est configuré pour vérifier qu'une séquence d'appel aux fonctions de communication est conforme au comportement attendu de l'ensemble d'acteurs. [0040] Le modèle formel 13 d'un flot de données comporte 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, sondes, micro- 6 processeurs, etc.). Chaque acteur est configure 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 cc comportement indéfiniment. Le processus de consommation/traitement/émission est communément appelé une activation. [0041] Chaque activation se déroule selon des reconfigurations prédéfinics, et pour une re- configuration donnée, l'activation va soit consommer/traiter/produire (on dit alors s'exécuter), soit ne rien faire (on dit alors passer), et le choix dc changer de configuration est imprédictihle. [0042] Chaque acteur s'active selon les reconfigurations prédéfinies dans des fenêtres tem- porelles (dites temps-réel) avec éventuellement des contraintes de fréquence (ou dc manière équivalente avec des contraintes de période). [0043] Par ailleurs, la spécification de communication 15 comporte des informations sur les applications, les services qu'elle offrent, les services qu'elles utilisent, le type dc données qui vont transiter sur les canaux, des informations sur les interactions entre les différentes applications, le lien ou la correspondance entre les applications de la plateforme et les acteurs du modèle formel, etc. [0044] Le module de supervision 11 est un outil dc génération de code qui prend en entrée la configuration provenant de la méthodologie formelle (i.e. modèle formel 13) et la description des applications de la spécification de communication 15, et génère automatiquement une couche logicielle de supervision en charge d'observer les communications réalisées par les implémentations des acteurs, et de corriger éventuellement les écarts vis-à-vis de la spécification formelle. [0045] Le système de supervision 11 selon l'invention donne ainsi les moyens d'intégrer au- tomatiquement des implémentations d'acteurs, écrites dans un langage quelconque et existant, sur une plateforme distribuée hétérogène. [0046] Les potentielles applications de ce système de supervision sont nombreuses, étant donné que les architectures ciblées sont utilisées dans de nombreux domaines tel que l'Internet, l'automobile, l'aviation, la météorologie, etc. [0047] En particulier, l'invention s'applique à une plateforme distribuée hétérogène pour un système ou dispositif embarqué où le respect du comportement attendu est considéré comme très important pour la sécurité et le bon fonctionnement de l'équipement pourvu d'un tel système. [0048] 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 7 application étant indépendante et s'exécutant sur un calculateur d'unc architecture distribuée. Les connexions entre applications peuvent être reconfigurées en fonction du mode de fonctionnement courant du véhicule, et/ou de la disponibilité des services. [0049] Dans la suite, l'invention sera décrite en détail en faisant référence à un système modélisé par un modèle formel composé d'un ensemble d'acteurs et en donnant une description du comportement attendu par le modèle. [0050] En effet, la Fig. 2 illustre de manière schématique un exemple d'un modèle formel défini par un graphe selon un mode de réalisation de l'invention. [0051] Selon cet exemple, le modèle formel 13 comporte un acteur « Acquisition » faisant l'acquisition de données fournies par un capteur à 30Hz et un acteur « Command » envoyant une commande à un actuateur à 10Hz. La commande est déterminée selon le résultat d'une chaîne de traitement reconfigurable constituée d'un acteur « Preprocess » effectuant un prétraitement de la donnée dans toutes les reconfigurations possibles, et dans une rcconfiguration, d'un acteur « Fast Proccss » effectuant un traitement rapide et basse définition de la donnée prétraitéc, et dans l'autre rcconfiguration d'un acteur « Hi-Quality Proccss » effectuant un traitement lent et haute définition. Le choix de la rcconfiguration courante est effectué par un acteur « Mode » qui utilise de préférence le traitement haute-définition lorsqu'il est disponible. [0052] 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 ara, représentent des acteurs dits génériques qui effectuent des traitements sur les données. Ces acteurs génériques ara, sont ainsi adaptés pour consommer des données, faire des calculs pour transformer les données et produire des résultats. Les triangles a() et a, représentent des acteurs dits horloge « Clock» a() ou échéance « Deadline » a7 qui produisent et consomment des données avec des contraintes de fréquence. Le cané as représente un acteur dit « Mode » as en charge de signaler des reconfigurations. Les arcs dirigés crclo sont des canaux unidirectionnels indiquant chacun un flot de données entre deux acteurs et les valeurs numériques associées donnant la quantité de données produite ou consommée sur le canal. [0053] Selon cet exemple, le système modélisé est composé de cinq acteurs génériques aras. (Acquisition a,, Preprocess a2, Fast Process al, Hi-Quality Process a4 et Command a,.) deux acteurs temporels a6 et a, (Clock et Deadline) et d'un acteur de Mode a5. L'acteur - Acquisition » al (acteur d'acquisition) fait l'acquisition de données fournies par l'acteur horloge a6 à 30Hz. L'acteur Command a; (acteur de commande) envoie une commande à l'acteur actuateur « Deadline » a7 à 10Hz. La commande est déterminée selon le résultat d'une chaîne de traitement reconfigurable constituée d'un autre acteur générique « Preprocess » a, effectuant un prétraitement de la donnée produite par 8 l'acteur d'acquisition al dans toutes les reconfigurations possibles. Dans une première configuration (mode noté par À1), l'acteur « Fast Process » a3 (acteur rapide) effectue un traitement rapide et basse définition de la donnée prétraitée par l'acteur de pré-traitement a2. Dans la deuxième reconfiguration (mode noté par X2), l'acteur « Hi-Quality Procès » a4 (acteur lent) effectue un traitement lent mais de haute définition. Ainsi, le chemin de traitement des données de la première configuration X, est le chemin reliant l'acteur d'acquisition al à l'acteur de prétraitement an, à l'acteur À, de traitement rapide aact puis finalement à l'acteur de commande a5. La deuxième configuration X2 est définie par le chemin reliant l'acteur d'acquisition a, à l'acteur de pré-traitement a2, à l'acteur de traitement lent a.tet puis finalement à l'acteur de commande a5. Ainsi, la configuration se propage d'un acteur à un autre et par conséquent, aucune synchronisation centralisée sur ces modes de rcconfigurations 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 a, qui utilise de préférence le traitement haute définition lorsqu'il est disponible. [0054] Selon cet exemple, l'acteur de traitement rapide a3à chaque fois qu'il s'active consomme une donnée sur son canal d'entrée e3 (représenté sur le canal c' par un « 1 ») et produit une donnée sur son canal de sortie c4(représenté sur le canal c.4par un « 1 »). De même pour l'acteur de traitement lent a.4qui consomme une donnée sur son canal d'entrée e5 et produit une donnée sur son canal de sortie e6. L'acteur de commande as à chaque fois qu'il s'active consomme une donnée sur son premier canal d'entrée c4ou sur son deuxième canal d'entrée c4 (selon le mode de configuration) et produit une donnée sur son canal de sortie e2. L'acteur de prétraitement a2 à chaque fois qu'il s'active consomme une donnée sur son premier canal d'entrée cl et une donnée sur son deuxième canal d'entrée c9 et produit une donnée sur son premier canal de sortie ç, ou sur son deuxième canal de sortie c5. (selon le mode de configuration). [0055] En revanche, l'acteur d'acquisition al consomme un nombre rationnel de données sur son canal d'entrée e2 (représenté sur le canal d'entrée c2par la valeur « 1/3 ») et produit un nombre rationnel de données sur son canal de sortie c, (représenté sur le canal de sortie cl par la valeur « 1/3 »). Ceci veut dire que l'acteur d'acquisition al consomme ou produit une donnée toutes les trois activations. L'exemple de la Fig. 2 montre qu'à l'état initial, il y a un jeton T1 (i.e. une donnée) disponible sur le canal e2 (entre l'acteur de commande aï et l'acteur d'acquisition ai). Alors, l'acteur d'acquisition al va consommer cette donnée existante sur ce canal c2 et va produire une donnée sur son canal de sortie cl (i.e. le canal c, reliant l'acteur d'acquisition a, à l'acteur de pré-traitement a2). Ainsi, l'acteur d'acquisition al 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 a, consomme une 9 donnée et produit une donnée toutes les trois activations. Ceci permet de 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 al fonctionnant à 30 Hz et l'acteur de commande a, fonctionnant à 10 Hz sans aucune perte de données. [0056] Dans la suite, on résume les éléments définissant le modèle formel 13 en faisant référence à l'exemple de la Fig. 2. Selon ce formalisme, la spécification d'un flot de données se compose des éléments Fl -F9 suivants : [0057] F1 : On définit l'ensemble des acteurs génériques a1-a5 qui traitent des données, ainsi que l'ensemble des acteurs de mode a, et a, qui traitent des données et/ou sélectionnent des modes de configurations. [0058] F2 : On définit l'ensemble des canaux cl-clo connectant les acteurs entre eux, chaque acteur étant associé à au moins un canal d'entrée ou de sortie. [0059] 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 cl-cm connectant les acteurs. [0060] 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 XI et X2). Le choix de la configuration courante est avantageusement fait par un acteur de mode 24 unique et cette configuration courante se propage de manière distribuée d'un acteur à un autre. [0061] F5 : Pour chaque acteur générique 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. 2, tous les acteurs à l'exception des acteurs de prétraitement a2, de traitement rapide a' et de traitement lent a4 s'exécutent dans le mode nominal sachant que l'acteur de pré-traitement a, s'exécute dans les modes Xi et X2, l'acteur de traitement rapide a' s'exécute dans le mode XI, et l'acteur de traitement lent a4 s'exécute dans le mode X,. [0062] F6 : Etant donnés les différents modes, on définit un ensemble implicite de canaux de 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 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. [0063] 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 d'horloge a, auxquels on associe une fréquence. Dans l'exemple de la Fig. 2, l'acteur d'acquisition al a une contrainte de fréquence maximale de 30Hz, exprimée par l'acteur horloge ab avec pour fréquence 30Hz, et l'arc c, les connectant et les quantités de données associées. [0064] F8 : On définit des contraintes de fréquence minimale pour certains acteurs gé- nériques ou de mode. Une manière possible de les exprimer est par des acteurs dits d'échéance a, auxquels on associe une fréquence. Dans l'exemple de la Fig. 2, l'acteur de commande a, a une contrainte de fréquence minimale de 10Hz, exprimée par l'acteur échéance a, avec pour fréquence 10Hz, l'arc cg 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 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). [0065] F9 : Un état initial du système composé par canal d'un nombre rationnel et d'une 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. 2, 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 et consommation sont rationnels selon un mode de réalisation avantageux de l'invention. [0066] Le tableau suivant Tab. 1 donne à titre d'exemple des données de configuration requises pour une implémentation du modèle formel 13 de la Fig. 2. [0067] 11 [Tahleauxl] -,..s.e, \ ... , .k.e.w.,,m, , ,,,,,,,t1/4%. '1/4'tk.,,.... -te, , - , ,,,-eve...e, ,\tektu,a, \ 'kk. , ' \ ,, , , , ',\,' , -,.\\ ,,, -'.' ' \\,.. ' - ' X N.' .\\NN. -,,,,,,,, \\N.:. \\.',,,,,,,,,,,,,,,\,N., ,,',,',,t,,*,,,,,,,,,,, '', ,,,,, ,, ,,,,,,,,,N.N.,..,,,iii....>,...e.....c...\.....\.\\\,sx,'\:s..-....c...... :.-....:,.......:.'.\\\\\\:,........\\,...,:.-.s.,:::.-.s.,:,:,.;.....s., 3Eidget {ms3 19 39 30 40 20 De nids ( s) 0 0 0 0 0 Eche nce irEitiate (rnsli 0 0 50 50 0 Echean ce entrees rn1s) 20 a0 Politique entrées p défaut Ignorer P ecétlent ignorer Ignorer Prete Persistant '''ersIstantiEphémère-r Persistant Persistant Persistant Persistant StrictiRe1,4ché Strict Strict strict Strict Strict Tableau 1 [0068] La première ligne représente les cinq acteurs génériques : Acquisition (acteur d'acquisition) al, Preproccss (acteur de prétraitement) a,, Fast Process (acteur de traitement rapide) a4, Hi-Quality Proccss (acteur de traitement lent) a4 et Command (acteur de commande) a,. [0069] Les deuxième, troisième, quatrième, et cinquième lignes indiquent des valeurs en ms, d'un budget, d'un délai initial, d'une échéance initiale, et d'une échéance d'entrées respectivement. Les sixième, septième, et huitième lignes désignent une politique d'entrées par défaut, un indicateur persistant/éphémère, et un indicateur strict/relâché. [0070] Les valeurs sont en général imposées par l'intégrateur de la plateforme et sont données ici uniquement à titre d'exemple. Le budget désigne la durée en ms allouée à chaque acteur pour faire ses différentes tâches. Le délai initial et l'échéance initiale indiquent les délais de communication et production des échantillons afin de prendre en compte l'acheminement et le traitement des différents échantillons. Un délai initial égal à zéro signifie qu'il n'y a aucune contrainte de latence forcée et l'acteur commence dès qu'il est prêt. L'échéance d'entrées désigne l'échéance d'arrivée pour les données consommées par les implémentations des acteurs et permet ainsi d'allouer une durée d'attente à un acteur afin d'attendre les données qui lui sont destinées avant de commencer à travailler. [0071] La politique d'entrées par défaut désigne dans cet exemple deux types de politiques. 12 Lorsqu'il n'y a pas de données d'entrées, la politique « Ignorer » ne produit pas de données de remplacement, et la politique « Précédent » copie la dernière entrée reçue. On peut également mettre en place une troisième politique « Défaut » qui produit systématiquement une même valeur par défaut. [0072] Une autre donnée de configuration d'entrée peut éventuellement concerner la dé- signation d'une absence de production comme étant une faute ou non. Dans l'exemple de la Fig. 2, seule l'absence de sortie de l'acteur Command vers l'acteur Acquisition n'est pas considérée comme une faute, la requête de calibration n'étant pas obligatoire. [0073] Par ailleurs, dans la suite de la description, on va s'intéresser plus particulièrement, à un système de supervision formelle de communications dans une architecture orientée-service. Autrement dit, la spécification de communication 15 est une spécification d'une implémentation orientée-service et les fonctions de communications sont des fonctions orientées-services. [0074] A titre d'exemple, on considère que l'architecture orientée-service est composée de trois services : AcquisitionService, PreprocessService, et ProcessService. Chaque service offre les interfaces suivantes : -AcquisitionService (service d'acquisition) public une interface AcquisitionService:Samples produisant les échantillons capteurs, et offre une interface AcquisitionService::Calibrate pour traiter des requêtes de calibration ; - PreprocessService (service de prétraitcment) publie une interface produisant les échantillons prétraités, et pour implémenter les reconfigurations, cette interface est dupliquée en interfaces PreprocessService::Samples1 et PreprocessService::Samples2, qui seront utilisées selon les reconfigurations en cours ; et - ProcessService (service de traitement) publie une interface ProcessService::Samples produisant les échantillons traités. [0075] Les implémentations de chaque service sont identifiées par un unique identifiant. Il y a une implémentation Acql de AcquisitionService, une implémentation Prel de PreprocessService, et deux implémentations Procl et Proc2 de ProcessService. Il y a également une implémentation qui est seulement cliente Coml. Le lien entre ces implémentations et les acteurs du modèle est donné dans le Tableau 2 suivant. [0076] 13 [Tablcaux2] 'N 11'Mn SU,,,,,,,, \ \ , ''',« Acql a.S.Sba& t,Uiii Acquisition Prel Preprocess Proci fast Process Proc2 [pal rocess Cornl Command a ea Li [0077] Les logiciels implémentant les cinq acteurs du modèle peuvent être réalisés par différents fournisseurs de logiciels. Ces logiciels font des appels à des fonctions de communication pour établir les communications orientées-service. [0078] A titre d'exemple, on décrit ci-dessous les fonctions (le communication relatives à l'interface (le programmation de la platefonne AutoSAR Adaptive pour l'automobile décrit dans les documents [4, 5]. Ces fonctions de communication comportent une fonction d'offre de service (OffrirService), une fonction de publication d'interface (Publierinterface), une fonction de souscription à une interface publiée (Souscrirelnterface), une fonction d'émission (Emettre), une fonction de réception (Recevoir), une fonction de requête (Requête), et une fonction de traitement sur une interface (Traiter). [0079] La fonction OffrirService (identifiant de service) permet d'identifier le logiciel appelant comme l'implémentation associée à l'identifiant. [0080] La fonction Publierinterface (identifiant d'interface) permet au logiciel appelant (le donner l'accès à l'interface associée à l'identifiant pour les autres logiciels. [ 00811 La fonction Souscrirelnterface (identifiant de service, identifiant d'interface) permet au logiciel appelant de recevoir les données émises par le logiciel associé à l'identifiant de service à travers l'interface associée à l'identifiant d'interface. [0082] La fonction Emettre (identifiant d'interface, donnée) permet au logiciel appelant d'émettre la donnée fournie à travers l'interface associée à l'identifiant d'interface ; ceci équivaut à la production d'un jeton dans le modèle formel 13 de flot de données. [0083] La fonction Recevoir (identifiant de service, identifiant d'interface) permet au logiciel appelant de consulter les données émises à travers l'interface associée aux identifiants depuis le dernier appel à Recevoir ; ceci équivaut à la consommation d'autant de jetons que de données consultées dans le modèle formel 13 de flot de 14 données. [0084] La fonction Requête (identifiant de service, identifiant d'interface, paramètres) permet au logiciel appelant d'envoyer une requête de traitement associée à l'identifiant d'interface au logiciel associé à l'identifiant de service, pour traitement des paramètres donnés, et de récupérer un éventuel résultat une fois la requête traitée ; ceci équivaut à la production d'un jeton dans le modèle formel 13 de flot de données, et la récupération du résultat équivaut à la consommation d'un jeton. [0085] La fonction Traiter (identifiant d'interface) permet au logiciel appelant de récupérer les paramètres d'une requête reçue sur l'interface identifiée, d'effectuer les traitements requis, et éventuellement d'émettre un résultat au logiciel ayant envoyé la requête ; la récupération de requête équivaut à la consommation d'un jeton dans le modèle formel 13 de flot de données, tandis que l'émission d'un résultat correspond à la production d'un jeton. [0086] Les Figs. 3A-3C illustrent de manière schématique la correspondance entre des acteurs du modèle formel et la description des interfaces orientées-service de la spécification de communication, selon un mode de réalisation de l'invention. [0087] Plus particulièrement, la Fig. 3A montre la correspondance entre la topologie du graphe du modèle formel 13 et les interfaces orientées-services pour offrir un service, publier une interface, et souscrire à une interface publiée. A titre illustratif, on ne considère dans cet exemple que deux acteurs Acquisition a, et Preprocess a2. Le logiciel Acql qui réalise le comportement de l'acteur Acquisition a, va publier des interfaces Publierinterface(Smples) correspondant au service d'acquisition. Plus particulièrement, le logiciel Acql va appeler la fonction OffrirService et ensuite, il va appeler la fonction Publierinterface créant ainsi un port de connexion sur lequel les données seront publiées. Ensuite, le logiciel Prel implémentant l'acteur Preprocess a, va appeler la fonction Souscrirelnterface pour souscrire à l'interface du logiciel Acql afin de consommer les échantillons produits. La Fig. 3A fait ainsi le lien entre ces différents éléments et permet de redessiner le graph de flot de données au fur et à mesure que les appels aux fonctions sont faits. On notera que la Fig.3A concerne une première phase dite d'initialisation destinée à vérifier que les communications con-espondent bien au graphe du modèle formel 13 de la Fig. 2. Une fois, que le graph est construit, on entre dans une deuxième phase dite de fonctionnement décrite par la Fig. 3B. [0088] En effet, la Fig. 3B montre la correspondance entre la production/consommation sur un canal du graphe du modèle formel 13 et l'émission/réception de données sur une interface orientée-service. Le logiciel Acql va appeler régulièrement la fonction Emettre sur son interface et il va fournir une donnée concrète sur cette interface. Le logiciel Prel implémentant l'acteur Preprocess va appeler la fonction Recevoir pour consommer cette donnée. [0089] La Fig. 3C montre la correspondance entre la production/consommation sur un canal du graphe du modèle formel 13 et envoi de requête et traitement sur une interface orientée-service. Plus particulièrement, Le logiciel Coml implémentant l'acteur Command envoie une requête comportant des paramètres et l'identifiant de la requête, ce qui correspond à la production d'un jeton dans le graphe du modèle formel de la Fig.2. De l'autre côté, le logiciel Acql de l'acteur Acquisition va appeler la fonction Traiter pour traiter la requête sur son interface. [0090] Le comportement attendu pour les implémentations des acteurs de l'exemple des Fig. 3A-3C est le suivant : [0091] -Acql : avec la configuration décrite ci-dessus, l'exemple du modèle formel 13 de la Fig. 2 détermine que l'acteur Acquisition a trois activations successives telles que la première doit avoir lieu entre Oms et 20ms, doit produire un jeton sur son canal de sortie et consommer un jeton sur son canal d'entrée. Les deux activations suivantes ne communiquent pas. Ainsi, le comportement attendu pour l'implémentation est d'appeler la fonction Encore sur l'interface AcquisitionService::Samples une fois et d'appeler la fonction Traiter de manière à traiter une requête pour l'interface AcquisitionService::Calibrate, et ce entre Oms et 20ms. Ce comportement doit se répéter entre 100ms et 120ms, 200ms et 220ms, etc. [0092] -Prel : avec la configuration décrite ci-dessus, l'exemple du modèle formel 13 de la Fig. 2 détermine que l'acteur Preprocess a une activation qui doit avoir lieu entre Oms et 50ms, doit consommer un jeton sur son canal d'entrée et produire un jeton contenant des données sur un des canaux de sortie, et un jeton ne contenant pas de données sur l'autre canal. Pour prendre en compte les reconfigurations possibles, cette implémentation vérifie si l'implémentation Proc2 a appelé la fonction OffrirService. Ainsi, le comportement attendu pour l'implémentation est d'appeler la fonction Recevoir sur l'interface Samples de Acql de manière à consulter une donnée, et d'appeler une fois la fonction Emettre soit sur son interface Samplesl soit sur son interface Samples2, et ce entre 0 et 50ms. Ce comportement doit se répéter entre 100ms et 150ms, 200ms et 250ms. etc. [0093] - Procl : avec la configuration décrite ci-dessus, l'exemple du modèle formel 13 de la Fig. 2 détermine que l'acteur Fast Process a une activation qui doit consommer un jeton sur son canal d'entrée et produire un jeton sur son canal de sortie, ce jeton contenant soit des données soit aucune donnée. Ainsi, le comportement attendu pour cette implémentation est d'appeler la fonction Recevoir sur l'interface Samplesl de Prel de manière à consulter une ou zéro donnée, et d'appeler la fonction Emettre sur son interface Samples une fois, et ce uniquement si une donnée a été effectivement reçue, et ce entre 0 et 90ms. Ce comportement doit se répéter entre 100ms et 190ms. 200ms et 290ms. etc. 16 [0094] -Proc2 : le comportement attendu est le même que celui de Froc] excepté que l'interface pour Recevoir est l'interface Samples2 de Prel. [0095] -Coml : avec la configuration décrite ci-dessus, l'exemple du modèle formel 13 de la Fig. 2 détermine que l'acteur Command a une activation qui doit consommer un jeton contenant des données sur un de ses canaux d'entrée, et un jeton ne contenant aucune donnée sur l'autre, de produire un jeton sur son canal de sortie. Ainsi, le comportement attendu pour cette implémentation est d'appeler la fonction Recevoir sur l'interface Samples de Procl et Proc2, de manière à consulter une donnée sur l'une ou l'autre, et optionnellement d'appeler la fonction Requête sur l'interface Cal ihratc une fois, et cc entre Oms et 110ms. Cc comportement doit se répéter entre 100ms et 210ms, 200ms et 3l Oms, etc. [0096] Une fois que la description d'un acteur est définie, le module de supervision 11 prend en entrée cette description et vérifie qu'une séquence d'appel aux fonctions de communication orientées-services est conforme au comportement attendu de l'acteur. [0097] On notera que le module de supervision 11 peut être implémenté selon différentes techniques en utilisant par exemple, des automates, des arbres, des listes, des choix de codes avec des conditions imbriquées, des expressions régulières avec une grammaire, etc. [0098] Toutefois, dans la suite de la description on considère à titre d'exemple, une technique de génération de codes basée sur des automates. Ainsi, le module de supervision 11 construit un automate décrivant le comportement attendu pour l'implémentation, dans lequel les transitions correspondent à un appel d'une des fonctions de communication décrites précédemment. [0099] Plus particulièrement, le module de supervision 11 est configuré pour construire un automate pour chaque implémentation logicielle correspondant à un acteur, chaque automate comportant un ensemble d'états dont la transition d'un état à un autre est déclenchée par un appel de l'implémentation logicielle d'une fonction parmi les fonctions de communication. L'automate se base sur le comportement attendu par le modèle formel pour tracer les séquences d'appel valides aux fonctions de communication de l'implémentation logicielle. [0100] Un exemple de construction d'un tel automate serait celle d'un automate divisé en deux parties, une correspondant à l'initialisation de l'implémentation logicielle, l'autre à son, fonctionnement une fois initialisé, connectés par une transition autorisée seulement après le démarrage synchronisé de la plateforme. [0101] En effet, les Figs. 4A et 4B illustrent de manière schématique la construction des première et seconde parties d'un automate, selon un mode de réalisation de l'invention. [0102] Plus particulièrement, la Fig. 4A montre la construction de la première partie de l'automate. Cette construction part d'un état initial et arrive à un état final en passant 17 par un certain nombre d'états intermédiaires et des transitions déclenchées lorsque : - l'implémentation appelle la fonction OffrirService avec un identifiant de service associé à cette implémentation ; - l'implémentation appelle la fonction PublicrInterface avec un identifiant d'interface correspondant à l'interface d'un service pour lequel un appel à OffrirService a amené à l'état courant ; - l'implémentation appelle la fonction SouscrireInterface avec un identifiant d'interface et de service correspondant à une connexion attendue au logiciel associé à cet identifiant de service. [0103] Plus particulièrement, l'exemple de la Fig. 4A représente l'automate d' initialisation généré pour l'implémentation Pro 1 de l'acteur Preprocess a2 de l'exemple de la Fig. 2. Dans la phase d' initial isation, l'implémentation est dans un état initial ETO (référence par un cercle noir). L'automate peut appeler n'importe quelle fonction mais tant qu'il n'a pas appelé la fonction OffrirService, on ne le reconnait pas comme étant l'implémentation Pro 1 de l'acteur Preprocess. Une fois qu'il est identifié comme étant l'implémentation Pro 1 de l'acteur Preprocess, il peut publier à l'état EU soit l'interface Samples1 soit l'interface Samples2. S'il a commencé par publier l'interface Samplesl, il publie ensuite l'interface Samples2 (état El2). En revanche, s'il a commencé par publier l'interface Samples2, il public ensuite l'interface Samples1 (état El3). Une fois qu'il a publié ces interfaces, il peut alors souscrire à l'interface Acql (état EI4) et finalement, on considère à l'état EI5 qu'il a terminé. [0104] Dans ce cas, une transition de l'état final de la première partie de l'automate vers l'état initial de la seconde partie est possible lorsqu'un signal de synchronisation est reçu par l'implémentation, indiquant l'exécution d'une application concrète sur la plateforme (i.e. indiquant un démarrage du système). [0105] Par ailleurs, selon l'exemple de la Fig. 4B, la construction de la deuxième partie de l'automate part d'un état initial de la seconde partie, et retourne à cet état en passant par un certain nombre d'états intermédiaires et des transitions déclenchées lorsque - l'implémentation appelle la fonction Emettre avec un identifiant d'interface précédemment publiée, et la quantité de données déjà émise n'excède pas celle attendue pour cette interface ; - l'implémentation appelle la fonction Recevoir avec un identifiant d'interface précédemment souscrite, et la quantité de données déjà reçue n'excède pas celle attendue pour cette interface ; - l'implémentation appelle la fonction Requête avec un identifiant de service et d'interface correspondant à un canal de sortie dans le modèle, et le nombre de requêtes déjà envoyées n'excède pas celui attendu pour cette interface ; - l'implémentation appelle la fonction Traiter avec un identifiant d'interface cor- 18 respondant à un canal d'entrée dans le modèle, et le nombre de requêtes déjà traitées n'excède pas celui attendu pour cette interface ; - l'échéance de l'activation en cours est dépassée. [0106] Plus particulièrement, l'exemple de la Fig. 4B représente l'automate de fonc- tionnement généré pour l'implémentation Pre 1 de l'acteur Preprocess. [0107] A l'état de fonctionnement initial EFO (représenté par un cercle noir), l'automate peut appeler la fonction Recevoir et tant qu'il ne reçoit pas un échantillon, il retourne à l'état initial EFO. [0108] Une fois qu'il appelle la fonction Recevoir et reçoit un échantillon, l'automate va transiter vers l'état EH. A l'état EH, l'automate va soit émettre un échantillon sur l'interface Samplesl soit émettre un échantillon sur l'interface Samples2 avant de retourner à son état initial EFO. Toutefois, si à l'état EF1, on détecte une violation d'échéance, alors l'automate retourne directement à son état initial EFO. [0109] Par ailleurs, si au lieu de commencer par Recevoir, l'automate commence par appeler la fonction Emettre, l'automate va transiter vers l'état EF2. A l'état EF2, l'automate va soit émettre un échantillon sur l'interface Samplesl, soit émettre un échantillon sur l'interface Samples2 avant de retourner à son état initial EFO. En outre, tant qu'il ne reçoit pas un échantillon, il retourne à l'état EF2. De même que précédemment, si à l'état EF2, on détecte une violation d'échéance, alors l'automate retourne directement à son état initial EFO. [0110] Ainsi, l'automate de fonctionnement créé pour l'implémentation Pre 1 décrit les séquences de fonctions de communication valides correspondant au comportement de son acteur Preprocess. [0111] Une fois cet automate construit, le module de supervision génère des éléments logiciels configurés pour capturer les appels de fonctions de communication et pour s'assurer que la séquence des appels effectués à l'exécution d'une application concrète correspond à la séquence définie par l'automate. [0112] Les éléments logiciels comportent les éléments logiciels suivants : - Une fonction étendue pour chacune des fonctions de communication décrites précédemment. A chaque appel par un logiciel, chaque fonction étendue interroge l'automate pour déterminer si une transition sortante de l'état courant correspond à cet appel. S'il y a une telle transition, la fonction étendue effectue l'appel à la fonction d'origine. Sinon, la fonction étendue enregistre une faute si nécessaire, et retourne immédiatement après la gestion de faute si celle-ci le permet. Un cas particulier concerne la fonction Recevoir, pour laquelle le nombre de données consultées n'est pas connu à l'avance. La version étendue de cette fonction s'assure qu'au plus, le nombre de données spécifié est consultable par l'application, toute donnée supplémentaire est mise en mémoire tampon en attendant la prochaine activation où elles seront rendues 19 consultables. Ainsi, plusieurs appels à Recevoir sont possibles pour une même activation, mais le nombre de données consultées n'excède jamais celui spécifié. - Une fonction pour la gestion d'échéance des données d'entrée. A chaque passage par l'état initial, la date d'échéance de réception des données d'entrée pour l'activation suivante est calculée et la fonction est programmée pour être appelée à cette date. Si la fonction est appelée de cette manière, elle enregistre une faute si nécessaire et implémente la politique de gestion de défaut. Par exemple, dans de cas de l'implémentation Prcl, la valeur du dernier échantillon reçu est mise à disposition comme si il avait été reçu. - Une fonction pour la gestion d'échéance de l'activation en cours. A chaque passage par l'état initial, la date d'échéance pour l'activation suivante est calculée et la fonction est programmée pour être appelée à cette date. Si la fonction est appelée de cette manière, elle met à jour l'état courant de l'automate pour démarrer une nouvelle activation et retourne immédiatement après la gestion de faute si celle-ci le permet. [0113] Le module de supervision est configuré pour générer également un logiciel en charge d'autoriser la transition de passage entre la phase d' initialisation et la phase de fonctionnement de toutes les implémentations de la plateforme. Tant que le module de supervision n'autorise pas le démarrage synchronisé, les logiciels d'implémentations d'acteurs ne peuvent pas entrer en phase de fonctionnement. Ce code peut par exemple attendre qu'un sous-ensemble de logiciels soit prêt à passer en fonctionnement, ou gérer une échéance temporelle. Ce code s'appuie sur des technologies existantes pour la synchronisation temporelle entre les logiciels, généralement disponibles sur les platefonnes logicielles orientées-service. [0114] Ainsi, la présente invention permet, à partir d'une interface de programmation standard qui fait des appels à des fonctions standards, de s'assurer que les appels sont faits dans le bon ordre et conformément au comportement attendu sans modifier les logiciels de l'interface de programmation. Ceci permet à un intégrateur d'être fourni par des fournisseurs de logiciels standards tout en utilisant sa propre méthodologie. [0115] 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 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. [0116] 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. 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 en dehors de cette plage. [0117] 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. [0118] Une troisième application concerne un système d'un processus industriel configuré pour la fahrication industrielle des objets selon des contraintes de débit particulières et selon un processus reconfigurahle. En effet, un procédé de fahrication industriel peut être vu comme un flot de données, avec des contraintes de débit pour des raisons techniques. REFERENCES BIBLIOGRAPHIQUES [0119] 1. X. K. Do, S. Louise and A. Cohen, Transaction Paranteteri7ed Dataflow: A model far context-depentlent slreamitzg applications, 2016 Design, Automation & Test in Europe Conference & Exhibition (DATE), Dresden, 2016, pp. 960-965. 2. Haitao Wci, Stéphane Zuckerman, Xiaoming Li, Guang R. Gao, A Dataflow Programming Language and its Compiler for Streaming Systems, Procedia Computer Science, Volume 29, 2014, Pages 1289-1298, ISSN 1877-0509. 3. Gustav Cedersjii and Jiirn W. Janneck. Software code generation for dynamic dataflow programs. In Proceedings of the l7th International Workshop on Software and Compilcrs for Emhedded Systems (SCOPES '14). ACM. New York, NY, USA, 2014, 31-39. 4. Explanation of ara::com API, AUTOSAR AP Release 17-03. 5. Specification of Time Synchronization for Adaptive Platform, AutoSAR AP Release 17-10 21 [Revendication 1] [Revendication 2] [Revendication 3] [Revendication 4] [Revendication 5]