INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Une telle configuration de la structure de support tridimensionnelle, et donc de l’orientation des différents revêtements photovoltaïques, permet de maximiser la surface insolée du module photovoltaïque tridimensionnel à chaque instant de la course de déplacement du Soleil, et donc de capter une quantité d’énergie importante provenant du Soleil, et ce sans requérir à un quelconque mécanisme de déplacement configuré pour modifier l’orientation du module photovoltaïque tridimensionnel en fonction de la position du Soleil.
En particulier, la disposition des éléments de support limite le phénomène d’ombres portées généré par chaque élément de support sur les autres éléments de support de la structure de support tridimensionnelle, et donc sur les revêtements photovoltaïques disposés sur les faces de support des autres éléments de support de la structure de support tridimensionnelle, tout en permettant une bonne pénétration lumineuse au sein du module photovoltaïque tridimensionnel.
De plus, compte tenu de la disposition des éléments de support, et donc des faces de support, tous les revêtements photovoltaïques sont au moins en partie simultanément insolés durant une partie importante de la course de déplacement du Soleil, ce qui assure une meilleure régularité de la production d’énergie au cours d’une journée (et notamment durant les phases ascendante et descendante du Soleil) et donc également au cours de l’année. La disposition des éléments de support permet également de produire de l’électricité plus tôt dans la journée et jusque plus tard dans la journée comparativement aux modules photovoltaïques tridimensionnels de l’art antérieur.
En outre, lorsqu’un revêtement photovoltaïque n’est pas directement insolé (du fait de l’ombre propre générée par l’élément de support respectif), il est néanmoins apte à capter au moins une partie de la lumière réfléchie par des revêtements photovoltaïques prévus sur d’autres éléments de support. En d’autres termes, le module photovoltaïque tridimensionnel selon la présente invention limite considérablement les risques d’obscurité générée par chaque élément de support sur les revêtements photovoltaïques disposés sur les faces de support des autres éléments de support. Enfin, même lorsqu’un revêtement photovoltaïque prévu sur un élément de support n’est ni directement, ni indirectement insolé, cela ne représente qu’une partie mimine des revêtements photovoltaïques appartenant au module photovoltaïque tridimensionnel qui n’est pas insolée.
Par conséquent, le module photovoltaïque tridimensionnel permet de produire, non seulement en instantanée, mais surtout annuellement, plus d’énergie par unité de surface qu’un panneau photovoltaïque classique et également qu’un module photovoltaïque tridimensionnel classique.
Le module photovoltaïque tridimensionnel peut en outre présenter une ou plusieurs des caractéristiques suivantes, prises seules ou en combinaison.
Selon un mode de réalisation de l’invention, le rapport de la surface développée des faces de support des éléments de support sur la surface au sol occupée par le module photovoltaïque tridimensionnel est supérieur à 3, et par exemple compris entre 4 et 6, et avantageusement entre 4,5 et 5,5. Ces dispositions assurent une production d’énergie, par unité de surface, relativement élevée comparativement à l’énergie produite, par unité de surface, par un module photovoltaïque tridimensionnel de l’art antérieur.
Selon un mode de réalisation de l’invention, l’axe central de la structure de support tridimensionnelle est configuré pour s’étendre sensiblement verticalement lorsque le module photovoltaïque tridimensionnel est disposé sur une surface horizontale.
Selon un mode de réalisation de l’invention, les revêtements photovoltaïques de ladite pluralité de revêtements photovoltaïques sont distincts les uns des autres et sont reliés en série et/ou en parallèle.
Selon un autre mode de réalisation de l’invention, au moins un revêtement photovoltaïque, et par exemple chacun des revêtements photovoltaïques, de ladite pluralité de revêtements photovoltaïques est flexible.
Selon un mode de réalisation de l’invention, chaque revêtement photovoltaïque comprend une pluralité de cellules photovoltaïques reliées en parallèle et/ou en série.
Selon un mode de réalisation de l’invention, les sommets des éléments de support sont répartis, et par exemple régulièrement répartis, autour de l’axe central de la structure de support tridimensionnelle.
Selon un mode de réalisation de l’invention, les sommets des éléments de support sont équidistants de l’axe central de la structure de support tridimensionnelle. En d’autres termes, les sommets des éléments de support sont disposés sur un cercle centré sur l’axe central de la structure de support tridimensionnelle.
En comparant l’incohérence associée à l’alerte émise avec un ensemble d’anomalies connues prédéterminées, le procédé comprend la catégorisation de l’alerte lorsque la ou chaque incohérence correspond à l’une des anomalies connues dudit ensemble d’anomalies.
Il est ainsi possible de connaitre la nature de l’anomalie rencontrée, notamment le type d’attaque informatique, et de réagir en fonction.
Toutefois, le procédé de détection 200 ne dépend pas du type d'attaque. Le procédé permet de détecter également des nouvelles classes d'attaques ciblant le matériel ou le logiciel.
Finalement, lors du vieillissement des composants, la fréquence des évènements transitoires augmente progressivement jusqu’à une défaillance permanente. Le procédé de détection, via cette analyse, permet d’observer cette variation de fréquence, pour participer à la maintenance préventive des composants et prévenir ce type de défaillances.
Orchestrateur de services d’un système d’orchestration d’un réseau de communication militaire ; Système d’orchestration et programme d’ordinateur associés La présente invention concerne les réseaux de radiocommunication militaires déployés sur le théâtre d’opération.
Dans le déploiement de centre de données de théâtre (« theatre cloud » en anglais) ou de réseaux de bordure (« Far Edge »), l’orchestration de services a besoin de déployer des configurations adaptées à la situation opérationnelle courante, tout en répondant aux usages des utilisateurs attendus.
Actuellement, la tâche de sélection d’un modèle de fichier de configuration (« template » ou « blue print » en anglais), puis celle de paramétrisation du modèle sélectionné pour obtenir le fichier de configuration, sont laissées à un opérateur de pilotage (« floor control ») de l’orchestration de services.
Une fois un fichier de configuration préparé, celui-ci est exécuté par un système d’orchestration du réseau de manière à réaliser le déploiement correspondant à ce fichier.
Pour permettre à l’opérateur de pilotage de sélectionner le modèle de fichier de configuration le plus adapté pour répondre à une situation opérationnelle particulière, un arbre de diagnostic est couramment utilisé. Cependant, les arbres de diagnostic proposés sont complexes : ils peuvent atteindre plus de 1000 ramifications.
De plus, malgré cette complexité, les modèles de fichier de configuration proposés ne couvrent que la composante réseau du déploiement, sans prendre en compte d’autres composantes cruciales pour un réseau de théâtre, comme les composantes de système d’information – IT et de sécurité. Ils ne prennent également pas en compte la situation opérationnelle effectivement rencontrée affectant les usages, les utilisateurs, et la priorisation des flux.
Par exemple, dans une situation opérationnelle où un lien sur le réseau est rompu, on comprend que la reconfiguration du réseau pour router les flux par d’autres chemins est nécessaire. Mais il faut aussi prendre en compte les besoins applicatifs des utilisateurs et si certaines applications génèrent un flux trop important, il est préférable de les supprimer ou de les déployer dans un autre centre de données du réseau. Il faut également prendre en compte les contraintes de sécurité. Par exemple, les réseaux militaires sont cloisonnés en différents niveaux de sécurité, comme les architectures Rouges/Noire des réseaux militaires. Certains chemins sont alors interdits à certains types de flux.
Pour cela l’invention a pour objet un orchestrateur de services d’un système d’orchestration d’un réseau de communication militaire, capable de générer des commandes vers une pluralité de contrôleurs, la pluralité de contrôleurs comportant au moins un contrôleur de réseau un contrôleur de système d’information et un contrôleur de sécurité, caractérisé en ce qu’il comporte un module d’intelligence artificielle – AI et un serveur d’interface de programmation d'application – API, le module d’AI comportant : une unité d’acquisition de données, adaptée pour acquérir une pluralité de variables d’entrées de description d’une situation opérationnelle ; une unité de réseau de neurones – NN, capable, à partir de la pluralité de variables d’entrées acquises par l’unité d’acquisition de données, de déterminer au moins un scénario, un scénario étant un modèle de fichier de configuration ; et une unité de moteur d’inférence, capable d’instancier des paramètres du scénario fourni par le module NN, pour déterminer un fichier de configuration prêt à être exécuté par le serveur d’API, le fichier de configuration comportant des commandes selon les composantes de réseau, de système d’information et de sécurité du réseau de communication.
Suivant des modes particuliers de réalisation, le système d’orchestration comporte une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les combinaisons techniquement possibles :
- la situation opérationnelle est décrite par des variables d’entrée quantitatives sur l’état courant de la composante réseau, sur l’état courant de la composante système d’information et sur l’état courant de la composante sécurité du réseau de communication.
- la situation opérationnelle est décrite par des variables d’entrée provenant d’un système de support opérationnel – OSS, d’un système de support fonctionnel – BSS, et/ou de dispositifs externes.
En variante, les mesures effectuées par les sondes réseau ou des résultats de calculs qui en découlent sont partagés avec l’orchestrateur 180, afin de permettre à l’orchestrateur 180, ou à tout autre dispositif ou système informatique centralisé, d’établir un modèle prédictif de congestion du ou des réseaux de communication 100a.
La illustre schématiquement un exemple d’architecture matérielle de sonde réseau, et permettant notamment d’implémenter l’architecture modulaire des Figs. 1B et 1C.
La sonde réseau comprend alors, reliés par un bus de communication 310 : un processeur ou CPU (pour « Central Processing Unit » en anglais) 301, ou une grappe de tels processeurs, comme par exemple des GPU (« Graphics Processing Units » en anglais) ; une mémoire vive RAM (pour « Random Access Memory » en anglais) 302 ; une mémoire morte ROM (pour « Read Only Memory » en anglais) 303, ou une mémoire réinscriptible de type EEPROM (« Electrically Erasable Programmable ROM » en anglais), par exemple de type Flash ; un dispositif de stockage de données, tel qu’un disque dur HDD (pour « Hard Disk Drive » en anglais) 304, ou un lecteur de support de stockage, tel qu’un lecteur de cartes SD (pour « Secure Digital » en anglais) ; un ensemble d’interfaces d’entrées et/ou sorties, telles que des interfaces de communication 305, permettant notamment à la sonde réseau de capter des paquets à destination du routeur auquel la sonde réseau est associée, ou en transit via le routeur auquel la sonde réseau est associée, d’injecter et de capter des paquets fanions comme décrit plus en détails ci-après, ainsi que de communiquer avec d’autres sondes réseau du système de communication ou avec l’orchestrateur 180.
Le processeur 301 est capable d’exécuter des instructions chargées dans la RAM 302 à partir de la ROM 303, d’une mémoire externe (non représentée), d’un support de stockage, tel qu’une carte SD ou le disque dur HDD, ou d’un réseau de communication. Lorsque la sonde réseau est mise sous tension, le processeur 301 est capable de lire de la RAM 302 des instructions et de les exécuter. Ces instructions forment un programme d’ordinateur causant l’implémentation, par le processeur 301, des étapes, comportements et algorithmes décrits ici.
Il en découle que l’architecture modulaire des Figs. 1B et 1C peut être implémentée sous forme logicielle par exécution d’un ensemble d’instructions par une machine programmable, ou être implémenté sous forme matérielle par une machine ou un composant dédié ou un ensemble de composants dédiés.
D’une manière générale, chaque sonde réseau comprend de la circuiterie électronique agencée et configurée pour implémenter les étapes, comportements et algorithmes décrits ici, et notamment l’architecture modulaire des Figs. 1B et 1C.
A noter que l’orchestrateur 180 peut aussi comprendre de manière analogue de la circuiterie électronique agencée et configurée pour implémenter les étapes et comportements décrits ici en relation avec ledit orchestrateur 180.
La illustre schématiquement un organigramme de mise en place de sonde réseau pour la surveillance d’un tunnel de communication en amont dudit tunnel de communication.
Dans une étape 401, la sonde réseau en question détecte un nouveau tunnel de communication dont un point de terminaison est le point de terminaison 120 auquel est associée ladite sonde réseau. La détection d’un nouveau tunnel de communication est préférentiellement réalisée par détection de la transmission d’un paquet d’encapsulation de tunnel, par exemple de type GRE, mGRE ou IPSec, correspondant à un tunnel de communication qui n’avait pas été précédemment détecté. Un nouveau tunnel de communication est ainsi détecté lorsque l’adresse source et l’adresse destination forment un couple de points de terminaison 120 encore inconnu de ladite sonde réseau (sachant que ladite sonde réseau est associée au point de terminaison 120 d’entrée dans le tunnel de communication, pour le sens de communication considéré).
Dans une étape 402, dans un mode de réalisation particulier, la sonde réseau déduit l’adresse d’une sonde réseau distante, avec laquelle ladite sonde réseau doit collaborer pour la surveillance du trafic du tunnel de communication en question. Pour ce faire, ladite sonde réseau récupère l’adresse du point de terminaison distant, c’est-à-dire celui qui est de l’autre côté du tunnel de communication qui a été nouvellement détecté à l’étape 401. L’adresse source correspond au point de terminaison 120 auquel est associée ladite sonde réseau, donc l’adresse du point de terminaison distant est l’adresse destination. A noter qu’aucune inspection profonde de paquet DPI (« Deep Packet Inspection » en anglais) n’est requise. Ladite sonde réseau déduit alors l’adresse de la sonde réseau distante, avec laquelle ladite sonde réseau doit collaborer pour surveiller le tunnel de communication en question, en appliquant la fonction de translation bijective, comme déjà expliqué ci-avant. Cette déduction d’adresse permet d’établir les communications inter-sondes et la configuration de l’injecteur 150 local.
Ainsi, la sonde réseau peut effectuer une instanciation automatique de communications inter-sonde entre ladite sonde réseau, qui supervise donc un premier point de terminaison 120 du tunnel de communication en question, et la sonde réseau distante, qui supervise le second point de terminaison 120 de ce tunnel de communication. L’instanciation automatique des communications inter-sondes est réalisable grâce à la prédéfinition des adresses des sondes réseau par rapport aux adresses de leurs points de terminaison respectifs. Préférentiellement, chaque sonde réseau ouvre un connecteur réseau (« socket » en anglais) avec l’adresse du point de terminaison 120 qui lui est associé, à laquelle la fonction de translation bijective est appliquée, et avec un port UDP dédié. Cela permet à chaque sonde réseau de recevoir des messages UDP qui sont adressés, par tout autre sonde réseau du système de communication, à destination de cette adresse et de ce port UDP dédié.
Comme déjà évoqué, d’autres approches de partage de plan d’adressage peuvent être implémentées.
Ainsi, lorsqu’un tunnel de communication est mis en place entre deux points de terminaison 120, chacune des sondes réseau surveillant une des extrémités dudit tunnel de communication détecte le transit d’un paquet dudit tunnel de communication.
Dans une étape 403, la sonde réseau instancie un injecteur de paquets de cadencement dans le tunnel de communication, c’est-à-dire un injecteur de paquets fanions. En appliquant le même algorithme, la sonde réseau distante instancie aussi un injecteur de paquets de cadencement dans le tunnel de communication, ce qui permet de créer une horloge de référence dans les deux sens de communication entre les sondes réseau via le tunnel de communication.
Dans une étape 404, la sonde réseau effectue des captures et des mesures de débit de données pour le tunnel de communication en question. Les mesures de débit de données sont réalisées par comptage de volume de données transmises entre des paquets fanions successifs, détectés dans le trafic sortant du tunnel de communication. Les mesures de débit de données peuvent être réalisées par type de service dans le tunnel de communication, par exemple en s’appuyant sur une information de type de service (e.g. champ DSCP) incluse dans les paquets d’encapsulation du tunnel de communication.
Selon un deuxième mode de réalisation, le procédé de détection est mis en œuvre par un logiciel d’un système d’exploitation 16 du système électronique 10 configuré pour interagir avec une mémoire protégée par une unité de protection mémoire.
Ce mode de réalisation est représenté schématiquement sur la avec la référence numérique 2.
Dans ce cas, le jeu de référence est stocké au niveau de la mémoire principale. Le logiciel bénéficiera des niveaux de privilège élevés du système d'exploitation pour configurer et lire les blocs matériels de comptage 22. La zone de stockage des jeux de références est protégée via l’unité de gestion mémoire (ou MMU de l’anglais « memory management unit »).
Selon un troisième mode de réalisation, le procédé de détection est mis en œuvre par une application propre à être mise en œuvre par le système électronique 10 par adjonction d’un pilote contrôlant les blocs matériels, comme représenté schématiquement sur la avec la référence numérique 3.
Ainsi, le procédé est mis en œuvre sous la forme d'une application tournant au même niveau que les applications à surveiller.
Ce mode de réalisation est le plus facile à implémenter.
En variante encore, le procédé de détection est mis en œuvre via une implémentation hybride, à la fois logicielle et matérielle, comme par exemple une réalisation au niveau logiciel qui stocke les jeux de référence dans une mémoire flash matérielle dédiée, pour protéger l’espace mémoire des jeux de références.
Dans l’état initial du procédé de détection 200, le système électronique 10 est en fonctionnement opérationnel.
Par exemple, le système électronique 10 est embarqué dans un aéronef en train de voler à destination un aéroport. Le système électronique 10 est alors par exemple un système avionique de communication, de pilotage, etc.
Le procédé de détection 200 comprend une première étape de mesure 210, lors du fonctionnement du système électronique 10, d’au moins un paramètre représentatif des interactions de l’application A avec l’un des blocs matériels d’exécution 20 pour obtenir des mesures dudit paramètre représentatif.
Les paramètres représentatifs sont tels que définis ci-dessus. Ils correspondent en particulier à ceux pour lesquels des mesures ont été effectuées lors du procédé de génération du jeu de référence associé.
Pour chaque mesure, le procédé de détection 200 comprend la comparaison 220 de la mesure avec l’ensemble de données de référence associé, ou jeu de référence, pour détecter d’éventuelles incohérences entre la mesure et l’ensemble de données de référence.
Une incohérence est un écart statistique de la mesure par rapport au jeu de référence. Par exemple, la mesure n’est pas comprise dans l’enveloppe formée par le jeu de référence.
Tout écart indique un comportement anormal de l’application qui pourrait être lié à une cyber-attaque.
Ainsi, le procédé de détection 200 comprend une étape d’émission 230 d’une alerte W selon un critère d’alerte portant sur la ou les incohérences détectées.
Chaque critère d’alerte dépend d’au moins une condition sur les paramètres représentatifs. Chaque critère d’alerte est par exemple une valeur seuil du paramètre mesuré.
Selon un mode de réalisation de l’invention, le module photovoltaïque tridimensionnel comprend une borne principale positive à laquelle sont reliées électriquement des bornes positives de tous les revêtements photovoltaïques, et une borne principale négative à laquelle sont reliées électriquement des bornes négatives de tous les revêtements photovoltaïques.
Selon un mode de réalisation de l’invention, le module photovoltaïque tridimensionnel présente une section transversale de forme polygonale, et par exemple hexagonale.
Selon un mode de réalisation de l’invention, le module photovoltaïque tridimensionnel présente une hauteur comprise entre 3 et 6 cm, et par exemple d’environ 4 cm. Une telle hauteur de module photovoltaïque tridimensionnel est notamment retenue lorsque le module photovoltaïque tridimensionnel est destiné à être installé sur des toits inclinés ou horizontaux. Le module photovoltaïque tridimensionnel pourrait cependant présenter une hauteur bien supérieure à 6 cm pour d’autres applications, par exemple lorsque le module photovoltaïque tridimensionnel est destiné à être installé selon une orientation sensiblement verticale.
La présente invention comporte en outre un dispositif photovoltaïque comportant une pluralité de modules photovoltaïques tridimensionnels selon la présente invention, lesdits modules photovoltaïques tridimensionnels étant disposés de manière adjacente. De façon avantageuse, le dispositif photovoltaïque s’étend selon un plan d’extension.
Selon un mode de réalisation de l’invention, pour chaque paire de modules photovoltaïques tridimensionnels adjacents du dispositif photovoltaïque, les embases des deux modules photovoltaïques tridimensionnels adjacents sont juxtaposées, c’est-à-dire sont au contact l’une de l’autre. De façon avantageuse, un côté d’une embase d’un module photovoltaïque tridimensionnel est configuré pour s’étendre le long et pour être en contact avec un côté d’une embase d’un module photovoltaïque tridimensionnel adjacent.
est une vue schématique éclatée d’un module photovoltaïque tridimensionnel selon la présente invention.
est une vue en perspective de dessus d’une structure de support tridimensionnelle appartenant au module photovoltaïque tridimensionnel de la .
est une vue de dessus de la structure de support tridimensionnelle de la équipée de revêtements photovoltaïques.
est une vue en perspective de côté de la structure de support tridimensionnelle de la .
Description détaillée Dans le présent document, on entend par « revêtement photovoltaïque » un élément photovoltaïque comprenant au moins une ou plusieurs cellule(s) photovoltaïque(s) supportée(s) ou non par une couche de substrat de base qui peut par exemple être flexible ou rigide.
Les figures 1 à 4 représentent un module photovoltaïque tridimensionnel 2 selon un mode de réalisation de l’invention. De façon avantageuse, le module photovoltaïque tridimensionnel 2 présente une section transversale de forme polygonale, et par exemple hexagonale.
Le module photovoltaïque tridimensionnel 2 comporte une structure de support tridimensionnelle 3 comportant un axe central A qui est configuré pour s’étendre verticalement lorsque le module photovoltaïque tridimensionnel 2 est disposé sur une surface horizontale.