TITRE : Systèm e de traitement graphique de données

La présente invention concerne les systèmes de traitement graphique de données et plus particulièrement les systèmes monocœur et multicœur pour interface graphique.

Elle se rapporte à une interface homme-machine utilisant un tel système de traitement.

Une application particulièrement intéressante de l’invention concerne les systèmes de traitement de données pour interfaces homme- machine embarquées à bord d’aéronefs.

Ainsi, dans ce domaine, les systèmes de traitement de données sont classiquement utilisés pour exécuter des calculs graphiques et créer des contenus graphiques destinés à être affichés sur un écran de l’interface. Il peut en particulier s’agir de créer des contenus graphiques comportant des zones tactiles manipulables manuellement, en l’espèce par un pilote, pour l’exécution de fonctions prédéfinies.

Pour la réalisation de calculs graphiques, on utilise, de manière générale, au moins un processeur de calculs graphiques (GPU, pour « Graphie Processing Unit ») coopérant avec au moins une unité centrale de traitement CPU (pour « Central Processing Unit » en anglai s).

Les architectures GPU sont des architectures de calcul exécutant un j eu d’instructions tels que des calculs bidimensionnels ou tridimensionnels permettant de construire une image.

Les GPU peuvent être composés d’un cœur unique ou de multiples cœurs de calcul qui se répartissent les tâches graphiques. Il s’agit d’architectures de traitement partiellement ou entièrement parallèles.

En ce qui concerne les systèmes de traitement de données destinés à être embarqués à bord d’aéronefs, comme on le conçoit, ce type de système électronique est soumis à des contraintes sévères de maîtrise du matériel employé et de déterminisme, qui impose de déterminer de manière certaine le fonctionnement du système, par exemple en ce qui concerne la durée de transfert de données. Ils nécessitent une validation et une certification par les autorités compétentes.

Les systèmes de traitement de données pour les interfaces homme-machine embarqués pour avions commerciaux doivent ainsi satisfaire un certain nombre de règles et de recommandations de développement.

Dans l’état de la technique, les systèmes de calcul embarqués sont généralement réalisés à partir de composants pris sur étagère ou « COTS » (pour « Commercial Off The Shelf »), c’est-à-dire de composants fabriqués en grande série pour réduire les coûts de fabrication et de maintenance.

Généralement, les composants constituant la chaîne de traitement pour les interfaces homme-machine sont groupés dans une unique zone par exemple un cœur physique.

On entend par « chaîne de traitement », une série de modules configurés sur ces composants et comprenant au moins une application graphique, communément appelée « User Application » en anglais, ci- après UA, générant des instructions pour l’exécution de fonctions graphiques prédéfinies aidant au pilotage des aéronefs.

La chaîne de traitement comprend également au moins une unité de calcul graphi que GPU et optionnellement un système d’affichage dans un poste de pilotage (CDS « Cockpit Di splay System » selon le vocable anglosaxon), ci-après CDS s’il n’y a pas de norme à respecter.

Enfin, la chaîne de traitement est délimitée par au moins un dispositif périphérique relié à un ou à plusieurs écrans d’affichage par exemple des écrans LCD.

Compte tenu du temps de développement et de la durée de vie d’un produit pour l’aéronautique, qui peut atteindre plusieurs dizaines d’années, il est courant que les composants utilisés lors de la conception de la chaîne de traitement soient en fait obsolètes même avant la fin du processus de conception, obligeant à réali ser des phases de modification et de recertification périodique. Autrement dit, le remplacement d’un de ces composants par de nouveaux composants différents conduit à recertifier tous les composants de la chaîne de traitement pour vérifier qu’il n’y ait pas de perturbations, ce qui peut être lent et coûteux.

En outre, les besoins relatifs à la composition de la chaîne de traitement diffèrent selon les industriels, obligeant le fournisseur à reconfigurer lesdits modules modifiant également leur emplacement, ce qui peut nécessiter des certifications à chaque nouvelle configuration.

Au vu de ce qui précède, l’invention se propose de pallier aux contraintes précitées dans un système de traitement graphique de données.

L’invention a donc pour obj et, selon un premier aspect, un système de traitement graphique de données, comprenant un au moins un cœur de traitement graphique de données comportant des moyens de mise en forme aptes à interpréter sous forme graphique ou sous forme d’instructions les données échangées via une interface homme-machine, et dans lequel lesdits moyens de mise en forme sont répartis sur un ou plusieurs cœurs.

Par « interprétation » on entend la possibilité de lire des données sous forme graphique ou sous forme d’un langage informatique, et d’exécuter les actions demandées ou nécessaires suite à cette lecture.

On peut citer par exemple le fait pour un pilote d’appuyer sur un bouton tactile affiché sur son écran conduisant par exemple à l’enclenchement d’un évènement et donc à l’exécution d’une fonction.

Les moyens de mi se en forme ont ainsi interprété des données sous forme graphique.

En outre, étant donné qu’appuyer sur un bouton tactile peut supposer que celui-ci change de forme graphique, des données sous forme d’instructions seront, dans ce cas, envoyées aux moyens de mise en forme pour modifier ladite forme du bouton.

Ces moyens de mise en forme sont ici répartis sur un ou plusieurs cœurs. Autrement dit, chaque cœur physique est entièrement ou partiellement partitionné et peut comporter une partie des moyens de mise en forme ou tout l’ensemble. Cela permet de réaliser une certification incrémentale.

Il est donc possible de mettre à j our une partie des moyens de mise en forme contenue dans un cœur physique sans devoir recertifier les autres parties des moyens de mise en forme accessibles via les autres cœurs physiques ou contenus dans le même cœur.

Avantageusement, les moyens de mise en forme comprennent des moyens de conversion aptes à convertir les données échangées via l’interface homme-machine, soit sous la forme graphique, soit sous la forme d’instructions, au moins un module de traitement apte à générer les instructions, et des moyens d’affichage aptes à afficher lesdites données sous forme graphique.

Ledit au moins un module de traitement est couplé aux moyens de conversion, eux-mêmes couplés auxdits moyens d’affichage.

On entend par « module de traitement » tout module U A apte à recevoir des données de capteurs par exemple et à générer des instructions pour représenter graphiquement lesdites données reçues.

Ces instructions sont envoyées auxdits moyens de conversion. Le module de traitement est aussi apte à recevoir des données suite à une interaction homme-machine, par exemple un appui sur un bouton, puis à envoyer des données sous forme d’instructions graphiques aux moyens de conversion pour éventuellement modifier le rendu du bouton.

Les moyens de conversion permettent, une fois les instructions graphiques reçues par le module UA, d’assurer des fonctions de calcul de l’affichage à proj eter sur un écran par exemple LCD.

Cette proj ection est rendue possible grâce à des moyens d’affichage sous forme de périphériques couplés à un ou à un plusieurs écrans d’affichage.

De préférence, les moyens de conversion comprennent au moins un module de mise en conformité apte à conformer les données à une norme de communication et d’affichage aéronautique ou automobile, et au moins une unité de calcul graphique apte à recevoir les données résultant de la mise en œuvre dudit au moins un module de mise en conformité et à les convertir en données aptes à être affichées par les moyens d’affichage. Ledit au moins un module de mise en conformité est de type CDS. Plus particulièrement, les données reçues par ledit au moins un module de traitement, sont rendus conforme à une norme telle que « ARINC 661 Part 1 » ou « ARINC 661 Part 2 » .

Par la suite, ces données conformes seront envoyées à au moins une unité de calcul graphique GPU apte à exécuter des fonctions de calcul pour permettre auxdites données d’être affichées sous forme graphique.

Bien sûr, les données peuvent être réparties entre plusieurs unités de calcul graphique aptes à fonctionner partiellement ou entièrement en parallèle.

Alternativement, les moyens de conversion comprennent au moins une unité de calcul graphique apte à recevoir les données résultant de la mise en œuvre dudit au moins un module de traitement et à les convertir en données aptes à être affichées par les moyens d’affichage.

En d’autres termes, les moyens de conversion sont ici optionnels. Par exemple, dans le cas où il n’y a pas de norme à respecter, le module de traitement U A peut envoyer une valeur d’altitude à afficher qui ne nécessite généralement pas de mise en conformité avec un standard quelconque.

Avantageusement, la répartition des moyens de mise en forme est configurable.

Ainsi, l’architecture comprenant les moyens de mise en forme est enti èrement modulaire. Autrement dit, on peut avoir par exemple, un module de traitement U A par cœur physique.

Cette configuration est particulièrement avantageuse étant donné que la mise à j our d’un module de traitement U A n’entraîne pas la mise à j our et la recertification des autres modules de traitement UA.

Ceci est également le cas pour le module CDS et l’unité de calcul graphique GPU.

Il est à noter qu’on peut également avoir un ensemble de modules de traitement U A et/ou de modules CDS et/ou d’unités de calcul graphique par cœur physique. On peut aussi choisir une autre configuration à tout moment. Par exemple, on peut choisir de répartir un ou plusieurs modules CDS sur plusieurs cœurs physiques ou les grouper dans un seul cœur physique.

Chaque unité de calcul graphique GPU est ainsi apte d’adresser ou un plusieurs écrans d’affichage.

De préférence, les moyens de mise en forme sont raccordés entre eux au moyen d’au moins un système de communication apte à autori ser les échanges de données entre lesdits moyens de mise en forme.

Le système de communication peut être un bus commun entre les moyens de mise en forme.

L’invention a encore pour obj et une interface graphique pour cockpit d’aéronef comprenant un système de traitement graphique de données tel que défini ci-dessus.

D’autres buts, caractéristiques et avantages de l’invention apparaîtront à la lecture de la description suivante, donnée uniquement à titre d’exemple non limitatif, et faite en référence aux dessins annexés sur lesquels :

[Fig 1 ] illustre un exemple de l’architecture générale d’un système de traitement de données conventionnel réalisé à partir de composants COTS ; [Fig 2A]

[Fig 2B]

[Fig 2C]

[Fig 2D]

[Fig 2E] représentent différentes configurations alternatives et exemplatives des moyens de mise en forme selon l’invention.

On a représenté sur la figure 1 l’architecture générale d’un système de traitement graphique de données selon l’invention, d’une interface homme-machine, désignée sous la référence numérique générale 1 .

L’architecture générale 1 est ici multicœur. Elle peut évidemment être monocœur.

Elle comprend, dans cet exemple de mode de réalisation, un ensemble de cœurs physiques de traitement de données C 1 -C4, ici au nombre de quatre, reliés entre eux par un système de communication B 1 , ici un bus de communication partagé apte à autoriser les échanges de données entre lesdits cœurs physiques C 1 à C4.

Chaque cœur physique de traitement est apte à fonctionner complètement ou partiellement en parallèle permettant de traiter des informations de manière simultanée dans le but de réaliser le plus grand nombre d’opérations en un temps plus court.

Comme on le voit sur la figure, chaque cœur de traitement C l - C4 comprend des moyens de mise en forme 2 aptes à interpréter sous forme graphique ou sous forme d’instructions les données échangées via une interface homme -machine non représentée ici .

Autrement dit, les moyens de mise en forme 2 sont aptes à lire des données sous forme graphique ou sous la forme d’un langage informatique, et d’exécuter les actions demandées ou nécessaires suite à cette lecture.

Le langage informatique peut être par exemple le langage de programmation C ou C++.

Les moyens de mise en forme 2 comportent une zone mémoire partitionnée en un ensemble de zones mémoires ZM aptes à stocker des programmes participant à l’interprétation sous forme graphique ou sous forme d’instructions les données échangés via l’interface homme- machine.

Chaque programme stocké dans une zone mémoire ZM peut communiquer avec un autre programme stocké dans une autre zone mémoire ZM à 1’intérieur du même cœur C 1 -C4.

Cette communication peut être réali sée par exemple via un bus de communication B2 apte à transférer les données résultant desdits programmes.

Cette architecture multicœur de traitement graphique des données peut être entièrement ou partiellement partitionnée.

Cela permet de réaliser une certification incrémentale.

Il est donc possible de mettre à j our une partie des moyens de mise en forme 2 contenue dans un cœur physique sans devoir recertifier les autres parties des moyens de mise en forme 2 accessibles via les autres cœurs physiques ou contenus dans le même cœur physique. Autrement dit, dans une architecture partitionnée, une modification d’un module U A ou CDS ou GPU contenu dans une partition, permet d’éviter de recertifier les autres modules contenus dans d’autres partitions.

Ce partitionnement est également modulaire, ce qui permet d’avoir plusieurs configurations alternatives possibles des moyens de mise en forme 2, dont certaines sont représentées sur les figures 2A à 2E.

Les moyens de mise en forme 2 comprennent au moins trois types de modules, illustrés dans la figure 2A, c’est-à-dire, UA, des moyens d’affichage EC sous la forme de périphériques, GPU et/ou CDS ici sous la dénomination PL.

Ces modules sont configurables et partitionnés dans les cœurs

C 1 -C4.

Sur la figure 2A est illustré un premier exemple de configuration. Ici, un unique module de traitement U A est couplé à un unique module de conversion PL, lui-même couplé à un unique périphérique d’affichage, et cela dans le même cœur C l .

Cette configuration est reproduite dans les troi s autres cœurs C2, C3 et C4.

Ainsi, si un de ces modules U A devait être modifié, les autres modules de traitement U A opérationnels ne seront pas mis à j our et/ou recertifiés.

On peut également avoir, comme illustré dans la figure 2B, un unique module de traitement U A stocké dans le cœur C l , couplé à un premier module de conversion PL I stocké dans le cœur C3 , et couplé à un deuxième et à un troisième module de conversion respectivement PL2, PL3 , stockés dans le cœur C2.

Une autre configuration possible, représentée dans la figure 2C, serait de stocker un premier et un deuxième module de traitement UA1 , UA2 dans le cœur C4 et les coupler à un module de conversion PL stocké dans le même cœur C4.

Le module de conversion PL peut être également couplé à un troisième module de traitement UA3 stocké dans le cœur C3 , et à troi s moyens d’affichage EC 1 , EC2 et EC3 qui sont, comme illustré dans la figure 2D, dans le cœur C4.

Une autre alternative serait de stocker le premier, le deuxième et le troi sième module de conversion PL I , PL2 et PL3 , et les moyens d’affichage EC dans le même cœur C4 comme représenté sur la figure 2E.

Bien évidemment, ces configurations sont données à titre d’exemples non limitatifs.

Ainsi, le partitionnement modulaire des cœurs physiques C 1 à C4 permet de modifier la configuration des moyens de mise en forme 2 selon les besoins du système tout en réduisant le nombre de modules à mettre à j our et/ou à recertifier si l’un d’eux devait être modifié.