EP1433031A1

EP1433031A1 - Method for organizing and executing a plurality of services, in particular on board a motor vehicle

Info

Publication number: EP1433031A1
Application number: EP02783158A
Authority: EP
Inventors: Samuel Boutin; Hugo Chale Gongora; Azim Panday
Original assignee: Renault SAS
Current assignee: Renault SAS
Priority date: 2001-09-12
Filing date: 2002-09-12
Publication date: 2004-06-30
Also published as: FR2829596A1; US20050283278A1; US7454271B2; JP2005517562A; WO2003023533A1; FR2829596B1

Abstract

The invention concerns a method which consists in: a) defining a plurality of use instances (CU) for each of which, in a given context (Ci) a request (Dj) calls for a response (Rk) providing a specific service, and b) selectively activating said response, when the transmission of said request (Dj) is detected in said context (Ci).

Description

Method for organizing and performing a plurality of services, in particular in a motor vehicle. 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. 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. This object of the invention is achieved, as well as others which will appear on reading the description which follows, with a method of organization and execution of a plurality of services, in particular in a motor vehicle, this process being remarkable in that a) a plurality of use cases (CU) is defined for each of which, in a context (Ci), a request (D _j ) calls for a reaction (R _k ) performing a particular service, and b ) said reaction is selectively activated, upon detection of the emission of said request (Dj) in said context (Ci).

As will be seen in detail below, this process allows, at the cost of a fine preliminary analysis of the architecture to be given to the software for performing the services in question, to subsequently modify these services, or to add new ones. , by means of a loading of information at a much lower rate than in the case of the method described in the document WO 99/56201 cited above, the implementation of such a loading then being much easier. Other characteristics and advantages of the present invention will become apparent on reading the description which follows and on examining the appended drawing in which: 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, and 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". Firstly, 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. As an illustrative and non-limiting example:

1) 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.

2) 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. 3) 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. As an example of a use case thus defined, the following can be cited: for any value of the vehicle parameters, a "request" from the driver constituted by pressing the "hazard warning" button, request which must be taken into account, calls a "reaction" consisting of the lighting of four indicators, with a repetition frequency of 2 Hz.

Three lists of contexts, requests and formalized reactions are thus established.

The identified use cases (CU) can be combined into services independent of each other

(such as, for example, wiping the windows and operating a lighting device), possibly activated in parallel. In the following, only the organization according to the invention of a single service will be described, the other services being organized in the same way.

"To define the automaton corresponding to all the services, the following steps are carried out. During a first step, a first service is taken into account. During 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. During a third step, for each automaton context CAi and for each use case CU _j , the context of which corresponds to CAi, 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 .

During a fourth step, an iterative process begins which stops when an iteration no longer adds a transition to the automaton.

During each iteration of this iterative process, for each use case CU _j the following steps are carried out: identification of the pairs (CAi, Ej _k ) compatible with the context of the use case CUj,

Creation, in the automaton, for each of these couples (CAi, Ejk), of the transition which leads from (CAi, Ej _k ) to

(CAj, Ei _j ) by the request Di of the use case CU _j , Ei _j being a state carrying out the response of the use case

CUj, and if the state Eij does not already exist, addition in the context of the Caj automaton,

-Back to the stop condition at the start of the iteration.

Finally, we return to the second stage, for another service that has not yet been processed.

If, during a new stage, a use case is added to a service, the third stage and the following ones are reproduced, if the new use case induces a new response. Otherwise, we go to the fourth step.

We note that 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.

In particular, 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.

When in a context of automaton Ca the different states correspond to different reactions Rj, then they have characterized by ^* the couples (Ca, Rj) and it is not necessary to name them (convention used for Figures 1 and 2 ).

Before stopping the study allowing to establish the contexts of use CU, it is advisable to make sure 1 exhaustiveness of this study.

For this purpose, for each service, we will specify the formalized requests which can occur "simultaneously" because of their time taken into account, or because several users can have access to them. We will then validate or invalidate the CUs obtained for each context with a set of competing requests which form a new formalized request that we will qualify as "simultaneous request", and a formalized reaction in the list of formalized reactions of the service.

Preferably, a change in the context of the PLC will have higher priority than a formal request. We therefore do not have to take into account a possible simultaneity in this case. If 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).

It is also advisable to make sure that the formulated automaton is correct, stage during which if, in the same starting state, two states of the automaton are connected by different requests, then one determines the need to define a priority between system responses and this priority is incorporated as an attribute of the state outputs. Priority information typically comes after the design of the use cases. It is possible that for mechanical or other reasons, two potentially competing demands may in fact never be achievable simultaneously. In this case, you have to wait for a more advanced design step to be sure that it is not necessary to specify a priority, unless this can be guaranteed directly (ex: open a door and close a door). In addition, if two identical requests lead to different states, then there is an inconsistency to be corrected and one of the requests must be deleted and the corresponding use case must be specified accordingly.

It is also advisable to make sure that the formulated automaton is complete according to the process explained below in connection with figure 1, which 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 ₂ and 5 possible reactions (Ri to R ₅ ). In FIG. 1, 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 ₀ , R ₂ ) to the state (C ₀ , R ₄ ) by the request D _x and from this latter state to the state (C ₀ , R ₅ ) by request D ₂ .

Arrows in broken lines show diagrams of potentially missing transitions, on request D _x or D ₂ not shown by an arrow in solid line. It appears that if the transitions from state (C ₀ , R ₂ ) on request Di or D ₂ are complete, it is not the same for the 4 other states represented.

For each of these other states (Ci, R _k ) it will then be necessary to verify that the request Di or the request D ₂ cannot trigger a transition to another state.

On the material level, 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.

Reference is now made to 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 ₂ and C ₃ . Requests Di, D ₂ make it possible to control, depending on the context of the automaton, transitions to states characterized by reactions Ri, R ₂ or R ₃ . The R ₃ block details, by way of example, the reactions activated in the state (Ci, R ₃ ): capture of values, quantities, execution of different functions, various commands, etc. In each of the three identified blocks cl, c2, c3 we gathered the states identified in the contexts of automata Ci, C ₂ and C ₃ respectively. As for the automaton in FIG. 1, the arrows in solid lines illustrate the transitions between states controlled by requests Di or D ₂ , formulated by the driver of the vehicle. On the other hand, 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 ₃ ) commands a transition to the state (Ci, R ₂ ).

If then a request D3 involving a change of context of an automaton appears, the state evolves towards the state (C ₂ , R ₂ ) shown in block c2.

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.

We will now describe, in connection with FIG. 3, an example of application of the method of organization and execution of services, according to the present invention. Example

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 ₂ in which the engine propelling the vehicle is rotating, or stopped, respectively.

In the context of automaton Ci we identify first and second states (Ci, R _x ) and (C _l7 R). The state (Ci, Ri) corresponds to an "air conditioning not requested" and therefore to an absence of reaction, illustrated by the mention "Nothing" corresponding to Ri.

The state (Ci, R) corresponds to "air conditioning requested" on request Di. The reaction R ₂ 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.

In this context Ci, when the driver requests the air conditioning to stop (request D), this request controls a transition of the automatic device from the state (Ci, R ₂ ) to the state (Ci, Ri).

In the context C ₂ (engine stopped) a request Di to activate the air conditioning must have no effect since the driver does not normally remain in his vehicle when stationary. The reaction to requests Di and D ₂ is then always Ri (= nothing).

The arrows in dashed lines illustrate the changes of state which result from changes in the context of the controller caused by the requests "engine stop request" or "engine start request", which illustrate the case of a parameter ( engine condition) affecting the service and not affected by the service.

According to an advantageous characteristic of the method according to the invention, it is possible to develop the "air conditioning" service described above, even though this development would not have been considered when designing this service.

This is how it is possible to modify the PLC so as to give the driver the possibility of activating air conditioning even when the vehicle is unoccupied.

Such a possibility adds additional comfort to the vehicle, in the sense that the air in the passenger compartment can be brought to a pleasant temperature even before the driver enters this passenger compartment, previously overheated by prolonged parking of the vehicle in the sun, for example.

In this context of automaton C ₃ "unoccupied vehicle", there are two states (C ₃ , Ri) and (C ₃ , R ₃ ). Dashed arrows illustrate the changes of state resulting from changes in the context of the PLC (occupant leaves the vehicle, occupied vehicle).

On a request D _x of the driver being outside his vehicle, charged by means of a remote control ensuring, in addition, conventionally, the unlocking of the doors of the vehicle, the electrical network of the vehicle can be energized, so to start the vehicle interior ventilation and lower the vehicle windows. All of these commands constitute the reaction R ₃ of the state (C ₃ , R ₃ ).

It is understood that 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 ₃ and R _{3 /} therefore at low information rate. , in the RAM memory storing the "value tables" corresponding to the "air conditioning" service.

It now appears that 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.

Of course, 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,

1 activation / deactivation of an alarm, storage of driver-specific settings (seat, mirrors, etc.), connection of a navigation system to an information system on car traffic, or any other service accessible via the Internet, etc., etc.

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. Thus, for example, 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.

Claims

CLAIMS 1. Method for organizing and performing a plurality of services, in particular in a motor vehicle, characterized in that: a) a plurality of use cases (CU) is defined for each of which, in a context (Ci) a request (D _j ) calls a reaction (R _k ) performing a particular service, and b) selectively activating said reaction, upon detection of the emission of said request (Dj) in said context (Ci).

2. Method for organizing a plurality of services according to claim 1, characterized in that: for each service provided by a system of hardware and software components, a plurality of use cases of the service is defined, each case of use comprising: a context corresponding to the conditions of application of the use case, in the form of computer parameters or physical states of hardware components, a user request, possibly implicit, and

- a response of the system to the request, and - and the system performs said response, upon detection of the emission of said request in said context.

3. A method of organizing a plurality of services according to claims 1 and 2, characterized in that it comprises a step of designing, for each service, an automaton implemented by the system of hardware and software components , the transitions of said automaton representing the requests of the use cases and the states representing the execution of the responses of the use cases.

4. Method for organizing a plurality of services according to one of the preceding claims, characterized in that it comprises the following steps: identification of the contexts of the automaton (CAi) which each represent a set of values vehicle parameters which are not affected by the service but which affect the service and - during the design stage, for each service

- definition of the states corresponding to the execution of the use case responses in their respective contexts, and iteratively, until an iteration does not add a transition, for each use case (CUj) : identification of the couples (CAi, E _jk ) compatible with the context of the use case (CU _j ), - creation, in the automaton, for each of these couples (CAi, Ej _k ), the transition which leads from ( CAi, E _jk ) to (CAi, Eij) by the request Di of the use case CUj, Eij being a state carrying out the response of the use case CU _j , (412) and - if the state Eij does not exist not already, added in context (CA _j ).

5. Method for organizing a plurality of services according to one of the preceding claims, characterized in that the design step comprises:

- a step of adding a formalized use case of the service, specified by a context or initial situation of the system, a request from a user to the system and a response from the system corresponding to a change in its state, - And, iteratively, for each state already constructed, we seek whether it is compatible with the context of the added use case and, if so, we construct a new state of the system linked to said state already constructed by the request of the added use case, the new state taking into account the already built state and its modification by the response of the added use case.

6. Method for organizing a plurality of services according to any one of claims 1 to 5, characterized in that the context represents at least one mode of operation of the system, the modes being transversal to the services and outside direct control services, for example a mode representing an available energy level and / or a type of user of the system and or an accident or not state of a vehicle.

7. A method of organizing a plurality of services according to claim 6, characterized in that the context represents a context of the system automaton, consisting of a set of combination of operating modes of the vehicle, the contexts of automata thus being transversal to the services, the use cases representing all the responses or absence of response of the system in all the contexts of the automaton, these representing, together, all the combinations of the operating modes of the vehicle.

8. A method of organizing a plurality of services according to any one of claims 1 to 7, characterized in that it includes a completion step during which, for each response, we consider all customer requests not still processed and a designer is asked if the request should be processed in the state corresponding to this response.

9. A method of organizing a plurality of services according to any one of claims 1 to 8, characterized in that it comprises a correction step during which if, for the same state, two states of the are connected to it, at the output, by the same request, it is determined that it is necessary to eliminate one of the two.

10. A method of organizing a plurality of services according to any one of claims 1 to 9, characterized in that it includes a joining step during which if two states have the same interface with respect to the others states, we merge them into one state.