INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Lorsque la lampe à décharge du faisceau principal et la lampe à décharge du faisceau de croisement sont mises simultanément en fonctionnement, la charge du circuit d'éclairage dans le domaine de transition peut être efficacement réduite si la commande réalisée afin que le moment de la puissance maximale fournie à une lampe à décharge soit décalé par rapport moment de la puissance maximale fournie à l'autre. Ainsi, commande est réalisée afin que l'une des lampes à décharge soit mise en fonction nement et que l'autre soit mise fonctionnement avec un petit retard.
Bien que le réglage de puissance soit réalisé pour l'établissement des relations P1 > PlR et P2 dans le domaine de régime permanent des figures 3 et 4 (voir troisième procédé (iii)), on peut aussi utiliser le premier et le second procédé (i) et (ii).
Bien que la situation dans laquelle les deux lampes à décharge sont mises en fonctionnement simultanément ou presque simultanément ait été décrite précédemment, on décrit maintenant, en référence à la figure 5, un exemple de commande dans lequel l'une des lampes ' décharge n'est mise en fonctionnement que lorsque l'autre a déjà été mise en fonctionnement.
Sur la figure 5, un changement cours du temps des puissances fournies P1 et P2 est indiqué. Les abscisses désignent le temps t et les ordonnées puissance P fournie à la lampe à décharge.
Dans cet exemple, P1 désigne une valeur de la puissance fournie à la lampe à décharge du faisceau principal et P2 la valeur de la puissance fournie à la lampe à décharge du faisceau de croisement.
La lampe à décharge du faisceau de croisement a déjà été mise en fonctionnement au temps t = 0. Dans cet état, la lampe à décharge du faisceau principal est mise en fonc- tionnement. La valeur P2 de la puissance fournie à la lampe à décharge du faisceau de croisement peut être réduite progressivement lorsque la lampe à décharge du faisceau principal atteint l'état de régime permanent après éclairage (temps de transition au domaine de régime permanent). Ainsi, la puissance peut être réglée de manière que la valeur P2 soit inférieure à la valeur nominale P2R. La raison en est la suivante. Si la puissance fournie à la lampe à décharge du faisceau de croisement est immédiatement réduite au temps t = 0, l'éclairement peut ne pas être suffisamment conservé avant que la lampe à décharge du faisceau principal ne soit stabilisée, et un changement du faisceau de croisement peut avoir un effet négatif sur les autres conducteurs décrit dans la suite une structure selon l'inven- tion.
figure 6 représente un exemple de structure de circuit dans un mode de réalisation de l'invention, compre- nant circuit d'éclairage qui peut effectuer simultanément le réglage de l'éclairage d'une lampe à décharge d'un faisceau principal et d'une lampe à décharge d' faisceau de croisement.
Le circuit d'éclairage constituant l'appareil 1 à lampes à décharge pour véhicule comprend une alimentation 2 (batterie d'accumulateurs), un circuit d'alimentation en courant continu 3, un circuit convertisseur continu-alter- natif 4 et un circuit d'amorçage 5 (5 _1 et (5 2) circuit d'alimentation en courant continu 3 est réalisé à l'aide de deux convertisseurs continus -continus 3A et 3B par exemple, et il est partagé par deux lampes à décharge 6 1 et 6 2. Le circuit d'alimentation en courant continu 3 transmet une tension continue prédéterminée après réception d'une tension continue d'entrée (désignée dans la suite par Vin) appliquée par l'alimentation 2, et une tension de sortie du circuit est réglée de manière variable par signal de commande transmis par un circuit de commande décrit dans la suite. Un convertisseur continu- continu (du type à découpeur ou électronique) a la structure d'un régulateur de commutation utilisé pour le circuit d'alimentation en courant continu 3. Une première section de circui (convertisseur continu-continu 3A) destinée à obte- nir une tension de sortie de polarité positive (tension positive de sortie) et une seconde section circuit (convertisseur continu-continu 3B) destinée à obtenir une tension de sortie de polarité négative (tension négative de sortie) sont disposées en parallèle. Un circuit convertisseur continu- alternatif 4 est placé dans un étage qui suit le circuit d'alimentation en courant continu 3 et a pour rôle de transformer la tension de sortie de ce dernier en une tension alternative, et à transmettre la tension alternative à la lampe à décharge En consé- quence, tensions de polarités positive et negative sont transmises par les bornes de sortie du circuit d'ali- mentation courant continu 3. Le circuit 4 a structure d'un pont complet comprenant quatre éléments de commutation sw1, sw2, sw3 et sw4 (pour lesquels on utilise élément de commutation à semi-conducteur, tel qu'un transistor à effet de champ, et qui est simplement indiqué par un symbole de commutateur sur le dessin).
Plus précisément, les éléments de commutation swl et sw2 sont connectés mutuellement en série et forment une première paire. Une première des extrémités de l'élément de commutation swl est connectée à la borne de sortie du convertisseur continu-continu 3A, et l'autre extrémité de l'élément de commutation swl est connectée à la borne de sortie du convertisseur continu-continu 3B l'intermé- diaire de l'élément de commutation sw2. Une première lampe à décharge 6-1 est connectée à un point a connexion des deux éléments de commutation par l'intermédiaire du circuit d'amorçage 5-1 (ou plutôt de sa charge inductive).
En outre, les éléments de commutation sw3 et sw4 sont connectés mutuellement en série et forment une seconde paire. Une première des extrémités de l'élément de commu- tation sw3 est connectée à la borne de sortie du conver- tisseur continu-continu 3A, et l'autre extrémité de l'élé- ment sw3 de commutation est connectée à la borne de sortie du convertisseur continu-continu 3B par l'intermédiaire de l'élément de commutation sw4. Une seconde lampe à décharge 6_2 est connectée à un point de connexion P des deux élé- ments de commutation par l'intermédiaire du circuit d'amor- çage 5_2 (ou plutôt de sa charge inductive).
Dans l'étage qui suit le circuit de conversion continu- alternatif 4, l'une quelconque des bornes de la première et de la seconde lampe à décharge qui est connectée aux points de connexion a et (3 est directement connectée à une masse ou est connectée à la masse par l'intermédiaire du dispositif de détection de courant (indiqué par des résistances Ril et Rit destinées à détecter le courant, comme indique sur le dessin) circuit intégré d'un organe de pilotage en -pont est utilisé pour les circuits de pilotage DRV1 et DRV2. Le circuit de pilotage DRV1 effectue la commande tout ou rien des éléments de commutation swl et sw2, et le circuit de pilotage DRV2 effectue la commande par tout ou rien des éléments de commutation sw3 et sw4. Plus précisément, si l'état de chaque élément est défini afin que l'élément de commutation swl soit mis à l'état conducteur et l'élément de commutation sw2 soit mis à l'état non conducteur par le circuit de pilotage DRV1 à un certain moment, l'état de chaque élément est défini de manière que l'élément de commutation sw3 soit mis à l'état non conducteur et l'élément de commutation sw4 soit mis à l'état conducteur par le circuit de pilotage DRV2 à ce moment. Si l'état de chaque elément est défini afin que l'élément de commutation swl soit mis à l'état non conducteur et l'élément de commu- tation à l'état conducteur par le circuit de pilotage DRV1 à un autre moment, l'état de chaque élément est défini afin que l'élément de commutation sw3 soit mis à l'état conducteur et l'élément de commutation sw4 soit mis à l'état non conducteur par le circuit de pilotage DRV2 à ce moment. Ainsi, les éléments de pilotage swl et sw4 sont au même état et les éléments de commutation sw2 et sw3 sont mis au même état, et ils exécutent une opération alternative de manière réciproque.
Ainsi, lorsqu'une tension de polarité positive est transmise à la première lampe à décharge 6 1 commande par tout ou rien des deux ensembles d'éléments de commu- tation, par exemple, une tension de polarité négative est appliquée à la seconde lampe à décharge 6 2. Au contraire, lorsqu'une tension de polarité négative est transmise à la première lampe à décharge 6-1, une tension de polarité positive est appliquée à la seconde lampe à décharge 6-2. Dans le circuit d'éclairage d'une première lampe à décharge (c'est-à-dire un circuit représenté sur la figure 6 et utilisé comme circuit d'éclairage pour la mise en fonc- tionnement de la première lampe à décharge 6-1 par exemple), les éléments de commutation swl et sw2 et le circuit de pilotage DRV1 peuvent constituer un circuit de conversion continu-alternatif, si bien que la partie liée à la seconde lampe à décharge 6 2 est supprimée.
On se réfère maintenant aux circuits amorçage 5-1 et 5-2 ; il est préférable qu'un circuit soit partagé par les deux lampes à décharge 6 1 et 6 2 au lieu d'utiliser des circuits d'amorçage 5-1 et 5-2 sous forme de circuits sépa- rés, si bien que le nombre d'éléments et le coût sont réduits exemples de détection d'une tension et d'un courant des lampes à décharge 6_1 et 6_2 comprennent les procédés suivants un procédé de détection d'une tension de tube de la lampe à décharge et d'un courant de tube de cette lampe dans un étage qui suit le circuit de conversion continu- alternatif, et un procédé de détection d'un signal qui correspond à la tension du tube et au courant du tube de la lampe à décharge exemples du procédé (a) comprennent un procédé de connexion de résistances (Ril, Rit) de détection de courant à la lampe à décharge et la conversion du courant qui circule en une tension qui peut être saisie.
Vis-à-vis de la deuxième solution, la troisième solution présente l'avantage d'une exécution des appliquettes beaucoup plus rapide, puisque la machine virtuelle n'effectue aucune vérification pendant l'exécution.
La troisième solution présente toutefois l'inconvénient d'un processus de vérification statique du code complexe et coûteux, tant en taille de code nécessaire pour conduire ce processus, qu'en taille de mémoire vive nécessaire pour contenir les résultats intermédiaires de la vérification, et qu'en temps de calcul. A titre d'exemple illustratif, la vérification de code intégré dans le système Java JDK commercialisé par SUN MICROSYSTEMS représente de l'ordre de 50 k-octets de code machine, et sa consommation en mémoire vive est proportionnelle à (Tp + Tr) xNb où Tp désigne l'espace maximum de pile, Tr désigne le nombre maximum de registres et Nb désigne le nombre maximum de cibles de branchements utilisées par un sous-programme, encore communément désigné par méthode, de l'appliquette Ces besoins en mémoire dépassent largement les capacités des ressources de la majorité des systèmes informatiques embarqués actuels, notamment des cartes à microprocesseur commercialement disponibles.
Plusieurs variantes de la troisième solution ont été proposées, dans lesquelles l'éditeur de l'appliquette transmet au vérificateur, outre le code de l'appliquette, un certain nombre d'informations supplémentaires spécifiques telles que types de données précalculés ou preuve préétablie de typage de données correct. Pour une description plus détaillée des modes opératoires
correspondants, on pourra utilement se reporter aux articles publiés par Eva ROSE et Kristoffer H0GSBRO ROSE, "Lightweight Bytecode Verification", Actes du Workshop Formai Underspinning of Java, Octobre 1998, et par George C. NECULA, "Proof-Carrying Code", Actes du 24e ACM Symposium Principles of Programming Languages, pages 106-119 respectivement.
Ces informations supplémentaires permettent de vérifier le code plus rapidement et de réduire légèrement la taille du code du programme de vérification mais ne permettent toutefois pas de réduire les besoins en mémoire vive, voire les augmentent, de manière très importante, dans le cas des informations de preuve préétablie de typage de données correct.
La présente invention a pour objet de remédier aux inconvénients précités de l'art antérieur.
En particulier, un objet de la présente invention est la mise en #uvre d'un protocole de gestion d'un fragment de programme, ou appliquette, téléchargé permettant une exécution sur de ce dernier par un système informatique embarqué disposant de faibles ressources, tel qu'une carte à microprocesseur.
Un autre objet de la présente invention est également la mise en #uvre d'un procédé de vérification d'un fragment de programme, ou appliquette, téléchargé dans lequel un processus de vérification statique du code de l'appliquette est conduit lors de son téléchargement, ce processus pouvant être rapproché, au moins dans son principe, de la troisième solution précédemment décrite, mais dans lequel des techniques nouvelles de vérification sont introduites, afin de permettre l'exécution de cette
vérification dans les limites de valeurs de taille mémoire et de vitesse de calcul imposées par les cartes à microprocesseur et autres systèmes informatiques embarqués peu puissants.
Un autre objet de la présente invention est également la mise en #uvre de procédés de transformation de fragments de programmes de type classique obtenus par exemple par la mise en #uvre d'un compilateur Java en fragments de programmes, ou appliquettes, normalisés, satisfaisant a priori aux critères de vérification du procédé de vérification objet de l'invention, en vue d'accélérer le processus de vérification et d'exécution de ces derniers au niveau des systèmes informatiques embarqués ou cartes à microprocesseur actuels.
Un autre objet de la présente invention est, enfin, la réalisation de systèmes informatiques embarqués permettant la mise en #uvre du protocole de gestion et du procédé de vérification d'un fragment de programme téléchargé précités ainsi que de systèmes informatiques permettant la mise en #uvre des procédés de transformation de fragments de programmes, ou appliquettes, classiques en fragments de programmes, ou appliquettes, normalisés précités.
Le protocole de gestion d'un fragment de programme téléchargé sur un système embarqué reprogrammable, objet de la présente invention, s'applique notamment à une carte à microprocesseur munie d'une mémoire réinscriptible. Le fragment de programme est constitué par un code objet, suite d'instructions, exécutable par le microprocesseur du système embarqué par l'intermédiaire d'une machine virtuelle munie d'une pile d'exécution et de registres ou
variables locales manipulées par ces instructions et permettant d'interpréter ce code objet. Le système embarqué est interconnecté à un terminal.
Il est remarquable en ce qu'il consiste au moins, au niveau du système embarqué, à détecter une commande de téléchargement du fragment de programme. Sur réponse positive à l'étape consistant à détecter une commande de téléchargement, il consiste en outre à lire le code objet constitutif du fragment de programme et à mémoriser temporairement ce code objet dans la mémoire réinscriptible. L'ensemble du code objet mémorisé est soumis à un processus de vérification instruction par instruction. Le processus de vérification consiste au moins en une étape d'initialisation de la pile des types et du tableau des types de registres représentant l'état de la machine virtuelle au début de l'exécution du code objet mémorisé temporairement et en une succession d'étapes de vérification instruction par instruction de l'existence, pour chaque instruction courante, d'une cible, cible d'instruction de branchement, cible d'un gestionnaire d'exceptions, et en une vérification et une actualisation de l'effet de l'instruction courante sur la pile des types et sur le tableau des types de registres.
Dans le cas d'une vérification non réussie du code objet, le protocole objet de l'invention consiste à effacer le fragment de programme enregistré momentanément, en l'absence d'enregistrement de ce dernier dans le répertoire de fragments de programmes disponibles, et à adresser au lecteur un code d'erreur.
Le procédé de vérification d'un fragment de programme téléchargé sur un système embarqué, objet de
En reprenant l'exemple introduit au tableau T6, le procédé de transformation détecte une cible de branchement
où la pile n'est pas vide au niveau de l'instruction 9. Il est donc procédé à l'insertion d'une instruction istore 1 avant l'instruction de branchement 5 qui mène à l'instruction 9 précitée afin de sauvegarder le contenu de la pile dans le registre 1 et d'assurer que la pile est vide lors du branchement. Symétriquement, l'insertion d'une instruction iload 1 est effectuée préalablement à la cible d'instruction 9 pour rétablir le contenu de la pile identiquement à ce qu'il était avant le branchement.
Finalement, une instruction istore 1 est insérée après l'instruction 8 pour garantir l'équilibre de la pile sur les deux chemins qui mènent à l'instruction 9. Le résultat de la transformation ainsi opérée en un code normalisé est représenté au tableau T7.
Le deuxième mode de réalisation du procédé de transformation objet de la présente invention sera maintenant décrit en liaison avec la figure 4b dans le cas où le code objet classique de départ satisfait aux critères Cl+C'4 et le code objet normalisé satisfait aux critères Cl+C4.
En référence à la figure 4b précitée, on indique que le procédé, dans ce mode de réalisation, consiste à annoter, selon une étape 500 sensiblement identique à celle représentée en figure 4a, chaque instruction courante Il par le type de données des registres avant et après l'exécution de cette instruction. De la même manière, les données d'annotations AIi sont calculées au moyen d'une analyse du flot des données relatif à cette instruction.
L'étape d'annotation 500 est alors suivie d'une étape consistant à effectuer une réallocation des
registres, étape notée 601, par détection des registres d'origine employés avec des types différents, division de ces registres d'origine en registres normalisés distincts, un registre normalisé étant alloué à chaque type de données utilisé. L'étape 601 est suivie d'une étape 602 de réactualisation des instructions qui manipulent les opérandes qui font appel aux registres normalisés précités. L'étape 602 est suivie d'une étape de suite de contexte 302.
En référence à l'exemple donné au tableau T6, on indique que le procédé de transformation détecte que le registre de rang 0, noté rO, est utilisé avec les deux types object, instructions 0 et 1, et int, instruction 9 et suivantes. Il est alors procédé à une division du registre d'origine rO en deux registres, le registre 0 pour l'utilisation des types object et le registre 1 pour les utilisations de type int. Les références au registre 0 de type int sont alors réécrites en les transformant en des références au registre 1, le code normalisé obtenu étant introduit au tableau T8 joint en annexe.
On note de manière non limitative que dans l'exemple introduit en liaison avec le tableau T8 précité, le nouveau registre 1 est utilisé à la fois pour la normalisation de la pile et pour la création de registres typés par division du registre 0 en deux registres.
Le procédé de transformation d'un code classique en un code normalisé à instruction de branchement à pile vide tel que décrit en figure 4a sera maintenant décrit de manière plus détaillée dans un mode de réalisation préférentiel non limitatif, en relation avec la figure 5a.
Ce mode de réalisation concerne l'étape 501 consistant à détecter au sein des instructions et de chaque instruction courante Il l'existence de branchement IB respectivement de cible de branchement CIB pour laquelle la pile n'est pas vide.
Suite à la détermination des instructions cible où la pile n'est pas vide, cette condition étant notée à l'étape 504a, Ii pilevide, le processus de transformation consiste à associer, à l'étape 504a précitée, à ces instructions un ensemble de nouveaux registres, un par emplacement de pile actif au niveau de ces instructions.
Ainsi, si i désigne le rang d'une cible de branchement dont le type de pile associée n'est pas vide et est du type tpli à tpni avec n > 0, pile non vide, le processus de transformation alloue n nouveau registres, ri à rn non encore utilisés et les associe à l'instruction i correspondante. Cette opération est réalisée à l'étape 504a.
L'étape 504a est suivie d'une étape 504 consistant à examiner chaque instruction détectée de rang i et à discriminer en une étape de test 504 l'existence d'une cible de branchement CIB ou d'un branchement IB. L'étape 504 est représentée sous forme d'un test désigné par : 3?CIB,IB et I,=CIB.
Dans le cas où l'instruction de rang i est une cible de branchement CIB représentée par l'égalité précédente, et que la pile des variables de pile au niveau de cette instruction n'est pas vide, c'est-à-dire en réponse positive au test 504, pour toute instruction précédente de rang i-1 constituée par un branchement, une levée d'exceptions ou un retour de programme, cette
condition est réalisée à l'étape de test 505 désignée par : Ii-1 = IB, levée EXCEPT, retour Prog.
être transformé en un code équivalent susceptible de passer avec succès la vérification de code effectuée sur la carte à microprocesseur.
Alors qu'il est possible d'envisager l'écriture directe de codes Java satisfaisant aux critères de vérification précédemment mentionnés dans le cadre de la mise en #uvre du protocole objet de la présente invention, un objet remarquable de celle-ci est également la mise en #uvre d'un procédé de transformation automatique de tout code Java standard en un code normalisé pour le même fragment de programme satisfaisant nécessairement aux critères de vérification mis en #uvre précédemment cités.
Le procédé de transformation en code normalisé et le système correspondant seront décrits ultérieurement dans la description de manière détaillée.
Une description plus détaillée du procédé de vérification d'un fragment de programme, ou appliquette, conforme à l'objet de la présente invention, sera maintenant donnée en liaison avec la figure 3a et les figures suivantes.
D'une manière générale, on indique que le procédé de vérification objet de la présente invention peut être mis en #uvre soit dans le cadre du protocole de gestion d'un fragment de programme objet de l'invention précédemment décrit en liaison avec la figure 2, soit de manière indépendante, afin d'assurer tout processus de vérification jugé nécessaire.
D'une manière générale, on indique qu'un fragment de programme est constitué par un code objet comportant au moins un sous-programme, plus communément désigné par méthode, et constitué par une suite d'instructions
exécutables par le microprocesseur du système embarqué par l'intermédiaire de la machine virtuelle.
Ainsi que représenté sur la figure 3a, le procédé de vérification consiste, pour chaque sous-programme, à effectuer une étape 200 d'initialisation de la pile des types et du tableau des types de registres de la machine virtuelle par des données représentant l'état de cette machine virtuelle au début de l'exécution du code objet, objet de la vérification. Ce code objet peut être mémorisé temporairement ainsi que décrit précédemment en liaison avec la mise en #uvre du protocole objet de la présente invention.
L'étape 200 précitée est alors suivie d'une étape 200a consistant à positionner la lecture de l'instruction courante Ii, index i, sur la première instruction du code objet. L'étape 200a est suivie d'une étape 201 consistant à effectuer une vérification du code objet précité instruction par instruction, par discrimination pour chaque instruction courante notée Ii de l'existence d'une cible d'instruction de branchement CIB, d'une cible d'un appel de gestionnaire d'exceptions, noté CEM, ou d'une cible d'un appel de sous-routine CSR.
L'étape de vérification 201 est suivie d'une étape de vérification 202 et d'actualisation de l'effet de l'instruction courante Ii sur les types de données de la pile des types et du tableau des types de registres en fonction de l'existence, pour l'instruction courante visée par une autre instruction, d'une cible d'instruction de branchement CIB, d'une cible d'un appel de sous-routine CSR ou d'une cible d'un appel de gestionnaire d'exceptions CEM.