INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
On observera ici que la forme canonique décrite ci-dessus en référence à la figure 146 permet de représenter les diagrammes d'états transitions de Harel (états hiérarchiques et états orthogonaux) ; transformations de ces cas étant évidentes pour l'homme du métier, elles ne seront pas décrites plus avant.
Notion d'historique (trace) Afin de pouvoir suivre ce qui se passe dans le système informatique, on peut disposer d'un historique qui relève toutes les actions effectuées par les objets et leur associe un temps logique.
Avant d'effectuer une action, un objet en informe le séquenceur par un message approprié, et le séquenceur écrit dans la trace les informations suivantes : # Quel objet effectue la transition # Quel était l'état de l'objet avant la transition (on l'appellera état précédent), au moyen d'un identifiant.
# Quelle est la cause de cette transition (soit l'utilisateur user le cas échéant, soit l'objet qui a causé la transition) On notera que les conditions spécifiées sur les transitions (voir UML - Unified Modeling Language, déjà mentionné) ou dans les états, peuvent également être notées dans la trace.
Cet historique va jouer un rôle dans le procédé de virtualisation décrit dans le chapitre suivant, ainsi que dans le mécanisme de Rollback explicité dans le chapitre VI.
Considérons l'exemple d'un objet 01 illustré sur la figure 147. La mise sous forme canonique va donner le résultat illustré sur la figure 148 ; l'appel à put du Séquenceur, illustrée sur la figure 148, correspond à une écriture dans l'historique avec les éléments que nous avons mentionnés plus haut.
Supposons maintenant que l'utilisateur crée cet objet 01. Celui-ci va donc entrer dans l'état Sentry, et effectuer son action Entryl. Au passage, la trace va être renseignée de la façon illustrée sur la figure 149.
Dans l'appel à méthode Put(01, initial, user) , 01 désigne l'objet qui effectue la transition, initial désigne l'état précédent de l'objet, tandis que user désigne ici l'objet (en l'espèce une action de l'utilisateur) qui est à l'origine de la transition (que l'on appellera la cause ). 54 désigne ici le temps logique auquel le message est reçu par le séquenceur.
Le curseur d'écriture indique où doit se faire la prochaine entrée dans la trace.
Le Séquenceur doit donc être capable de réagir à l'événement put, en écrivant les différentes informations reçues dans l'historique. Le comportement du séquenceur, en ce qui concerne la gestion de l'historique, peut alors être représenté de la façon illustrée sur la figure 150, où H représente Historique.
Exclusion mutuelle des premiers cycles - Notion de cycle Lorsqu'un objet déclenche un événement chez un autre (en lui envoyant un message ou par une notification de changement d'état si l'objet y est abonné, etc), il provoque
Dans ces conditions la phase instantanée s'écrit à valeur constante près: cp(t) = 2 n [f0.t +'/2 p.t2 ] (2) La représentation des différents signaux échangés alors la suivante: En appelant S1(t) le signal émis par l'objet portatif localisateur celui- ci représentable par une relation de la forme (t) = a1 cos [cp(t)] = al.cos{2n [f0.t +1/2.p.t2]} Le signal reçu par l'objet portatif de l'individu à localiser est alors de la forme: (t - i) = b1.cos (2 n [f0(t -i)+1/2.p.(t - i)2]} (4) ou i représente le temps de transit du signal entre l'objet portatif TER localisateur et l'objet portatif TER de l'individu à localiser.
signal S2 (t) réémis par l'objet portatif de l'individu à localiser est défini la relation: S2(t) = a2.cos{2 n[(f0 + F) (t -i)+1/2.p.(t - i)2] } (5) ou F représente le décalage en fréquence.
Enfin le signal qui est reçu par l'objet portatif localisateur écrit: S2(t - -T ) = b2.cos (2 n [(f0 + F)(t -2i)+1/2.p.(t - 2 -T)2] } D'autre part, le signal de référence locale généré par l'objet portatif localisateur est de la forme: R(t) = a1.cos{ 2 n [( f0.+ F')t +1/2.p.t2] } (8) La distance séparant les deux terminaux est obtenue analysant le produit X(t) du mélange entre les signaux R(t) et S2(t -i). Ce produit vérifie la relation: X(t) =1/2 a1.b2.cos{ 2 n [2 p i t + (F- F ) t+2(f0 + F) T - 2.p.T2] } (9) Le terme (F'-F) représente un décalage fixe en fréquence égal à zéro si F est choisi égal à F. Le terme 2 p i de l'équation (8) représente une fréquence fb dont la valeur est directement proportionnelle au temps de transit c'est à dire à la valeur de la distance d séparant les deux objets portatifs. autres termes représentent des phases sans importance par la suite. La distance d s'obtient par la relation: d = c.i où c représente la vitesse de la lumiere.
précision obtenue s'exprime par la relation: ='/2.(c. T/AF) Ofb granularité de précision sur la mesure de fb est reliée à durée d'émission du burst. Pour obtenir la précision souhaitée, il souhaitable d'émettre non pas une seule rampe mais plusieurs à la suite unes des autres. Soit N le nombre de rampes élémentaires, la granularité mesure devient Afb = 1/NT. L'erreur sur d devient Ad ='/2.(c. T/AF) /NT ='/2. / (OF.N) Dans la bande 860 MHZ en prenant un étalement AF = 600kHz N égal à , la granularité de mesure de distance Ad est égale à 1,25 m. prenant = ms, la granularité d'analyse en fréquence Afb = 1/NT = 5 Hz.
bande de fréquence à analyser correspond à une distance maximale 500 m, soit à une valeur maximale de fb = iAF /T = 2.d.AF/T.c = 2kHz.La d'analyse comporte alors 512 points.
mode de réalisation d'un module de guidage terminal fonctionnant suivant le procédé qui vient d'être décrit est montré à la figure où les éléments homologues à ceux des figures 1 et 2 sont représentés avec les mêmes références. Celui-ci comprend un processeur de traitement signal 15 du commerce convenablement programmé pour effectuer le calcul de distance décrit précédemment. Le processeur 15 est couplé par premier 15, à une voie d'émission 16 et par un deuxième port 152 à voie de reception17. Un bus 18 relie un troisième port du processeur 15 au combiné GSM 3 et un quatrième port reçoit les signaux physiologiques du récepteur 13 portée par la liaison 14 au travers du convertisseur analogique -numérique ibis.
voie d'émission 16 comprend un modulateur 19, un étage mélangeur un dispositif de commutation 21, un amplificateur 22 et un filtre 23, ces éléments étant reliés dans cet ordre en série entre le premier port 151 et l'antenne 9. L'étage mélangeur 20 mélange le signal fourni par modulateur 19 avec celui fourni par un synthétiseur de fréquences commandé en fréquence par le signal de rampe défini par la relation (1) dans le mode de fonctionnement avec transpondeur mais qui est commandé par fréquence fixe F1 pour l'émission de bursts lorsque l'objet portatif est dans mode de fonctionnement d'un objet portatif à localiser, ou commandé par la fréquence fixe F2 pour l'émission de bursts sur cette fréquence lorsque l'objet portatif est en mode localisateur.
voie de réception 17 comprend un filtre 25, un amplificateur 26, un dispositif commutation 27, un étage mélangeur de fréquence 28, et un démodulateur ces éléments étant reliés dans cet ordre en série entre l'antenne 9 et deuxième port 152,1'étage mélangeur 28 mélange le signal fourni par l'amplificateur 26 au travers du dispositif de commutation 27 avec celui fourni un synthétiseur à fréquence 30 commandé également en fréquence le signal de rampe défini par la relation (1) en mode transpondeur mais aussi par une fréquence fixe lors de la réception des bursts sur la fréquence F1 en mode localisateur, et par une fréquence fixe aussi lors de la réception des bursts sur la fréquence F2 lorsque l'objet portatif est dans le mode de fonctionnement d'objet portatif à localiser. dispositif de transposition de fréquence 31 est couplé entre les dispositifs commutation 21 et 27.
dispositifs de commutation 21 et 27 comportent deux états A et B activés partir du clavier 12 du combiné GSM ou par une station de surveillance représentée dans le réseau GSM, ou d'un automate interne en fonction mode de fonctionnement en cours, ils permettent aux modules de guidage de fonctionner soit en interrogateur( émetteur- récepteur) pour le mobile localisateur, soit en transpondeur-répondeur pour les mobiles à localiser. Dans ce mode de fonctionnement les dispositifs de commutation et 27 sont positionnés respectivement dans les états A et B pour le module du mobile localisateur et ceux de l'objet portatif répondeur du mobile à localiser dans leur état B. Dans l'état A du commutateur 21 l'objet portatif est en mode interrogateur, il se trouve alors dans l'état de fonctionnement d'un poste central c'est à dire qu'il émet en sortie de la voie d'émission 16 le signal S1 (t) vers l'objet portatif de l'individu à localiser, et qu'il reçoit à 'entrée de la chaîne de réception 17 le signal S2(t-i) provenant de l'objet portatif de l'individu à localiser.
Ce signal est transmis au travers du dispositif de commutation 27 placé dans l'état B sur une première entrée du dispositif de transposition de fréquence 31 pour être transposé de la fréquence de décalage -F. signal obtenu en sortie de l'étage mélangeur 32 résulte du mélange du signal R(t) appliqué par la sortie du commutateur 21 à l'entrée de l'amplificateur 22 avec le signal obtenu en sortie du dispositif de transposition de fréquence 31. Ce signal qui représente le terme en cosinus du signal X(t) est converti sous une forme numérique par le convertisseur analogique-numérique 33 avant d'être transmis au processeur 15 pour le calcul de la fréquence fb et de la distance d. La distance d calculée est transmise sur le bus 18 afin d'être visualisée par le combiné GSM avec l'identifiant du mobile localisé.
Côté répondeur les dispositifs de commutation 21 et 27 rebouclent la sortie de l'amplificateur 26 sur l'entrée de l'amplificateur 22 au travers du dispositif de transposition de fréquence 31 qui est chargé d'effectuer le décalage fréquence +F du signal s1(t-,z) reçu par le terminal à localiser.
Comme il est possible de le vérifier sur la figure 4, des combinaisons différentes des états A et B des dispositifs dé- commutation 21 et 27 permettent de placer indifféremment chacun des objets portatifs en état de veille 'une émission d'un autre objet portatif que ceux- ci se trouvent dans le rôle de l'objet localisateur ou de l'objet localisé.
dispositif qui vient d'être décrit peut être avantageusement complété par un dispositif permettant d'indiquer la direction d'où proviennent les émissions d'un autre objet portatif détecté. Ceci peut être obtenu en incorporant à l'objet portatif un atténuateur enclenché lorsque le secouriste arrive à proximité de la personne recherchée, dans un rayon de quelques mètres. L'atténuateur permet alors de réduire fortement le signal reçu et de le recentrer dans la partie non saturée de la caractéristique distance/champ reçu. Une autre possibilité est d'utiliser une antenne directive 9 sur le module de localisation 8, solidaire par exemple de la face arrière du GSM; l'utilisateur tourne progressivement avec son GSM devant lui vers la direction présentant le maximum signal reçu. Mieux encore, une autre possibilité est de munir l'objet portatif deux antennes et de programmer le module de localisation 8 pour analyser déphasage des signaux reçus par les deux antennes.
L'utilisation d'un combiné GSM du commerce pour réaliser à la fois la fonction de communication et la fonction de localisation à longue distance qui lui sont directement associées est naturellement recommandee, vu le faible prix de cet équipement. II suffit seulement de le relier par le 18 au module de guidage terminal (2) sur sa prise d'extension qui est formee par un interface RS232 classique.
Pour satisfaire aux contraintes d'autonomies liées à celles des batteries, car est clair qu'actuellement la charge des batteries des appareils portables ne tient pas plus de quelques jours en mode veille, à partir d'une charge complète et à condition de rencontrer des contraintes d'environnement normales à la température ambiante, il est conseillé munir respectivement le module de localisation et le module communication chacun de leur propre batterie.
Le système qui vient d'être décrit peut être configuré selon plusieurs modes de fonctionnement dépendant des-circonstances recherches.
A l'issue de l'opération de mélange, on peut éliminer le (ou les) solvant(s) organique (s), notamment par séchage, évaporation (par exemple par entraînement à la vapeur). On peut également effectuer une étape finale de mise en forme du solide obtenu.
L'opération de mélange est en général effectuée à une température comprise entre 10 et 80 C, par exemple entre 15 et 35 C.
A l'issue de l'opération de mélange, le (ou les) solvant(s) organique (s) peut (peuvent) être recyclé(s), après séparation, vers une étape de préparation de la solution organique de polymère et/ou vers une étape de préparation de la suspension organique de particules minérales.
La solution organique de polymère peut être issue de la dissolution du polymère solide dans le solvant organique. Cependant, elle est issue préférentiellement de la polymérisation des monomères correspondants dans le
solvant organique ; on emploie ainsi de préférence dans le procédé selon l'invention un ou des polymères obtenus par polymérisation en solution.
De plus, de manière avantageuse, le solvant organique dans lequel le polymère est en solution est identique au solvant organique dans lequel les particules minérales sont en suspension.
On met généralement en #uvre une suspension organique présentant une teneur en particules minérales comprise entre 1 et 30 %, en particulier entre 5 et 20 %, et par exemple entre 5 et 15 %, en masse.
De même, la teneur en polymère de la solution organique employée est habituellement comprise entre 5 et 30 % en masse.
Les quantités de matières premières utilisées sont telles que le mélangemaître préparé contient en général de 10 à 150 parties, de préférence de 25 à 100 parties, et en particulier de 40 à 75 parties, de particules minérales pour 100 parties de polymère.
Dans le cadre de l'invention, par "polymère" on entend également "copolymère".
Le polymère utilisé est en général un élastomère II présente, en général, au moins une température de transition vitreuse comprise entre-150 et +300 C, en particulier entre-150 et +20 C.
A titre de polymères possibles, on peut citer, notamment, les polymères diéniques, en particulier les élastomères diéniques Par exemple, on peut citer le caoutchouc naturel, les polymères dérivant de monomères aliphatiques ou aromatiques, comprenant au moins une insaturation (tels que, notamment, l'éthylène, le propylène, le butadiène, l'isoprène, le styrène), le polyacrylate de butyle, les élastomères silicones, les élastomères thermoplastiques, les élastomères fonctionnalisés, les polymères halogénés, et leurs mélanges.
Le polymère employé peut être l'EPDM. De manière préférée, on emploie un SBR (copolymère styrène butadiène) ou/et un BR (polybutadiène).
On peut mettre en #uvre au moins deux polymères différents Les particules minérales employées dans le cadre de l'invention sont en général anioniques. Cependant, elles peuvent subir, préalablement à leur emploi, un traitement de surface, notamment pour les rendre cationiques (cationisation), par exemple par un dopage à l'aluminium.
Elles sont habituellement choisies dans le groupe suivant : silices, en particulier silices de précipitation, alumines, silicoaluminates, oxydes de titane, oxydes de zinc, carbonates de calcium, phosphates de calcium, phosphates de zirconium, argiles, hydrotalcites.
Les particules minérales préférentiellement employées dans la présente invention consistent en une charge connue ou utilisable pour le renforcement des compositions de polymère.
Le code "HTML" nécessaire pour programmer un tel formulaire est bien connu en soi est à la portée de l'homme de métier. II n'est pas nécessaire le détailler nouveau. On peut cependant indiquer qu'il contient notamment une ligne code en langage "HTML" qui se présente typiquement sous forme (4), dans laquelle http:Il127.0.01:8080 est l'URL de rebouclage de la relation (1 cgi-smart répertoire "CGI" précité contenant le script de chargement "loader" que l'on a appelé "il", script associé à la partie IL du programme de chargement.
Si l'affichage visuel du formulaire 8 sur l'écran 5 n'est pas souhaité (par exemple a pas d'opérateur humain, les informations peuvent être cachées incorporant le paramètre "HTML" suivant : "TYPE=hidden" dans ligne de code précitée.
Lors d'une troisième étape, la partie OL envoie une requête "HTTP" type "GET" à carte à puce 2a, toujours par ouverture de sessions entre agents intelligents appariés. En faisant appel à la fonction "CGI" offerte par carte à puce telle qu'elle a été décrite en regard de la figure 5, l'application IL s'exécute, serveur "WEB" formé par la carte à puce 2a passant paramètres requête "HTTP" à cette dernière application.
La requete précitée contient une ligne de code typiquement de la forme suivante Smartlloader?AID=xxx & ByteCode=yyy & Signature=zzz (5), Dans laquelle "xxx" est l'entête 70 ("2001" dans l'exemple de figure 9), " le "Byte Code" 71 ("0123456789ABCDEF" dans l'exemple la figure 9) et " la signature électronique 71 ("0123456789ABCDEF" dans l'exemple de figure 9). Les trois parties du fichier de chargement sont donc bien insérées dans trois champs du formulaire "HTML" 8, sous forme concaténée.
Le chargement d'une "applet" particulière identifiée par l'entête 70 a lieu à ce moment.
Enfin, lors d'une quatrième étape un code de retour transmis de la partie IL à la partie OL, toujours par mise en oeuvre de sessions entre agents appariés. II s'agit en général d'un simple acquittement ou, si l'opération ne s'est pas réalisée correctement d'un code d'erreur. Dans ce dernier cas, il est nécessaire de renouveler les étapes 1 à 4.
Comme solution alternative, il est possible d'utiliser méthode "POST' précitée. Pour fixer les idées, la figure 10 illustre un exemple d'un tel formulaire référencé 8'. On retrouve diverses zones de texte et de graphique 80, une zone d'affichage de l'entête 70 et une zone d'affichage de la signature électronique 72, ainsi que des boutons d'envoi "send" 81 et remise à zéro "Reset" 82. Ces éléments jouent un rôle tout à fait similaire éléments de mêmes référence de la figure 9 et il est inutile de les re-décrire. Par contre, la zone d'affichage 71' ne visualise plus explicitement le "Byte Code", mais un répertoire ou un sous-répertoire où le code de l' "applet" à charger est enregistré. En l'occurrence, cette zone pointe sur un fichier, appelé arbitrairement "APPLET.BIN", enregistré sur une unité de stockage appelée "C", qui peut être un disque dur présent dans le terminal 1. Un bouton supplémentaire de navigation "browse" 83 permet de balayer les divers (sous-)répertoires de ce disque et de sélectionner un fichier particulier ("APPLET. BIN").
La méthode "POST" comme la méthode "GET" est bien connue en soi, et il est inutile de la re-décrire en détail. Dans le cadre précis de l'invention, l' "applet" correspondant au fichier "APPLET.BIN" est chargée, à partir de l'unité "C", de manière similaire à ce qui a été décrit pour la méthode "GET".
On va maintenant décrire un deuxième exemple de chargement d' "applet" dans la carte à puce 2a.
II est également possible d'enchaîner plusieurs formulaires lors du chargement. A la place d'un simple statut (acquittement ou code d'erreur dans le premier exemple décrite en regard de la figure 8), le retour de la partie IL contient alors un nouveau formulaire. Ainsi, des séquences dynamiques d'échanges entre les parties OL et IL peuvent être réalisées.
Par exemple, après analyse du fichier de chargement, la partie IL peut demander une autorisation (c'est-à-dire une signature électronique) supplémentaire, par exemple celle d'une instance gouvernementale. Elle renvoie alors à la OL un formulaire qui peut avoir typiquement la structure "HTML" suivante (6)
Authorisation form ACTION="http:ll@carte:80801cgi-smartlloader"> TYPE="text" NAME="GouvSignature" MAXLENGTH="8">Signature dans laquelle "Authorisation form", entre les balises "HTLM" dénommees " " et , représente le titre (arbitraire) du formulaire, "@carte" la traduction litterale de l'adresse URL de rebouclage de la relation (1) et 8080 le numéro de la ligne de code Signature requiert l'entree d'une variable appelée arbitrairement "Signature", en mode texte, de longueur maximale 8 octets, et est la balise "HTML" indiquant la du code de formulaire.
Le processus complet comprend alors deux étapes supplémentaires avant l'étape finale d'acquittement ou de code d'erreur, soit six étapes, comme illustré par figure 11.
façon plus générale, le nombre d'allers et retours peut dépendre paramètres figurant dans l'un ou l'autre des formulaires échangés entre la à puce et partie OL des programmes de chargement.
Jusqu'à ce point, la localisation de la partie OL n'a pas été précisee expressément. Outre le fait que le procédé rend, a priori, compatible OL et IL, il permet aussi une très grande souplesse précisément quant à cette localisation, étant entendu que la partie IL est stockée dans la carte à puce 2a comme formant l'une des applications présente dans cette carte à puce. Le procédé selon l'invention présente notamment l'avantage supplémentaire de ne plus exiger proximité physique entre les deux parties OL et puisqu'elles ne sont plus tributaires du protocole de communication ISO les échanges entre deux portions de logiciel mettant en ceuvre protocole de communication Internet TCPIIP.
Aussi, la partie OL, ainsi que les données proprement dites de l' "applet" charger sur la carte à puce 2a peuvent être stockees soit en local, soit dans site éloigné. Dans tous les cas cependant, les echanges entre ces deux parties mettent en ceuvre, comme il vient d'être rappelé, un protocole de communication '7CPIIP" et le chargement d'une "applet" se deroule comme il a été rappele précédemment grâce aux fonctions de serveurlclient "WEB" et "CGI" offertes la carte à puce 2a.
Plus précisément, la valeur CO-1 reflète le degré de confiance que le possesseur du répertoire RO accorde au contenu du répertoire RI. En effet, puisqu'en général le possesseur du répertoire RO accepte les suggestions provenant du répertoire RI, il accorde un degré de confiance relativement fort à la validité de l'acte d'acceptation dans le répertoire RI. En d'autres termes, le possesseur du répertoire RO considère que le possesseur du répertoire RI a un bon jugement en matière d'acceptation et de refus dans ledit répertoire RI.
Or il se trouve que le possesseur du répertoire RI a accepté dans ce répertoire une grande partie des suggestions provenant du répertoire R2 (c'est-à-dire que la valeur CI -2 est élevée). Puisque son jugement est bon aux yeux du possesseur du répertoire RO, le système peut conclure que le possesseur du répertoire RO va probablement aussi accepter les suggestions provenant du répertoire R2.
Par le même raisonnement, si la valeur CO-1 est forte et si la valeur CI-2 est faible, alors, le système peut conclure que la valeur CO-2 sera faible.
Bien évidemment, la profondeur de la transitivité (le nombre des intermédiaires) peut être plus grande : le système peut se baser sur plusieurs intermédiaires qui se sont fortement validés dans le passé (de préférence le passé récent - voir plus haut à propos de la pondération) pour prédire qu'un nouveau répertoire sera probablement validé ou pas. Mais, bien évidemment, la fiabilité du coefficient obtenu baissera avec la profondeur de la transitivité.
On a déjà mentionné que la détection de répertoires proches permet de présenter ces répertoires à l'utilisateur dans la deuxième liste (intitulée voisins d'intérêt ) illustrée de manière schématique dans la figure 55a. Le coefficient de probabilité d'acceptation est un indicateur qui est présenté avec chacun de ces répertoires (il peut
par exemple être intitulé statistiques d'acceptation ). L'utilisateur préférera cocher des répertoires qui ont ce coefficient le plus élevé possible.