EP1433031A1 - Procede d'organisation et d'execution d'une pluralite de prestations, notamment dans un vehicule automobile - Google Patents

Procede d'organisation et d'execution d'une pluralite de prestations, notamment dans un vehicule automobile

Info

Publication number
EP1433031A1
EP1433031A1 EP02783158A EP02783158A EP1433031A1 EP 1433031 A1 EP1433031 A1 EP 1433031A1 EP 02783158 A EP02783158 A EP 02783158A EP 02783158 A EP02783158 A EP 02783158A EP 1433031 A1 EP1433031 A1 EP 1433031A1
Authority
EP
European Patent Office
Prior art keywords
context
request
state
organizing
service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP02783158A
Other languages
German (de)
English (en)
Inventor
Samuel Boutin
Hugo Chale Gongora
Azim Panday
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Renault SAS
Original Assignee
Renault SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Renault SAS filed Critical Renault SAS
Publication of EP1433031A1 publication Critical patent/EP1433031A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/23—Pc programming
    • G05B2219/23006—Finite state modeling
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/23—Pc programming
    • G05B2219/23289—State logic control, finite state, tasks, machine, fsm

Definitions

  • the present invention relates to a method of organizing and carrying out a plurality of services, in particular in a motor vehicle.
  • Document WO 99/56201 discloses a method for reprogramming a system forming part of a motor vehicle (internal combustion engine, electric motor, braking system, etc.) or of a system linked to a user of said system. vehicle (mobile phone, navigation system, radio receiver, etc.). Such reprogramming may be necessary to ensure the execution of a service such as, for example, the adjustment of the operation of the engine, after a certain operating time, or the updating of the list of telephone numbers. saved in the mobile phone.
  • a service such as, for example, the adjustment of the operation of the engine, after a certain operating time, or the updating of the list of telephone numbers. saved in the mobile phone.
  • the method described designed to ensure reprogramming accessible only to authorized persons or entities, performs such reprogramming, or programming of a new function, by means of the downloading into a microcontroller of a compiled code for executing a complete software capable of ensuring this reprogramming or of performing this new function.
  • the loading of such a complete software obviously takes place with a high flow of information. It is therefore disadvantageously cumbersome to implement.
  • the object of the present invention is to produce an automaton from a plurality of use cases defining a service. Furthermore, the invention also aims to allow the reprogramming of services, specific to a motor vehicle for example, by modification of already installed services, or addition of new services, this reprogramming does not require knowledge of the architecture of the microcontroller used for execution benefits . It is then much lighter and is executed by means of a transfer of information at low speed, by comparison with that required by the method described in the aforementioned patent.
  • FIG. 1 is a graphic representation of an automaton corresponding to the implementation of the FIG. 2 is a graphical representation of another automaton corresponding to the implementation of the present invention of a particular service in different contexts
  • FIG. 3 is a functional diagram of an automaton of the type represented in FIG. 2 adapted, by way of example, to control the air conditioning of the passenger compartment of a motor vehicle, according to the method according to invention.
  • a motor vehicle normally comprises a plurality of physical systems: propulsion engine, braking, suspension, heating, air conditioning, communications, etc. devices used by the driver of the vehicle to obtain various "services".
  • the method according to the invention consists in formalizing the cases in which the driver uses each of the systems. To this end, for each of these "use cases", a “context” of operation is defined, the “request” from the driver and the “reaction” of the system to such a request, issued in said context.
  • a "context” of operation is defined, the "request” from the driver and the “reaction” of the system to such a request, issued in said context.
  • the context of use may consist of information from the environment: temperature of the passenger compartment, vehicle speed, driving condition (outside temperature, presence of rain, etc.). This information is detectable using appropriate sensors, or can be calculated.
  • the context may also take into account information produced during previous reactions during the implementation of the service.
  • the driver's requests are actions by the driver on organs or interfaces (button, keyboard, voice recognition device for a word, etc.) which allow him to call or modify one of the services offered by the vehicle). Requests can be implicit when the driver is not in control of the situation, such as putting yourself in an accident situation is a request for which the driver is not responsible.
  • the reactions of the system are facts which activate the services themselves: activation of windscreen wipers, activation of a flashing light, display of an icon on a screen, etc. Formalization of cases according to the invention, the usage is supplemented by timeout information indicating within which time a reaction must be implemented and under what time a context or a request must be taken into account.
  • the identified use cases can be combined into services independent of each other
  • a first service is taken into account.
  • a second step for the service considered, we identify the contexts of the CAi automaton which each represent a set of values of vehicle parameters which are not affected by the service but which affect the service, for example, the stopped or running state of the engine is not affected by the air conditioning service but affects it.
  • a state Ei is defined for each response i j of the use case CUj j such that, by definition, when we access Ei j , we execute Ri j .
  • an iterative process begins which stops when an iteration no longer adds a transition to the automaton.
  • the context represents at least one mode of operation of the system, the modes being transversal to the services and outside of direct control of the services, for example a mode representing a level of available energy. and / or a type of user of the system and or an accident or not condition of a vehicle.
  • the context may represent a context of the system automaton, consisting of a set of combinations of vehicle operating modes, the contexts of automata thus being transversal to the services, the use cases representing all the responses or absence of response from the system in all PLC contexts, these representing together all the combinations of vehicle operating modes.
  • a change in the context of the PLC will have higher priority than a formal request.
  • a request to change context PLC and a simple request from the driver appear in parallel, we preferably deal with the change of context of the PLC, then the formalized request.
  • Two changes of PLC context cannot happen simultaneously, by definition (for example, the abovementioned "motor running” and "motor stopped” PLC contexts obviously cannot coexist).
  • FIG. 1 constitutes a graphic representation of this automaton, in the case where the preliminary study made it possible to identify a single context of automaton Co, two requests Di and D 2 and 5 possible reactions (Ri to R 5 ).
  • the different states (Ci, R k ) are represented by circles and the transitions between states on request Di or D 2 / by arrows in solid line. This is how, for example, we pass from the state (C 0 , R 2 ) to the state (C 0 , R 4 ) by the request D x and from this latter state to the state (C 0 , R 5 ) by request D 2 .
  • the different contexts, requests and reactions identified can be saved in various predetermined locations of RAM memories in the form of a boolean set to "1", for example to signal the existence of such or such context of PLC or request, or. to produce this or that reaction.
  • a suitable computer such as a duly programmed microcontroller, or hardware means such as a wired or printed circuit, make it possible to materialize the automaton used in the present invention.
  • FIG. 2 of the appended drawing in which the structure of an automatic machine suitable for implementing a particular service has been represented graphically, in different contexts of automatic systems Ci, C 2 and C 3 .
  • Requests Di, D 2 make it possible to control, depending on the context of the automaton, transitions to states characterized by reactions Ri, R 2 or R 3 .
  • the R 3 block details, by way of example, the reactions activated in the state (Ci, R 3 ): capture of values, quantities, execution of different functions, various commands, etc.
  • cl, c2, c3 we gathered the states identified in the contexts of automata Ci, C 2 and C 3 respectively.
  • the arrows in solid lines illustrate the transitions between states controlled by requests Di or D 2 , formulated by the driver of the vehicle.
  • the uni- or bidirectional arrows in broken lines illustrate transitions between the context of automata. This is how a request D, formulated from a state (Ci, R 3 ) commands a transition to the state (Ci, R 2 ).
  • the automaton allowing the execution of the particular service in question having been defined (as illustrated by figure 2), it remains to code and to load in RAM memory said automaton, as indicated above.
  • a request monitor constantly observes the state of the booleans representing these requests. The transitions between states resulting from these requests and conditions determine the activation of sensors, organs, functions or commands allowing the execution of the requested service, in any of the states identified during the analysis of this service.
  • the service analyzed is the air conditioning control of the passenger compartment of a motor vehicle. It is described by a set of CUs such as: a) in the context where the engine is running, the client requests air conditioning, the response of which is to switch on the air conditioning and the signaling of this switching on b) in the context where the engine is stopped and the customer requests air conditioning, nothing happens At first analysis this command can be illustrated by two blocks cl and c2 corresponding to the context of automata Ci and C 2 in which the engine propelling the vehicle is rotating, or stopped, respectively.
  • the state (Ci, R) corresponds to "air conditioning requested" on request Di.
  • the reaction R 2 is then constituted by the lighting of an LED diode on the dashboard to confirm to the driver the activation of the air conditioning by the activation of a refrigerant compressor and its regulation, in order to reach a predetermined passenger compartment temperature displayed by the driver, and possibly by a request for additional torque from the engine, to avoid torque surges, etc.
  • this additional capacity for activating the air conditioning of the unoccupied vehicle can be easily added to the automaton by loading or downloading a few additional digital identifiers, those corresponding to C 3 and R 3 / therefore at low information rate.
  • the RAM memory storing the "value tables" corresponding to the "air conditioning" service.
  • the invention makes it possible to achieve one of the goals set, namely to provide a method of organization and execution of services designed to allow modifications of the services, or additions of new services, for simple additions to the initial programming. Thanks to the use of an automaton executing the "intermediate" language described above, the architecture of the microcontroller hosting the automaton does not have to be taken into account when these modifications or new services are introduced. . This introduction is obtained by means of a light download of additional instructions, at low speed, and not by fully recharging the modified or added services, as known from the prior art, heavy recharging and at high speed.
  • the invention is not limited to the "air conditioning" application described above and extends, on the contrary, to any other application that one may have to implement in the environment of a motor vehicle such as, for example: the door opening / closing control,
  • the invention is also not limited to the evolution of an existing service and also extends, as indicated above, to the addition of a new service.
  • the invention further extends to applications taking into account requests other than those originating from the driver of the vehicle.
  • requests other than those originating from the driver of the vehicle.
  • the exceeding of a certain age or a certain mileage by this vehicle could automatically trigger actions of calibration or adjustment of the engine, justified by its age or its state of wear.
  • the invention also extends to the organization and execution of services in an environment other than the automobile.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Fittings On The Vehicle Exterior For Carrying Loads, And Devices For Holding Or Mounting Articles (AREA)
  • Testing And Monitoring For Control Systems (AREA)
  • Air-Conditioning For Vehicles (AREA)

Abstract

Suivant le procédé, a) on définit une pluralité de cas d'utilisation (CU) pour chacun desquels, dans un contexte (Ci) une demande (Dj) appelle une réaction (Rk) réalisant une prestation particulière, et b) on active sélectivement ladite réaction, sur détection de l'émission de ladite demande (Dj) dans ledit contexte (Ci) .

Description

Procédé d'organisation et d'exécution d'une pluralité de prestations, notamment dans un véhicule automobile. La présente invention est relative à un procédé d'organisation et d'exécution d'une pluralité de prestations, notamment dans un véhicule automobile.
On connaît du document WO 99/56201 un procédé de reprogrammation d'un système formant partie d'un véhicule automobile (moteur à combustion interne, moteur électrique, système de freinage, etc..) ou d'un système lié à un utilisateur dudit véhicule (téléphone portable, système de navigation, récepteur radio, etc..) . Une telle reprogrammation peut être nécessaire pour assurer l'exécution d'une -prestation telle que, par exemple, -le réglage du fonctionnement du moteur, après un certain temps de fonctionnement, ou la mise à jour de la liste des numéros d'appel enregistrés dans le téléphone portable. Le procédé décrit, conçu pour assurer une reprogrammation accessible aux seules personnes ou entités autorisées, exécute une telle reprogrammation, ou une programmation d'une nouvelle fonction, par le moyen du téléchargement dans un microcontrôleur d'un code compilé d'exécution d'un logiciel complet capable d'assurer cette reprogrammation ou d'exécuter cette nouvelle fonction. Le chargement d'un tel logiciel complet s'opère évidemment avec un fort débit d'informations. Il est donc désavantageusement lourd à mettre en œuvre .
La présente invention a pour but de réaliser un automate à partir d'une pluralité de cas d'utilisation définissant une prestation. Par ailleurs l'invention a aussi pour but de permettre la reprogrammation de prestations, propres à un véhicule automobile par exemple, par modification de prestations déjà installées, ou additions de nouvelles prestations, cette reprogrammation n'exigeant pas la connaissance de l'architecture du microcontrôleur utilisé pour l'exécution des prestations . Elle est alors beaucoup plus légère et s'exécute au moyen d'un transfert d'informations à faible débit, par comparaison avec celui exigé par le procédé décrit dans le brevet précité. On atteint ce but de l'invention, ainsi que d'autres qui apparaîtront à la lecture de la description qui va suivre, avec un procédé d'organisation et d'exécution d'une pluralité de prestations, notamment dans un véhicule automobile, ce procédé étant remarquable en ce que a) on définit une pluralité de cas d'utilisation (CU) pour chacun desquels, dans un contexte (Ci) une demande (Dj) appelle une réaction (Rk) réalisant une prestation particulière, et b) on active sélectivement ladite réaction, sur détection de l'émission de ladite demande (Dj) dans ledit contexte (Ci) .
Comme on le verra plus loin en détail, ce procédé permet, au prix d'une analyse préalable fine de l'architecture à donner au logiciel d'exécution des prestations en cause, de modifier ultérieurement ces prestations, ou d'en ajouter de nouvelles, au moyen d'un chargement d'informations à débit beaucoup plus faible que dans le cas du procédé décrit dans le document WO 99/56201 précité, la mise en œuvre d'un tel chargement étant alors beaucoup plus aisé. D'autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre et à 1 ' examen du dessin annexé dans lequel : la figure 1 est une représentation graphique d'un automate correspondant à la mise en œuvre de la présente invention, la figure 2 est une représentation graphique d'un autre automate correspondant à la mise en œuvre de la présente invention d'une prestation particulière dans différents contextes, et la figure 3 est un diagramme fonctionnel d'un automate du type de celui représenté à la figure 2 adapté, à titre d'exemple, à la commande de la climatisation de l'habitacle d'un véhicule automobile, selon le procédé suivant l'invention.
Un véhicule automobile comprend normalement une pluralité de systèmes physiques : moteur de propulsion, dispositifs de freinage, de suspension, de chauffage, de climatisation, de communications, etc.. utilisés par le conducteur du véhicule pour obtenir diverses "prestations". Dans un premier temps le procédé suivant 1 ' invention consiste à formaliser les cas dans lesquels le conducteur utilise chacun des systèmes. A cet effet, pour chacun de ces "cas d'utilisation", on définit un "contexte" de fonctionnement, la "demande" du conducteur et la "réaction" du système à une telle demande, émise dans ledit contexte. A titre d'exemple illustratif et non limitatif :
1) le contexte d'utilisation peut être constitué d ' informations provenant de 1 ' environnement : température de l'habitacle, vitesse du véhicule, condition de roulage (température extérieure, présence d'une pluie, etc..) . Ces informations sont détectables à 1 ' aide de capteurs appropriés, ou bien calculables.
Le contexte peut aussi tenir compte d'informations produites lors de réactions antérieures lors de la mise en œuvre de la prestation.
2) les demandes du conducteur sont des actions de celui-ci sur des organes ou interfaces (bouton, clavier, dispositif de reconnaissance vocale d'un mot, etc..) qui lui permettent d'appeler ou de modifier l'une des prestations offertes par le véhicule) . Les demandes peuvent être implicites lorsque le conducteur n'est pas maître de la situation, comme par exemple se mettre en situation d'accident est une demande dont le conducteur n'est pas responsable. 3) les réactions du système sont des faits qui activent les prestations elle-mê es : mise en marche d' essuies-glace, activation d'un feu clignotant, affichage d'une icône sur un écran, etc.. La formalisation des cas d'utilisation est, suivant l'invention, complétée par une information de temporisation indiquant sous quel délai une réaction doit être mise en œuvre et sous quel délai un contexte ou une demande doit être prise en compte. A titre d'exemple de cas d'utilisation ainsi définis, on peut citer le suivant : pour n'importe quelle valeur des paramètres véhicules, une "demande" du conducteur constituée par l'enfoncement du bouton "feux de détresse", demande qui doit être prise en compte, appelle une "réaction" constituée par l'allumage de quatre clignotants, avec une fréquence de répétition de 2 Hz.
On établit ainsi trois listes de contextes, de demandes et de réactions formalisés.
Les cas d'utilisation (CU) identifiés peuvent être réunis en prestations indépendantes les unes des autres
(telles que, par exemples, l'essuyage des vitres et le fonctionnement d'un dispositif d'éclairage), éventuellement activées en parallèle. Dans la suite on décrira seulement l'organisation suivant l'invention d'une seule prestation, les autres prestations étant organisées de même.
"Pour définir l'automate correspondant à toutes les prestations, les étapes suivantes sont effectués. Au cours d'une première étape, compte une première prestation est prise en compte. Au cours d'une seconde étape, pour la prestation considérée, on identifie les contextes de l'automate CAi qui représent, chacun, un ensemble de valeurs de paramètres du véhicule qui ne sont pas affectées par la prestation mais qui affectent la prestation. Par exemple, l'état arrêté ou tournant du moteur n'est pas affecté par la prestation climatisation mais l'affecte. Au cours d'une troisième étape, pour chaque contexte d'automate CAi et pour chaque cas d'utilisation CUj, dont le contexte correspond à CAi, on définit, pour chaque réponse ij du cas d'utilisation CUj, un état Eij tel que, par définition, quand on accède à Eij, on exécute Rij .
Au cours d'une quatrième étape, on entame un processus itératif qui s'arrête lorsque une itération n'ajoute plus de transition à l'automate .
Au cours de chaque itération de ce processus itératif, pour chaque cas d'utilisation CUj on effectue les étapes suivantes : identification des couples (CAi, Ejk) compatibles avec le contexte du cas d'utilisation CUj,
Création, dans l'automate, pour chacun de ces couples (CAi, Ejk) , de la transition qui mène de (CAi, Ejk) à
(CAj, Eij) par la demande Di du cas d'utilisation CUj, Eij étant un état réalisant la réponse du cas d'utilisation
CUj, et si l'état Eij n'existe pas déjà, ajout dans le contexte d'automate Caj,
-Retour à la condition d'arrêt au début de 1 ' itération.
Enfin, on retourne à l'a seconde étape, pour une autre prestation qui n'a pas encore été traitée.
Si, au cours d'une nouvelle étape, on ajoute un cas d'utilisation à une prestation, on reproduit la troisième étape et les suivantes, si le nouveau cas d'utilisation induit une nouvelle réponse. Sinon, on passe à la quatrième étape.
On note que le contexte représente au moins un mode de fonctionnement du système, les modes étant transversaux aux prestations et hors du contrôle direct des prestations, par exemple un mode représentant un niveau d'énergie disponible et/ou un type d'utilisateur du système et ou un état accidenté ou non d'un véhicule.
En particulier, le contexte peut représenter un contexte d'automate du système, constituée d'un ensemble de combinaison des modes de fonctionnement du véhicule, les contextes d'automates étant ainsi transversaux aux prestations, les cas d'utilisation représentant toutes les réponses ou absences de réponse du système dans tous les contextes d'automate, ceux-ci représentant, ensemble, toutes les combinaisons des modes de fonctionnement du véhicule.
Lorsque dans un contexte d'automate Ca les différents états correspondent à des réactions Rj différentes, alors ils ont caractérisés par* les couples (Ca, Rj ) et il n'est pas nécessaire de les nommer (convention utilisée pour les figures 1 et 2 ) .
Avant d'arrêter l'étude permettant d'établir les contextes d'utilisation CU, il convient de s'assurer de 1 ' exhaustivité de cette étude.
A cet effet, pour chaque prestation, on précisera les demandes formalisées qui peuvent se produire "simultanément" du fait de leur délai de prise en compte, ou parce que plusieurs utilisateurs peuvent y avoir accès. On validera ou invalidera ensuite les CU obtenus pour chaque contexte avec un ensemble de demandes concurrentes qui forment une nouvelle demande formalisée que l'on qualifiera de "demande simultanée", et une réaction formalisée dans la liste des réactions formalisées de la prestation.
De préférence, un changement de contexte d'automate sera plus prioritaire qu'une demande formalisée. On n'a donc pas à prendre en compte une éventuelle simultanéité dans ce cas. Si une demande de changement de contexte d'automate et une simple demande du conducteur apparaissent en parallèle, on traite de préférence le changement de contexte d'automate, puis la demande formalisée. Deux changements de contexte d'automate ne peuvent arriver simultanément, par définition (par exemple, les contexte d'automates "moteur tournant" et "moteur arrêté" précités ne peuvent évidemment coexister) .
Il convient aussi de s'assurer que l'automate formulé est correct, étape au cours de laquelle si, dans un même état de départ, deux états de l'automate sont reliés par des demandes différentes, alors on détermine la nécessité de définir une priorité entre les réponses du système et on incorpore cette priorité comme un attribut des sorties de l'état. Une information de priorité vient typiquement après la conception des cas d'utilisation . Il est possible que pour des raisons mécaniques ou autres, deux demandes potentiellement concurrentes ne soient en fait jamais réalisables simultanément. Dans ce cas il faut attendre une étape de conception plus avancée pour être sûr qu'il n'est pas nécessaire de spécifier une priorité, à moins' que cela puisse être garanti directement (ex : ouvrir une porte et fermer une porte) . De plus, si deux demandes identiques mènes à des états différents, il y a alors une inconhérence à corriger et l'une des demandes doit être supprimée et le cas d'utilisation correspondant doit être précisé en conséquence .
Il convient aussi de s'assurer que l'automate formulé est complet selon le processus explicité ci-dessous en liaison avec la figure 1, qui constitue une représentation graphique de cet automate, dans le cas où l'étude préalable a permis d'identifier un seul contexte d'automate Co, deux demandes Di et D2 et 5 réactions possibles (Ri à R5) . Sur la figure 1, les différents états (Ci, Rk) sont représentés par des cercles et les transitions entre états sur demande Di ou D2/ par des flèches en trait plein. C'est ainsi que, par exemple, on passe de l'état (C0,R2) à l'état (C0, R4) par la demande Dx et de ce dernier état à l'état (C0, R5) par la demande D2.
Des flèches en trait interrompu schématisent des transitions potentiellement manquantes, sur demande Dx ou D2 non figurées par une flèche en trait plein. Il apparaît que si les transitions à partir de l'état (C0, R2) sur demande Di ou D2 sont complètes, il n'en est pas de même des 4 autres états représentés .
Pour chacun de ces autres états (Ci, Rk) il faudra alors vérifier que la demande Di ou la demande D2 ne peut pas déclencher une transition vers un autre état.
Sur le plan matériel, les différents contextes, demandes et réactions identifiés peuvent être enregistrés dans divers emplacements prédéterminés de mémoires RAM sous la forme d'une booléen mis à "1", par exemple pour signaler l'existence de tel ou tel contexte d'automate ou demande, ou. pour produire telle ou telle réaction. Un calculateur approprié, tel qu'un microcontrôleur dûment programmé, ou des moyens matériels tel qu'un circuit câblé ou imprimé, permettent de matérialiser l'automate utilisé dans la présente invention.
On se réfère maintenant à la figure 2 du dessin annexé où l'on a représenté graphiquement la structure d'un automate propre à mettre en œuvre une prestation particulière, dans différents contexte d'automates Ci, C2 et C3. Des demandes Di, D2 permettent de commander, selon le contexte d'automate, des transitions vers des états caractérisés par des réactions Ri, R2 ou R3. Le bloc R3 détaille, à titre d'exemple, les réactions activées dans l'état (Ci, R3) : capture de valeurs, de grandeurs, exécution de différentes fonctions, commandes diverses, etc.. Dans chacun des trois blocs repérés cl, c2, c3 on a rassemblé les états identifiés dans les contextes d'automates Ci, C2 et C3 respectivement. Comme pour l'automate de la figure 1, les flèches en trait plein illustrent les transitions entre états commandées par des demandes Di ou D2, formulées par le conducteur du véhicule. Par contre les flèches uni- ou bidirectionnelles en trait interrompu illustrent des transitions entre contexte d'automates. C'est ainsi qu'une demande D , formulée à partir d'un état (Ci, R3) commande une transition vers l'état (Ci, R2) .
Si alors une demande D3 impliquant un changement de contexte d'automate apparaît, l'état évolue vers l'état (C2, R2) figuré dans le bloc c2.
L'automate permettant l'exécution de la prestation particulière en cause ayant été défini (comme illustré par la figure 2), il reste à coder et à charger en mémoire RAM ledit automate, comme indiqué ci-dessus. Un moniteur des demandes observe à chaque instant l'état des booléens représentatifs de ces demandes. Les transitions entre états découlant de ces demandes et conditions déterminent l'activation de capteurs, organes, fonctions ou commandes permettant d'exécuter la prestation demandée, dans l'un quelconque des états identifiés pendant l'analyse de cette prestation.
On va maintenant décrire, en liaison avec la figure 3 un exemple d'application du procédé d'organisation et d'exécution de prestations, suivant la présente invention. Exemple
La prestation analysée est la commande de climatisation de l'habitacle d'un véhicule automobile. Elle est décrite par un ensemble de CU tels que : a) dans le contexte où le moteur est tournant, le client demande la climatisation, dont la réponse est la mise en marche de la climatisation et la signalisation de cette mise en marche b) dans le contexte où le moteur est arrêté et le client demande la climatisation, rien ne se passe En première analyse cette commande peut être illustrée par deux blocs cl et c2 correspondant à des contexte d'automates Ci et C2 dans lesquels le moteur propulsant le véhicule est tournant, ou arrêté, respectivement.
Dans le contexte d'automate Ci on identifie des premier et deuxième états (Ci, Rx) et (Cl7 R) . L'état (Ci, Ri) correspond à une "climatisation non demandée" et donc à une absence de réaction, illustrée par la mention "Rien" correspondant à Ri .
L'état (Ci, R) correspond à une "climatisation demandée" sur demande Di. La réaction R2 est alors constituée par l'allumage d'une diode LED sur le tableau de bord pour confirmer au conducteur 1 ' activation de la climatisation par l' activation d'un compresseur de fluide frigorigène et de sa régulation, pour atteindre une température d'habitacle prédéterminé affiché par le conducteur, et, éventuellement, par une demande de couple supplémentaire au moteur, pour éviter des à-coups de couple, etc, ....
Dans ce contexte Ci, quand le conducteur demande l'arrêt de la climatisation (demande D) , cette demande commande une transition de l'automate de l'état (Ci, R2) vers l' état (Ci, Ri) .
Dans le contexte C2 (moteur arrêté) une demande Di d' activation de la climatisation ne doit avoir aucun effet du fait que le conducteur ne demeure normalement pas dans son véhicule, à l'arrêt. La réaction aux demandes Di et D2 est alors toujours Ri (= rien) .
Les flèches en trait interrompu illustrent les changements d'état qui résultent de changements de contexte d'automate provoqués par les demandes « demande d'arrêt moteur » ou "demande de démarrage du moteur", qui illustrent bien le cas d'un paramètre (état moteur) affectant la prestation et non affecté par la prestation.
Suivant une caractéristique avantageuse du procédé selon l'invention, il est possible de développer la prestation "climatisation" décrite ci-dessus, quand bien même ce développement n'aurait pas été envisagé lors de la conception de cette prestation.
C'est ainsi qu'il est possible de modifier l'automate de manière à donner au conducteur la possibilité d'activer la climatisation, alors même que le véhicule est inoccupé.
Une telle possibilité ajoute un confort supplémentaire au véhicule, en ce sens que l'air de l'habitacle peut être amené à une température agréable avant même que le conducteur ne pénètre dans cet habitacle, surchauffé antérieurement par un stationnement prolongé du véhicule au soleil, par exemple.
Dans ce contexte d'automate C3 "véhicule inoccupé", on distingue deux états (C3, Ri) et (C3, R3) . Des flèches en trait interrompu illustrent les changements d'état résultant de changements de contexte d'automate (occupant sort du véhicule, véhicule occupé) .
Sur une demande Dx du conducteur se trouvant à l'extérieur de son véhicule, chargée au moyen d'une télécommande assurant en outre, classiquement, le déverrouillage des portes du véhicule, on peut mettre sous tension le réseau électrique du véhicule, de manière à mettre en route la ventilation intérieure du véhicule et abaisser les fenêtres du véhicule. L'ensemble de ces commandes constitue la réaction R3 de l'état (C3, R3) .
On comprend que cette capacité supplémentaire d' activation de la climatisation du véhicule inoccupé peut être aisément ajoutée à l'automate par un chargement ou téléchargement de quelques identificateurs numériques supplémentaires, ceux correspondant à C3 et R3/ donc à faible débit d'informations, dans la mémoire RAM stockant les "tableaux de valeurs" correspondant à la prestation "climatisation" .
Il apparaît maintenant que l'invention permet bien d'atteindre l'un des buts fixés, à savoir fournir un procédé d'organisation et d'exécution de prestations conçu pour permettre des modifications des prestations, ou des ajouts de prestations nouvelles, moyennant des additions simples à la programmation initiale. Grâce à l'utilisation d'un automate exécutant le langage "intermédiaire" décrit ci-dessus, l'architecture du microcontrôleur accueillant l'automate n'a pas à être prise en compte au moment où l'on introduit ces modifications ou prestations nouvelles. Cette introduction s'obtient par le moyen d'un téléchargement léger d'instructions complémentaires, à faible débit, et non par rechargement complet des prestations modifiées ou ajoutées, tels que connu de la technique antérieure, rechargement lourd et à fort débit.
Bien entendu l'invention n'est pas limitée à l'application "climatisation" décrite ci-dessus et s'étend, au contraire, à toute autre application que l'on peut avoir à mettre en œuvre dans l'environnement d'un véhicule automobile telle que, par exemple : la commande d'ouverture/fermeture des portes,
1 ' activation/désactivation d'une alarme, le stockage de réglages propres au conducteur (siège, rétroviseurs, etc..) , la connexion d'un système de navigation à un système d'information sur le trafic automobile, ou à tout autre service accessible par le réseau Internet, etc, etc..
L'invention n'est pas non plus limitée à l'évolution d'une prestation existante et s'étend également, comme on l'a indiqué ci-dessus, à l'ajout d'une nouvelle prestation. L'invention s'étend encore à des applications prenant en compte des demandes autres qu ' originaires du conducteur du véhicule. C'est ainsi que, par exemple, le dépassement d'un certain âge ou d'un certain kilométrage par ce véhicule pourrait déclencher automatiquement des actions de calibrage ou réglage du moteur, justifié par son âge ou son état d'usure.
L'invention s'étend aussi à l'organisation et à 1 ' exécution de prestations dans un environnement autre qu ' automobile .

Claims

REVENDICATIONS 1. Procédé d'organisation et d'exécution d'une pluralité de prestations, notamment dans un véhicule automobile, caractérisé en ce que : a) on définit une pluralité de cas d'utilisation (CU) pour chacun desquels, dans un contexte (Ci) une demande (Dj) appelle une réaction (Rk) réalisant une prestation particulière, et b) on active sélectivement ladite réaction, sur détection de l'émission de ladite demande (Dj) dans ledit contexte (Ci) .
2. Procédé d'organisation d'une pluralité de prestations selon la revendication 1, caractérisé en ce que : pour chaque prestation réalisée par un système de composants matériels et logiciels, une pluralité de cas d'utilisation de la prestation est définie, chaque cas d'utilisation comportant : un contexte correspondant à des conditions d'application du cas d'utilisation, sous la forme de paramètres informatiques ou d'états physique de composants matériels, une demande de l'utilisateur, éventuellement implicite, et
- une réponse du système à la demande, et - et le système effectue ladite réponse, sur détection de l'émission de ladite demande dans ledit contexte.
3. Procédé d'organisation d'une pluralité de prestations selon les revendications 1 et 2 , caractérisé en ce qu'il comporte une étape de conception, pour chaque prestation, d'un automate mis en oeuvre par le système de composants matériels et logiciels, les transitions dudit automate représentant les demandes des cas d'utilisation et les états représentant 1 ' exécution des réponses des cas d'utilisation.
4. Procédé d'organisation d'une pluralité de prestations selon l'une des revendications précédentes, caractérisé en ce qu'il comporte les étapes suivantes : identification des contextes de l'automate (CAi) qui représentent, chacun, un ensemble de valeurs de paramètres du véhicule qui ne sont pas affectées par la prestation mais qui affectent la prestation et - au cours de l'étape de conception, pour chaque prestation
- définition des états correspondant à l'exécution des réponses de cas d'utilisation dans leurs contextes respectifs, et de manière itérative, jusqu'à ce qu'une itération n'ajoute pas de transition, pour chaque cas d'utilisation (CUj) : identification des couples (CAi, Ejk) compatibles avec le contexte du cas d'utilisation (CUj) , - création, dans l'automate, pour chacun de ces couples (CAi, Ejk) , la transition qui mène de (CAi, Ejk) à (CAi, Eij) par la demande Di du cas d'utilisation CUj, Eij étant un état réalisant la réponse du cas d'utilisation CUj, (412) et - si l'état Eij n'existe pas déjà, ajout dans le contexte (CAj) .
5. Procédé d'organisation d'une pluralité de prestations selon l'une des revendications précédentes, caractérisé en ce que l'étape de conception comporte :
- une étape d'ajout d'un cas d'utilisation formalisé de la prestation, spécifié par un contexte ou situation initiale du système, une demande d'un utilisateur au système et une réponse du système correspondant à un changement de son état, - et, de manière itérative, pour chaque état déjà construit, on cherche s'il est compatible avec le contexte du cas d'utilisation ajouté et, si oui, on construit un nouvel état du système relié audit état déjà construit par la demande du cas d'utilisation ajouté, le nouvel état tenant compte de l'état déjà construit et de sa modification par la réponse du cas d'utilisation ajouté.
6. Procédé d'organisation d'une pluralité de prestations selon l'une quelconque des revendications 1 à 5, caractérisé en ce que le contexte représente au moins un mode de fonctionnement du système, les modes étant transversaux aux prestations et hors du contrôle direct des prestations, par exemple un mode représentant un niveau d'énergie disponible et/ou un type d'utilisateur du système et ou un état accidenté ou non d'un véhicule.
7. Procédé d'organisation d'une pluralité de prestations selon la revendication 6, caractérisé en ce que le contexte représente un contexte d'automate du système, constituée d'un ensemble de combinaison des modes de fonctionnement du véhicule, les contextes d'automates étant ainsi transversales aux prestations, les cas d'utilisationreprésentant toutes les réponses ou absences de réponse du système dans tous les contextes d'automate, ceux-ci représentant, ensemble, toutes les combinaisons dés modes de fonctionnement du véhicule.
8. Procédé d'organisation d'une pluralité de prestations selon l'une quelconque des revendications 1 à 7, caractérisé en ce qu'il comporte une étape de complétion au cours de laquelle, pour chaque réponse, on envisage toutes les demandes clients non encore traitées et on demande à un concepteur si un traitement de la demande doit être effectué dans l'état correspondant à cette réponse.
9. Procédé d'organisation d'une pluralité de prestations selon l'une quelconque des revendications 1 à 8, caractérisé en ce qu'il comporte une étape de correction au cours de laquelle si, pour le même état, deux états de l'automate lui sont reliés, en sortie, par la même demande, on détermine qu'il est nécessaire d'éliminer l'une des deux.
10. Procédé d'organisation d'une pluralité de prestations selon l'une quelconque des revendications 1 à 9, caractérisé en ce qu'il comporte une étape de jonction au cours de laquelle si deux états ont la même interface vis à vis des autres états, on les fusionne en un seul état.
EP02783158A 2001-09-12 2002-09-12 Procede d'organisation et d'execution d'une pluralite de prestations, notamment dans un vehicule automobile Withdrawn EP1433031A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0111794A FR2829596B1 (fr) 2001-09-12 2001-09-12 Procede d'organisation et d'execution d'une pluralite de prestations, notamment dans un vehicule automobile
FR0111794 2001-09-12
PCT/FR2002/003119 WO2003023533A1 (fr) 2001-09-12 2002-09-12 Procede d'organisation et d'execution d'une pluralite de prestations, notamment dans un vehicule automobile

Publications (1)

Publication Number Publication Date
EP1433031A1 true EP1433031A1 (fr) 2004-06-30

Family

ID=8867209

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02783158A Withdrawn EP1433031A1 (fr) 2001-09-12 2002-09-12 Procede d'organisation et d'execution d'une pluralite de prestations, notamment dans un vehicule automobile

Country Status (5)

Country Link
US (1) US7454271B2 (fr)
EP (1) EP1433031A1 (fr)
JP (1) JP2005517562A (fr)
FR (1) FR2829596B1 (fr)
WO (1) WO2003023533A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102012019993A1 (de) * 2012-10-12 2014-04-17 Audi Ag Verfahren zum Konfigurieren einer Steuereinheit, Steuereinheit und Fahrzeug
US11861353B2 (en) * 2019-05-31 2024-01-02 Nec Corporation System update procedure planning apparatus, method, and computer-readable recording medium

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5301553A (en) * 1989-12-20 1994-04-12 Tjs Development Corporation Apparatus for remote sensing and receiving
US5717387A (en) * 1990-01-19 1998-02-10 Prince Corporation Remote vehicle programming system
US6067008A (en) * 1993-05-25 2000-05-23 Intellectual Property Development Associates Of Connecticut, Inc. Methods and apparatus for inputting messages, including advertisements, to a vehicle
US5806018A (en) * 1993-05-25 1998-09-08 Intellectual Property Development Associates Of Connecticut, Incorporated Methods and apparatus for updating navigation information in a motorized vehicle
US5732074A (en) * 1996-01-16 1998-03-24 Cellport Labs, Inc. Mobile portable wireless communication system
US5799193A (en) 1996-04-29 1998-08-25 Siemens Corporate Research, Inc. Scenario based iterative method for development of an object oriented system model
US5787367A (en) * 1996-07-03 1998-07-28 Chrysler Corporation Flash reprogramming security for vehicle computer
US6275585B1 (en) * 1998-04-28 2001-08-14 Motorola, Inc. Method for reprogramming a vehicle system or a user system in a vehicle
US6882917B2 (en) * 1999-07-30 2005-04-19 Oshkosh Truck Corporation Steering control system and method

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO03023533A1 *

Also Published As

Publication number Publication date
US20050283278A1 (en) 2005-12-22
FR2829596B1 (fr) 2003-12-26
FR2829596A1 (fr) 2003-03-14
JP2005517562A (ja) 2005-06-16
US7454271B2 (en) 2008-11-18
WO2003023533A1 (fr) 2003-03-20

Similar Documents

Publication Publication Date Title
US7312691B2 (en) System and method of using telematics units for locking and unlocking vehicle functions
EP2920768B1 (fr) Procédé d'aide au diagnostic à distance d'un véhicule
FR2705072A1 (fr) Système et procédé pour programmer au moins un appareil de commande d'un véhicule automobile.
CN103167447B (zh) 验证在车辆与中央设施之间发送的消息
CN112291739A (zh) 智能终端与车载终端WiFi联机方法、系统、介质及T-BOX
EP1433031A1 (fr) Procede d'organisation et d'execution d'une pluralite de prestations, notamment dans un vehicule automobile
CN110406469B (zh) 车门声效模拟方法、装置及车载处理器
CN111447589A (zh) 基于移动通信的车载以太网诊断系统监控及授权使用方法
FR3066874B1 (fr) Procede et dispositif de controle a distance de fonctions de vehicules par un equipement de communication mobile
US9065416B2 (en) Methods and systems for controlling the volume of infotainment units of vehicles
CN109484396A (zh) 一种车辆自动驻车的方法及装置
CN111169411B (zh) 车辆、车辆自动控制装置及基于鉴权的车辆自动控制方法
FR2859839A1 (fr) Dispositif de commande multiple de moteurs electriques
EP3571693B1 (fr) Dispositif d'assistance d'usager(s) d'un véhicule, à agents conversationnels multiples
EP3107751B1 (fr) Procédé et dispositif d'acquisition de données provenant d'un dispositif d'autorisation de démarrage d'un véhicule, et véhicule comprenant ledit dispositif
CN115848268A (zh) 一种车辆智能提醒的方法及装置
WO2019145612A1 (fr) Télécommande automatique asservie par un véhicule
FR3128173A1 (fr) Procede de gestion de la securisation d’un vehicule automobile.
FR3113634A1 (fr) Procédé et système de supervision de clés digitales de véhicules
CN117854186A (zh) 车辆门锁的控制方法、系统、计算机设备及存储介质
FR3128346A1 (fr) Procede et dispositif de controle d’alerte d’oubli d’un dispositif de communication mobile dans un vehicule
CN116980147A (zh) 业务处理方法、装置、系统及车辆
WO2005038725A1 (fr) Systeme de diagnostic predictif des dysfonctionnements d’un vehicule automobile et son dispositf de diagnostic embarque
FR2707117A1 (fr) Système de téléchargement de données de programme pour calculateur de gestion de processus.
CN116825102A (zh) 汽车控制方法、装置和电子设备

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20040219

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LI LU MC NL PT SE SK TR

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20130403