Method for organizing and execution of a number of services, especially in a motor vehicle, which also relates to updating of control software in such a way that a complete and lengthy reinstallation is not needed

The present invention relates to a method of organizing and executing a plurality of services, in particular in a motor vehicle.

Document WO 99/56201 discloses a method of 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 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 call numbers recorded in mobile phone. The described method, designed to ensure reprogramming accessible only to authorized persons or entities, performs such reprogramming, or programming of a new function, by means of downloading into a microcontroller of a compiled code for the execution of a complete software capable of performing this reprogramming or 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 precisely to allow the reprogramming of services, specific to a motor vehicle for example, by modification of services already installed, or additions of new services, this reprogramming not requiring knowledge of the architecture of the microcontroller used. for the performance of the services. It is then much lighter and is carried out by means of a transfer of information at a low rate, compared 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 following description, with a method of organizing and performing a plurality of services, in particular in a motor vehicle, this process being remarkable in that a) we define a plurality of formalized use cases (CUF) for each of which, in a context (Ci) a request (Dj) calls a reaction (R_k) performing a particular service, and b) said reaction is selectively activated upon detection of the transmission 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 aforementioned document WO 99/56201, the implementation of such loading then being much easier.

According to other characteristics of the present invention:

- the definition of said formalized use cases (CUF) includes that of a period within which said context (Ci) and / or said request (Dj) must be taken into account,

- the definition of said formalized use cases (CUF) includes that of a time limit in which the reaction (R_k) must be implemented,

- to selectively activate a particular service, an automaton is established whose states are the pairs (C_iz R_k) contexts and reactions occurring in at least one of said formalized use cases (CUF) and whose transitions are chosen from among the formalized requests (DJ,

- context change conditions (CCCi) are defined, the occurrence of which commands the passage of a context (C_ki) to another context (C_k2) ,

- a context change condition (CCCJ commands a transition between two states (Cn, R_kJ and (Ci2, R_k2) f

- we define a period under which the change of context must be established,

- the automaton is programmed by coding said contexts (Ci), requests (DJ and reactions (R_k) using digital identifiers,

- said plurality of services is modified by a corresponding modification of the set of states (C_iz R_k) and requests (Dj) ensuring the transitions between said states,

- said modification affects an existing service, or adds a new service,

- The automaton is produced by programming a control computer for said services.

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:

- Figure 1 is a graphical representation of an automatic device designed for the implementation of the present invention,

- Figure 2 is a graphic representation of another controller designed for the implementation according to the invention of a particular service in different contexts, and

- Figure 3 is a functional diagram of a controller of the type of that shown in Figure 2 adapted, by way of example, to the control of the air conditioning of the passenger compartment of a motor vehicle, according to the method according to l 'invention.

A motor vehicle normally comprises a plurality of physical systems: propulsion engine, braking, suspension, heating, air conditioning, communications devices, etc., 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, an operating context is defined, the driver's request and the system's reaction to such a request, emitted in said context.

By way of illustrative and non-limiting example:

1) the context of use can consist of information coming from the environment: temperature of the passenger compartment, vehicle speed, driving condition (outside temperature, presence of rain, etc.). This information can be detected using appropriate sensors, or else it can be calculated.

The context may also include requests from the driver, stored, such as the driver pressed the hazard warning lights button .

2) the driver's requests are actions of the latter on organs or interfaces (button, keyboard, voice recognition device of a word, etc.) which allow him to call one of the services offered by the vehicle).

3) the reactions of the system are facts which activate the services themselves: start of windshield wipers, activation of a flashing light, display of an icon on a screen, etc.

The formalization of the use cases is, according to the invention, supplemented by timing information indicating under what time period a reaction must be implemented and under what time period a context or a request must be taken into account.

As an example of the use case thus defined, the following can be cited: in any context, a request ”from the driver constituted by pressing the hazard warning lights button, a request which must be taken into account in at most one second, calls for a reaction consisting of the lighting of four flashing lights for 50 ms, with a repetition frequency of 2 Hz.

Two contexts formalized as indicated above, and having different timings, are considered to be different.

We thus establish three lists of formalized contexts, requests and reactions.

The identified use cases (CU) can be combined into services that are independent of each other (such as, for example, wiping windows and the operation of 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.

The use cases (CU) established as above make it possible to produce formalized use cases (CUF) by the following process: a unique numeric identifier (a specific boolean in a numeric word, for example) is associated with each context, request and reaction, appearing at least once in one of the use cases and it is considered that a particular CU use case is equivalent to the formalized CUF use case (Ci, Dj, R_k) if the identifier Ci, the request Dj and the reaction R_k correspond well to the context, demand, and reaction of the use case, respectively.

We can then establish an automaton whose states are the pairs (formalized context, formalized reaction) intervening in at least one formalized use case whose transitions are chosen from among the formalized requests.

If we then denote by Ci, R_k and Dj the contexts, reactions and formalized requests, a Dj request! calls a state transition (Cü, R_ki) in the state (Cü, R_k2) if, and only if, (Cü, D_jX, R_k2) is a formalized use case (CUF) in the Cü context.

Between two states (Cü, R_ki) and (Cü, R_k2) there can be only one transition and only one to avoid any ambiguity: otherwise, according to the invention, we will return to the previous rule by eliminating a formalized use case responsible for the ambiguity, or we will specify a priority in taking requests into account.

According to the present invention, the conditions for changing the context CCCi are also formalized, these conditions being independent of the requests and of the reactions formalized even if, in practice, they may be correlated, or even identical, to a request or to the completion of a reaction.

An identifier and a time delay characterizing the time period under which the change from one context to another can be detected is associated with each of the conditions CCCi. These context changes are then expressed by triples (Cü, CCCu, C₁₂). As a practical example of such a change of context, in the context of the air conditioning service for the passenger compartment of a motor vehicle, mentioned later in detail, we can cite the passage from the engine stopped context to the engine running context when the driver starts the engine propelling the vehicle.

Before stopping the study making it possible to establish the formalized CUF contexts of use, it is advisable to ensure the exhaustiveness of this study.

To this end, for each service, we will specify the formalized requests that may occur simultaneously

Ί because of their delay in taking into account, or because several users can have access to them. We will then validate or invalidate the CUFs obtained for each context with a set of competing requests which form a new formalized request which we will qualify as a simultaneous request, and a formalized reaction in the list of formalized reactions of the service.

A change of context will always be a higher priority than a formal request. There is therefore no need to take into account a possible simultaneity in this case. If a request for a change of context and a simple request from the driver appear in parallel, the change of context is first processed, then the formalized request. Two changes of context cannot occur simultaneously, by definition (for example, the aforementioned contexts with engine running and engine stopped cannot obviously coexist).

It should also be ensured 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 C_o, two requests Di and D₂ and 5 possible reactions (Ri to R₅). In figure 1, the different states (Ci, R_k) are represented by circles and the transitions between states on request D₂ or D₂,

<td>by</td><td>arrows</td><td>in</td><td>trait</td><td>full</td><td>This is</td><td>so</td><td>than,</td><td>through</td>

<td>example,</td><td>we pass</td><td>of</td><td>The state</td><td>(VS₀, R₂)</td><td>in the state</td><td>(VS_o,</td><td>R₄ ) through</td><td>the</td>

<td>request</td><td>D₂ and of</td><td>this</td><td>latest</td><td>state</td><td>in the state</td><td>(Co,</td><td>R₅) through</td><td>the</td>

request D₂.

Arrows in dashed line schematize potentially missing transitions, on request D₂ or D₂not shown by a solid arrow. It appears that if the transitions from state (C_o, R₂) on request D-_±or D₂ are complete, it is not the same for the 4 other states shown.

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 hardware level, the various contexts, requests and reactions identified can be recorded in various predetermined locations of RAM memories in the form of a Boolean set to 1, for example to signal the existence of a particular context or request, or to produce this or that reaction. An appropriate 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 where the specific automaton to be implemented has been graphically represented, in different contexts Ci, C₂ and C₃. Di, D requests₂ allow to control, depending on the context, transitions to characterized states reactions Ri, R₂ or R₃. Block R₃ details, for 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 blocks marked cl, c2, c3, the states identified in the contexts Ci, C have been gathered₂ and C₃ respectively.

As for the automaton of figure 1, the arrows in solid line illustrate the transitions between states commanded by requests D_T or D₂, formulated by the structure of a service by as driver of the vehicle.

On the other hand, the uni- or arrows illustrate bidirectional in dashed line transitions between formalized contexts.

This is how a request D₂, formulated from a state (Ci, R₃) commands a transition to the state (Ci, R₂) .

If then

C If a context change condition appears, the state evolves into the state (C₂, R₂) shown in block c2.

The automaton allowing the execution of the particular service in question having been defined (as illustrated in FIG. 2), it remains to code and load said automaton into RAM memory, as indicated above. A request monitor observes at each moment the state of the Booleans representing these requests. It is the same for the conditions of change of context (CCCi). The transitions between states resulting from these requests and conditions determine the activation of sensors, components, functions or commands making it possible to perform the requested service, in any of the states identified during the analysis of this service.

An example of application of the method of organization and execution of services, according to the present invention, will now be described in conjunction with FIG. 3. Example

The service analyzed is the air conditioning control of the passenger compartment of a motor vehicle.

In the first analysis, this command can be illustrated by two blocks cl and c2 corresponding to contexts Ci and C₂ in which the engine propelling the vehicle is running, or stopped, respectively.

In the context Ci we identify the first and second states (Ci, Ri) and (Ci, R₂). The state (Ci, Ri) corresponds to unsolicited air conditioning 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 D_T. The R reaction₂ 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, to reach a passenger compartment temperature predetermined displayed by the driver, and, possibly, ίο by a request for additional torque to the engine, to avoid torque surges, etc, ....

In this context Ci, when the driver requests the stopping of the air conditioning (request D₂), this request commands a transition of the state automaton (Ci, R₂) to the state (Ci, RJ.

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

Dashed arrows illustrate state changes that result from context changes caused by engine stop or engine start conditions.

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 during the design of this service.

Thus it is possible to modify the automatic device so as to give the driver the possibility of activating the air conditioning, even when the vehicle is unoccupied.

Such a possibility adds additional comfort to the vehicle, in 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 C₃ unoccupied vehicle, there are two states (C₃, R_x) and (C₃, R₃). Arrows in broken lines illustrate changes of state resulting from changes in context (occupant leaves the vehicle, occupied vehicle).

At a request Di from the driver located outside his vehicle, charged by means of a remote control further ensuring, conventionally, the unlocking of the vehicle doors, it is possible to switch on the vehicle's electrical network, so as to start up a refrigerant compressor powered by an electric motor supplied by this network, as well as the regulation of the operation of the compressor according to a preprogrammed temperature or commanded by the driver of the vehicle, etc .... All of these commands constitute the reaction R₃ state (C₃, R3)

It will be understood that this additional capacity for activating the air conditioning of the unoccupied vehicle can easily be added to the PLC by loading or downloading a few additional digital identifiers, those corresponding to C₃ and R₃, therefore at a low data rate, in the RAM memory storing the tables of values ​​corresponding to the air conditioning service.

It now appears that the invention makes it possible to achieve the aim set, namely to provide a process for the organization and execution of services designed to allow modifications to services, or additions to new services, by means of simple additions to initial programming.

Thanks to the use of a PLC executing the intermediate language described above, the architecture of the microcontroller accommodating the PLC 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 downloading of additional instructions, at low speed, and not by full reloading of the modified or added services, as known from the prior art, heavy reloading 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 may have to be implemented in the environment of a motor vehicle. such as, for example: opening / closing the doors, activating / deactivating an alarm, storing driver-specific settings (seat, mirrors, etc.), connecting a navigation system to a navigation system information on automobile traffic, or any other service accessible via the Internet, etc, etc ...

The invention is not limited to the development of an existing service either and also extends, as indicated above, to the addition of a new service.

The invention also 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 of a certain mileage by this vehicle could automatically trigger actions to calibrate or adjust 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 an automobile.