INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
L’unité de surveillance MON1, MON2 permet également de vérifier que la consigne de position calculée par l’unité de commande COM1, COM2 de la voie en contrôle n’est pas erronée.
Si l’unité de surveillance MON2 est uniquement sur la deuxième voie en attente alors, elle compare la consigne de position calculée par l’unité de commande COM1 de la voie en contrôle.
Lors de la phase de génération 100 du jeu de référence J, il est possible de construire un jeu de référence exhaustif, au prix de nombreuses exécutions de l'application, avec un jeu d'événements différents. Au contraire, lors de la phase de détection 200, il n’est pas possible d'exécuter plusieurs fois l’application dans le but de détecter une attaque. La détection doit avoir lieu directement, lors de l'exécution.
Ainsi, seul un nombre limité de paramètres est mesuré à partir de blocs matériels de comptage 22 afin de minimiser le temps de détection.
Selon un mode de réalisation, les paramètres mesurés sont alternés rapidement afin de couvrir dans une courte période de temps l'ensemble des événements significatifs par échantillonnage.
En variante, les paramètres mesurés sont choisis au moyen d’une sélection hiérarchique des événements surveillés.
Lorsqu’au moins une alerte W associée à l’un des blocs matériels d’exécution 20 est émise, une nouvelle itération des étapes du procédé de détection 200 à partir de l’étape de mesure 210 est mise en œuvre.
L’ensemble des blocs matériels d’exécution 20 dont une mesure de paramètre représentatif est effectuée étant, à chaque itération, inclus dans l’ensemble des blocs matériels d’exécution 20 de la précédente itération, l’ensemble des blocs matériels d’exécution 20 étant notamment inclus dans l’ensemble des blocs matériels d’exécution 20 associés à la ou les alertes.
Ainsi, un petit nombre d'événements est choisi, correspondant au nombre de blocs matériels de comptage 22 disponibles et couvrant les différents blocs matériels d’exécution 20 du processeur 14, afin de constituer un premier niveau de surveillance.
En cas de dépassement d'un ou plusieurs de ces événements par rapport à des seuils issus du jeu de référence, une suspicion d'attaque est levée et les paramètres mesurés sont reconfigurés pour se focaliser sur le bloc matériel d’exécution 20 concerné afin de confirmer ou infirmer la suspicion.
Les étapes de mesure 210 sont ainsi répétées avantageusement sur plusieurs niveaux hiérarchiques. Cette méthode permet d'améliorer la fiabilité de la détection malgré le nombre limité de blocs matériels de comptage 22.
Le procédé de détection 200 comprend, lorsqu’une alerte W associée à l’un des blocs matériels d’exécution 20 est émise, une nouvelle itération des étapes du procédé de détection 200 à partir de l’étape de mesure 210, le critère d’alerte comprenant, à chaque itération, un nombre croissant de conditions.
Ainsi, il est possible d’affiner l’alerte et de caractériser plus précisément la suspicion d’attaque.
Par exemple, une première condition d’alerte est le dépassement d’un seuil d’accès mémoire d’un bloc matériel. A la prochaine itération, la condition d’alerte comprend en plus de ce seuil, le dépassement d’un seuil de calculs exécutés par ce bloc matériel.
Le procédé 200 comprend ensuite l’analyse 240 de la nature du bloc matériel d’exécution 20 associé à chaque incohérence, l’analyse de la fréquence temporelle des incohérences, et/ou l’analyse de l’écart de chaque mesure associée aux incohérences à l’ensemble de données de référence.
Le procédé de détection 200 comprend alors une étape de détection 250, en fonction de la ou chaque analyse d’une anomalie, en particulier une attaque informatique ou une défaillance matérielle de l’un des blocs matériels.
En effet, en fonction de la fréquence, du type et de la gravité des évènements anormaux, il est possible de distinguer une attaque informatique d’une défaillance matérielle. En particulier, les évènements transitoires liés à la sûreté de fonctionnement sont essentiellement ponctuels, et se traduisent au niveau des blocs matériels de comptage 22 par un pic.
Les évènements liés à la cyber-sécurité au contraire durent le temps de l'attaque, et les attaques ont généralement un effet plus durable sur les blocs matériels de comptage 22.
Selon un mode de réalisation de l’invention, les lignes de crête sont sécantes en un point d’intersection situé sensiblement sur l’axe central de la structure de support tridimensionnelle.
Selon un mode de réalisation de l’invention, chaque ligne de crête est rectiligne.
Selon un mode de réalisation de l’invention, les lignes de crête sont régulièrement réparties autour de l’axe central de la structure de support tridimensionnelle.
Selon un mode de réalisation de l’invention, chacune des lignes de crête est inclinée par rapport à l’axe central d’un angle d’inclinaison compris entre 10 et 40°, avantageusement entre 20 et 30°, et par exemple d’environ 26°.
Selon un mode de réalisation de l’invention, chacune des faces de support présente une forme globalement triangulaire.
Selon un mode de réalisation de l’invention, chaque face de support comporte un premier bord s’étendant le long de la ligne de crête respective, un deuxième bord s’étendant jusqu’au sommet de l’élément de support respectif et un troisième bord opposé au sommet de l’élément de support respectif. De façon avantageuse, le deuxième bord de chaque face de support présente une extrémité qui est opposée au sommet respectif et qui est plus proche de l’axe central que le sommet respectif.
Selon un mode de réalisation de l’invention, le deuxième bord de chaque face de support est incliné par rapport à l’axe central de la structure de support tridimensionnelle, de telle sorte que l’extrémité dudit deuxième bord, qui est opposée au sommet respectif, est plus proche de l’axe central que le sommet respectif.
Selon un mode de réalisation de l’invention, chaque face de support de chaque élément de support est inclinée, par rapport à un plan de référence respectif qui est parallèle à l’axe central et qui passe par le troisième bord de ladite face de support, d’un angle d’inclinaison compris entre 5 et 10°, et par exemple d’environ 7°.
Selon un mode de réalisation de l’invention, le premier bord de chaque face de support présente une longueur comprise entre 35 et 55 mm, et avantageusement entre 40 et 50 mm, et par exemple d’environ 44 mm.
Selon un mode de réalisation de l’invention, le deuxième bord de chaque face de support présente une longueur comprise entre 55 et 75 mm, et avantageusement entre 60 et 70 mm, et par exemple d’environ 65 mm.
Selon un mode de réalisation de l’invention, le troisième bord de chaque face de support présente une longueur comprise entre 25 et 45 mm, et avantageusement entre 30 et 40 mm, et par exemple d’environ 34 mm.
Selon un mode de réalisation de l’invention, le nombre d’éléments de support est compris entre 3 et 6.
Selon un mode de réalisation de l’invention, pour chaque paire d’éléments de support adjacents de la structure de support tridimensionnelle, les faces de support adjacentes des deux éléments de support adjacents sont situées en regard l’une de l’autre.
Selon un mode de réalisation de l’invention, pour chaque paire d’éléments de support adjacents de la structure de support tridimensionnelle, les faces de support adjacentes des deux éléments de support adjacents sont reliées l’une à l’autre le long d’une zone de liaison qui est inclinée par rapport à l’axe central de la structure de support tridimensionnelle et qui s’étend vers le bas en s’éloignant de l’axe central de la structure de support tridimensionnelle.
Selon un mode de réalisation de l’invention, toutes les faces de support des éléments de support présentent des orientations différentes.
Selon un mode de réalisation de l’invention, les deux faces de support de chaque élément de support sont symétriques par rapport à un plan de symétrie respectif passant par la ligne de crête respective.
- la latence moyenne de transit des paquets fanions de l’intervalle de numéros de séquence considéré ;
- la gigue minimum subie par les paquets fanions de l’intervalle de numéros de séquence considéré ;
- la gigue maximum subie par les paquets fanions de l’intervalle de numéros de séquence considéré ;
- la gigue moyenne subie par les paquets fanions de l’intervalle de numéros de séquence considéré ;
- la volumétrie de transit de données (quantité de paquets, d’octets…) dans le tunnel de communication sur l’intervalle de numéros de séquence considéré.
La sonde réseau P2 902 prépare alors une réponse MeasResp. La réponse MeasResp est de type MeasResp1, adapté pour fournir les informations demandées par la requête MeasReq de type MeasReq1.
La sonde réseau P2 902 ajoute dans la réponse MeasResp les informations récupérées suivantes, pour chaque type de service requis :
- l’intervalle de numéros de séquence réellement considéré ;
- la volumétrie actuelle (c’est-à-dire, au moment où la requête MeasReq est reçue) du dernier paquet fanion reçu et le numéro de séquence Seq dudit dernier paquet fanion reçu.
Alors, dans une étape 915, la sonde réseau P2 902 envoie la réponse MeasResp, de type MeasResp1, ainsi préparée. La réponse MeasResp est envoyée à la sonde réseau P1 901 en réponse à la requête MeasReq reçue à l’étape 911.
Dans une étape 916, la sonde réseau P1 901 reçoit la réponse MeasResp émise par la sonde P2 902.
Dans une étape 917, la sonde réseau P1 901 calcule une éventuelle perte de volume de données (de paquets, d’octets…) sur l’intervalle de numéros de séquence réellement considéré par la sonde réseau P2 902 pour effectuer ses calculs et construire la réponse MeasResp. La perte de volume de données correspond à la différence entre la volumétrie calculée par la sonde réseau P1 901 vis-à-vis de son propre historique d’échantillonnages, sur l’intervalle de numéros de séquence réellement considéré par la sonde réseau P2 902, et la volumétrie transmise par la sonde réseau P2 902 dans la réponse MeasResp.
Lorsque les numéros de séquence constituant les bornes de l’intervalle de numéros de séquence de l’historique retourné dans la réponse MeasResp sont les mêmes, une perte totale des paquets fanions entre deux mesures successives est survenue. Dans ce cas, les valeurs de latence et gigue transmises par la sonde réseau P2 902 ne sont pas prises en compte par la sonde réseau P1 901. La sonde réseau P1 901 calcule alors une valeur approximée de la perte de volume de données. En effet, lorsqu’un paquet fanion a été perdu, la volumétrie est cumulée en réception sur l’échantillon du dernier paquet fanion reçu (c’est-à-dire que, en considérant que le paquet fanion de numéro séquence S2 a été perdu, la volumétrie en réception associée au numéro séquence S1 = S2-1 cumule la volumétrie des paquets non-perdus en chemin qui ont été transmis entre le paquet fanion de numéro séquence S1 et le paquet fanion de numéro séquence S3=S2+1 au lieu de simplement la volumétrie des paquets non-perdus en chemin qui ont été transmis entre le paquet fanion de numéro séquence S1 et le paquet fanion de numéro séquence S2). Ainsi, en considérant deux réponses MeasResp successives, la sonde réseau P1 901 peut estimer la perte de volume de données en déterminant la différence d’informations de « volumétrie actuelle » telles qu’indiquées dans lesdites deux réponses MeasResp successives, et en la comparant avec la différence d’informations de « volumétrie actuelle » telles que mémorisées à l’envoi des requêtes MeasReq correspondantes.
Dans une étape 918, la sonde réseau P1 901 mémorise des informations permettant de savoir où en est la surveillance du tunnel de communication vis-à-vis des historiques d’échantillonnages, pour le ou les types de service (e.g., DSCP) considérés. Typiquement, la sonde réseau P1 901 mémorise le numéro de séquence Seq du dernier paquet fanion reçu et la volumétrie actuelle, tels qu’indiqués par la sonde réseau P2 902 dans la réponse MeasResp.
Dans une étape 919, grâce aux informations de latence et de gigue transmises par la sonde réseau P2 902 et au calcul d’éventuelle perte de volume de données à l’étape 917, la sonde réseau P1 901 évalue si une éventuelle situation de congestion est rencontrée par le tunnel de communication, que ce soit en termes de latence, de gigue, ou de pertes de paquet lors du transit dans le tunnel de communication. Grâce à cette évaluation de situation de congestion, la sonde réseau P1 901 peut instruire le routeur local pour modifier des profils de transmission de données dans le ou les réseaux de communication 100a de sorte à prendre en compte, préférentiellement améliorer (e.g., gestion d’admission de services), les situations de congestion qui seraient révélées. En variante, la sonde réseau P1 901 remonte à l’orchestrateur 180 des informations relatives aux calculs, de sorte à permettre à l’orchestrateur 180 d’ajuster la gestion d’admission de services.
Faire effectuer les calculs de latence, gigue et volumétrie en réception permet que le message MeasResp soit de petite taille comparativement à l’envoi des mesures brutes. Ainsi, le protocole inter-sondes a un coût réduit sur la consommation de bande passante.
Avantageusement, la pluralité de variables d’entrée comporte en outre des variables supplémentaires.
Ainsi, le module 182 reçoit des informations du BSS, c’est-à-dire les objectifs ou contraintes métiers, c’est-à-dire l’utilisation recherchée du réseau 100. Elles comprennent par exemple :
- indicateurs d’usage : nombre d’utilisateur du réseau 100 et leurs profils d’abonné (définissant notamment la priorité des communications entre utilisateurs) ;
- indicateurs de priorisation ou type de mission planifiée et importance ; et,
- liste des applications nécessaires à la mission (Service Reconnaissance imagerie, aide au tir, …)
En plus de ces informations, des variables d’ordre de service du réseau peuvent être fournies telles que par exemple un profil d’abonné de chaque utilisateur comportant par exemple : un niveau de priorité permettant de prioriser ses communications ; des droits d’accès permettant d’autoriser l’accès à certains contenus ; des privilèges permettant de définir les applications que cet utilisateur peut utiliser, etc.
Le module 182 reçoit également des informations de l’OSS, c’est-à-dire des variables d’ordre opérationnel sur le réseau 100, comme par exemple : les plages d’adressage IP d’un groupe d’utilisateurs, d’un point d’accès ; les adresses IP de chaque VM et port virtuel ; les capacités physiques de chaque serveurs, commutateur, routeur… ; les capacités maximum en termes de bande passante des liens, de taille CPU, mémoires RAM, capacité de stockage des équipements...
Enfin, le module 182 reçoit avantageusement des données de description externe de la situation opérationnelle, permettant de l’appréhender. Elles comprennent par exemple :
- des informations météorologiques ;
- un type d’attaque ;
- un type d’ennemis.
Par exemple, des capteurs connectés (référencés de manière générale par le chiffre 176 sur les figures) comportent tout ou parties des capteurs suivants : capteurs de gaz, capteurs d’incendies, capteurs de bruits, capteurs chimique, capteurs vidéo, capteurs de température, capteurs d’humidités, capteurs de détection d’intrusion mécanique (ouverture de portes, fenêtres…), centre d’information (suite à appels aux services de secours ou autres).
En fait, il s’agit ici de toutes les informations externes au réseau permettant d’intégrer la dimension opérationnelle, aux dimension réseaux, IT, et sécuritaire.
L’unité de réseau de neurone – NN 184 met en œuvre un algorithme du type réseau de neurones artificiels, de préférence un perceptron multicouche (« multilayer perceptron »), de préférence encore du type totalement connecté (« fully connnected »).
L’unité 184 est capable, à partir des données acquises par l’unité 182, de déterminer au moins un scénario.
Un scénario est un modèle (« template » en anglais) de fichier de configuration. Il comporte des commandes selon les trois composantes IT, réseau, et sécurité du réseau.
Puis, l’étape 708 est effectuée, où il est mis fin à l’algorithme.
En procédant ainsi un historique des échantillonnages réalisés par la sonde réseau est stocké en mémoire.
Les historiques des échantillonnages de part et d’autre du tunnel de communication permettent de détecter et d’évaluer les situations de congestion, que ce soit en termes de latence, de gigue (« jitter » en anglais) ou de pertes de paquet lors du transit dans le tunnel de communication. Le protocole inter-sondes permet aux sondes réseau supervisant un même tunnel de communication, ou l’orchestrateur 180, de collecter ces historiques des échantillonnages, ou des informations qui en sont dérivées par calculs, de part et d’autre du tunnel de communication, afin d’évaluer d’éventuelles situations de congestion.
Dans un mode de réalisation particulier, une des sondes réseau (typiquement la sonde réseau en amont du tunnel de communication, dans un sens de communication considéré) demande à l’autre sonde réseau de l’autre côté du tunnel de communication de lui transmettre en réponse des données d’historique d’échantillonnages ou des informations qui en sont dérivées par calculs. Une requête MeasReq est transmise pour ce faire dans le cadre du protocole inter-sondes. Préférentiellement, la requête comporte un champ indiquant un intervalle de numéros de séquence de paquets fanions pour lequel l’historique, ou lesdites informations qui en sont dérivées par calculs, doit être fourni en réponse. Préférentiellement, la requête MeasReq comporte elle-même un numéro de séquence qui lui est propre, qui est repris dans une réponse MeasResp fournissant l’historique d’échantillonnages demandé, afin de faciliter l’association requête - réponse.
Lorsqu’une sonde réseau reçoit de son homologue de l’autre côté du tunnel une requête MeasReq, ladite sonde réseau détermine quel intervalle d’historique d’échantillonnages est concerné par la demande. La sonde réseau retrouve alors en mémoire l’historique d’échantillonnages demandé. Si à cause de pertes de paquets (e.g., perte du paquet fanion 2 dans la ), l’historique d’échantillonnages disponible en mémoire de ladite sonde ne correspond pas à l’historique d’échantillonnages demandé, alors la sonde réseau retrouve en mémoire l’historique d’échantillonnages le plus proche de l’historique d’échantillonnages demandé et le transmet, ou des informations qui en sont dérivées par calculs, dans la réponse MeasResp. La réponse MeasResp inclut une information indiquant quel intervalle d’historique d’échantillonnages est réellement retourné, ou respectivement quel intervalle d’historique d’échantillonnages a été réellement utilisé pour dériver les informations retournées.
Par exemple, en s’appuyant sur la , une requête MeasReq demande l’historique d’échantillonnages concernant l’intervalle de numéros de séquence de paquets fanions allant de 2 à 6. Etant donné que le paquet fanion 2 a été perdu en route, la réponse MeasResp inclut l’historique d’échantillonnages concernant l’intervalle de numéros de séquence de paquets fanions allant de 1 à 6. En variante, la réponse MeasResp inclut l’historique d’échantillonnages concernant l’intervalle de numéros de séquence de paquets fanions allant de 3 à 6.
La illustre schématiquement un organigramme de collaboration de sondes réseau P1 901 et P2 902 pour évaluer une situation de congestion dans un tunnel de communication, dans un premier mode de réalisation.
Dans une étape 910, la sonde réseau P1 901, en amont du tunnel de communication, envoie une requête MeasReq à la sonde P2 902, en aval du tunnel de communication. La requête MeasReq est de type MeasReq1, et comporte préférentiellement une indication d’au moins un type de service (e.g., DSCP), ainsi qu’un champ indiquant un intervalle de numéros de séquence de paquets fanions, pour lesquels des résultats de calculs de latence, gigue et volumétrie doivent être fournis en réponse. Les calculs sont réalisés par la sonde P2 902 au vu de l’historique d’échantillonnages stocké par la sonde P2 902 vis-à-vis dudit ou desdits types de service précisés dans la requête MeasReq dans le tunnel de communication considéré. Si ce n’est implicite dans le protocole inter-sondes, la requête MeasReq indique quel tunnel de communication est concerné, et quel sens de communication est aussi concerné (par exemple, en indiquant une adresse de point de terminaison 120 source et de point de terminaison 120 destination).
Dans un mode de réalisation particulier, l’intervalle de numéros de séquence est notifié dans la requête MeasReq uniquement par un numéro de séquence de borne inférieure de l’intervalle en question, étant implicitement entendu que la borne supérieure de l’intervalle en question se termine au dernier paquet fanion reçu par la sonde P2 902.
Préférentiellement, la sonde réseau P1 901 mémorise le numéro de séquence Seq du dernier paquet fanion localement capturé et la volumétrie actuelle telle que vue par la sonde réseau P1 901 au moment de l’envoi de la requête MeasReq. Cela permet par la suite, à la sonde réseau P1 901, d’estimer la perte de volume de données dans le cas où tous les paquets fanions seraient perdus sur l’intervalle de numéros de séquence de paquets fanions sur lequel s’applique la requête MeasReq.
Dans une étape 911, la sonde réseau P2 902 reçoit la requête MeasReq émise par la sonde P1 901.
Dans une étape 912, la sonde réseau P2 902 recherche l’intervalle de numéros de séquence sur lequel porte la requête MeasReq, d’après les indications contenues dans ladite requête MeasReq. Si à cause de pertes de paquets, l’historique d’échantillonnages disponible en mémoire de la sonde réseau P2 902 ne correspond pas à l’historique d’échantillonnages demandé par la sonde réseau P1 901, alors la sonde réseau P2 902 retrouve en mémoire l’historique d’échantillonnages le plus proche de l’historique d’échantillonnages demandé par la sonde réseau P1 901.
Dans une étape 913, la sonde réseau P2 902 sélectionne la ou les tables de mesures appropriées d’après le ou les types de service (e.g., DSCP) concernés, et récupère (« retrieve » en anglais) les échantillons (mesures) qui correspondent à l’intervalle de numéros de séquence recherché et qui sont contenus dans cette ou ces tables de mesures. Cette récupération d’échantillons délimite une zone de calculs parmi l’historique d’échantillonnages stocké par la sonde réseau P2 902.
Dans une étape 914, la sonde réseau P2 902 effectue des calculs de latence, gigue et volumétrie, pour chaque type de service requis. En se référant à la , la sonde réseau P2 902 utilise la différence entre la colonne 804 et la colonne 803. Préférentiellement, la sonde réseau P2 902 calcule :
- la latence minimum de transit des paquets fanions de l’intervalle de numéros de séquence considéré ;
- la latence maximum de transit des paquets fanions de l’intervalle de numéros de séquence considéré ;
A cet effet, la présente invention concerne un module photovoltaïque tridimensionnel comportant :
- une structure de support tridimensionnelle comportant un axe central et une pluralité d’éléments de support répartis autour de l’axe central de la structure de support tridimensionnelle, chaque élément de support comportant un sommet et deux faces de support qui sont sensiblement planes et qui sont reliées l’une à l’autre le long d’une ligne de crête, la ligne de crête de chacun des éléments de support étant inclinée par rapport à l’axe central de la structure de support tridimensionnelle et s’étendant jusqu’au sommet de l’élément de support respectif en s’éloignant de l’axe central de la structure de support tridimensionnelle,
- une pluralité de revêtements photovoltaïques fixés à la structure de support tridimensionnelle, chaque revêtement photovoltaïque étant disposé sur une face de support respective et s’étendant sensiblement parallèlement à la face de support respective, chaque revêtement photovoltaïque comprenant au moins une cellule photovoltaïque et recouvrant au moins en partie la face de support respective.