INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Les composés de formules I, l'a et l'b, sous une forme optiquement active, s'avèrent ainsi tout particulièrement utiles pour la préparation de coordinats de complexes métalliques catalytiques utiles pour réaliser une hydrogénation asymétrique énantiosélective de dérivés cétoniques.
Il a également été montré que ces mêmes composés de formules générales I, l'a et l'b, sous une forme optiquement active, pouvaient être utilisés pour préparer des coordinats de complexes métalliques catalytiques utiles pour réaliser une oxydation énantiosélective de fonctions hydroxyles.
En conséquence, la présente invention a également pour objet un complexe métallique à base d'un métal de transition et comprenant à titre de ligand dudit métal au moins une forme optiquement active d'un composé de formules générales I, l'a et l'b, telles que définies ci-dessus.
10 ## N propenylidene] benzenecarbohydrazonamide N
11 ,,,,[J . N'-[(E,2E)-3-(2-furyl)-2et propenylidene]benzenecarbohydrazonamide
##N N#N N'-[(E)-2-furylmethylidene]benzene
12 01-" N carbohydrazonamide CI o 13 NI, - N'-{(E)-[5-(2-chlorophenyl)-2i . N furyl]methylidenelbenzenecarbohydrazonamide P\ gNv 0 V'b - N'-{(E)-[5-(4-nitrophenyl)-2- 'j N'-(E)-[5-(4-nitrophenyi)-2-
14 ##N furyl]methylidene}benzenecarbohydrazonamide
Composé Formule Nom N
N furyl)methylidene]benzenecarbohydrazonamide 17 ' CI N'-{(E)-[5-(3-chlorophenyl)-2-
N'N furyl]methylidenebenzenecarbohydrazonamide zon '-7 N'-(E)-[5-(2-nitrophenyl)-2- 18 0 furyllmethylidenelbenzenecarbohydrazonamide bzz r N No - N'- f (E)-[5-(3-nitrophenyl)-2- 19 0 furyljmethylidene}benzenecarbohydrazonamide N i .Ili N'-[(E)-3- 20 N furylmethylidene]benzenecarbohydrazonamide
Composé Formule Nom
N"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#O O#O [5-((E)-{(2Z)-2-
21 [amino(phenyl)methylene]hydrazonol îf ### methyl)-2-furyl]methyl acétate 22 , ,1I , ô , Br N'-{(E)-[5-(4-bromophenyl)-2- 'j furyl]methylidene}benzenecarbohydrazonamide N Si)
23 O# N'- [(E)-(5-nitro-2N#N #O# furyl)methylidene]benzenecarbohydrazonamide
zon Ze\ N'-[(E)-(5-ethyl-2O N'-[(E)-(5-ethyl-2- 24 N furyl)methylidene]benzenecarbohydrazonamide
25 N N#N## N'-[(E)-3-methylphenylmethylidene]benzene
L'environnement d'exécution de la plate-forme spécifique (Runtime Environment ou RE) comprend la machine virtuelle embarques ("on- platform") (41) se limitant à un interpréteur, une plate-forme et les méthodes dites natives (43) ou encore statiques associées. La plate-forme API comprend les API (44) (Application Programming Interface) definissant un ensemble de classes, dites classes système (45), et les conventions d'appel par lesquelles une application accède à l'environnement d'exécution (RE) aux méthodes statiques (43). Les méthodes statiques (43) exécutent les services d'allocation de mémoire, d'entrée et sortie, et cryptographique de la L'interpréteur de la machine virtuelle embarquée de la (41)(on- platform), de support au langage "Java", et lit de façon sequentielle le pseudocode intermédiaire, instruction par instruction. Chaque instruction standard de ce pseudocode intermédiaire est interprétée dans langage du microprocesseur par l'interpréteur puis exécutée par le microprocesseur. En règle générale, les instructions standards du pseudocode intermédiaire permettent de traiter des fonctions évoluées telle que le traitement arithmétique et la manipulations d'objets. La notion d'objet concerne les objets informatiques tels qué listes, tableaux de données ou analogues. Les classes dites clients (46) des applications et les classes systèmes (45) des API sont toutes chargées dans le même espace mémoire et sont gérées par l'intermédiaire d'une table de classe (47).
La machine virtuelle (41) est également chargée de gérer les classes et objets et de faire respecter les séparations ou pare-feu entre les applications afin de permettre un partage sécurisé des données, appelées également attributs, variables ou champs (fields). Dans le cas d'un objet portable de type carte à puce, une application d'une plate-forme spécifique peut être activée directement l'environnement d'exécution (RE) lorsqu'une APDU (Application Protocol Data Unit) sélection émise par un service ou terminal est reçue carte. Afin restreindre l'accès aux données entre les parties partageant même espace mémoire, une des méthodes classiques sur une plate-forme classique est basée sur la restriction explicite de visibilité déclarée dans le code source. Suivant la figure 4c, les méthodes (NM1 NM2), respectivement (NM3, NM4), et les attributs (NA1, respectivement (NA3, NA4) sont encapsulées dans des classes (NC13), respectivement (NC12), qyi elles-mêmes font partie de paquetages (Paquetage ), respectivement (Paquetage n) regroupant chacun plusieurs classes. classe peut être publique telle que (NC11 ou NC12) ou privée telle que (NC13) par rapport à un paquetage, ce qui implique, dans le dernier cas, que seules les classes du même paquetage peuvent accéder à cette classe. méthodes (exemple NM2) et les données (exemple NA1) d'une classe (NC13) peuvent être privées par rapport à la classe (NM2, NA1), elle-même privée par rapport au paquetage (Paquetage 1), ou publiques par rapport au paquetage (par exemple NM1, NA2) ou à la classe (par exemple NM4, NA4). Cette restriction de la visibilité permet d'obtenir un accès flexible entre les différents ensembles de paquetages (Paquetage 1, Paquetage n) stockés dans le même espace nom, mais présente quelques inconvénients. La plate-forme classique ou spécifique supporte mal la notion de sous-paquetages. Les classes client d'une application de grande taille doivent être réparties entre différents sous-paquetages qui représentent uniquement pour la machine virtuelle des paquetages différents. Pour partager les ressources entre ces sous-paquetages, ces ressources sont nécessairement déclarées publiques, les rendant ainsi visibles de tout autre paquetage. II est ainsi difficile d'organiser de façon claire le paquetage d'applications différentes pour des applications de grande taille et d'obtenir des pare-feu entre applications.
Dans le cas la plate-forme classique, sur une station, le respect de la confidentialité ressources, telle que déclarée dans les programmes sources, repose vérifications dynamiques. Pour effectuer ces vérifications dynamiques, la machine virtuelle doit posséder toutes les informations concernant déclarations de restriction d'accès pour chaque classe, méthode attribut, ce qui ne peut être possible dans le cas de l'espace mémoire disponible sur la machine virtuelle embarquée (onplatform) utilisant pseudocode intermédiaire ou byte code prélié de la machine virtuelle hors plate-forme (offplatform). Dans le cas d'une plate- forme spécifique objçt portable, les restrictions d'accès peuvent se vérifier statiquement lors de la compilation et peuvent être vérifiées à nouveau par le vérifieur de la partie hors plate-forme. II est en effet supposé que ce qui est charge sur la plate-forme spécifique de l'objet portable est correct, car aucune vérification ne peut être effectuée sur la plate-forme spécifique du fait la perte des informations lors de la phase de conversion. De plus n'est pas garanti qu'un paquetage ne puisse pas être étendu ou modifié de nouvelles classes venant de sources étrangères, ce qui peut détruire toute la sécurité basée sur l'utilisation de paquetages privés.
Le deuxième moyen procuré par la machine virtuelle d'une plate- forme classique est la notion de séparation des espaces nom. Avec le schéma de liaison dynamique d'une plate-forme classique, les classes peuvent être chargées, à partir de répertoires du système de fichier local, appelé "CIassPath" préalablement déclaré comme constituant l'emplacement des classes systèmes forant la plate-forme API standard, ou à partir d'autres répertoires du système de fichier local ou de serveurs éloignés. Les classes client d'une application, extérieures au "CIassPath", doivent être chargées par un chargeur de classe spécifiquement programmé. Cette caractéristique est particulièrement utilisée pour le chargement des applications "Java" par navigateurs habilités "Java". Ainsi, les applications venant de différentes sources, sont chargées par des chargeurs de classes différents. Pour chaque localisateur, communément appelé URL (Uniform Resource Locator), une instance spécifique de classe "chargeur de classe d'application" est utilisée. Le nom externe d'une classe est l'assemblage + . Quand une classe est chargée, elle est stockée dans une table de classe interne, et une référence relative au chargeur de classe utilisé pour charger cette classe est ajoutée en préfixe du nom de paquetage de la classe. Le nom de la classe est alors Référence du Chargeur de Classe> + + < Nom De La Classe . Ainsi des classes déclarées comme appartenant au même paquetage mais chargées par des chargeurs de classes différents ne sont pas perçues par la machine virtuelle comme appartenant au même paquetage.
Lors de la résolution d'une référence, la politique habituelle des chargeurs de classe est de rechercher d'abord dans les classes système et en cas d'échec, de rechercher parmi les fichiers de classe présents à l'emplacement où le charger peut charger les classes. Selon ce principe de fonctionnement du chargeur, une application ne peut directement accéder aux classes clients d'une autre application chargée par un chargeur de classes différent. Une application peut accéder à toutes les ressources publiques des classes publiques du CIassPath, mais les classes du CIassPath ne peuvent accéder directement aux classes d'une application bien qu'elles puissent faire référence à des instances de classes clients de l'application en les convertissant en un type public défini dans le "Classpath". Une application ne peut étendre ou modifier des paquetages de classes système du Classpath ou de toutes autres applications chargées par des chargeurs de classes' différents. L'utilisation de la séparation des espaces nom en insérant . référence du chargeur de classe dans le nom de la classe, ajoutée au typage complet fourni par le langage "Java", permet de procurer un pare-feu efficace entre les applications. Le mécanisme inné de séparation de nom d'espace permet facilement le chargement nouvelles applications. Les applications peuvent échanger des objets l'entremise des classes spécifiquement programmées à cette fin localisees dans le "Classpath". Une application peut utiliser un objet venant d'une autre application chargée par un chargeur de classe différent, si objet peut être changé en un type public défini dans le "Classpath".
Malheureusement ce mécanisme de séparation de nom, basé une machine virtuelle classique et son processus de liaison dynamique peut être effectué sur une plate-forme spécifique. La liaison dynamique peut être effectuée par la machine virtuelle d'une plate forme spécifique, celle ' nécessitant un espace mémoire permettant le stockage de fichier de classe d'une plate-forme "Java" classique, présentant des références non résolues. Dans une plate-forme spécifique, les classes systèmes des API et les classes clients des applications ne sont pas isolées dans des espaces de nommage particuliers.
L'objet de la présente invention est de proposer une solution procurant les avantages de la séparation de nom dans le cadre de systèmes embarqués possédant une machine virtuelle en deux parties, le schéma liaison statique étant effectué par la partie hors plate-forme.
Dans le contexte de systèmes embarqués, tels que par exemple terminaux de paiement; mult-application, il est nécessaire d'avoir des pare- feu performants entre les applications "Java" fournies par différentes sources, telles que différents systèmes de paiement (Visa, Mastercard...). peut etre utile de permettre une coopération flexible entre les applications venant des différentes sources. Le système embarqué doit aussi être facilement mis à jour en téléchargeant de nouvelles applications ou nouveaux modules utilitaires ou encore des mises à jour sans perturber applications déjà chargées.
Un premier but de l'invention est de proposer un procédé chargement permettant d'obtenir des pare-feu robustes entre applications tout en autorisant une coopération entre les applications et possibilité de faire évoluer les applications ou de charger d'autres applications.
but est atteint par le fait que le procédé de chargement d'applications sur un système embarqué selon l'invention comprenant un environnement d'exécution incluant une machine virtuelle comprenant un interpréteur de langage de type pseudocode intermédiaire, interfaces de programmation d'application (API), à partir d'une station laquelle le code source l'application est écrit, compilé en pseudocode par un compilateur, vérifié un vérificateur, converti par un convertisseur et chargé par un chargeur, caractérise en ce que - la conversion comprend la réalisation de la liaison statique d'une pluralité d'ensembles de paquetages destinés à être stockés dans le même espace nom sur le système embarqué, appelés modules, en attribuant un identificateur à chaque module (MID), et un numéro de référence à chaque classe, à chaque méthode et à chaque attribut encapsulés dans les classes i du module, - la référence à une méthode ou un attribut, dans le pseudocode lié d'un module, étant codée sur trois multiplets constitués par un indicateur indiquant la référence à une classe interne ou externe au module, le numéro de la classe et soit le numéro de la méthode soit le numéro de l'attribut, - les modules chargés sont un ou plusieurs modules d'interface de programmation d'application, appelé Module API, comprenant des classes système ou des modules de services correspondant chacun à une application, une référence :à une classe externe étant systématiquement interprétée par la machine ,virtuelle comme une référence à un module d'interface de programmation d'application.
Selon une autre pârticularité, le chargement des modules sur le système embarqué comprend la mémorisation d'une part d'au moins un tableau représentation des modules, le numéro associé, par le lieur compris entre 0 et n, à un module constituant l'index dudit module dans le tableau, et d'autre part d'une table mémorisant l'association de l'index du tableau de représentation à l'identificateur (MID) dudit module, ledit tableau et la table étant en mémoire programmable non volatile, une référence externe à un module externe dans le pseudocode étant interprétée par l'interpréteur de la machine virtuelle comme constituant un index d'accès au module équivalent à celui du tableau des modules.
Selon une autre particularité, le chargement comprend la mémorisation, pour chaque module, d'un tableau de représentation ses classes, comprenant une référence à l'index de son module et, pour chaque classe, un tableau de représentation des attributs et des méthodes.
Selon une autre particularité, les modules sont référencés dans un tableau de modules unique, les classes système sont contenues dans un module API unique, toute référence à une classe externe dans le pseudocode différente de n sera interprétée par la machine virtuelle comme référence audit module@Pl.
Selon une autre particularité, les classes étant déclarées publiques, en paquetage privé, les attributs et méthodes étant déclarés protégés, en paquetage privée ou en classe privée, la numérotation des classes s'effectue suivant l'ordre classes publiques puis classes en paquetages privés, la numérotation des attributs ou méthodes est effectuée le convertisseur suivant l'ordre attribut ou méthode public, protégé, en paquetage privé et en classe privée.
Selon une autre particularité, les classes système sont contenues dans plusieurs modules API chargeables séparément, le chargeur maintient dans la mémoire non volatité programmable deux tableaux de représentation modules et deux tables d'association MIDIIMi correspondantes, l'un pour modules API et l'autre pour les modules non-API, le chargeur chargeant modules dans l'un des deux tableaux selon la nature du module spécifié dans l'entête de celui-ci, toute référence externe d'un module du tableau de module étant interprétée comme une référence à l'index du module API. Selon une autre particularité, la liaison statique d'un module est effectuée de telle sorte que la référence à une classe externe à un module non API dans pseudocode intermédiaire est un index dans un tableau de l'entête du module, dont chaque entrée est un identificateur (MID) d'un module API référencé, le chargement dudit module sur la plate-forme cible comprenant le remplacement de ladite référence par le numéro de l'index du module obtenu à partir de l'identificateur (MID) de la table d'association modules API.
Un autre but de l'invention est de proposer un système embarqué correspondant.
Bien qu'on ait indiqué un décalage suivant l'axe optique, on obtient des effets analogues par décalage transversalement à l'axe optique ou par pivotement de l'élément dioptrique, par exemple autour d'un axe transversal à l'axe optique. Dans ce cas, des parties seulement de l'image peuvent être défocalisées.
La présente invention n'est nullement limitée aux modes de réalisation décrits et représentés, mais l'homme du métier saura y apporter toute variante conforme à son esprit.
présente invention concerne une tuyère pour chalumeau ou pour torche travail à l'arc électrique, en particulier pour chalumeau d'oxycoupage, et l'utilisation d'une telle tuyère dans un procédé de soudage, de coupage, de traitement thermique ou analogues.
De façon connue, les tuyères et autres orifices calibrés permettent de contrôler les écoulement des fluides, qu'il s'agisse de contrôler ou mesurer des débits ou de créer des jets aux caractéristiques précises.
Ainsi, dans le domaine de l'oxycoupage de métaux, des jets d'oxygène cohérents, de sections bien déterminées et de vitesse maximale, sont genérés et délivrés par des tuyères équipant les chalumeaux d'oxycoupage. II existe plusieurs profils de tuyères plus ou moins élabores pouvant etre utilisés à cette fin, par exemple les tuyères dites de LAVAL, tuyères a sections cylindriques, les tuyères à sections cylindriques avec divergent, les tuyères étagées....
façon analogue, dans le domaine du coupage plasma, la tuyère la torche à plasma entoure l'électrode et porte un orifice d'éjection du jet plasma, lequel forme diaphragme de constriction dudit jet de plasma. d'autres termes, un gaz sous pression, dit gaz plasmagène, est introduit dans torche à plasma, est distribué entre l'électrode et la tuyère, s'écoule ensuite, après ionisation par un arc électrique, par l'orifice de tuyère en direction de la pièce métallique à couper ou à souder, par exemple une tôle d'acier de construction.
Dans tous les cas, il est nécessaire que le ou les matériaux constitutifs de la tuyère soit choisi avec soin, de manière à ce qu'ils puissent résister le plus longtemps possible aux contraintes physico-chimiques, notamment thermiques, auxquell la tuyère est soumise durant l'opération de coupage et donc ainsi diminuer fréquence de remplacement . Pour ce faire, il est souhaitable que les tuyères soient réalisées en cuivre ou en alliage de cuivre. Lorsque des pressions élevées de gaz doivent être mises en oeuvre, en particulier en oxycoupage, il convient de réduire la imension des tuyères, ce conduit à diminuer le diamètre du passage de gaz de la tuyère, lequel devient souvent inférieur au millimètre.
Or, diminuer ainsi la dimension du passage de traversant axialement tuyère engendre des problèmes de fabrication. effet, pour des raisons liées à l'écoulement gazeux, il est habituellement nécessaire, lors de la fabrication des tuyères, de procéder à des perçages au sein du corps de tuyère dont la longueur peut atteindre 10 fois le diamètre et, pour ce faire, il nécessaire d'utiliser des outils qui s'avèrent particulièrement fragiles, compte tenu des dimensions à atteindre, à savoir un iamètre très faible ( < 1 et une longueur élevée par rapport audit diamètre (jusqu'à 10 mm, voire plus).
De plus, pour garantir un écoulement efficace du dans les passages gaz, il est indispensable que l'état de surface parois de la tuyère soit plus lisse possible, ce qui ne peut pas être gisement obtenu lorsqu'on réalise des perçages de petites dimensions (de l'ordre ou inférieur au millimètre).
De le problème qui se pose alors est de concevoir des pièces d'usure pour torches ou chalumeaux qui soient capables de répondre favorablement aux exigences et contraintes susmentionnées sans toutefois présenter problèmes d'usinage exposés ci-dessus.
En d'autres termes, la présente invention vise à résoudre le problème de la fabrication de tuyères pour torche ou chalumeau pourvues d'un canal ou passage de gaz dont le diamètre interne soit très petit, c'est-à-dire inférieur millimètre, et ayant, en outre, un état de surface paroi interne aussi lisse possible pour permettre un écoulement efficace du gaz.
La presente invention concerne alors une tuyère de torche de travail à l'arc électrique ou de chalumeau formée d'un corps de tuyère traversé par au moins un passage principal de gaz, caractérisée en ce 'au moins un premier tube métallique est inséré coaxialement dans au moins une partie dudit passage principal de gaz.
Selon le cas, la tuyère selon l'invention peut comprendre l'une ou plusieurs des caractéristiques suivantes - la longueur LT, dudit premier tube métallique est inférieure ou égale à la longueur LP dudit passage principal gaz, de préférence la longueur LT, dudit premier tube métallique est comprise entre 4 mm et 30 mm.
- au moins un deuxième tube métallique est inséré coaxiaiement dans au moins une partie dudit passage principal de gaz et coaxialement audit premier tube métallique.
- au moins une partie dudit deuxième tube métallique est positionné concentriquement à au moins une partie dudit premier tube métallique.
- ledit corps de tuyère est formé moins une sous-partie amont et d'au moins une sous-partie aval, fixées idairement l'une à l'autre, de préférence par vissage.
titre d'exemple, nous voulons qu'un module puisse référer uniquement à ses propres classes et aux classes systèmes de la plate-forme API, classes système correspondant aux classes du "CIassPath" d'une plate-forme classique. Selon l'invention, pour permettre la distinction entre une référence à une classe interne au module et la reférence à une classe système (ou externe au module), un indicateur interne 1) ou externe (1E) est ajouté à la référence à une méthode ou à un attribut. référence résolue est alors codée sur trois multiplets : Selon une convention posée, pour la valeur n premier multiplet la valeur 255 d'après notre exemple, correspond à une référence interne au module et toute autre valeur pour premier multiplet correspond à une référence externe au module.
Le lieur du convertisseur (92) de la machine virtuelle hors objet portable (90), relie en premier le module API (65), qui ne possède pas de références externes dans son pseudocode, et produit une implantation ou agencement, correspondant à un plan de noms symboliques de ses classes et de leurs méthodes et attributs. Lors de la mise en liaison des autres modules, cette implantation sera utilisée pour établir les références externes à des classes systèmes du module API (65).
Suivant notre convention des multiplets (bytes) encodant les références, il peut y avoir au plus 256 (n+1) classes dans le module API et 256 classes dans chaque module supplémentaire.