Method for managing a display in a vehicle, and driver assistance method and system for a vehicle using same

Abstract

The invention relates to a method for managing a display in a motor vehicle (EGO), the motor vehicle comprising, on the one hand, a driver assistance system comprising a trajectory planner software component (PP) and applications (APP 1, APP 2, APP N) and, on the other hand, a plurality of human-machine interfaces (HMI) for displaying or signalling information, and a manager software component (MHMI) that manages the human-machine interfaces (HMI), wherein the use of at least one interface (HMI) is capable of being invoked simultaneously by at least two different applications (APP 1 APP 2, APP N), and wherein the method is characterised in that, for each application (APP 1, APP 2, APP N) for which a constraint / request has been submitted to the planner software component (PP) and arbitrated by it, a display request is sent to the manager software component (MHMI), and the positive or negative outcome of this request is then decided by the manager software component (MHMI), and the at least one relevant interface (HMI) is controlled in accordance with predetermined display or signalling modalities.

Description

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 of 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 composition or the mode of operation of this HMI (LED, TFT screen, backlit pictogram hidden in a piece of trim, etc.) and by freeing itself from any communication between applications, at least any direct communication between them. In addition, the proposed solution should make it possible to provide a display that remains consistent regardless of the number and 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, 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, to send 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 to decide at the level of said manager software component whether to respond positively or negatively to this request, and where appropriate to control said at least one interface concerned in accordance with predetermined display or signaling methods.,

[0009] 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:

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

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

[0012] 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.

[0013] 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, in addressing 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 in deciding at the level of said management software component (GIHM) whether to respond positively or negatively to this request, and where appropriate controlling said at least one interface (IHM) concerned in accordance with predetermined display or signaling methods.

[0014] 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 Single-component software applications (GIHM), the latter are limited to sending requests and are not involved in the processing, nor in the visual and / or sound implementation of these requests. 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.

[0015] 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.

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

[0017] A) Type of characteristic, such as: - 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: e.g. 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.

[0018] B) Feature status (for example): a. Enabled. b. Disabled. c. Standby. d. Canceled.

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

[0020] D) Optional specific fields (which are not used by all applications): Set speed: used for example by ACC. Side line crossing: used for example by the LKA.

[0021] 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 available HMIs.

[0022] 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 application with another characteristic concerned by another application.

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

[0024] 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 that emits on a type of characteristic, the arbitration remains unchanged).

[0025] A second level of arbitration relates to the interdependence of characteristic types: 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".

[0026] All 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 consistent, 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).

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

[0028] The invention also relates, as shown schematically by way of example in Figure 2, considered in relation to Figure 1, 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 the human-machine interfaces (IHM) of the vehicle (EGO) according to the confirmation of the planning software component and any additional information at its disposal, 4) in arbitrating the display request at the level of said management 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 (HMIs), by implementing the display management method described above.

[0029] Thus, in addition to the display management described previously, the driving assistance method implements a preliminary 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).

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

[0031] The first stage of the planning software component (PP) advantageously consists 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 (e.g. emergency or comfort) as well as the surrounding conditions (ODD for certain functions, most limiting target in the case of target tracking, etc.).

[0032] 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 put into execution by the vehicle, if it refuses it, it is not.

[0033] 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.

[0034] 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 target tracking activated will request an activation pictogram (a green vehicle on the dashboard). In case of temporary deactivation, a different pictogram will be displayed (an orange vehicle on the dashboard). In case of permanent deactivation, another third pictogram will be visible (a gray vehicle on the dashboard).

[0035] 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 could also be envisaged that AEB displays nothing on this aforementioned pictogram and displays a message elsewhere, but that during this activation it is desired to make the ACC pictogram disappear.

[0036] It follows from the above that the aforementioned assistance process is essentially based on the following three fundamental procedures:

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

[0038] 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 software component (GIHM) manager can change over time depending on the vehicle.

[0039] Using 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 the software component (GIHM) to apply its rules. b. As long as the protocol is the same, new applications can be added to existing ones.

[0040] Of course, each application can use its own coding and structure, but the assistance process always presents the four successive steps shown in Figure 2. In the latter, the applications comprise two functional sub-blocks, namely a decision 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).

[0041] 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 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. 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.

[0042] 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 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.

[0043] 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.

[0044] Advantageously, and as is apparent for example from figure 2, 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 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). alternatively or additionally to the integration of such a component (DU), and as is apparent from Figure 1, the application (APP 1, APP 2, APP N) concerned may also call upon, interrogate 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).

[0045] As shown by way of example in Figure 1, 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.

[0046] A possible overall architecture of a driving assistance system according to the invention is represented in a simplified manner in Figure 1.

[0047] 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 from the applications based on the decisions of the planning software (PP) and controlling the displays on the HMIs, after arbitration - an upper 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).

[0048] In this architecture, input data comes from sensors (C), such as camera, LIDAR, sonar, tracker or similar, or even internal vehicle detectors (EGO). These data are processed (e.g. 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.

[0049] 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) of the vehicle path planning (EGO) whose aim 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) of control / command of the trajectory and movement makes it possible to generate the data / instructions allowing to control the actuators of the vehicle such as the brakes, the steering (by the chassis interfaces) or even the means of propulsion.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.

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

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

[0052] 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 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, a 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 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) whether to respond positively or negatively to this request, and to control said at least one interface (IHM) concerned, using said management software component (GIHM) and 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 the applications (APP 1, APP 2, APP N) by applying predefined rules and / or criteria, taking for example into account 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.

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 sending 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 applications (APP 1, APP 2, APP N) of comfort or safety 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, 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 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 in that the management 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.,

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

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

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.

Images