INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Selon un autre mode de réalisation préféré de l’invention représenté sur la , le dispositif d’amortissement 40 associé à la seconde aube 26b située au centre, est complété par la coopération par frottements deux à deux d’autres surfaces des talons 32a, 32b. En effet, la seconde base 36b du talon mobile 32b comprend de part et d’autre de cette base 36b une extension circonférentielle 54 d’épaisseur réduite, venant se loger dans un évidement pratiqué sur la surface radialement interne 37a, au niveau d’une extrémité circonférentielle de celle-ci. Par conséquent, parmi les secondes surfaces de friction du talon mobile, le dispositif d’amortissement 40 comporte également une face radialement externe 52b de l’extension circonférentielle de gauche, coopérant par frottements avec une face d’évidement 52a prévue sur la surface radialement interne 37a de l’aube de gauche, cette face d’évidement 52a faisant alors partie intégrante des premières surfaces de friction du dispositif 40.
De même, parmi les secondes surfaces de friction du talon mobile, le dispositif d’amortissement 40 comporte également une face radialement externe 52b de l’extension circonférentielle de droite, coopérant par frottements avec une face d’évidement 52a prévue sur la surface radialement interne 37a de l’aube de droite, cette face d’évidement 52a faisant elle aussi partie intégrante des premières surfaces de friction du dispositif 40.
Bien entendu, diverses modifications peuvent être apportées par l’homme du métier à l’invention qui vient d’être décrite, uniquement à titre d’exemples non limitatifs et dans la limite de la portée des revendications annexées.
ROUE AUBAGEE POUR TURBOMACHINE D’AERONEF , COMPRENANT UN DISPOSITIF D’AMORTISSEMENT DYNAMIQUE REALISE A L’AIDE D’UN ORGANE DE RECONSTITUTION D’UNE VEINE DE CIRCULATION DES GAZ La présente invention se rapporte au domaine des turbomachines d’aéronef, et plus précisément à la conception des roues aubagées formant les turbines et les compresseurs de ces turbomachines.
Elle concerne plus spécifiquement l’amortissement dynamique par frottements des aubes, qui se succèdent selon la direction circonférentielle pour former une rangée annulaire d’aubes.
L’invention s’applique à toutes les conceptions de turbomachine, par exemple les turboréacteurs à soufflante entrainée directement par un corps basse pression, ou entraînée indirectement par un réducteur.
ETAT DE LA TECHNIQUE ANTERIEURE Les compresseurs et les turbines des turbomachines d’aéronefs sont réalisés par une succession axiale de roues aubagées fixes et mobiles, également dites roues aubagées de stator, et roues aubagées de rotor. Dans le cas où une telle roue aubagée est sectorisée angulairement, à savoir selon la direction circonférentielle de la roue, il convient habituellement de limiter les contraintes vibratoires sur les aubes agencées de manière adjacente selon la direction circonférentielle de la roue.
Pour ce faire, il est mis en œuvre des moyens permettant d’assurer un amortissement dynamique de ces secteurs, en dissipant l’énergie de la résonnance par frottements entre les talons des aubes. Une telle solution d’amortissement est par exemple connue du document FR 3 085 712 A1.
Une autre solution plus classique consiste à mettre en œuvre une technologie de frottements par contact, entre les talons des aubes adjacentes présentant des formes particulières. Cette technologie, également dite de « prétorsion », se caractérise par une découpe spécifique des deux faces circonférentielles opposées du talon, avec une excroissance coté extrados, et une empreinte de forme complémentaire du côté intrados. La coopération deux à deux de ces faces circonférentielles permet un maintien des deux talons adjacents l’un par rapport à l’autre, dans la direction axiale. Cette technologie de prétorsion est également dénommée par le terme « interlock » de langue anglaise.
Un autre avantage de ce procédé est que le risque que la donnée k qui est vérifiée soit accessible est bien moindre qu'avec un procédé de vérification classique. En effet, la donnée k n'est pas stockée en mémoire, et les données X1 à XN sont toutes indépendantes de la donnée k. Il faudrait donc avoir accès à toutes les données X1 à XN pour obtenir la donnée k.
Système sur puce comportant des moyens d’isolation des ressources et de contre-mesure, et procédé correspondant. Des modes de mise en œuvre et de réalisation de l’invention concernent les circuits intégrés, notamment les systèmes sur puce (« System on Chip » en anglais), par exemple un microcontrôleur ou un microprocesseur, et plus particulièrement les techniques d’isolation des ressources appartenant au système sur puce.
Dans les techniques d’isolation des ressources conventionnelles, typiquement seul un « domaine de confiance » mis en œuvre de façon logicielle notamment pour la gestion des restrictions et des droits d’accès, est informé d’un accès illégal à une ressource, par un mécanisme de gestion des accès illégaux.
En outre, des moyens de contre-mesure peuvent classiquement être prévus pour limiter le fonctionnement du système sur puce contre de potentielles anomalies, par exemple en restreignant les accès à toutes ou certaines des ressources seulement à un environnement de confiance sécurisé. Les anomalies peuvent correspondre à une violation des règles d’isolations des ressources, pouvant être causées par une attaque visant à une récupération de données sensibles ou secrète, et dans le cadre d’une ingénierie inversée.
Or, il est de la responsabilité du domaine de confiance de générer un signal d’alerte commandant la fonctionnalité des moyens de contre-mesure si un accès illégal est identifié comme une anomalie ou comme une attaque potentielle.
Lors du traitement logiciel de décision mis en œuvre pour générer le signal d’alerte, des secrets ne sont pas bloqués pendant plusieurs cycles d’horloge. En outre, une accumulation d’interruptions du domaine de confiance, causée par des accès illégaux multiples, pourrait créer un déni de services au niveau du domaine de confiance, et retarder ledit traitement logiciel.
Ainsi, il existe un besoin d’améliorer les mécanismes de protections contre les accès illégaux, notamment du point de vue de la mise en œuvre des actions et moyens de contre-mesure.
A cet égard, des modes de réalisation et de mise en œuvre prévoient de générer directement le signal d’alerte commandant les moyens de contre-mesure, depuis la ressource qui a reçu un accès illégal, sans passer par le traitement logiciel de décision.
En outre, des modes de réalisation et de mise en œuvre prévoient de pouvoir sélectionner le comportement pour chaque ressource afin de décider si un accès illégal doit être silencieux ou causer la génération du signal d’alerte.
Selon un aspect, il est ainsi proposé un système sur puce comportant au moins une ressource esclave, un système d’isolation des ressources, et un moyen de contre-mesure apte et destiné à limiter le fonctionnement du système contre de potentielles anomalies, et, pour ladite au moins une ressource esclave, un circuit de protection configuré pour bloquer ou transmettre des transactions adressées à la ressource en fonction de droits d’accès de la ressource et de la transaction, le circuit de protection étant configuré pour générer et communiquer directement un signal d’alerte au moyen de contre-mesure en cas de blocage d’une transaction.
Le système sur puce peut typiquement comporter au moins un dispositif maître apte à générer les transactions adressées à la ressource, par exemple via un bus d’interconnexion.
On notera en particulier que c’est le circuit de protection associé à sa ressource respective (et qui est également parfois appelé « pare-feu », ou « firewall » en anglais) qui est à l’origine de la génération du signal d’alerte. La commande de l’action prise par les moyens de contre-mesure est ainsi directement communiquée, ce qui améliore la réactivité et la fiabilité du mécanisme de contre-mesure.
représente une vue schématique du procédé de gestion d’ambiance pour un habitacle du véhicule automobile de la , selon l’invention.
Description détaillée La illustre schématiquement un véhicule automobile 2 selon l’invention.
Le véhicule automobile 2 comprend préférentiellement un dispositif 6 correspondant à un ordinateur de bord 6 apte à mette en œuvre les étapes d’un procédé de gestion d’ambiance selon l’invention, notamment en employant au moins un élément de captation de paramètres internes 8 à l’habitable 4 et/ou au moins un élément de captation de paramètres externes 10 à l’habitable 4.
Le dispositif 6 comprend, ou peut être relié à, une pluralité d’unités qui seront décrites suivant la .
La représente schématiquement le procédé 100 de gestion d’ambiances multisensorielles pour l’habitacle 4 du véhicule automobile 2 de la .
Le procédé 100 comprend une pluralité d’étapes 102, 104, 106, 108, dont une étape de diffusion d’ambiance 108 au sein de l’habitacle, ladite diffusion comprenant une activation d’au moins une des sources suivantes : visuelle, sonore, olfactive, organique et/ou haptique.
Avantageusement, le procédé 100 comprend une première étape 102 de captation de paramètres contextuels à l’habitacle comprenant au moins un paramètre extérieur à l’habitacle.
Préférentiellement, la captation 102 de paramètres comprend des paramètres intérieurs et/ou extérieurs dudit habitacle (environnementaux et contextuels). L’étape 102 est opérée au moyen d’une unité de captation du véhicule automobile, qui rassemble des données depuis l’intérieur et/ou l’extérieur de l’habitacle.
Les paramètres extérieurs à l’habitacle sont liés au contexte dans lequel évolue le véhicule automobile, i.e. l’environnement externe au véhicule automobile. Ces paramètres extérieurs sont captés au moyen d’au moins un élément de la liste suivante : une caméra, un microphone, un capteur de luminosité, un capteur de pluie, un radar, un capteur de mesure d’humidité, un détecteur de gaz, un capteur de température et un système de positionnement GPS et un système de connexion à distance.
Préférentiellement, le système de connexion à distance comprend une connexion à un autre véhicule automobile (« car to car ») et/ou une connexion à une infrastructure (« car to infrastructure ») et/ou à un serveur informatique à distance (« cloud »).
La diffusion peut faire le lien avec l’état de la chaussée (pouvant être filmée par la caméra ou récupérée depuis le « cloud » par exemple) et/ou le trafic routier et/ou les panneaux de signalisation et/ou le paysage et/ou l’éclairage extérieur (jour/nuit), etc, afin d’assurer une communication directe entre l’environnement extérieur et les occupants du véhicule automobile.
De manière avantageuse, les ambiances multisensorielles générées en fonction de paramètres extérieurs à l’habitacle permettent d’améliorer considérablement la sécurité routière, par exemple, en diffusant des effets de la lumière et/ou du son pour avertir les conducteurs de dangers potentiels sur la route.
Préférentiellement, la captation 102 comprend une combinaison de paramètres extérieurs et/ou de paramètres intérieurs de l’habitacle. Ces derniers sont captés au moyen d’au moins un élément de la liste suivante : une caméra, un microphone, un capteur de présence humaine (permettant la détermination du nombre d’occupants dans le véhicule), un capteur de mesure d’humidité, un système de positionnement GPS, un capteur de pression, un capteur de température, une horloge et un calendrier.
Avantageusement, le procédé 100 comprend, en outre, une étape d’analyse 104 des paramètres captés, préférentiellement au moyen d’une unité d’analyse apte à interpréter les données captées lors de la captation 102. Ainsi, il peut être possible d’accéder à l’état du conducteur ou des passagers, i.e. état émotionnel, cognitif et physique. Cela permet au procédé de proposer des ambiances ou des solutions de remédiation, par exemple, contre la somnolence du conducteur, le stress, la fatigue, l’inconfort postural, etc. Par exemple, les odeurs peuvent être utilisées pour aider à prévenir la somnolence au volant.
Préférentiellement, l’analyse 104 des paramètres captés permet également d’accéder à l’état de l’air intérieur et/ou de l’air extérieur, à l’état de la route, du trafic, des conditions météorologiques, etc.
Le procédé est mis en œuvre par un calculateur/ordinateur/produit programme.
Le calculateur, destiné à être en communication avec un utilisateur, via une interface par exemple, est configuré pour mettre en œuvre :
– un modèle/outil de simulation, correspondant à tout outil basé sur le processus de modélisation d'un phénomène réel à l'aide d'un ensemble de techniques mathématiques et de connaissances en physique. Dans notre cas, les outils de simulation nous permettent de calculer des indicateurs de performance pour l'évaluation de la conception d'un rotor,
– un modèle d’intelligence artificielle, ou modèle d’IA, autrement dit un modèle d'apprentissage automatique ou de machine learning. Dans le cas présent, le modèle d’intelligence artificielle correspond à un réseau de neurones bayésiens par indicateur de performance, appelé ci-dessous « BNN » pour « Bayesian Neural Networks » en langue anglaise.
Le modèle BNN permet notamment de définir des « prédictions probabilistes ». Autrement dit ici, le modèle BNN permet, à partir d’un ensemble de paramètres donné caractérisant le rotor, de définir une prédiction d’indicateur de performance (définie par une valeur moyenne) et une incertitude (définie par un écart-type) associée à ladite prédiction.
Chaque modèle d’IA est caractérisé par un critère de performance de modèle d’IA, représentant la variation (pour des dimensions identiques de rotor), entre les valeurs obtenues avec le modèle d’IA et les valeurs obtenues avec un modèle de simulation. En effet, la différence entre la valeur prédite par le modèle d’IA et la valeur réelle obtenue par les logiciels de simulations forment une erreur. Cette erreur peut par exemple correspondre à l’erreur quadratique moyenne.
Plus précisément chaque indicateur de performance peut être défini par un modèle BNN. Selon notre exemple, puisque le rotor est contraint par 4 indicateurs de performance, il est donc nécessaire de définir quatre réseaux BNN.
Chaque modèle d’IA est caractérisé par un indicateur de confiance, permettant de caractériser la fiabilité du modèle IA en question.
Le procédé comprend tout d’abord une phase préliminaire, consistant à entraîner les quatre modèles BNN décrits ci-dessus.
Entraîner un BNN comporte les mêmes étapes de base que l’entraînement d'un réseau neuronal standard.
Collecte des données E01
La première étape consiste à collecter et à prétraiter les données.
La collecte de données (des outils de simulation classique) est une étape cruciale dans le développement et l'entraînement de modèles d'apprentissage automatique, car les performances du modèle d’IA finales seront directement influencées par la qualité et la quantité des données collectées.
Lors de cette étape, pour chaque dimensionnement/géométrie de pièce, autrement dit de rotor, des modèles/outils de simulations sont utilisés pour déterminer les indicateurs de performance décrits précédemment. Plus précisément : L’outil Mathematica est utilisé pour calculer le facteur de sécurité safety factor, MotorCAD est utilisé pour calculer les indicateurs de performance concernant le couple, le facteur de vibrations et la fluctuation de couple.
Selon un mode de réalisation, le système sur puce comporte un canal d’alerte connectant directement le circuit de protection avec le moyen de contre-mesure et dédié à la transmission dudit signal d’alerte.
En d’autres termes, le signal d’alerte peut être communiqué directement et sans intermédiaire via le canal d’alerte, et n’étant pas soumis à une mise en œuvre logicielle la fiabilité est ainsi améliorée.
Selon un mode de réalisation, le système sur puce comporte une pluralité de ladite au moins une ressource, et un élément multiplexeur configuré pour regrouper tous les canaux d’alerte connectés auxdits circuits de protection respectifs, sur un seul canal d’alerte sortant et directement connecté au moyen de contre-mesure.
Par exemple, l’élément multiplexeur a une fonction de transmission des signaux d’alerte, indistinctement de leurs provenances, du type « porte OU ».
Selon un mode de réalisation, le système d’isolation des ressources comporte, dans un jeu de registres de configuration, pour chaque ressource un emplacement pour contenir une donnée de paramétrage des alertes, le circuit de protection de chaque ressource étant configuré pour générer ou non ledit signal d’alerte en cas de blocage d’une transaction adressée à la ressource, en fonction de la donnée de paramétrage des alertes pour cette ressource.
Ainsi, la commande de l’action prise par les moyens de contre-mesure peut être activé ou désactivé en fonction de chaque ressource. En effet, une ressource peut être considérée critique ou non, en fonction de l’utilisation qui est faite du système sur puce. Ainsi il peut être souhaitable ou non d’activer le signal d’alerte en cas de blocage d’une transaction pour une ressource donnée.
Selon un mode de réalisation, le système sur puce comporte en outre au moins un dispositif maître apte à générer lesdites transactions adressées à la ressource, les transactions comprenant une donnée d’identification du maître, et le système d’isolation des ressources comporte, dans un jeu de registres de configuration, pour chaque dispositif maître, un emplacement pour contenir une deuxième donnée de paramétrage des alertes, le circuit de protection de chaque ressource étant configuré pour générer ou non ledit signal d’alerte en cas de blocage d’une transaction adressée à la ressource par le dispositif maître, en fonction de la deuxième donnée de paramétrage des alertes pour ce dispositif maître.
Ainsi, la commande de l’action prise par les moyens de contre-mesure peut être activé ou désactivé en fonction de chaque dispositif maître. En effet, on peut considérer qu’un environnement de confiance, par exemple la mise en œuvre d’un micrologiciel (usuellement « firmware » en anglais) d’un dispositif maître « de confiance », ne peut pas générer d’accès illégal. Une détection d’un accès illégal en provenance d’un tel environnement pourra donc systématiquement être traité comme une attaque par le moyen de contre-mesure.
Selon un autre aspect, il est également proposé un procédé de gestion de l’isolation de ressources d’un système sur puce, dans lequel : - le système sur puce comprend au moins une ressource esclave, un système d’isolation des ressources, et un moyen de contre-mesure apte et destiné à limiter le fonctionnement du système contre de potentielles anomalies ; et - le procédé comprend, pour chaque ressource, une mise en œuvre d’une protection comprenant un blocage ou une transmission de transactions adressées à la ressource, en fonction de droits d’accès de la ressource et de la transaction, et une génération d’un signal d’alerte directement communiqué au moyen de contre-mesure en cas de blocage d’une transaction.
Selon un mode de mise en œuvre, le signal d’alerte est transmis sur un canal d’alerte dédié, connectant directement le circuit de protection avec le moyen de contre-mesure.
Selon un mode de mise en œuvre, le système sur puce comporte une pluralité de ladite au moins une ressource, et tous les canaux d’alerte connectés auxdits circuits de protection respectifs sont regroupés sur un seul canal d’alerte sortant et directement connecté au moyen de contre-mesure.
Selon un mode de mise en œuvre, une donnée de paramétrage des alertes, pour chaque ressource, est contenue dans un jeu de registres de configuration, et ledit signal d’alerte est généré ou non en cas de blocage d’une transaction adressée à une ressource, en fonction de la donnée de paramétrage des alertes pour cette ressource.
Selon un mode de mise en œuvre, dans lequel le système sur puce comporte en outre au moins un dispositif maître générant lesdites transactions adressées à la ressource comprenant une donnée d’identification du maître, une deuxième donnée de paramétrage des alertes, pour chaque dispositif maître, est contenue dans un jeu de registres de configuration, et ledit signal d’alerte est généré ou non en cas de blocage d’une transaction adressée à une ressource par le dispositif maître, en fonction de la deuxième donnée de paramétrage des alertes pour ce dispositif maître.
Dans cet exemple, le système sur puce SOC comporte en outre un dispositif maître TDMSTR qualifié « de confiance », typiquement en charge de la configuration et de la gestion de droits d’accès définissant les règles d’isolation, mises en place par un système d’isolation des ressources RIF décrit plus en détails ci-après.
Dans un cas particulier, le bus d’interconnexion BUS peut comporter un canal de notification d’erreur RREP, par exemple prévu pour communiquer une information de réponse à une transaction par les ressources esclaves.
Par ailleurs, le système sur puce SOC comporte un moyen de contre-mesure TAMP apte et destiné à limiter le fonctionnement du système sur puce SOC contre de potentielles anomalies.
- une interface de communication 625, de préférence de type sans fil, par exemple de type Bluetooth ou WiFi, l'interface étant notamment apte à transmettre des données, en particulier vers une entité électronique ;
- une interface d’entrée/sortie 630 connectée à un capteur de température 635 et, de façon optionnelle, à un module de localisation 640 (par exemple de type GPRS, UMTS ou GPS), un capteur d’immersion 645 (par exemple de type capacitif) et/ou un capteur d’assujettissement mécanique 650 (par exemple un capteur de contact de type piézoélectrique).
La carte électronique 600 peut également comprendre une mémoire de stockage (655), par exemple de type SSD (sigle de Solid State Device en terminologie anglo-saxonne), pouvant comporter les programmes précités et des données mesurées, traitées ou à traiter selon des modes de réalisation particuliers.
Le bus de communication 605 permet la communication et l'interopérabilité entre les différents éléments inclus dans la carte électronique 600 ou reliés à elle. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément de la carte électronique 600 directement ou par l'intermédiaire d'un autre élément de la carte électronique 600.
Le code exécutable de chaque programme permettant à l'appareil programmable de mettre en œuvre les processus selon l'invention peut être stocké, par exemple, dans la mémoire de stockage 655 ou en mémoire morte 615.
Selon une variante, le code exécutable des programmes pourra être reçu par l'intermédiaire d’un réseau de communication via l'interface 625, pour être stocké de façon identique à celle décrite précédemment.
De manière plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage de la carte électronique 600 avant d'être exécutés.
L'unité centrale 610 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans la mémoire de stockage 655 ou dans la mémoire morte 615 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple la mémoire de stockage 655 ou dans la mémoire morte 615, sont transférés dans la mémoire vive 620 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en œuvre de l'invention.
La illustre un exemple d’étapes mises en œuvre dans un dispositif autonome pour effectuer des mesures et transmettre des données.