FR2829596A1

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

Info

Publication number: FR2829596A1
Application number: FR0111794A
Authority: FR
Inventors: Samuel Boutin; Gongora Hugo Chale; Azim Panday
Original assignee: Renault SAS
Current assignee: Renault SAS
Priority date: 2001-09-12
Filing date: 2001-09-12
Publication date: 2003-03-14
Anticipated expiration: 2021-09-12
Also published as: WO2003023533A1; US20050283278A1; JP2005517562A; FR2829596B1; EP1433031A1; US7454271B2

Abstract

Suivant le procédé, a) on définit une pluralité de cas d'utilisation formalisés (CUF) pour chacun desquels, dans un contexte (C i) une demande (D j) 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 (D j) dans ledit contexte (C i).

Description

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 oeuvre.

La présente invention a précisément 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 formalisés (CUF) pour chacun desquels, dans un contexte (Cl) une demande (D,) 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 oeuvre d'un tel chargement étant alors beaucoup plus aisé.

Selon d'autres caractéristiques de la présente invention : - la définition desdits cas d'utilisation formalisés (CUF) inclut celle d'un délai dans lequel ledit contexte (Ci) et/ou ladite demande (DJ) doit être pris en compte, - la définition desdits cas d'utilisation formalisés (CUF) inclut celle d'un délai dans lequel la réaction (Rk) doit être mise en oeuvre, pour activer sélectivement une prestation particulière, on établit un automate dont les états sont les couples (Cl, Rk) des contextes et des réactions intervenant dans au moins un desdits cas d'utilisation formalisés (CUF) et dont les

transitions sont choisies parmi les demandes formalisées (dol), on définit des conditions de changement de contexte (CCCI) dont la survenance commande le passage d'un contexte (Cki) à un autre contexte (cl2), une condition de changement de contexte (CCC, commande une transition entre deux états (Cn, Rki) et (Ci2, Rk2) on définit un délai sous lequel le changement de contexte doit s'établir, on programme l'automate en codant lesdits contextes (Ci), demandes (Dj) et réactions (Rk) à l'aide d'identificateurs numériques, on modifie ladite pluralité de prestations par une modification correspondante du jeu des états (Cl, Rk) et des demandes (D,) assurant les transitions entre lesdits états, ladite modification touche une prestation existante, ou ajoute une nouvelle prestation, on réalise l'automate par programmation d'un calculateur de commande desdites prestations.

D'autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre et à l'examen du dessin annexé dans lequel : la figure 1 est une représentation graphique d'un automate conçu pour la mise en oeuvre de la présente invention, la figure 2 est une représentation graphique d'un autre automate conçu pour la mise en oeuvre suivant l'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 l'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 l'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 à l'aide de capteurs appropriés, ou bien calculables.

Le contexte peut aussi comprendre des demandes du conducteur, mémorisées, telles que"le conducteur a appuyé sur le bouton d'allumage des feux de détresse".

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 l'une des prestations offertes par le véhicule).

3) les réactions du système sont des faits qui activent les prestations elle-mêmes : 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

oeuvre 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 : dans n'importe quel contexte, une "demande" du conducteur constituée par l'enfoncement du bouton"feux de détresse", demande qui doit être prise en compte en au plus une seconde, appelle une"réaction" constituée par l'allumage de quatre clignotants pendant 50ms, avec une fréquence de répétition de 2 Hz.

Deux contextes formalisés comme indiqués ci-dessus, et présentant des temporisations différentes, sont considérés comme différents.

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.

Les cas d'utilisation (CU) établis comme ci-dessus permettent de produire des cas d'utilisation formalisés (CUF) par la démarche suivante : on associe un identificateur numérique unique (un booléen spécifique dans un mot numérique, par exemple) à chaque contexte, demande et réaction, apparaissant au moins une fois dans un des cas d'utilisation et on considère qu'un cas d'utilisation CU particulier est équivalent au cas d'utilisation formalisé CUF (Ci, D, Rk) si l'identificateur Ci, la demande Dj et la réaction Rk correspondent bien au contexte, à la demande et à la réaction du cas d'utilisation, respectivement.

On peut alors établir un automate dont les états sont les couples (contexte formalisé, réaction formalisée) intervenant dans au moins un cas d'utilisation formalisé

dont les transitions sont choisies parmi les demandes formalisées.

Si on désigne alors par Cl Rk et D, les contextes, réactions et demandes "formalisées", une demande D31 appelle une transition de l'état (CI,, Rkl) à l'état (Cl1, Rk2) si, et

seulement si, (CI,, DJ1'Rk2) est un cas d'utilisation formalisé (CUF) dans le contexte Cn.

Entre deux états (Cn, Rki) et (Cii, Rk2) il ne peut y avoir qu'une transition et une seule pour éviter toute ambiguïté : dans le cas contraire, suivant l'invention, on reviendra à la règle précédente par élimination d'un cas d'utilisation formalisé responsable de l'ambiguïté, ou on précisera une priorité dans la prise en compte des demandes.

Suivant la présente invention on formalise aussi des conditions de changement de contexte CCCi, ces conditions étant indépendantes des demandes et des réactions formalisées même si, en pratique, elle peuvent être corrélées, voire même identiques, à une demande ou à l'achèvement d'une réaction.

On associe à chacune des conditions CCCl un identificateur et une temporisation caractérisant le délai sous lequel le changement d'un contexte à l'autre peut être détecté. Ces changements de contexte s'expriment alors par des triplets (CI,, CCCu, Crû). Comme exemple pratique d'un tel changement de contexte, dans le cadre de la prestation "climatisation de l'habitacle d'un véhicule automobile", évoquée plus loin en détail, on peut citer le passage du contexte"moteur arrêté"au contexte"moteur tournant"quand le conducteur fait démarrer le moteur propulsant le véhicule.

Avant d'arrêter l'étude permettant d'établir les contextes d'utilisation formalisés CUF, il convient de s'assurer de l'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 CUF 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.

Un changement de contexte sera toujours 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 et une simple demande du conducteur apparaissent en parallèle, on traite d'abord le changement de contexte, puis la demande formalisée. Deux changements de contexte ne peuvent arriver simultanément, par définition (par exemple, les contextes "moteur tournant"et"moteur arrêté"précités ne peuvent évidemment coexister).

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 Co, deux demandes Dl et D2 et 5 réactions possibles (Ri à Rs). Sur la figure 1, les différents états (Ci, Rk) sont représentés par des cercles et les transitions entre états sur demande Dl ou D par des flèches en trait plein. C'est ainsi que, par exemple, on passe de l'état (Co. Rs) à l'état (Co, R4) par la demande Dl et de ce dernier état à l'état (Co, Rs) par la demande D2.

Des flèches en trait interrompu schématisent des transitions potentiellement manquantes, sur demande Dl ou D2 non figurées par une flèche en trait plein. Il apparaît que si les transitions à partir de l'état (Co, 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 (Cl, Rk) il faudra alors vérifier que la demande Dl 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 à"l", par exemple pour signaler l'existence de tel ou tel contexte 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 oeuvre une prestation particulière, dans différents contextes Ci, C2 et C3. Des demandes Di, D2 permettent de commander, selon le contexte, des transitions vers des états caractérisés par des réactions Ri, R2 ou Rs. Le bloc R3 détaille, à titre d'exemple, les réactions activées dans l'état (Ci, P) : 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 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 Dl 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 contextes formalisés.

C'est ainsi qu'une demande D2, formulée à partir d'un

état (Ci, R3) commande une transition vers l'état (Ci, R). Si alors une condition de changement de contexte CCC1 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. Il en est de même pour les conditions de changement de contexte (CCCI). 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.

En première analyse cette commande peut être illustrée par deux blocs cl et c2 correspondant à des contextes CI et C2 dans lesquels le moteur propulsant le véhicule est tournant, ou arrêté, respectivement.

Dans le contexte CI on identifie des premier et deuxième états (Ci, Ri) et (Ci, 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, R2) 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 l'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 D2), 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 Dl 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 Dl 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 provoqués par les conditions"arrêt du moteur"ou"démarrage du moteur".

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 Ça"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 (occupant sort du véhicule, véhicule occupé).

Sur une demande Di 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 un compresseur de fluide frigorigène actionné par un moteur électrique alimenté par ce réseau, ainsi que la régulation du fonctionnement du compresseur en fonction d'une température préprogrammée ou commandée par le conducteur du véhicule, etc.... 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 le but fixé, à 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 oeuvre dans l'environnement d'un véhicule automobile telle que, par exemple : la commande d'ouverture/fermeture des portes, l'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 à l'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 formalisés (CUF) pour chacun desquels, dans un contexte (Cl) une demande (D,) 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 (Cl).

2. Procédé conforme à la revendication 1, caractérisé en ce que la définition desdits cas d'utilisation formalisés (CUF) inclut celle d'un délai dans lequel ledit contexte (Cl) et/ou ladite demande (DJ) doit être pris en compte.

3. Procédé conforme à la revendication 1 ou 2, caractérisé en ce que la définition desdits cas d'utilisation formalisés (CUF) inclut celle d'un délai dans lequel la réaction (Rk) doit être mise en oeuvre.

4. Procédé conforme à l'une quelconque des revendications 1 à 3, caractérisé en ce que, pour activer sélectivement une prestation particulière, on établit un automate dont les états sont les couples (Cl, RJ des contextes et des réactions intervenant dans au moins un desdits cas d'utilisation formalisés (CUF) et dont les transitions sont choisies parmi les demandes formalisées

(Di).

5. Procédé conforme à la revendication 4, caractérisé en ce qu'on définit des conditions de

changements de contexte (CCCI) dont la survenance commande le passage d'un contexte (Cki) à un autre contexte (cl2),

6. Procédé conforme à la revendication 5, caractérisé en ce que ladite condition de changement de contexte (CCC1) commande une transition entre deux états (con, Rkl) et (Cû, Rk2).

7. Procédé conforme à l'une quelconque des revendications 5 et 6, caractérisé en ce qu'on définit un délai sous lequel ledit changement de contexte (CCCI) doit s'établir.

8. Procédé conforme à l'une quelconque des revendications 4 à 7, caractérisé en ce qu'on programme ledit automate en codant lesdits contextes (Ci), demandes (Dj) et réactions (Rk) à l'aide d'identificateurs numériques.

9. Procédé conforme à la revendication 8, caractérisé en ce qu'on modifie ladite pluralité de prestations par une modification correspondante du jeu d'états (Ci, Rk) et des demandes (DJ) assurant les transitions entre lesdits états.

10. Procédé conforme à la revendication 9, caractérisé en ce que ladite modification touche une prestation existante, ou ajoute une nouvelle prestation.

11. Procédé conforme à l'une quelconque des revendications 4 à 10, caractérisé en ce qu'on réalise l'automate par programmation d'un calculateur de commande desdites prestations.

12. Procédé conforme à l'une quelconque des revendications 1 à 11, caractérisé en ce que lesdites prestations sont choisies dans le groupe formé par la commande d'ouverture/fermeture des portes, l'activation/désactivation d'une alarme, le stockage de réglages propres au conducteur, la connexion d'un système de navigation à un système d'information sur le trafic automobile ou à un autre service accessible par le réseau Internet.