INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
En considérant l’exemple d’une mission en cours subissant une diversion d’un aéronef, un opérateur de l’aéronef peut préférer visualiser la notification sur une page spécifique de l’espace de travail d’un système non-certifié, afin de pouvoir superposer la synthèse de la situation délivrée par l’espace de travail et les différentes suggestions calculées par le dispositif de gestion des évènements 140. Avantageusement, cela permet de fournir une visualisation comparative, par exemple sur une carte, un affichage des critères utilisés pour les calculs des suggestions, ainsi qu’un classement visuel par pertinence de suggestion ou encore l’affichage du détail de certaines suggestions spécifiques à la demande de l’opérateur. Ainsi, selon certains modes de réalisation, pour les notifications de type « complexe conseil », la dynamique d’affichage associée peut comprendre en outre une génération de rendu des notifications sur l’interface Homme-Machine d’un espace de travail connecté à un système non-certifié via le moyen par un bouton tactile sur lequel est inscrit « Afficher plus de détails » par exemple.
L’homme du métier comprendra que le dispositif de traitement de notification ou des sous-systèmes du dispositif selon les modes de réalisation de l’invention peuvent être mis en œuvre de diverses manières par matériel (« hardware »), logiciel, ou une combinaison de matériel et de logiciels, notamment sous la forme de code de programme pouvant être distribué sous la forme d'un produit de programme, sous diverses formes. En particulier, le code de programme peut être distribué à l'aide de supports lisibles par ordinateur, qui peuvent inclure des supports de stockage lisibles par ordinateur et des supports de communication. Les procédés décrits dans la présente description peuvent être notamment implémentés sous la forme d’instructions de programme d’ordinateur exécutables par un ou plusieurs processeurs dans un dispositif informatique d'ordinateur. Ces instructions de programme d’ordinateur peuvent également être stockées dans un support lisible par ordinateur.
Par ailleurs, l'invention n'est pas limitée aux modes de réalisation décrits ci-avant à titre d’exemple non limitatif. Elle englobe toutes les variantes de réalisation qui pourront être envisagées par l'homme du métier. En particulier, l’invention n’est pas limitée aux exemples de donnés dans la description à titre d’exemple non limitatif.
Procédé de détection de leurrage d’un système d’alerte de trafic et d’évitement de collision et système d’alerte de trafic et d’évitement de collision associé La présente invention concerne un procédé de détection de leurrage d’un système d’alerte de trafic et d’évitement de collision.
La est un schéma d’un dispositif de traitement des suggestions mettant en œuvre le procédé de traitement de données, selon des modes de réalisation de l’invention.
La est un organigramme représentant les étapes du procédé de traitement de données, selon des modes de réalisation de l’invention.
La est un organigramme représentant l’étape consistant à appliquer un traitement de notifications du procédé de traitement de données, selon des modes de réalisation de l’invention.
La représente plusieurs exemples de rendu de notifications, sous forme condensée, sur une interface Homme-Machine.
La représente un exemple de rendu de plusieurs notifications, sous forme étendue, sur une interface Homme-Machine.
La représente un exemple de rendu d’une notification de type complexe, sous forme étendue sur une interface Homme-Machine.
Une référence identique utilisée dans plusieurs figures désigne des éléments identiques ou analogues.
Description détaillée La est un schéma d’une architecture informatique du dispositif d’assistance au pilotage d’un aéronef 100 selon des modes de réalisation de l’invention.
Le dispositif d’assistance au pilotage d’un aéronef 100 comprend des sources de données de mission en cours ou futures 120, un dispositif de gestion des évènements 140, un dispositif de traitement des suggestions 160 et une interface Homme-Machine 180.
Tel qu’utilisées ici, les sources de données de mission en cours ou futures 120 font référence à l’ensemble des données pouvant être acquises par le dispositif d’assistance au pilotage de l’aéronef 100 à travers différentes systèmes de l’avionique certifiée ou l’avionique non-certifiée et/ou de différentes sources externes (tel que l’environnement et la météorologie) ou sources internes à l’aéronef. Ces données sont accessibles au dispositif de gestion des évènements 140.
Le dispositif de gestion des évènements 140 est configuré pour effectuer une analyse puis corréler de manière fiable l’intégralité du contenu des sources données de mission en cours ou futures 120 pertinentes concernant un aéronef. Le dispositif de gestion des évènements 140 est notamment configuré pour déterminer si une adaptation d’une situation courante doit être réalisée par l’équipage de l’aéronef. Le cas échéant, le dispositif de gestion des évènements 140 peut fournir à l’équipage de l’aéronef une ou plusieurs suggestions représentant les solutions qui apparaissent les plus pertinentes pour cette adaptation.
Comme illustré sur la , le dispositif de gestion des évènements 140 peut comprendre un module de compétences 142. Ce module comprend une ou plusieurs unités de calcul non représenté sur la figure. Ces unités de calculs peuvent être configurées pour calculer des évènements à partir des données ou paramètres de mission en cours ou futures, pour traiter des requêtes de résolution et/ou générer des propositions de résolution.
Le dispositif de gestion des évènements 140 peut comprendre en outre un module de traitement 144 configuré pour déterminer l’existence d’un impact sur la mission (ou sur un paramètre associé à une mission, appelé paramètre de mission) en cours de l’aéronef, soit à partir d’un évènement calculé, soit à partir d’une proposition de résolution.
Le dispositif de gestion des évènements 140 peut également comprendre un module de résolution 146 configuré pour émettre les requêtes de résolution à partir de l’existence d’un impact, pour évaluer et sélectionner des propositions de résolution selon des critères prédéfinis, et ainsi pour construire une suggestion, caractérisée comme une solution d’adaptation de la mission en cours de l’aéronef à partir d’au moins une proposition de résolution.
Dans un mode de réalisation, le dispositif de gestion des évènements 140 peut comprendre un module de gestion 148 configuré d’une part pour gérer des contentions et des priorités de flux, et d’autre part pour aiguiller les échanges entre les différents modules du dispositif
Telle qu’utilisée ici, une ‘suggestion’ désigne une ou plusieurs informations et/ou une proposition d’actions, relatives à un ou plusieurs paramètres de mission, prédéfinies par le dispositif de gestion des évènements 140. Une suggestion est destinée à être affichée sur l’interface Homme-Machine 180. Les informations d’une ‘suggestion’ peuvent comprendre en outre des données auxiliaires associées à une partie ou à l’ensemble des éléments liés à la construction de la suggestion (éléments de construction) Les données auxiliaires peuvent être par exemple des données de contexte liée à la construction de la suggestion (par exemple suggestion de déroutement vers un aéroport proche suite à un contexte de défaillance système de l’avionique). Les actions associées à une suggestion peuvent être exécutées par au moins un membre de l’équipage. Les suggestions calculées par le dispositif de gestion des évènements 140 peuvent être utilisées par les opérateurs de l’équipage comme support d’aide à la décision, par exemple dans le cadre de tâches de planification de vol et de mission, de gestion de la mission en cours et de systèmes constituant le cockpit, jusqu’à l’arrivée de l’aéronef à sa destination finale. Ainsi, une suggestion peut comprendre un ensemble de messages et/ou des données numériques spécifiques aptes à être utilisé(e)s par l’équipage comme aide à la prise de décision. Les suggestions déterminées par le dispositif de gestion des évènements 140 peuvent être de différentes natures, comme par exemple des suggestions correspondant à un rappel d’actions ou des informations stratégiques (par exemple suggestion d’optimisation ou encore une suggestion d’alternative suite à un évènement non prévu).
Il existe donc un besoin pour une antenne capable d’émettre des ondes radiofréquences de polarisation circulaire et présentant un encombrement réduit.
A cet effet, la description décrit une antenne radiofréquence comportant au moins un réseau antennaire fonctionnant à une fréquence de fonctionnement, chaque réseau antennaire comprenant un dipôle alimenté, le dipôle alimenté étant relié en un point d’accès à un transmetteur radiofréquence propre à générer ou recevoir une onde à la fréquence de fonctionnement. Chaque réseau antennaire comprend également au moins un dipôle couplé, chaque dipôle couplé étant relié en un point d’accès à une charge résistive et/ou capacitive et/ou inductive respective. Le dipôle alimenté et chaque dipôle couplé comportent deux brins, les brins s’étendant depuis le point d’accès, les points d’accès étant agencés pour former un polygone, le premier brin d’un dipôle s’étendant le long du deuxième brin d’un dipôle voisin sur ledit polygone à une distance inférieure ou égale au dixième de la longueur d’onde correspondant à la fréquence de fonctionnement, ladite longueur d’onde étant dite longueur de fonctionnement.
Selon des modes de réalisation particuliers, l’antenne présente une ou plusieurs des caractéristiques suivantes, prise(s) isolément ou selon toutes les combinaisons techniquement possibles :
- les deux brins présentent une longueur inférieure ou égale au quart de la longueur d’onde de fonctionnement.
- le premier brin d’un dipôle s’étend le long du deuxième brin d’un dipôle voisin sur ledit polygone à une distance inférieure ou égale au vingtième de la longueur d’onde de fonctionnement.
- une direction étant définie pour chaque brin, les directions des deux brins présentent entre elles un angle égal à 90° à 10% près, le dipôle alimenté et chaque dipôle couplé étant agencés pour que chaque direction d’un brin présente une intersection avec une direction d’un autre brin.
- le polygone est un polygone régulier.
- le nombre de dipôles couplés d’un réseau antennaire est compris entre 2 et 4.
- l’antenne radiofréquence comporte deux réseaux antennaires, le polygone formé par les points d’accès du deuxième réseau antennaire étant inclus dans l’espace interne délimité par le polygone formé par les points d’accès du premier réseau antennaire, chaque réseau antennaire fonctionnant à une fréquence de fonctionnement respective.
- l’antenne radiofréquence comporte un plan réflecteur situé à une distance inférieure ou égale au quart de la longueur d’onde de fonctionnement.
- les brins présentent des méandres ou des repliements.
- les charges des dipôles couplés sont choisies pour que :
- le rayonnement de l’antenne radiofréquence présente une polarisation circulaire droite avec un gain maximum dans la direction perpendiculaire à l’antenne radiofréquence,
- le rayonnement de l’antenne de l’antenne radiofréquence présente une polarisation circulaire droite uniforme pour une ouverture d’élévation entre 90° et -90° autour de la direction perpendiculaire à l’antenne radiofréquence, et
- le gain de la polarisation croisée est minimisé.
La description se rapporte également à un système, notamment système de positionnement par satellites, comportant au moins une antenne radiofréquence telle que précédemment décrite.
Selon un autre aspect, il est proposé un dispositif comportant une unité de traitement configurée pour la mise en œuvre de tout ou partie d’un procédé tel que défini dans les présentes.
Selon un autre aspect, il est proposé un équipement connecté relié à une interface d’utilisateur pour la mise en œuvre, lorsque l’équipement connecté est embarqué dans un véhicule, d’une ou plusieurs itérations des étapes : - émettre au moins une donnée relative à un mouvement de l’équipement connecté ; -recevoir de l’unité de traitement, un message de recommandation comportant au moins une consigne à adopter par le véhicule pour fluidifier une situation de trafic ; -transmettre le message de recommandation à l’interface d’utilisateur.
Selon une option, en fonction de la situation de trafic identifiée, une phase de calcul définissant au moins des consignes respectives à adopter par au moins une sous-partie des véhicules de la partie de véhicules est exécutée pour fluidifier la situation de trafic.
Avantageusement, la phase de calcul peut ainsi permettre de sélectionner, en fonction de la situation de trafic identifiée, une sous-partie des véhicules de la partie de véhicules pour laquelle des consignes respectives peuvent être définies. Par exemple, la sous-partie des véhicules peut être déterminée à partir d’informations liées à l’environnement routier ou, comme il est décrit par la suite, en fonction d’un comportement d’un utilisateur de l’équipement d’utilisateur.
Selon une option, l’au moins une donnée relative à un mouvement d’au moins un véhicule de la pluralité de véhicules comprend au moins une donnée parmi une première position du véhicule, une première direction du véhicule, une première vitesse du véhicule, une première accélération du véhicule, et une combinaison de ces données. Bien entendu, d’autres données relatives à un mouvement de l’équipement connecté sont possibles.
Ainsi, un suivi de l’ensemble des mouvements effectués par les véhicules peut être rendu possible, à partir de données obtenues des équipements connectés.
Selon une option, l’au moins une donnée relative à un mouvement d’au moins un véhicule de la pluralité de véhicules est au moins une donnée relative à un mouvement d’au moins un équipement connecté embarqué dans un véhicule de l’au moins une partie de véhicules.
Ainsi, un suivi de l’ensemble des mouvements effectués par les véhicules embarquant les équipements connectés peut être rendu possible, à partir de données aisément obtenables.
Selon une option, l’au moins une consigne comprend au moins une consigne parmi une trajectoire, une valeur d’une deuxième vitesse, une valeur d’une deuxième accélération, une consigne de freinage, une consigne d’accélération, une consigne de changement de voie, et une combinaison de ces consignes. Bien entendu, d’autres consignes sont possibles.
Aussi, chaque utilisateur de l’équipement d’utilisateur respectif peut être informé de consignes concrètes de conduite destinées à fluidifier la situation de trafic.
Selon une option, les données obtenues à l’étape /a/ comprennent en outre des données statistiques relatives à un environnement routier de la pluralité de véhicules.
Par « environnement routier », on peut entendre une zone de périmètre défini comportant au moins une route. Le périmètre défini peut par exemple être de l’ordre de la dizaine de mètres, de la centaine de mètres ou de plusieurs milliers de mètres en fonction d’un cas d’usage cible. L’environnement routier peut comporter tous les éléments situés dans la zone. Les éléments peuvent être en mouvement, par exemple des véhicules, des piétons, des animaux, ou non, par exemple des infrastructures le long des voies, du mobilier urbain.
La prise en compte de données statistiques relatives à l’environnement routier peut permettre de définir des consignes à l’étape /c/ qui soient à la fois adaptées à une situation actuelle au sein de l’environnement routier, tout en considérant des données plus générales qui peuvent permettre d’augmenter les données de la phase de calcul pour obtenir des consignes plus fines.
Selon une option, les données obtenues à l’étape /a/ comprennent en outre, pour chaque équipement connecté un niveau de priorité associé au véhicule embarquant l’équipement connecté.
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=mydotsclient"
Uri-Path: "mid=57956"
Uri-Path: "dadi=4572sd174sf1"
Content-Format: "application/cbor"
Lorsque le message de sollicitation comprend plusieurs identifiants DADI, ces derniers peuvent être séparés au moyen d’un séparateur comme par exemple « ; » entre les identifiants (par ex. dadi=DADI-111 ; DADI-112 ; DADI-113), ou l’argument est répété (par ex. Uri-Path: "dadi=DADI-111", Uri-Path:"dadi=DADI-112", Uri-Path:"dadi=DADI-113"). Cette dernière possibilité est moins intéressante car elle augmente la taille du message de sollicitation (et donc le risque de fragmentation du message).
Les différents entêtes du message de sollicitation représentés ci-dessus sont définis dans le document RFC9132 publié par l’IETF (« Internet Engineering Task Force » en anglais). Ainsi, l’un des entêtes « Uri-Path », comprend, dans le cadre de la mise en œuvre de la présente solution, la valeur « 4572sd174sf1 » de l’identifiant DADI DADI-111 associé au domaine client 11.
En variante, le ou les identifiant(s) DADI sont insérés dans le corps du message de sollicitation « Request Mitigation » (par ex., les messages PUT ou POST).
Selon une autre variante de réalisation, qui peut être utilisée de façon alternative à ce qui vient d’être décrit ou de façon complémentaire, afin de s’assurer que les différents serveurs de mitigation recevant le message de sollicitation « Request Mitigation » puisse avoir accès à une valeur du paramètre DOTS « dadi » (par exemple, la requête « Request Mitigation » a été acheminée vers un serveur DOTS qui n’est pas en mesure de la déchiffrer), le nœud client C1 peut insérer une option UDP ou TCP, selon le protocole de transport utilisé message de sollicitation pour envoyer le message de sollicitation « Request Mitigation ». Un exemple de format d’une telle option conforme au format documenté dans la publication RFC793 de l’IETF, est le suivant :
A réception du message de sollicitation « Request Mitigation », le serveur de mitigation S12 détermine, au cours d’une étape E3, s’il est capable de traiter ce message, c’est-à-dire dans l’implémentation particulière envisagée ici, s’il est habilité à le faire. Cette détermination peut être réalisée par des moyens connus de l’homme du métier et non décrits en détail ici.
Si le serveur S12 est capable (i.e. habilité ici) de traiter le message de sollicitation, alors il informe le nœud client C1 qu’il peut répondre favorablement au message de sollicitation reçu, dans une étape E4. L’attaque impactant les ressources du domaine client 11 est alors mitigée de manière classique (soit directement par le serveur S12 soit en s’interfaçant avec une entité externe telle qu’un « mitigator »).
Si au cours de l’étape E3, le serveur de mitigation S12 détermine qu’il n’est pas en mesure de traiter le message de sollicitation « Request Mitigation » car, dans l’implémentation particulière envisagée ici, il n’est pas habilité à gérer la ressource ciblée par l’attaque (identifiée par exemple par les champs « target-prefix », « target-uri », « target-fqdn », etc., du corps du message), alors, le serveur de mitigation S12 cherche à identifier un autre serveur de mitigation habilité à traiter le message de sollicitation. A cet effet, le serveur de mitigation S12 cherche à obtenir au moins un identifiant DADI associé au domaine client 11 auquel appartient le nœud client C1 émetteur du message de sollicitation au cours d’une étape E5.
A ce stade, deux situations se présentent : une première situation dans laquelle le message de sollicitation « Request Mitigation » ne comprend aucun identifiant DADI associé au domaine client 11, et une deuxième situation (cas envisagé en exemple ici) dans laquelle le message de sollicitation « Request Mitigation » comprend au moins un identifiant DADI associé au domaine client 11 (dans son corps de message, dans l’un de ses champs d’entête, ou dans une option transport telle qu’une option UDP comme décrit précédemment).
Dans la première situation, le serveur S12 détermine alors un nom de domaine associé au domaine client 11. A cet effet, il extrait par exemple, un nom de domaine associé au domaine client 11 compris, par exemple, dans le certificat utilisé pour créer l’association (D)TLS requise au préalable pour l’envoi du message de sollicitation « Request Mitigation ». Puis il interroge au moyen du nom de domaine ainsi obtenu, le premier registre d’identifiants DADI en lui envoyant lors d’une étape E6, une requête SVCB. Le premier registre d’identifiants DADI utilise alors ce nom de domaine pour obtenir au moins un identifiant DADI DADI-111, DADI-112 et/ou DADI-113, associé au domaine client 11. Une fois ces identifiants DADI DADI-111, DADI-112 et/ou DADI-113 obtenus, ils sont transmis au serveur de mitigation S12 par le premier registre d’identifiants DADI.
Une fois en possession du ou des identifiant(s) DADI DADI-111, DADI-112, DADI-113 associé(s) au domaine client 11, le serveur S12, émet, dans une étape E7, une nouvelle requête, désignée par exemple ici par « QUERY_DPS_REGISTRY », et spécialement conçue pour les besoins de la présente solution, à destination du registre DPS_Active_DADI afin d’identifier au moins un serveur de mitigation, habilité à traiter le message de sollicitation « Request Mitigation » associé au(x) identifiant(s) obtenu(s). Comme indiqué en référence à la table 2, un tel registre DPS_Active_DADI est alimenté par les fournisseurs de services DPS dont les services DPS mettent en œuvre la présente solution.
Dans l’exemple de la , les parties de fond 31 des premiers tronçons 25 sont dans la continuité l’une de l’autre et se rejoignent à la pointe de la pièce en V 29.
De même, les bords pliés 33 des deux premiers tronçons 25 sont dans la continuité les uns des autres.
La partie de fond 31 est allongée suivant la direction principale d. Le premier tronçon 25 comporte deux bords pliés 33, s’étendant eux aussi sensiblement parallèlement à la direction principale d, et placés de part et d’autre de la partie de fond 31. Les bords pliés 33 des premiers tronçons 25 délimitant l’intérieur de la pièce en V 29 sont raccordés l’un à l’autre par une portion de bord 35 arquée. Les bords pliés 33 délimitant l’extérieur de la pièce en V 29 sont raccordés l’un à l’autre par une autre portion de bord 37 arquée, formant la pointe du V.
Les premiers tronçons 25, en revanche, restent ouverts suivant la direction principale d, à l’opposé de la pointe du V.
Comme illustré sur la , le réservoir interne 3 comporte un tirant central 39 ayant des extrémités 41 opposées solidaires des deux fonds internes 7.
Le tirant central 39 s’étend typiquement le long de l’axe central interne CI du réservoir interne 3. Ces extrémités 41 font saillie hors du réservoir interne 3, à travers les fonds internes 7.
Le ou chaque premier tronçon 25 est rigidement fixé au tirant central 39.
Plus précisément, le ou chaque premier tronçon 25 est rigidement fixé à l’extrémité 41 du tirant central 39 faisant saillie à travers le fond interne 7, par l’intermédiaire de la partie de fond 31.
Dans l’exemple de la , un orifice est ménagé dans la zone de la pièce en V 29 où les parties de fond 31 des premières branches 25 se rejoignent, cet orifice étant engagé autour de l’extrémité 41 et rigidement fixé à celle-ci.
Comme visible sur les figures, le ou chaque second tronçon 27 présente une forme générale coudée, et plus précisément une forme générale en L.
Le second tronçon 27 est avantageusement une tôle emboutie.
Le second tronçon 27, perpendiculairement à une ligne centrale LC, présente des sections de forme générale en U. La ligne centrale LC est illustrée sur la , et présente une forme générale en L.
Typiquement, le ou chaque second tronçon 27 comprend une partie d’extrémité distale 43 d’orientation sensiblement parallèle à l’axe central interne CI.
La partie d’extrémité distale 43 comporte avantageusement une partie plate 45, tournée vers la partie tubulaire externe 13 et fixée à la partie tubulaire externe13.
Elle comporte également des bords dressés distaux 47, se dressant à partir de la partie plate 45 à l’opposé de la partie tubulaire externe 13.
La partie plate 45 est allongée suivant l’axe central interne CI. Les bords dressés distaux 47 sont également allongés suivant l’axe central interne CI et se dressent de part et d’autre de la partie plate 45.