Method for managing displays in a vehicle, and method and system for driver assistance for vehicles using it

Abstract

The invention relates to a method for managing display in a vehicle, and a method and system for driver assistance for a vehicle using it. The invention relates to a method for managing display in a motor vehicle (EGO) comprising, on the one hand, a driver assistance system including a software component (PP) for trajectory planning and applications (APP 1, APP 2, APP N) and, on the other hand, a plurality of human-machine interfaces (HMI) for displaying or signaling information and a software component (HMI) for managing said human-machine interfaces (HMI), the use of at least one interface (HMI) being able to be requested simultaneously by at least two different applications (APP 1, APP 2, APP N).The method is characterized in that, for each application (APP 1, APP 2, APP N) for which a constraint / request has been submitted to and arbitrated by the planning software component (PP), it consists of sending a display request to the management software component (GIHM), and deciding at the level of said management software component (GIHM) whether to respond to this request, and commanding at least one relevant interface (IHM) in accordance with predetermined display or signaling methods. Figure to be published with the abbreviation: Fig. 1.

Description

Title of the invention: Method for managing a display in a vehicle, and method and system for assisting driving in a vehicle using same

[0001] The present invention relates to the field of automatic and selective signaling and communication of information to the driver and / or passengers of a vehicle by means of human-machine interfaces (HMI) equipping the latter, in particular following actions affecting the vehicle and triggered by different safety or comfort software applications.

[0002] In this context, the invention relates to a method for managing displays in a vehicle, as well as a method and a driving assistance system for a vehicle using said display management method.

[0003] In a motor vehicle, human-machine interfaces (HMIs) are of a regulatory and / or informative nature.

[0004] Their number is necessarily limited and it is important not to overload the displays too much in order to have information that is concise, easily assimilated and complete for users.

[0005] Furthermore, vehicles are increasingly equipped with safety or comfort software applications developed by different entities, generally without constraints in terms of interoperability or compatibility, unless they can be implemented and fulfill their functions in the vehicle concerned.

[0006] Under these conditions, there is therefore a need for the different applications present to be able to share and use (if necessary request simultaneously) the same HMIs, at least one or more of them. For example, two applications can light up the same pictogram, or the same location on a screen can display two different pieces of information in relation to two different applications.

[0007] The main problem posed by the present invention consists in being able to propose a solution allowing different applications implemented simultaneously, and therefore operating together, in the same vehicle to use, at least two, the same HMI, without knowing the nature, the constitution or the mode of operation of this HMI (LED, TFT screen, pictogram with backlight hidden in a piece of trim, etc.) and by freeing itself from any communication between applications, at least from any direct communication between them. In addition, the proposed solution should make it possible to provide a display which remains coherent regardless of the number and the nature of the applications implemented.

[0008] This problem is solved, according to a first aspect of the invention, by a method for managing display in a motor vehicle comprising, on the one hand, a driving assistance system comprising a trajectory planner software component and comfort or safety applications separately transmitting requests or constraints to said planner software component for execution by the vehicle and, on the other hand, a plurality of human-machine interfaces for displaying or signaling information, at least some of which originate from the aforementioned applications, and a software component managing said human-machine interfaces, the use of at least one interface being able to be requested simultaneously by at least two different applications, not communicating with each other,

[0009] method characterized in that it consists, for each application for which a constraint / request has been submitted to the planner software component and arbitrated by the latter according to predefined prioritization rules, in addressing a display request to the manager software component in accordance with the result of the arbitration and according to a predefined protocol common to the different applications, and in deciding at the level of said manager software component whether to respond positively or negatively to this request, and where appropriate controlling said at least one interface concerned in accordance with predetermined display or signaling methods.

[0010] The invention will be better understood from the following description, which relates to a preferred embodiment, given as a non-limiting example, and explained with reference to the appended schematic drawings, in which:

[0011] [Fig. 1] schematically and simplifiedly represents an architecture of a driving assistance system for a motor vehicle, and,

[0012] [Fig.2] is a partial representation of the architecture of [Fig.l] illustrating an example of a decision-making process that can be followed by the driving assistance method according to the invention.

[0013] The invention relates, according to a first aspect, to a method for managing a display in a motor vehicle (EGO) comprising, on the one hand, a driving assistance system comprising a trajectory planner software component (PP) and comfort or safety applications (APP 1, APP 2, APP N) separately transmitting requests or constraints to said planner software component (PP) for execution by the vehicle (EGO) and, on the other hand, a plurality of human-machine interfaces (HMI) for displaying or signaling information, at least some of which originate from the aforementioned applications, and a software component (GIHM) managing said human-machine interfaces (HMI), the use of at least one interface (HMI) being able to be requested simultaneously by at least two different applications (APP 1, APP 2, APP N), not communicating with each other.

[0014] According to the invention, this method consists, for each application (APP 1, APP 2, APP N) for which a constraint / request has been submitted to the planning software component (PP) and arbitrated by the latter according to predefined prioritization rules, to address a display request to the management software component (GIHM) in accordance with the result of the arbitration and according to a predefined protocol common to the different applications, and to decide at the level of said management software component (GIHM) on the positive or negative follow-up to be given to this request, and where appropriate to control said at least one interface (IHM) concerned in accordance with predetermined display or signaling methods.

[0015] Thanks to the aforementioned provisions, and in particular to the implementation of a software component (GIHM) managing human-machine interfaces (HMI), the invention allows different applications (APP1, APP2, ..., APPi, ..., APPN), possibly developed independently by different entities, to "coexist" with each other using the same human-machine interface(s) (HMI), without having knowledge of the HMI used, without having to communicate with any other application and by proposing a coherent overall display. By entrusting the management of the display for all applications to a single software component (GIHM), the latter are limited to sending requests and are not involved in the processing, nor in the visual and / or sound implementation, of the latter.The solution proposed by the invention is therefore both generic, extensible and scalable: for the same display request, an entry-level vehicle can light up a diode, while a more high-end vehicle can display a pictogram on a TFT screen.

[0016] In accordance with a simple and efficient embodiment of the method, limiting the constraints at the application level while allowing the acceptance of various applications, said display management method may consist of implementing a communication protocol defined by the management software component (GIHM) and in which each request message sent by an application (APP 1, APP 2, APP N) to the management software component (GIHM) comprises the following fields: the type of characteristic linked to the vehicle (EGO) and / or to the environment concerned by the request / constraint, the degree of urgency of this characteristic, the state of this characteristic, the reason for the change of state of the characteristic and possibly an informative field specific to the application concerned.

[0017] As possible practical examples, the request messages may include the following fields A) to D):

[0018] A) Type of characteristic, such as for example: - Longitudinal “non-urgent”: for example adaptive cruise control system (Adaptive Cruise Control - ACC), Contextual Auto Regenerator (CARB), etc. - Longitudinal “urgent”: e.g. Autonomous Emergency Braking (AEB), Vulnerable Road User (VRU), Autonomous Emergency Braking Car to Car, etc. - “Non-urgent” lateral: for example Lane Centering Assist (LCA), Semi Automatic Lane Change (SALC), ... - “Urgent” lateral: for example Lane Keep Assist (LKA), emergency LKA (e-LKA), etc. - Informative: features that do not affect the vehicle's actuators, such as Realistic HMI (R-HMI), Intelligent Speed ​​Assist (ISA), Lane Departure Warning (LDW), etc.

[0019] B) State of the characteristic (for example): a. Activated. b. Disabled. c. Stand-by. d. Cancelled.

[0020] C) Reason for cancellation (source of cancellation): a. Driver deactivation. b. Camera temporarily blocked. c. Camera permanently blocked. d. ODD not respected.

[0021] D) Optional specific fields (which are not used by all applications):

[0022] Set speed: used for example by ACC.

[0023] Lateral line crossing: used for example by the LKA.

[0024] This protocol defined by the management software component (GIHM) and which must be used by all applications requesting a display can of course evolve to adapt to varied HMI offers and to possible developments in the available HMIs.

[0025] Advantageously, the display management method may consist of prioritizing, at the level of the management software component (GIHM), the display requests received from the applications (APP 1, APP 2, APP N) by applying predefined rules and / or criteria, taking into account for example the type of characteristic linked to the vehicle (EGO) and / or to the environment concerned by the request / constraint linked to a request, the degree of urgency or importance of the characteristic concerned by this request and / or the possible interdependence of the characteristic concerned by this request with another characteristic concerned by another request.

[0026] As an example of prioritization and arbitration rules implemented by the management software component (GIHM), the method may for example provide:

[0027] A first level of arbitration by type of characteristic: If the management software component (GIHM) receives only one request per type of characteristic then the arbitration is simple (each characteristic has its request accepted at this first level of arbitration). If the management software component (GIHM) receives more than one request on the same type of characteristic (for example an ACC / ISA request on the “non-urgent” longitudinal) then said manager (GIHM) prioritizes each field according to its value. For example: an activated ISA has priority over a deactivated ACC. The overall request remains “non-urgent longitudinal activated”. At the end of this step there remains only one single request per type of characteristic (concerning modularity, if we add an application which emits on a type of characteristic, the arbitration remains unchanged).

[0028] A second level of arbitration relates to the interdependence of the types of characteristics: For example, if an “urgent longitudinal” request is present, we choose not to display any request (whatever it may be) coming from a “non-urgent longitudinal”.

[0029] All the statuses resulting from the arbitrations produce a display on the HMI in question: dashboard screen / LED / IVI (Infotainment) / counter / or similar. In this way the display is coherent, each application is independent of the others and the arbiter (PP) and the manager (GIHM) can manage as many applications as necessary (no limit for the quantity of applications).

[0030] Of course, the management software component (GIHM) can request or control at least two different interfaces (IHM) for the same display request.

[0031] The invention also relates, as shown schematically by way of example in [Fig.2], considered in relation to [Fig.l], to a method for assisting the driving of a vehicle (EGO) whose movement is at least partially controlled by applications (APP 1, APP 2, APP N) by means of constraints / requests, characterized in that it consists, for a given application (APP 1, APP 2, APP N), 1) in transmitting a request or constraint to a planning software component (PP) when said application considers it necessary, 2) in returning to said application a confirmation of whether or not said request / constraint has been taken into account by said planning software component, 3) in transmitting by said application a display request to a software component (GIHM) managing human-machine interfaces machine interface (HMI) of the vehicle (EGO) based on the confirmation of the planner software component and any additional information available to it, 4) to arbitrate the display request at the level of said manager software component, taking into account requests from other applications (APP 1, APP 2, APP N) and to address resulting commands to the relevant human-machine interfaces (HMI), this by implementing the display management method described above.

[0032] Thus, in addition to the display management described previously, the driving assistance method implements a prior arbitration function between the different constraints issued by the plurality of applications (APP 1, APP 2, ..., APPN) before the latter communicate with the software component (GIHM) managing the human-machine interfaces (HMI).

[0033] In the context of the present invention, this arbitration function is fulfilled by software (PP) for planning the vehicle's path (EGO) which receives the various requests / constraints, for example of the type: avoid collision, follow target, change lane, turn on lighting, start the windshield wipers, etc.

[0034] The first stage of the planning software component (PP) is advantageously made up of an arbitration block for the received constraints. There is no limit to the number of applications that issue constraints and the planning software (PP) relies on predetermination rules for prioritization. These rules take into account the type of constraint (for example urgency or comfort) as well as the surrounding conditions (ODD for certain functions, most limiting target in the case of target tracking, etc.).

[0035] The planning software (PP) responds to each application that has sent a constraint to inform it whether this constraint is accepted or not. If it accepts the constraint, the latter is executed by the vehicle, if it refuses it, it is not.

[0036] For example, if one application issues a "change lane" constraint and another application issues a "follow target ahead" constraint, the planning software (PP) may choose to reject the "change lane" and accept "follow target ahead." This implies that the vehicle (EGO) will remain in its lane in target following mode.

[0037] When an application receives the acceptance / rejection of its request, a specific HMI can be requested by this application. For example, the ACC application in activated target tracking will request an activation pictogram (a green vehicle on the dashboard). In the event of temporary deactivation, a different pictogram will be displayed (an orange vehicle on the dashboard). In the event of permanent deactivation, another third pictogram will be visible (a gray vehicle on the dashboard).

[0038] Other applications may need to use this same pictogram already used by ACC in target tracking. For example, an AEB application could display a red pictogram in the same place as the ACC pictograms. It can also be considered that the AEB does not display anything on this aforementioned pictogram and displays a message elsewhere, but that during this activation it is desired to make the ACC pictogram disappear.

[0039] It is clear from the above that the aforementioned assistance method is essentially based on the following three fundamental procedures:

[0040] A common arbitration function: all applications (APP 1, APP 2, .. APPN) issue requests / constraints to an arbiter, namely a vehicle path planning (EGO) software (PP). a. This is important for modularity, applications do not communicate “with each other”. b. Applications only communicate with the arbiter: they make a request and receive a response. c. It is up to the arbitrator to decide which applications have their requests accepted / rejected. d. The referee implements a predetermined set of rules to decide.

[0041] A global display management function: the software component (GIHM) managing the human-machine interfaces (HMI) decides what is lit / displayed (or not) on the vehicle's HMIs. a. Applications do not know how their display / signaling requests are implemented: LED, pictogram on a TFT, visual or sound animation, etc. b. The operating rules of the management software component (GIHM) may change over time depending on the vehicle.

[0042] Use of a common protocol: all applications use the same formalism to communicate with the software component (GIHM) managing human-machine interfaces (HMI). a. This common protocol allows said software component (GIHM) manager to be able to apply its rules. b. As long as the protocol is the same, new applications can be added to existing ones.

[0043] Of course, each application can use its own coding and structure, but the assistance method always presents the four successive steps shown in [Fig.2]. In the latter, the applications comprise two functional sub-blocks, namely a decision-making unit (DU) which generates requests when the conditions are given and sends them to the arbitrator, and a unit for generating and sending (according to the fixed protocol) display requests (IU).

[0044] The invention also relates to an on-board driving assistance system for a motor vehicle (EGO) comprising, on the one hand, a trajectory planner software component (PP) and comfort or safety applications (APP 1, APP 2, APP N) separately transmitting requests or constraints to said planner software component (PP) for execution by the vehicle (EGO) and, on the other hand, a plurality of human-machine interfaces (HMI) for displaying or signaling information, at least some of which come from the aforementioned applications, and a software component (GIHM) managing said human-machine interfaces (HMI), the use of at least one interface (HMI) being able to be requested simultaneously by at least two different applications (APP 1, APP 2, APP N), not communicating with each other.

[0045] According to the invention, this system is characterized in that the planner software component (PP) is configured to receive and arbitrate according to predefined prioritization rules constraints / requests coming from the applications (APP 1, APP 2, APP N), in that said applications (APP 1, APP 2, APP N) are configured to each address a display request to the manager software component (GIHM) in accordance with the result of the arbitration and according to a predefined protocol common to the different applications, and in that the manager software component (GIHM) is configured to decide on the positive or negative follow-up to give to this request, and where appropriate the choice of the interface (IHM) and the display or signaling methods on the latter.

[0046] For the sake of simplicity and universality of communication, the single communication protocol used by the applications (APP 1, APP 2, APP N) for sending request messages to the management software component (GIHM), each display request message includes the following fields: the type of characteristic linked to the vehicle (EGO) and / or to the environment concerned by the request / constraint, the degree of urgency of this characteristic, the state of this characteristic, the reason for the change of state of the characteristic and possibly an informative field specific to the application concerned.

[0047] According to a characteristic of the invention and as mentioned previously, the management software component (GIHM) is configured to prioritize the display requests received from the applications (APP 1, APP 2, APP N) by applying predefined rules and / or criteria, taking into account for example the type of characteristic linked to the vehicle (EGO) and / or to the environment concerned by the request / constraint linked to a request, the degree of urgency or importance of the characteristic concerned by this request and / or the possible interdependence of the characteristic concerned by this request with another characteristic concerned by another request.

[0048] Advantageously, and as is apparent for example from [Fig.2], each ap plication (APP 1, APP 2, APP N) comprises an analytical and decision-making component (DU) configured to selectively transmit requests or constraints to the planner software component (PP) and a display control component (IU) configured to selectively generate and transmit display request messages to the manager software component (GIHM). As an alternative or in addition to the integration of such a component (DU), and as is apparent from [Fig.l], the application (APP 1, APP 2, APP N) concerned may also call upon, query or be solicited by a global software component (SU) for understanding the environment and the situation and state of the vehicle (EGO), in relation to the establishment and selective transmission of requests or constraints to the planner software component (PP).

[0049] As shown by way of example in [Fig.l], the system preferably also comprises means (C, WM, SU) for detecting and evaluating the environment of the vehicle and the current situation of the latter, on the one hand, and means (PP, TMC, A) for determining the trajectory and controlling the movement of the vehicle, of which the planner software component (PP) is part, on the other hand, these different means collaborating mutually and with the management software component (GIHM) and the different human-machine interfaces (IHM) to carry out the expected driving assistance functions and inform the driver of the vehicle (EGO) and possibly its occupants.

[0050] A possible overall architecture of a driving assistance system according to the invention is represented in a simplified manner in [Fig.l].

[0051] It comprises three hardware / software functional layers represented in a superimposed manner in this figure, namely: - a lower layer comprising the hardware resources equipping the vehicle (“EGO vehicle HW”) and comprising the internal and external sensors and detectors (C) providing the status and situation data, the actuators (A) executing the vehicle movement control command instructions (EGO) and the human-machine interfaces (HMI) for regulatory and informative display - an intermediate layer of middleware specific to the vehicle and comprising software (WM) for modeling the vehicle (EGO) and its environment, software (SU) for understanding the environment and the situation and state of the vehicle (EGO), software (PP) for planning the vehicle's path (EGO) and software (TMC) for controlling / commanding the trajectory and movement of the vehicle (EGO). This intermediate layer also includes the software component (GIHM) managing the human-machine interfaces (HMI) receiving the display requests of applications based on decisions of the planning software (PP) and controlling the displays on the HMIs, after arbitration - a higher layer (“Applications”) of applications (APP 1, APP 2, .. APPN), which may for example include an application corresponding to the emergency braking system (AEB) and an application corresponding to the adaptive cruise control system (ACC).

[0052] In this architecture, the input data comes from sensors (C), such as camera, LIDAR, sonar, tracker or similar, or even detectors internal to the vehicle (EGO). This data is processed (eg merged) by the software component (WM), then sent to the software component (SU) so that the latter can analyze situations (such as a collision) by predicting the position of objects in the future. This set of hardware and software elements composes the information feed to the applications.

[0053] The applications (APP 1, APP 2, ..., APPi, ..., APP N) then subscribe to situations of the software component (SU) to analyze a risk (for example the AEB application) or request to follow a vehicle (for example the ACC application). The applications send constraints or requests (of the maneuver request type) to the software component (PP) for planning the vehicle's path (EGO) whose purpose is to generate a trajectory to satisfy the constraints it has received, in particular by arbitrating between the different requests / constraints issued by the applications. The software (TMC) for controlling / commanding the trajectory and movement makes it possible to generate the data / instructions making it possible to control the vehicle's actuators such as the brakes, the steering (via the chassis interfaces) or even the propulsion means.At the same time, the software component (GIHM) managing the human-machine interfaces (HMI) accordingly controls the display on the HMI(s) concerned. This set of hardware and software elements makes up the descending part of the information.

[0054] Preferably, the assistance system implements the methods described above.

[0055] Finally, the invention also relates to a motor vehicle (EGO) characterized in that it comprises a driving assistance system as described previously.

[0056] Of course, the invention is not limited to the embodiment described and shown in the attached drawings. Modifications remain possible, in particular from the point of view of the constitution of the various elements or by substitution of technical equivalents, without departing from the scope of protection of the invention.

Claims

Claims

1. Method for managing displays in a motor vehicle (EGO) comprising, on the one hand, a driving assistance system comprising a trajectory planner software component (PP) and comfort or safety applications (APP 1, APP 2, APP N) separately transmitting requests or constraints to said planner software component (PP) for execution by the vehicle (EGO) and, on the other hand, a plurality of human-machine interfaces (HMI) for displaying or signaling information, at least some of which originate from the aforementioned applications, and a software component (GIHM) managing said human-machine interfaces (HMI), the use of at least one interface (HMI) being able to be requested simultaneously by at least two different applications (APP 1, APP 2, APP N), not communicating with each other, method characterized in that it consists, for each application (APP 1, APP 2,APP N) for which a constraint / request has been submitted to the planning software component (PP) and arbitrated by the latter according to predefined prioritization rules, to send a display request to the management software component (GIHM) in accordance with the result of the arbitration and according to a predefined protocol common to the different applications, and to decide at the level of said management software component (GIHM) whether to respond positively or negatively to this request, and where appropriate to control said at least one interface (IHM) concerned in accordance with predetermined display or signaling methods.,

2. Method according to claim 1, characterized in that it consists of implementing a communication protocol defined by the management software component (GIHM) and in which each request message sent by an application (APP 1, APP 2, APP N) to the management software component (GIHM) comprises the following fields: the type of characteristic linked to the vehicle (EGO) and / or to the environment concerned by the request / constraint, the degree of urgency of this characteristic, the state of this characteristic, the reason for the change of state of the characteristic and possibly an informative field specific to the application concerned.

3. Method according to claim 1 or 2, characterized in that it consists of prioritizing, at the level of the management software component (GIHM), the display requests received from applications (APP 1, APP 2, APP N) by applying predefined rules and / or criteria, taking into account for example the type of vehicle-related (EGO) and / or environment-related characteristic concerned by the request / constraint linked to a request, the degree of urgency or importance of the characteristic concerned by this request and / or the possible interdependence of the characteristic concerned by this request with another characteristic concerned by another request.

4. Method according to any one of claims 1 to 3, characterized in that it consists of requesting or controlling at least two different interfaces (HMI) for the same display request.

5. Method for assisting the driving of a vehicle (EGO) whose movement is at least partially controlled by applications (APP 1, APP 2, APP N) by means of constraints / requests, characterized in that it consists, for a given application (APP 1, APP 2, APP N), 1) in transmitting a request or constraint to a planner software component (PP) when said application considers it necessary, 2) in returning to said application a confirmation of whether or not said request / constraint has been taken into account by said planner software component, 3) in transmitting by said application a display request to a software component (GIHM) managing the human-machine interfaces (IHM) of the vehicle (EGO) according to the confirmation of the planner software component and any additional information at its disposal, 4) in arbitrating the display request at the level of said manager software component,taking into account requests from other applications (APP 1, APP 2, APP N) and addressing resulting commands to the relevant human-machine interfaces (HMIs), by implementing the display management method according to any one of claims 1 to 4.,

6. On-board driving assistance system for a motor vehicle (EGO) comprising, on the one hand, a trajectory planner software component (PP) and comfort or safety applications (APP 1, APP 2, APP N) separately transmitting requests or constraints to said planner software component (PP) for execution by the vehicle (EGO) and, on the other hand, a plurality of human-machine interfaces (HMI) for displaying or signaling information, at least some of which originate from the aforementioned applications, and a software component (GIHM) managing said human-machine interfaces machine (HMI), the use of at least one interface (HMI) which can be requested simultaneously by at least two different applications (APP 1, APP 2, APP N), not communicating with each other, system characterized in that the planner software component (PP) is configured to receive and arbitrate according to predefined prioritization rules constraints / requests coming from the applications (APP 1, APP 2, APP N), in that said applications (APP 1, APP 2, APP N) are configured to each address a display request to the manager software component (GIHM) in accordance with the result of the arbitration and according to a predefined protocol common to the different applications, and in that the manager software component (GIHM) is configured to decide on the positive or negative follow-up to give to this request, and where appropriate the choice of the interface (HMI) and the display or signaling methods on the latter.

7. System according to claim 6, characterized in that in the single communication protocol used by the applications (APP 1, APP 2, APP N) for sending request messages to the management software component (GIHM), each display request message includes the following fields: the type of characteristic linked to the vehicle (EGO) and / or to the environment concerned by the request / constraint, the degree of urgency of this characteristic, the state of this characteristic, the reason for the change of state of the characteristic and possibly an informative field specific to the application concerned.

8. System according to claim 6 or 7, characterized in that the management software component (GIHM) is configured to prioritize the display requests received from the applications (APP 1, APP 2, APP N) by applying predefined rules and / or criteria, taking into account for example the type of characteristic linked to the vehicle (EGO) and / or to the environment concerned by the request / constraint linked to a request, the degree of urgency or importance of the characteristic concerned by this request and / or the possible interdependence of the characteristic concerned by this request with another characteristic concerned by another request.

9. System according to any one of claims 6 to 8, characterized in that each application (APP 1, APP 2, APP N) comprises an analytical and decision-making component (DU) configured to selectively transmit requests or constraints to the component scheduler software (PP) and a display control component (UI) configured to selectively generate and transmit display request messages to the manager software component (GIHM).

10. System according to any one of claims 6 to 9, characterized in that it also comprises means (C, WM, SU) for detecting and evaluating the environment of the vehicle and the current situation of the latter, on the one hand, and means (PP, TMC, A) for determining the trajectory and controlling the movement of the vehicle, of which the planner software component (PP) is part, on the other hand, these different means collaborating mutually and with the management software component (GIHM) and the different human-machine interfaces (IHM) to carry out the expected driving assistance functions and inform the driver of the vehicle (EGO) and possibly its occupants.

11. System according to any one of claims 6 to 10, characterized in that it implements the display management method according to any one of claims 1 to 4 and the driving assistance method according to claim 5.

12. Motor vehicle (EGO) characterized in that it comprises a driving assistance system according to any one of claims 6 to 11.