Brevet FR3115957A1 — publié le 20220506

Procédé d’échange de données dans une plateforme de communication, produit programme d’ordinateur et plateforme de communication associés La présente invention concerne un procédé d’échange de données dans une plateforme de communication comprenant une pluralité de dispositifs abonnés et un dispositif de gestion apte à contrôler les échanges de flux de données, chaque flux de données étant de type cyclique ou de type acyclique. Le procédé comprend une pluralité d’étapes de transmission cyclique et une pluralité d’étapes de transmission acyclique. Chaque étape de transmission cyclique comprend la transmission d’au moins un flux de données de type cyclique par au moins une application et est mise en œuvre dans une fenêtre temporelle cyclique. Chaque étape de transmission acyclique comprend la transmission d’au moins un flux de données de type acyclique par au moins une application et est mise en œuvre dans une fenêtre temporelle acyclique, allouée statiquement à cette application entre deux fenêtres cycliques. Figure pour l'abrégé : Figure 2 Procédé d’échange de données dans une plateforme de communication, produit programme d’ordinateur et plateforme de communication associés La présente invention concerne un procédé d’échange de données dans une plateforme de communication notamment pour un environnement avionique modulaire intégré, connu également sur l’acronyme anglais de « IMA » ( Integrated Modular Avionics ). La présente invention concerne également un produit programme d’ordinateur et une plateforme de communication pour un tel environnement. De manière connue en soi, l’environnement IMA présente un concept qui permet l’utilisation d’une même ressource par différents clients en allouant à chaque client une part prédéfinie de la ressource. Ainsi, par exemple, un calculateur de l’environnement IMA se caractérise par le fait de pouvoir héberger plusieurs applications pouvant utiliser les ressources spatiales et temporelles de ce calculateur de manière partagée. L’invention trouve notamment son application dans un réseau avionique utilisant un bus de communication à gestion centralisée, notamment un bus de communication de type 1553. De manière connue en soi, un tel bus de communication de type 1553 présente un réseau de communication de données utilisé principalement dans le monde militaire. Il s’agit d’un réseau avionique de type maître-esclave avec une topologie en bus. Ainsi, dans un environnement IMA, le bus de communication de type 1553 présente une ressource qui doit être partagée entre les applications. Ce bus présente un faible débit au regard de certains standards actuels. Le partage de ce bus doit donc être réalisé de manière particulièrement fine, afin de permettre les communications nécessaires. Les données numériques circulant via le bus de communication de type 1553 présentent généralement des flux de données de deux types. Le premier type de ces flux correspond à des flux de données cycliques, dont la transmission se reproduit à l’identique dans le temps. Ces flux sont donc parfaitement prédictibles, ce qui permet d’éviter toute congestion des données dans le réseau. Le deuxième type de flux de données concerne des flux de données acycliques. Ces flux sont par nature aléatoires et sont généralement liés à des demandes spécifiques qui ne sont pas prévisibles au niveau du bus de communication 1553. Toutefois, ces flux de données de type acyclique doivent être traités de manière plus ou moins prioritaire et se traduisent généralement par un trafic de données supplémentaire. Dans un environnement donné, il arrive que les flux de données de type acyclique soient supérieurs au débit réservé au trafic acyclique du bus de communication de type 1553. De plus, de tels flux de type acyclique sont potentiellement partagés entre les différentes applications utilisant le réseau et l’évolution d’une application peut modifier le comportement de ces flux acycliques correspondant aux autres applications. Par conséquent, l’évolution d’une application peut avoir des répercussions sur le comportement d’autres applications, ne permettant pas de ce fait une certification avionique incrémentale. La présente invention a pour but de résoudre ces problèmes et de proposer donc une résolution déterministe de l’ensemble des transmissions dans les réseaux avioniques utilisant le bus de communication 1553 ou autre bus analogue, notamment en ce qui concerne les flux de données acycliques. Cela permet alors d’éviter des congestions de flux de type acyclique dans le réseau avionique, ce qui évite la nécessité de requalification et/ou re-certification de l’ensemble des applications en cas de modification de l’une d’entre elles. À cet effet, l’invention a pour but un procédé d’échange de données dans une plateforme de communication notamment pour un environnement avionique modulaire intégré, la plateforme comprenant une pluralité de dispositifs abonnés aptes à mettre en œuvre des applications et un dispositif de gestion raccordé à chaque dispositif abonné via un réseau informatique et apte à contrôler les échanges de flux de données entre les applications, chaque flux de données étant de type cyclique ou de type acyclique. Le procédé comprend une pluralité d’étapes de transmission cyclique et une pluralité d’étapes de transmission acyclique ; chaque étape de transmission cyclique comprenant la transmission d’au moins un flux de données de type cyclique par au moins une application et étant mise en œuvre dans une fenêtre temporelle, dite fenêtre cyclique, prédéterminée pour ce flux de données et chaque étape de transmission acyclique comprenant la transmission d’au moins un flux de données de type acyclique par au moins une application et étant mise en œuvre dans une fenêtre temporelle, dite fenêtre acyclique, allouée statiquement à cette application entre deux fenêtres cycliques. Suivant d’autres aspects avantageux de l’invention, le procédé comprend une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les combinaisons techniquement possibles : - chaque fenêtre cyclique est comprise dans une unité temporelle de référence, l’ensemble des unités temporelles de référence suivant l’une après l’autre et formant un cycle de cadencement ; - chaque fenêtre acyclique est allouée dans l’une des unités temporelles de référence en dehors de la fenêtre cyclique correspondante ; - les flux de données sont échangés dans la plateforme de communication selon un protocole utilisant un bus de communication à gestion centralisée, notamment un bus de communication à gestion centralisée de type 1553 ; - chaque étape de transmission est lancée par le dispositif de gestion conformément à la fenêtre temporelle courante ; - chaque fenêtre acyclique est allouée en fonction d’une bande passante disponible pour transmettre le flux de données correspondant ; - pour au moins une application : - chaque flux de données de type acyclique correspondant à cette application définit un niveau de priorité par rapport aux autres flux de données de type acyclique de cette application ; - les flux de données de type acyclique correspondant à cette application sont transmises dans une ou plusieurs fenêtres acycliques correspondant à cette application selon leur niveau de priorité ; - au moins un flux de données de type acyclique est associé à un temps de vieillissement, la transmission de ce flux de données de type acyclique étant abandonnée lorsqu’elle n’est pas faite dans son temps de vieillissement ; - au moins une étape de transmission acyclique est mise en œuvre dans un intervalle temporel disponible lorsque cet intervalle temporel intervient avant la fenêtre acyclique allouée à l’application correspondante ; - au moins une étape de transmission par latence comprenant la transmission d’au moins un flux de données de type acyclique associé à une latence maximale et étant mise en œuvre dans une fenêtre temporelle allouée statiquement à ce flux entre deux fenêtres cycliques en respectant la latence maximale. L’invention a également pour objet un produit programme d’ordinateur comportant des instructions logicielles qui, lorsque mises en œuvre par un équipement informatique, mettent en œuvre le procédé tel que défini ci-dessus. L’invention a également pour objet une plateforme de communication pour un environnement avionique modulaire intégré comprenant une pluralité de dispositifs abonnés aptes à mettre en œuvre des applications et un dispositif de gestion raccordé à chaque dispositif abonné via un réseau informatique et apte à contrôler les échanges de flux de données entre les applications, chaque flux de données étant de type cyclique ou de type acyclique ; la plateforme étant configurée pour mettre en œuvre le procédé tel que défini ci-dessus. Les caractéristiques et avantages de l’invention apparaîtront à la lecture de la description qui va suivre, donnée à titre d’exemple et non limitative, faite en référence aux dessins annexés, sur lesquels : - la est une vue schématique d’une plateforme de communication selon l’invention ; - les figures 2 à 4 sont différentes illustrations d’un procédé de communication mis en œuvre par la plateforme de communication de la . La présente en effet une vue schématique d’une plateforme de communication 10 selon l’invention. La plateforme de communication 10 est notamment utilisable dans un environnement avionique modulaire intégré, connu également sous le terme de « environnement IMA » (de l’acronyme anglais Integrated Modular Avionics ). Comme expliqué précédemment, l’environnement IMA permet l’utilisation d’une même ressource par différents clients en allouant à chaque client une part prédéfinie de la ressource. La plateforme de communication 10 est embarquée dans un aéronef, par exemple un avion de combat. Comme cela est représenté sur la , la plateforme de communication 10 comprend une pluralité de dispositifs abonnés 12 et un dispositif de gestion 14. Le dispositif de gestion 14 est connecté à chaque dispositif abonné 12 via un réseau informatique 16. Le réseau informatique 16 est mis en œuvre selon un protocole de communication utilisant un bus de communication à gestion centralisée, notamment un bus de communication de type 1553. Par « bus de type 1553 » ou « bus de communication de type 1553 », on entend tout bus de communication à gestion centralisée dont les principes de communication sont basés sur le bus de communication 1553. Par exemple, toute version améliorée du bus de communication 1553 ou par exemple le bus de communication 3910 peuvent être considérés en tant que bus de communication de type 1553. Selon un exemple particulier de l’invention, le réseau informatique 16 est configuré pour fonctionner selon le protocole de communication MIL-STD-1553, connu notamment dans le domaine militaire. Chacun des dispositifs abonnés 12 présente un client et/ou une ressource partagée entre différents clients. Ainsi, au moins certains des dispositifs abonnés 12 sont aptes à mettre en œuvre des applications. Ces applications sont aptes à transmettre des données numériques sous la forme de flux de données entre ces différentes applications ou alors aux ressources partagées, via le réseau informatique 16 comme cela sera expliqué par la suite. Chaque flux de données est de type cyclique ou de type acyclique. De manière connue en soi, les flux de données de type cyclique correspondent à des flux de données dont la transmission se reproduit à l’identique dans le temps selon un cycle de cadencement. Les flux de données de type acyclique présentent des flux de données aléatoires correspondant à des demandes particulières envoyées par les applications mises en œuvre par les dispositifs abonnés 12. Les flux de données de type acyclique présentent donc des flux aléatoires qui peuvent être envoyés par des applications et/ou des ressources de la plateforme de communication 10 de manière qui ne peut pas être prédite au stade de configuration de la plateforme de communication 10. Selon un exemple particulier de réalisation, les flux de données de type acyclique associés à au moins l’une des applications mises en œuvre par les dispositifs abonnés 12 présentent des niveaux de priorité différents. Ces niveaux de priorité permettent donc à l’application de déterminer l’ordre selon lequel ces flux de données acycliques doivent être transmis. Selon un exemple complémentaire ou alternatif, au moins certains des flux de données de type acyclique présentent un temps de vieillissement. Ce temps de vieillissement indique un délai au-delà duquel la transmission du flux de données correspondant doit être abandonnée lorsqu’elle n’est pas faite avant. Selon encore un exemple complémentaire ou alternatif, au moins certains des flux de données de type acyclique présentent également une latence maximale correspondant au délai maximal sous lequel ce flux de données doit être transmis. Le dispositif de gestion 14 permet de contrôler l’ensemble des échanges entre les dispositifs abonnés 12 via le réseau avionique 16. En particulier, ce dispositif de gestion 14 est connu sous le terme anglais de Bus C ontroller . Ce dispositif de gestion 14 permet donc de contrôler l’ensemble des échanges entre les dispositifs abonnés 12 via le réseau avionique 16, selon des règles de gestion prédéterminées permettant de rendre ce réseau avionique 16 déterministe. Ces règles de gestion sont par exemple déterminées au stade de configuration de la plateforme de communication 10. En particulier, le dispositif de gestion 14 permet de mettre en œuvre un procédé d’échange de données dans la plateforme de communication 10 qui sera expliqué en détail par la suite. Ce procédé d’échange de données comprend une pluralité d’étapes de transmission cyclique et une pluralité d’étapes de transmission acyclique. La mise en œuvre de l’ensemble de ces étapes est gérée par le dispositif de gestion 14 selon les règles prédéterminées. Ces règles seront donc expliquées ci-dessous. Selon ces règles, les étapes de transmission cyclique sont répétées selon un cycle de cadencement, connu sous le terme anglais de MAF ( Major Frame ). De manière connue en soi, chaque cycle de cadencement est composé d’une pluralité d’unités temporelles de référence, connues sous le terme anglais de MIF ( Minor Frame ). Les unités temporelles de référence sont par exemple toutes de même durée et s’enchaînent l’une après l’autre de manière continue au sein d’un même cycle de cadencement MAF. Chaque unité temporelle de référence comprend une fenêtre temporelle de transmission de flux de données de type cyclique. Une telle fenêtre temporelle est dite par la suite fenêtre cyclique. Les fenêtres cycliques sont attribuées de manière prédéterminée au stade de la configuration de la plateforme de communication 10 à chacun des flux de données de type cyclique. Dans l’exemple de la , un cycle de cadencement MAF est illustré. Ce cycle de cadencement MAF est composé de 6 unités temporelles de référence MIF1 à MIF6. Chacune de ces unités temporelles de référence MIF1 à MIF6 définit une fenêtre cyclique qui est illustrée par une portion hachurée sur cette . Selon l’invention, et comme cela est représenté sur la , au moins certaines des unités temporelles de référence et de préférence l’ensemble des unités temporelles de référence, comprennent en outre des fenêtres temporelles dédiées à la transmission des flux de données de type acyclique. Plus particulièrement, selon un exemple de réalisation, chaque unité temporelle de référence comprend une fenêtre temporelle qui est allouée de manière statique à l’une des applications mises en œuvre par l’un des dispositifs abonnés 12. Cette fenêtre temporelle est dite par la suite fenêtre acyclique et permet la transmission de l’ensemble des flux de données de type acyclique qui correspondent à cette application. Notamment, dans l’exemple de la , les fenêtres acycliques F1 à F6 sont associées à des applications différentes. Ainsi, dans l’exemple de cette figure, la première fenêtre acyclique F1 est déterminée pour une première application A1 et la deuxième fenêtre acyclique F2 est déterminée pour une deuxième application A2. La première fenêtre acyclique F1 est alors placée dans la partie temporelle disponible de la première unité temporelle de référence MIF1 et la deuxième fenêtre acyclique F2 est placée dans la partie disponible de la deuxième unité temporelle de référence MIF2. Ensuite, des fenêtres acycliques relatives à la première application A1 peuvent être placées dans chaque unité temporelle de référence d’ordre impair (c’est-à-dire MIF3 et MIF5) et les fenêtres acycliques relatives à la deuxième application A2 peuvent être placées dans chaque unité temporelle de référence d’ordre pair (c’est-à-dire MIF4 et MIF6). Les fenêtres acycliques sont donc déterminées en fonction de la bande passante disponible dans le réseau informatique 16 et le temps disponible dans l’unité temporelle de référence correspondante. Il est donc clair que plusieurs fenêtres acycliques correspondant à des applications différentes peuvent par exemple être placées dans une même unité temporelle de référence lorsque la bande passante et le temps disponible à l’intérieur de cette unité temporelle de référence le permettent. Dans l’exemple de la , lors de la mise en œuvre du procédé d’échange de données selon l’invention, le dispositif de gestion 14 lance soit une étape de transmission cyclique, soit une étape de transmission acyclique en fonction de la fenêtre temporelle courante. Ainsi, lors de chaque étape de transmission cyclique, des flux de données de type cyclique sont transmis par les applications correspondantes, conformément aux règles prédéterminées. Lors de chaque étape de transmission acyclique, l’application correspondant à la fenêtre acyclique en cours a la possibilité de transmettre des flux de données acycliques selon la bande passante disponible dans cette fenêtre acyclique. Lorsque l’application correspondant à la fenêtre acyclique en cours comprend plusieurs flux de données acycliques à transmettre, elle peut les transmettre selon les niveaux de priorité définis par ces flux. De plus, lorsqu’au moins certains des flux de données acycliques sont associés à un temps de vieillissement, l’application a la possibilité d’abandonner le transfert de ce flux lorsque le temps de vieillissement a expiré et le flux n’a pas été transmis. Selon un exemple particulier de l’invention, au moins certaines étapes de transmission acyclique sont mises en œuvre par le dispositif de gestion 14 dans un intervalle temporel disponible lorsque cet intervalle temporel intervient avant la fenêtre acyclique allouée à l’application correspondante. Ce cas est notamment illustré sur la . En particulier, dans l’exemple de cette , la deuxième application A2 devant transmettre ses flux de données de type acyclique dans la deuxième unité temporelle de référence MIF2 peut transmettre ces flux dans la première unité de référence MIF1, lorsque la première application A1 n’a pas de flux de données de type acyclique à transmettre ou lorsqu’elle n’utilise pas entièrement la bande passante dans sa fenêtre acyclique comprise dans la première unité de référence MIF1. Selon encore un autre exemple de réalisation combinable avec les précédents exemples de réalisation, le procédé d’échange de données peut comprendre également au moins une étape de transmission, dite transmission par latence, d’au moins certains flux de données de type acyclique pour lesquels une latence maximale est définie. Cette étape de transmission est mise en œuvre par le dispositif de gestion 14 dans une fenêtre temporelle particulière qui est allouée statiquement à un flux de données de type acyclique, en respectant la latence maximale attribuée à ce flux. Ainsi, dans l’exemple de la , au moins certains flux de la première application A1 peuvent être transmis dans une fenêtre temporelle particulière allouée statiquement dans le temps disponible entre des fenêtres temporelles cycliques pour respecter sa latence maximale. Cela est illustré en détail sur la . En particulier, dans l’exemple de cette , la fenêtre F3 présente une fenêtre particulière allouée statiquement à un flux de données de type acyclique particulier de la première application A1, en respectant la latence maximale associée à ce flux. Ainsi, la première application A1 a la possibilité d’émettre ce flux dans la première fenêtre acyclique F1 lorsque les autres flux le permettent (notamment après l’analyse des priorités et des latences maximales éventuelles associées à ces flux). Lorsque cela n’est pas possible, ce flux particulier sera émis dans la fenêtre F3 qui lui est allouée pour respecter sa latence maximale. Les autres flux de données de type acycliques de la même application peuvent par exemple être transmis dans les fenêtres temporelles acycliques allouées pour cette application ou alors dans le temps disponible. Dans ce dernier cas, ces flux sont donc transmis selon le principe de meilleur effort, connu sous le terme anglais de best effort . On conçoit alors que la présente invention présente un certain nombre d’avantages. Tout d’abord, l’invention permet de rendre la transmission de l’ensemble des flux au sein d’une plateforme de communication dans un environnement IMA complètement déterministe. Cela a été rendu possible en associant à chaque flux de données de type acyclique une fenêtre temporelle particulière ou en associant une latence maximale à ce flux qui peut être tenue par la plateforme. Ainsi, chacune des applications peut avoir ses fenêtres de transmission dédiées, ce qui évite d’impacter les autres applications quand ladite application transmet des données particulières, non prévues par la configuration initiale de la plateforme. Cela évite alors la nécessité de requalification et/ou re-certification des applications en cas de changement d’au moins l’une d’entre elles, tout en respectant le protocole de transmission basé sur le bus de communication de type 1553. Procédé d’échange de données dans une plateforme de communication (10) notamment pour un environnement avionique modulaire intégré, la plateforme (10) comprenant une pluralité de dispositifs abonnés (12) aptes à mettre en œuvre des applications et un dispositif de gestion (14) raccordé à chaque dispositif abonné (12) via un réseau informatique (16) et apte à contrôler les échanges de flux de données entre les applications, chaque flux de données étant de type cyclique ou de type acyclique ; le procédé comprenant une pluralité d’étapes de transmission cyclique et une pluralité d’étapes de transmission acyclique ; chaque étape de transmission cyclique comprenant la transmission d’au moins un flux de données de type cyclique par au moins une application et étant mise en œuvre dans une fenêtre temporelle, dite fenêtre cyclique, prédéterminée pour ce flux de données ; chaque étape de transmission acyclique comprenant la transmission d’au moins un flux de données de type acyclique par au moins une application et étant mise en œuvre dans une fenêtre temporelle, dite fenêtre acyclique, allouée statiquement à cette application entre deux fenêtres cycliques. Procédé selon la revendication 1, dans lequel : - chaque fenêtre cyclique est comprise dans une unité temporelle de référence, l’ensemble des unités temporelles de référence suivant l’une après l’autre et formant un cycle de cadencement ; - chaque fenêtre acyclique est allouée dans l’une des unités temporelles de référence en dehors de la fenêtre cyclique correspondante. Procédé selon la revendication 1 ou 2, dans lequel les flux de données sont échangés dans la plateforme de communication selon un protocole utilisant un bus de communication à gestion centralisée, notamment un bus de communication à gestion centralisée de type 1553. Procédé selon l’une quelconque des revendications précédentes, dans lequel chaque étape de transmission est lancée par le dispositif de gestion (14) conformément à la fenêtre temporelle courante. Procédé selon l’une quelconque des revendications précédentes, dans lequel chaque fenêtre acyclique est allouée en fonction d’une bande passante disponible pour transmettre le flux de données correspondant. Procédé selon l’une quelconque des revendications précédentes, dans lequel pour au moins une application : - chaque flux de données de type acyclique correspondant à cette application définit un niveau de priorité par rapport aux autres flux de données de type acyclique de cette application ; - les flux de données de type acyclique correspondant à cette application sont transmises dans une ou plusieurs fenêtres acycliques correspondant à cette application selon leur niveau de priorité. Procédé selon l’une quelconque des revendications précédentes, dans lequel au moins un flux de données de type acyclique est associé à un temps de vieillissement, la transmission de ce flux de données de type acyclique étant abandonnée lorsqu’elle n’est pas faite dans son temps de vieillissement. Procédé selon l’une quelconque des revendications précédentes, dans lequel au moins une étape de transmission acyclique est mise en œuvre dans un intervalle temporel disponible lorsque cet intervalle temporel intervient avant la fenêtre acyclique allouée à l’application correspondante. Procédé selon l’une quelconque des revendications précédentes, comprenant en outre au moins une étape de transmission par latence comprenant la transmission d’au moins un flux de données de type acyclique associé à une latence maximale et étant mise en œuvre dans une fenêtre temporelle allouée statiquement à ce flux entre deux fenêtres cycliques en respectant la latence maximale. Produit programme d’ordinateur comportant des instructions logicielles qui, lorsque mises en œuvre par un équipement informatique, mettent en œuvre le procédé selon l’une quelconque des revendications précédentes. Plateforme de communication (10) notamment pour un environnement avionique modulaire intégré, comprenant une pluralité de dispositifs abonnés (12) aptes à mettre en œuvre des applications et un dispositif de gestion (14) raccordé à chaque dispositif abonné (12) via un réseau informatique (16) et apte à contrôler les échanges de flux de données entre les applications, chaque flux de données étant de type cyclique ou de type acyclique ; la plateforme (10) étant configurée pour mettre en œuvre le procédé selon l’une quelconque des revendications 1 à 9.