INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
L’opération 110 est identique à l’opération 108 sauf que les bits de l’identifiant Id u sont remplacés par une valeur constante prédéterminée et identique pour tous les processus exécutés par le calculateur 2. Par exemple, les bits de l’identifiant Id u sont tous mis à zéro. Dans ce cas, les valeurs intermédiaires générées I’w 1,r , I’w 2,r , I’w 3,r et I’w 4,r ne varient pas en fonction de l’identifiant Id u . Dès lors, si deux processus exécutés ont le même espace d’adressage, alors que la requête contenant l’adresse @r soit émise par l’un ou par l’autre de ces processus, les valeurs intermédiaires I’w 1,r , I’w 2,r , I’w 3,r et I’w 4,r sont identiques. Dès lors, comme cela sera compris à la lecture de la suite de cette description, l’ensemble S i,r est le même pour ces deux processus puisque les tables T j sont les mêmes pour tous les processus. Cela permet donc à ces deux processus de partager un mot enregistré dans la mémoire cache 6.
A l’issue de l’opération 108 ou à l’issue de l’opération 110, lors d’une opération 112, le circuit 44 convertit les valeurs intermédiaires I’w 1,r , I’w 2,r , I’w 3,r et I’w 4,r générées par le circuit 42 en valeurs finales Iw 1,r , Iw 2,r , Iw 3,r et Iw 4,r en utilisant pour cela les tables T 1 à T 4 .
Le fonctionnement du circuit 44 est expliqué dans le cas particulier de la conversion d’une valeur intermédiaire I’w j,r en valeur finale Iw j,r à l’aide de la table T j . Ce qui est décrit dans ce cas particulier est appliqué pour chacune des valeurs de l’indice « j » comprise entre 1 et 4.
Un contrôleur (10) de type STM32H730VBTx (nom commercial) possédant 9 liaisons séries (8 pour les sections et 1 pour la communication RS485 avec le serveur) peut contrôler 8 bandes de sections possédant chacune d’entre elle une liaison série.
Le protocole de communication de gestion des appuis permet de transmettre les évènements qui surviennent sur les touches des sections (sur laquelle l’état d’une touche a changé) jusqu’au contrôleur principal LC8.
Décomposition d’une trame : Lors d’un appui, ou d’un relâchement d’une touche, la section envoie une trame au contrôleur principal.
On retrouve deux informations dans cette trame : Type d’évènement : appui ou relâchement de la touche (champ Bit de front) Identification de la touche mise à jour : N° de la section (champ Compteur station) + N° du bouton mis à jour sur la section (champ N° bouton)
Une trame est composée de deux octets (16 bits de données utiles au total).
Un bit identifiant permet de repérer s’il s’agit du premier octet de la trame (valeur «0 ») ou du second octet (valeur « 1 »). Le premier octet contient une valeur codée sur 6 bits correspondant au compteur station (désignant le numéro de l’alignement de capteurs dans un ensemble de dispositifs chaînés) ; le deuxième octet contient le numéro du capteur dans son alignement, codé sur 4 bits plus un bit « drapeau ».
Gestion des marqueurs de temps : Pour pouvoir traiter ces données relatives à l’appui, il faut ajouter une information de temps et ainsi replacer les événements dans la temporalité. Cette gestion du temps se fait sur le contrôleur principal, c’est-à-dire que c’est à la réception d’une trame que l’on viendra ajouter un marqueur de temps. Le contrôleur principal prend en compte le temps de trajet de la trame provenant des différents dispositifs.
Le contrôleur principal du serveur procède aux traitements suivants :
a) Réception de la trames, déclenché par la détection d’un signal, et vérification des paquets reçus. Cette vérification concerne l’alternation 0-1 dans le premier bit de chaque octet. Si le contrôleur repère que l’enchainement n’est pas respecté, cela veut dire qu’il manque un paquet et donc que la trame est erronée. Dans ce cas-là le contrôleur supprime le paquet de la trame erronée.
b) Création et horodatage des évènements, par décodage des trames reçues et utilisation d’un code applicatif. Cette couche de traitement va venir lire le buffer de réception et récupérer les informations qui sont dans les trames (n° bouton et type d’évènement). Pour ce qui est du numéro du bouton, on va fusionner le champ compteur station et le champ n° du bouton de manière à obtenir un identifiant unique du bouton sur tout le système. Voici le calcul du numéro du bouton :
N° bouton = n° du ruban * 1000 + n° section * 9 + n° bouton sur la section
Avec le N° du ruban : 0 à 7 Une fois ces informations récupérées, il suffit de leur associer un marqueur de temps (timestamp) pour obtenir un évènement complet. Ce marqueur de temps est défini par le nombre de ms qui se sont écoulées depuis le dernier reset du système. C’est une valeur codée sur 32bits qui peut être récupérée par la fonction.
c) Traitement des types d’appui, par l’exploitation du drapeau indiquant une étape d’acquisition, et un traitement par un code applicatif pour caractériser l’interaction de l’opérateur humain
d) déclenchement des actions associées à l’interaction humaine.
Application à la signalétique Pour les applications de signalétique, l’invention consiste à implanter sur un circuit imprimé formant une bande allongée un alignement de diodes électro-luminescentes (21 à 24) pilotables individuellement associées,
a) soit sur le même circuit imprimé souple,
Par exemple, il peut y avoir autant, plus ou moins de portions d’organe d’étanchéité secondaire que de secteurs de joint d’étanchéité.
En outre, la illustre les premières ouvertures 502 et deuxièmes ouvertures 503 des canaux, visibles ici respectivement sur la face amont des secteurs d’anneaux interne 13, et sur la surface interne S int des secteurs d’anneaux interne.
Dans le mode de réalisation représenté, la portion de turbomachine présente trois joints d’étanchéité : un joint d’étanchéité intérieur amont 62 (« FIS »), un joint d’étanchéité extérieur amont 63 (« FOS ») et un premier joint d’étanchéité en aval du compresseur à haute pression 61 (« CDP »).
De tels joints sont maintenant décrits en lien avec la qui n’est qu’un exemple de configuration pour un chemin de refroidissement de l’air dans une turbomachine, et l’homme du métier parviendra à identifier un joint d’étanchéité extérieur amont 63 (« FOS ») un joint d’étanchéité interne amont 62 (« FOS ») et un premier joint d’étanchéité en aval d’un compresseur à haute pression 61 (« CDP ») dans d’autres géométries du circuit de refroidissement.
Dans le mode de réalisation représenté, de l’air est prélevé en aval du dernier disque de compresseur 401 ainsi qu’en dessous de la chambre de combustion 5.
Le joint d’étanchéité 61 définit la quantité d’air pour le circuit de refroidissement 401 prélevé en aval du dernier disque du compresseur haute pression 4.
L’air prélevé en dessous de la chambre de combustion peut par exemple être prélevé par une embouchure d’air, débouchant dans un logement compris entre le joint d’étanchéité extérieur amont 63 et le joint d’étanchéité interne amont 62.
Sur la , ces deux joints d’étanchéité délimitent respectivement l’entrée et la sortie d’un tel logement.
Le joint d’étanchéité 62 est traversé par l’air provenant du compresseur haute pression 401 souhaitant entrer dans ce logement, et qu’il serve ensuite au circuit de refroidissement 82 ou qu’il soit destiné au circuit de purge 81.
Le joint d’étanchéité 63 lui délimite la sortie du logement d’admission d’air, et limite le flux d’air rejoignant le circuit de purge 81.
Par exemple, le joint d’étanchéité 62 peut être localisé radialement sous l’embouchure d’admission d’air, tandis que le joint d’étanchéité 63 peut être localisé sous le premier distributeur de la turbine haute pression 701.
Dans le mode de réalisation représenté, on notera que la surface en regard des joints d’étanchéité 62 et 63 est une surface externe d’un étage du rotor de la turbine haute pression.
Avantageusement, chaque bras 28 de l’élément de support 14 coulisse dans la première portion 46 du dispositif de guidage 34 correspondant, pour guider le déplacement de l’élément de support 14 entre la première position extrême et la position centrale.
Par exemple, lorsque le deuxième bord 26 de l’élément de support 14 est poussé vers sa deuxième position comme expliqué ci-dessus, chaque bras 28 coulisse dans la première portion 46 du dispositif de guidage 34 correspondant, plus particulièrement en s’éloignant de la portion de jonction 50, de sorte à tourner l’élément de support 14 selon le premier axe de rotation vers sa première position extrême ( ).
Comme illustré sur la , la première portion 46 du deuxième dispositif de guidage 34-2 est par exemple ouverte, de sorte que le deuxième bras 28-2 coulisse hors de ladite première portion 46.
De même, lorsque le deuxième bord 26 de l’élément de support 14 est tiré vers sa première position comme expliqué ci-dessus, chaque bras 28 coulisse dans la première portion 46 du dispositif de guidage 34 correspondant, plus particulièrement vers la portion de jonction 50, de sorte à tourner l’élément de support 14 selon le premier axe de rotation vers sa position centrale ( ).
De même, chaque bras 28 de l’élément de support 14 coulisse avantageusement dans la deuxième portion 48 du dispositif de guidage 34 correspondant, pour guider le déplacement de l’élément de support 14 entre la deuxième position extrême et la position centrale.
Avantageusement, le dispositif d’actionnement 16 comprend une unité de contrôle 52 agencée pour contrôler la mobilité de l’élément de support 14.
En particulier, l’unité de contrôle 52 est agencée pour contrôler la rotation de la bielle rotatif 32, et notamment pour contrôler l’actionneur rotatif électrique 36.
De préférence, l’unité de contrôle 52 comprend une interface de commande, par exemple comprenant des boutons et /ou une interface directement affichée sur l’élément fonctionnel 18, par laquelle l’utilisateur peut commander la mobilité de l’élément de support 14.
Par ailleurs, le dispositif d’actionnement 16 est peu complexe et économique. En particulier, un tel dispositif d’actionnement 16 comprenant une bielle rotative 32 permet une mobilité de l’élément de support 14, sans utilisation de systèmes complexes nécessitant un asservissement complexe.
On suppose dans cet exemple que l’utilisateur UR1 utilise son terminal client T1 pour accéder au site web ST1 géré par le système CMS PT1. L’accès de l’utilisateur UR1 au site ST1 se fait via le client de navigation 12. Le client de navigation 12 gère les interactions entre l’utilisateur UR1 et le site web ST1. Il permet par exemple d’afficher une ou des pages web 32 du site web ST1 sur un écran d’affichage (non représenté) du terminal client T1.
L’accès au site ST1 peut se faire de diverses manières. L’utilisateur UR1 peut par exemple entrer dans son client de navigation une adresse URL (ou un nom de domaine) du site web ST1. Selon un exemple, l’utilisateur UR1 active un hyperlien (ou lien web) pointant vers le site web ST1 (par exemple en cliquant sur ce lien). Cet hyperlien définit une adresse web (par exemple URL) du site web ST1. Ainsi, le navigateur web 12 utilise l’adresse définie par l’hyperlien pour demander au système PT1 l’accès au site web ST1.
Selon un exemple, l’utilisateur UR1 accède au site web ST1 par l’intermédiaire d’un site intermédiaire ST2 (par exemple un réseau social ou autre), différent de ST1, sur lequel est fourni un hyperlien, par exemple un lien enrichi en données. En activant cet hyperlien, l’utilisateur est redirigé grâce à son client de navigation 12 vers le site web ST1.
Au cours d’une étape S2 de réception ( ), le système PT1 reçoit, depuis le terminal client T1, des données d’utilisateur DT3 représentatives de l’utilisateur UR1 accédant au site web ST1 via son client de navigation 12. Les données d’utilisateur DT3 permettent au système PT1 de reconnaître (ou d’identifier) l’utilisateur UR1. Comme décrit par la suite, cette reconnaissance ne nécessite pas d’obtenir des données personnelles (nom, prénom, date de naissance, etc.) de l’utilisateur. Pour ce faire, on suppose dans cet exemple que le module de contrôle PG2 a au préalable collecté les données d’utilisateur DT3 au sein du client de navigation 12 et ces données sont ensuite transmises au système PT1.
Comme déjà indiqué, un problème réside en ce qu’il peut être difficile de reconnaître ou identifier l’utilisateur UR1, en particulier si celui-ci utilise un terminal client T1 inconnu ou inhabituel, ou encore si son client de navigation implémente un mécanisme de sécurité (par exemple un bloqueur de publicité, navigateur web limitant les cookies tiers, etc.) limitant l’accès à des informations relatives à l’utilisateur. La collecte des données d’utilisateur DT3 et leur traitement ultérieur permet de reconnaître avec précision l’utilisateur UR1, quelles que soient les ressources qu’il utilise pour accéder au site web ST1.
Dans les exemples considérés, c’est le module de contrôle PG2, exécuté par ou chargé dans le client de navigation 12, qui collecte et envoie les données d’utilisateur DT3 au système PT1 via le réseau NT1. Ce module de contrôle PG2 est fourni par le système PT1 ou par le module PG3, par exemple sur détection d’une demande d’accès du client de navigation 12 au site web ST1.
Selon un exemple particulier, préalablement à l’étape S2 de réception, le système PT1 reçoit une demande d’accès du client de navigation 12 pour accéder au site web ST1. En réponse à cette demande d’accès, le système PT1 ou le module de contrôle PG3 déclenche l’envoi du module de contrôle PG2 (ou de données permettant l’installation du module de contrôle PG2) au terminal client T1, causant ainsi l’exécution de ce module PG2 par le client de navigation 12. Le terminal client T1 reçoit ainsi le module de contrôle PG2 puis l’exécute au sein du client de navigation 12, ce module de contrôle PG2 se chargeant ensuite d’envoyer les données d’utilisateur DT3 (et le cas échéant ID3) au système PT1 pour permettre la reconnaissance (ou identification) de l’utilisateur UR1.
Les données d’utilisateur DT3 reçues (S2) par le système PT1 peuvent être ou comprendre de quelconques données auxquelles le client de navigation 12 donne accès. Ces données d’utilisateur DT3 peuvent comprendre par exemple un identifiant ID3 de cookie (par exemple un cookie provenant de Google Analytics®) comme illustré en et/ou des données de calque (ou « data layers » en anglais) implantées par d’autres applications (du type PG1 par exemple).
Les données d’utilisateur DT3 comprennent par exemple des données de système DT3a, ou des données de navigateur DT3b, ou les deux ( ). On suppose à titre illustratif dans ce qui suit que les données d’utilisateur DT3 comprennent des données de système DT3a et des données de navigateur DT3b, bien que des variantes soient possibles.
Les données de système DT3a sont représentatives de propriétés (ou caractéristiques techniques) système du terminal client T1. Ces données de système DT3a caractérisent par exemple le terminal client T1, notamment des ressources logicielles et/ou matérielles implémentés dans le terminal T1. Les données de système DT3a caractérisent par exemple au moins l’un parmi : le terminal client T1 (par exemple le type du terminal, la version du terminal, la marque, les extensions du terminal, son type de stockage, etc.), le processeur 10 du terminal (le type et/ou la version du processeur par exemple), le système d’exploitation implémenté par le processeur 10 (par exemple le type et/ou la version du système d’exploitation), l’écran d’affichage du terminal T1 (résolution et/ou taille de l’écran par exemple), son adresse IP, voire son adresse MAC, etc.
Selon un exemple particulier, le client de navigation 12 est configuré pour collecter des données de système DT3a auprès du terminal T1, par exemple lors d’une phase d’installation du client de navigation 12 dans le terminal T1.
Les données de navigateur DT3b sont représentatives de propriétés (ou caractéristiques techniques) du client de navigation 12. Ces données DT3b caractérisent par exemple un type du client de navigation 12, une version du client de navigation 12 (par exemple type/version d’un navigateur web), et/ou au moins une extension (ou plugin) du client de navigation 12. A titre purement illustratif, le type du navigateur web peut être "Win32" et sa version (identifiant de version « buildID ») "20181001000000". Le nombre et le type des données de navigateur DT3b peuvent varier au cas par cas.
Selon un exemple particulier, le client de navigation 12 est configuré pour obtenir des données de navigateur DT3b. Pour ce faire, le client de navigation 12 peut demander au terminal T1 de telles données de navigateur DT3b (le système du terminal T1 peut être configuré pour fournir ou non les données DT3b demandées).
Le recours à la fois aux données de système DT3a et données de navigateur DT3b permet de renforcer les capacités du système PT1 à reconnaître de façon unique l’utilisateur UR1 accédant au site web ST1. Le croisement de ces données permet de reconnaître l’utilisateur UR1 de façon fiable même si celui-ci modifie par exemple son client de navigation ou si le système d’exploitation du terminal T1 est mis à jour entre deux visites du site web ST1.
Selon un exemple particulier, les données d’utilisateur DT3 comprennent au moins un identifiant ID3 (dit aussi identifiant applicatif) d’une application ou d’un service exécuté par le client de navigation 12 (par exemple un identifiant de cookie de l’application Google Analytics®) ( ).
Un tel identifiant ID3 peut comprendre par exemple des données de cookie, c’est-à-dire des données contenues dans des cookies stockés dans le terminal client T1. Ces données de cookies peuvent être collectées par le client de navigation 12 et incluses dans les données d’utilisateur DT3 transmises au système PT1.
1) Lors de l’étape d), en réponse au déclenchement d’un défaut de cache, le procédé comporte :
- la sélection d’une ligne à évincer parmi les W lignes identifiées par les premières valeurs des W index de ligne générées lors de l’étape b), puis
- la comparaison d’un compteur associé à la ligne à évincer sélectionnée, à une seuil prédéterminé, et
- lorsqu’il résulte de cette comparaison que la valeur de ce compteur a franchi le seuil prédéterminé, l’exécution des opérations d1) et d2) et la réinitialisation de ce compteur et, à l’inverse, lorsqu’il résulte de cette comparaison que la valeur de ce compteur n’a pas encore franchi le seuil prédéterminé, l’enregistrement du mot fourni à partir de la mémoire de rang supérieur, dans la ligne à évincer sélectionnée et l’incrémentation du compteur associé à cette ligne à évincer.
2) Le compteur est enregistré dans une deuxième colonne de la table d’indirection associée à l’index de ligne qui pointe sur le tableau contenant la ligne à évincer.
- l’utilisation d’un bit sale associé à chaque ligne de la mémoire cache pour déterminer si, avant d’évincer cette ligne de la mémoire cache, il faut d’abord sauvegarder le ou les mots contenus dans cette ligne dans une mémoire de rang supérieur, et
- l’enregistrement du bit sale associé à chaque ligne de la mémoire cache dans une troisième colonne de la table d’indirection associée à l’index de ligne qui pointe sur le tableau contenant cette ligne.
- l’utilisation d’un bit de validité associé à chaque ligne de la mémoire cache pour déterminer si cette ligne doit être sélectionnée en priorité pour être évincée de la mémoire cache, et
- l’enregistrement du bit de validité associé à chaque ligne de la mémoire cache dans une quatrième colonne de la table d’indirection associée à l’index de ligne qui pointe sur le tableau contenant cette ligne.
- lors de l’étape a), la requête reçue comporte également un identifiant de processus reçu qui distingue le processus qui a émis cette requête de tous les autres processus simultanément exécutés par le calculateur électronique,
- lors de l’étape b), les premières valeurs des W index de ligne sont également générées en fonction de l’identifiant de processus reçu lors de l’étape a).
L’écart entre les butées de fin de course peut être compris entre 5 cm et 100 cm. Cependant il n’existe pas de limite haute car l’invention est opérationnelle bien au-delà de 100cm. Bien entendu, l’écart nécessaire entre les butées de fin de course dépend du traitement à réaliser.
L’axe de déplacement de la glissière se fait de préférence dans un plan sensiblement transversal à la base mobile. Lorsque la base comporte une plateforme, l’axe de déplacement de la glissière peut être parallèle à la plateforme.
La plage prédéfinie de positionnement latéral peut correspondre à une plage de déplacement le long de de la glissière éloignée des butées de fin de course et centrée sur une position de référence de la glissière comprise de préférence entre 1/3 et 2/3 de sa course totale à partir de la butée correspondant au moindre écartement de l’outil. Dans le cadre d’une grande glissière au-delà de 10cm la position de référence peut se situer sur une portion plus large qu’entre 1/3 et 2/3 de sa course, par exemple entre 10% et 90% de sa course.
Contrôle et guidage L’unité de contrôle peut comporter tout processeur, par exemple microcontrôleur et les interfaces pour interagir avec l’environnement de celui-ci, par exemple capteur(s), étage de puissance pour le pilotage des moteurs, HMI, émetteur/ récepteur pour échanger avec une télécommande sans fil.
L’unité de contrôle peut, le cas échéant, être montée de manière amovible sur le système, notamment sur la base. Dans ce cas, le système peut comporter une zone de réception comportant une série de connecteurs permettant de monter l’unité de contrôle sur la base.
Le système peut comporter une commande à distance, notamment sans fil, de préférence une télécommande, permettant à un opérateur de contrôler à distance le déplacement de l’actionneur agissant sur la position latérale de l’outil.
Le système peut comporter un laser de guidage formant un repère visuel sur une zone à traiter pour guider la base.
Le système peut comporter au moins un capteur de géométrie du profil d’une zone à traiter, notamment d’au moins une pièce, en amont de l’outil dans le sens de déplacement de celui-ci, le pilotage de l’actionneur pouvant se faire automatiquement en fonction du profil ainsi mesuré.
Le système peut être relié et communiqué avec un système de suivi du traitement pour y prélever des informations pertinentes à la réalisation du guidage.
Outil Le système peut comporter un outil reçu sur le support, notamment une torche de soudage, une ponceuse, une fraise, une lame, un capteur ultrason, un capteur à courant de foucault, de préférence une torche de soudage.
L’outil peut être monté de manière amovible sur le support de torche. Torche de soudage
La torche peut être configurée pour dévider, lors du soudage, un fil d’apport.
Le système peut comporter un poste de soudage, notamment un poste de soudage standard utilisable pour une opération de soudage à arc. Par « poste de soudage standard », on désigne un poste de soudage couramment utilisé pour des opérations de soudage à arc, par exemple de type MAG ou MIG. L’utilisation d’un poste de soudage standard permet de réduire significativement le coût du système, ce type de poste se trouvant couramment dans le commerce.
Le poste de soudage, encore appelé générateur, peut être fixe relativement aux pièces à souder durant le déplacement de la base.
Comme décrit plus en détail ci-après, le système PT1 peut traiter et stocker des données dans au moins une mémoire non volatile (non représentée) du système PT1, en particulier des données DT4 et au moins une empreinte numérique FP1. Selon un exemple particulier, le système PT1 peut également traiter et stocker des données de formulaires FM1 soumises par l’utilisateur UR1 au cours d’une visite du site web ST1. La nature et l’utilisation de ces différentes données sont décrites ultérieurement dans des exemples particuliers de réalisation.
Comme illustré en , le terminal client T1 peut comprendre un processeur 10, un module d’analyse PG1 et un module de contrôle (dit aussi unité de contrôle ou module/unité de suivi) PG2. De même que PG3, les modules PG1 et PG2 peuvent être des composants logiciels et/ou matériels. A noter que des exemples de réalisation sont possibles dans lesquels le module d’analyse PG1 n’est pas implémenté par le terminal T1.