Electronic driving assistance module for a motor vehicle

EP4676798A1Pending Publication Date: 2026-01-14AMPERE SAS
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
EP2024707247
Authority / Receiving Office
EP · EP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2023-03-06
Filing Date
2024-02-29
Publication Date
2026-01-14

AI Technical Summary

Technical Problem

Current driver attention monitoring systems for semi-autonomous vehicles are costly to develop and qualify for high ASIL levels, especially when using neural networks, due to the complexity of combining ISO26262 and ISO/PAS 21448 standards.

Method used

An electronic module with a secure block and a fallible block, where the secure block verifies the output of the fallible block to ensure data validity, allowing the use of artificial intelligence for calculations while maintaining a high level of reliability at a lower development cost.

Benefits of technology

This approach reduces the development and implementation costs of driver attention monitoring systems by separating functionalities into safe and fallible blocks, ensuring reliable output verification and meeting ASIL levels without the high expense of dedicated sensors.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure EP2024055291_12092024_PF_FP_ABST
    Figure EP2024055291_12092024_PF_FP_ABST
Patent Text Reader

Abstract

The invention relates to an electronic driving assistance module for a motor vehicle, the module comprising: -at least one secure block (U1, U2) that is suitable for generating a first item of output data (S1, S2) that has a high level of reliability; and - at least one fallible block (U3) that receives at least one item of input data relating to the motor vehicle, and that provides at least one second item of output data (S33), the second item of output data being dependent on the at least one item of input data and having a level of reliability that is lower than that of each first item of output data; and - a securing block (U4) which receives the first and second items of output data as input and which delivers, as output, a secure item of information (S4), the level of reliability of which is higher than that of the second item of output data.
Need to check novelty before this filing date? Find Prior Art

Description

Description Title of the invention: Electronic module for assisting in driving a motor vehicle Technical field of the invention

[0001] The present invention relates generally to safety in the automotive field.

[0002] It relates more specifically to an electronic module programmed and structured with the aim of helping a driver to drive his motor vehicle.

[0003] The invention finds a particularly advantageous application in the design of secure software for automating the driving of motor vehicles. State of the art

[0004] Modern motor vehicles have several computers that provide a large number of functions, including autonomous or semi-autonomous vehicle control functions.

[0005] These functions include, for example, the function of automatically keeping the vehicle in the center of its lane, or the adaptive cruise control function (which allows the vehicle's speed to be maintained at a set speed and, if necessary, to regulate this speed if traffic becomes denser in order to maintain appropriate safety distances).

[0006] These functions implement a significant amount of software, typically representing several million lines of code.

[0007] Some of these functions are critical to vehicle safety. Therefore, software must be developed according to strict design rules defined, for example, by the ISO26262 standard. Computer hardware and sensors (camera, radar, etc.) are also selected according to this standard.

[0008] This ISO26262 standard defines levels of requirement for automotive safety ranging from ASIL-A level (least critical level) to ASIL-D level (most critical level).

[0009] During the design of the vehicle, it is planned to develop each function in compliance with the ASIL level assigned to it.

[0010] Naturally, the more critical the function, the higher the ASIL level, and the more costly software development becomes, particularly in terms of development time.

[0011] In parallel with this, the SAEJ3016 standard defines degrees of driving delegation, the highest level (five) designating fully autonomous vehicles and the other levels designating vehicles requiring a more or less high attention.

[0012] In the context of partial vehicle automation (with a level below four), it is necessary to perform a driver attention monitoring function. This program may typically consist of monitoring that the driver has their hands on the steering wheel. Thus, the vehicle's semi-autonomous driving functions can only be implemented if the driver has their hands on the steering wheel.

[0013] The driver attention monitoring function must then also satisfy a given ASIL level (e.g. ASIL-B level).

[0014] Two strategies can be used to determine if the driver has their hands on the wheel.

[0015] A first strategy consists of measuring the torque exerted by the driver on the steering wheel while a second strategy consists of equipping the steering wheel with capacitive sensors.

[0016] The second strategy is the one that gives the best results, but it is much more expensive than the first which does not require any dedicated sensors (those used are already present in the vehicles being sufficient).

[0017] In this context, document US20210024075 then proposes using artificial intelligence (in this case a neural network) to improve the detection of the driver's hands on the steering wheel.

[0018] This technical solution proves to be effective but it has a major drawback which makes it unusable in practice: it is not possible to ensure at a reasonable cost that the neural network presents the desired ASIL level.

[0019] In addition, a new ISO / PAS 21448 standard has been introduced to cover defects related to intrinsic limitations of a function. Combining these two standards for a component embedding neural network-based functions makes their qualification extremely difficult.

[0020] This is why the best technical solution remains the one based on the second strategy, which we recall is the most expensive. Presentation of the invention

[0021] The present invention proposes a solution allowing the use of algorithms that are difficult to qualify at an ASIL level, while limiting their development cost.

[0022] More particularly, the invention proposes an electronic module for assisting in driving a motor vehicle, comprising: - at least one safe block suitable for generating a first output data which has a high level of reliability, and - at least one faulty block which receives at least one input data relating to the motor vehicle, and which provides at least one second output data, said second output data being a function of said at least one input data and having a reliability level lower than that of each first output data, and - a security block which receives as input the first and second output data and which provides as output secure information whose reliability level is higher than that of said second output data.

[0023] Thus, thanks to the invention, the security block allows, on the basis of the data transmitted by the secure blocks, to verify the data transmitted by the faulty block in order to guarantee their validity and to deduce secure information from them.

[0024] Thus, it is possible to use artificial intelligence to perform calculations, and then to check the result of these calculations not by redoing these calculations in a safe block, but simply by checking that the faulty block is working correctly.

[0025] This solution therefore proves to be inexpensive in terms of development and implementation on a vehicle.

[0026] Other advantageous and non-limiting characteristics of the electronic module according to the invention, taken individually or in all technically possible combinations, are the following: - said secure information indicates whether a driver of the motor vehicle is attentive; - said secure information indicates whether or not the driver has his hands on the steering wheel of the motor vehicle; - said secure information is determined based on the torque exerted by the driver on the steering wheel; - said at least one input data item relates to the torque exerted by a driver of the motor vehicle on a steering wheel of the motor vehicle, and said at least one second output data item is determined by comparing said at least one input data item with a threshold; - said at least one second output data is determined by means of a neural network; - the faulty block provides at least one other output data, the secure information being identical to said second output data if at least one condition is met, said condition being that said other output data is comparable to said first output data; - said other output data is calculated by the faulty block and is considered comparable to said first output data if it is equal to a value which is a function of said first output data; - said other output data is calculated by the faulty block and is considered comparable to said first output data if it is complementary to a function of said first output data; - the secure information is identical to said second output data if at least one condition is met, said condition being that said first output data indicates an absence of hardware error.

[0027] The invention also provides a motor vehicle comprising a chassis and bodywork elements which delimit a passenger compartment, at least two steered wheels, a steering system comprising a steering wheel which is located in the passenger compartment and which is connected to the steered wheels, and a torque sensor adapted to measure the torque exerted by the driver on the steering wheel, as well as an electronic module as mentioned above.

[0028] Of course, the various features, variants and embodiments of the invention may be combined with each other in various combinations to the extent that they are not incompatible or mutually exclusive. Detailed description of the invention

[0029] The description which follows with reference to the appended drawings, given as non-limiting examples, will make it clear what the invention consists of and how it can be implemented.

[0030] On the attached drawings:

[0031] [Fig.l] is a schematic perspective view of a motor vehicle according to the invention;

[0032] [Fig.2] is a schematic view of software for detecting a driver's grip on the steering wheel of the motor vehicle in [Fig.l].

[0033] In [Fig.l], a motor vehicle 1 is shown which is suitable for implementing the invention.

[0034] This is a car. Alternatively, it could be another type of vehicle (truck, motorcycle, bus, etc.).

[0035] Here, this vehicle 1 conventionally comprises a chassis and bodywork elements which delimit a passenger compartment in which there is in particular a seat for the driver 5 of the vehicle, a dashboard and a steering wheel 3. It also comprises wheels, at least two of which are steered.

[0036] This vehicle 1 comprises a powertrain, a braking system and a steering system for turning the vehicle (not visible in the figure). Conventionally, the steering system comprises an electronically controllable power steering actuator, the powertrain comprises an electronically controllable engine control actuator, and the braking system comprises an electronically controllable braking actuator.

[0037] This vehicle 1 is further equipped with at least one human-machine interface. In practice, the dashboard incorporates a display screen 4 and at least one is provided speaker (not visible).

[0038] The vehicle 1 also includes an electronic processing unit 2 which includes one or more computers (microprocessors or microcontrollers), memories and input and output interfaces.

[0039] Thanks to its input interfaces, the electronic processing unit 2 is adapted to receive various input data, which come from sensors or third-party computers. These input data are, for example, related to the motor vehicle and its external environment (position on the road, etc.).

[0040] The electronic processing unit 2 is in particular adapted to receive a signal E2 corresponding to the torque measured by a torque sensor exerted on the steering system. This measured torque corresponds in practice to the torque exerted by the driver on the steering wheel 3.

[0041] It is also suitable for receiving other signals E31 - E34, including for example the speed of motor vehicle 1.

[0042] By means of its output interfaces, the electronic processing unit 2 is adapted to control the human-machine interface in order to provide the driver with information. It is also adapted to control the power steering actuator, the engine control actuator, and the brake actuator.

[0043] Thanks to its memories, the electronic processing unit 2 stores a computer application, consisting of computer programs (or “software”) comprising instructions whose execution by the computers allows the implementation of the method described below.

[0044] In the remainder of this presentation, we will consider that each “software” makes it possible to implement a particular “function” to assist in driving the vehicle.

[0045] Here, we will consider in particular three software programs allowing two distinct functions of autonomous vehicle control and a function of monitoring the driver's attention to be executed.

[0046] One of these driving functions is the automatic regulation of the vehicle's speed, known as ACC (Adaptive Cruise Control).

[0047] With this function, the driver can select a speed setpoint. This may, for example, be a specific speed (such as 80 km / h), or a request telling the vehicle to travel, if possible, at the maximum speed permitted on the traffic lane being used. Based on this speed setpoint and data from sensors on board the vehicle, the ACC function can calculate control setpoints for the engine control actuator and the braking actuator. These setpoints are calculated so as to regulate the vehicle speed either at the speed setpoint as long as no third-party vehicle is too closely preceding vehicle 1, or at a reduced speed which depends on the speed of the third-party vehicle in front of it, in order to maintain an acceptable safety distance from it.

[0048] Another of these steering functions is keeping the vehicle in the center of its lane, known as the LCA function (from the English “Lane Centering Assist”).

[0049] This function allows you to automatically control the vehicle's steering so that it remains centered in its lane.

[0050] The monitoring function, which is more specifically the subject of this presentation, makes it possible to check that the driver is paying attention to the driving of his vehicle. It is based here on the detection of the driver's holding of the steering wheel 3.

[0051] This function, called the HOD function (from the English "Hands On Detection"), is necessary for the implementation of the other two functions in the sense that these two other functions can only be implemented if the driver keeps his hands on the steering wheel (permanently or at least intermittently).

[0052] At this stage, it can be noted that each function must be characterized by a level of reliability, hereinafter called “ASIL safety level” (from the English “Automotive Safety Integrity Level”).

[0053] This ASIL security level allows, on the basis of a risk analysis, to determine to what extent the software is able to implement the function safely.

[0054] The ASIL security level considered here will be established in accordance with the ISO26262 standard.

[0055] Thus, software with a guaranteed security level can be classified according to four levels, from the lower level ASIL-A to the higher level ASIL-D (level offering the greatest security), passing in order through levels ASIL-B and ASIL-C.

[0056] On the other hand, software that does not meet any particular security level will have a “QM” classification.

[0057] We will then say that a first software has a higher ASIL level than another if its ASIL level is classified at a higher level than that of this other software or if this other software is classified as “QM”.

[0058] It should also be noted that data and hardware can be certified by a security level. This security level will again be defined by the aforementioned standard. Thus, in the following, data, a sensor or a computer can be characterized by its ASIL level.

[0059] The invention proposes to simplify the design and development of software for assisting motor vehicle drivers, while ensuring an ASIL level that complies with the specifications.

[0060] To do this, it is proposed to separate, in the electronic module 20 from the electronic processing unit 2 which is responsible for implementing the driving assistance function considered (here the HOD function): - initial functionalities that can be developed with the required ASIL level and - second functionalities that cannot be, then adding a security block to verify that the second functionalities give reliable results based on the results given by the first functionalities.

[0061] Therefore, the electronic module 20 is split into several distinct software components hereinafter called “blocks”, including: - at least one safe block Ul, U2 satisfying the required ASIL level, - at least one U3 faulty block with a lower ASIL level (typically a QM level), and - a safety block U4 which makes it possible to check the validity of the outputs of each faulty block U3 on the basis of the output of at least one safe block Ul, U2, and which preferably has the desired ASIL level.

[0062] These blocks are separate software components. They also preferably form separate hardware components. In other words, the software components are preferably stored in separate memories and executed by separate computers (processors, logic units, etc.).

[0063] Once these blocks have been defined, it is planned to create certification scenarios at the desired ASIL level for the entire driver assistance function. These scenarios are preferably developed to validate this ASIL level in extreme cases, so as to reduce the number of scenarios to be considered.

[0064] It is thus possible to know the coverage of the chosen model, that is to say the percentage of validated scenarios. The objective is that all the scenarios are validated, so that all the functionalities are guaranteed. We say that the coverage rate is 100%.

[0065] In the context of this presentation, the driving assistance function which will be considered more precisely will therefore be the HOD function, for detecting the driver's steering wheel position.

[0066] This function will be based on the detection of a torque exerted on the steering wheel 3 by the driver 5. In other words, the steering wheel will be devoid of capacitive sensors to detect whether or not the driver is placing his hands on the steering wheel. The function will instead be executed on the basis of the data emitted by the torque sensor exerted on the steering wheel.

[0067] Here, the electronic module 20 implementing this function comprises two safe blocks Ul, U2, i.e. two software components making it possible to provide data at the desired ASIL level, here at ASIL B level.

[0068] The first safe block Ul is a component that allows for the determination of both software and hardware faults. Typically, this block allows for the detection of a fault in the power steering, a fault in the signals circulating on the vehicle's CAN network, a fault in the electronic processing unit 2... Such a block being already known to those skilled in the art, it will not be described further here. It can only be specified that it emits an output signal SI, appearing for example in the form of a boolean equal to 0 as long as no fault is detected and to 1 otherwise.

[0069] The second safe block U2 is an interface component for receiving signals E2 from networks external to the electronic processing unit 2, typically CAN or Ethernet networks. This second safe block U2 emits an output signal S2, for example in the form of a variable whose value is equal to the torque exerted by the driver 5 on the steering wheel 3. Typically, it may be an analog-digital interface.

[0070] The electronic module 20 here comprises a single faulty block U3, i.e. a single software and hardware component which provides data not at the desired ASIL level, here data at the QM level.

[0071] This faulty block U3 nevertheless constitutes the heart of the electronic module 20 since it is this which is able to determine whether or not the driver has his hands on the steering wheel.

[0072] It receives as input the output signal S2 from the second safe block U2 (the torque exerted on the steering wheel).

[0073] Here he also receives several other data, namely: - an E31 signal indicating the vehicle speed, - an E32 signal indicating any driver request relating to the LC A function (does he wish to activate it or not?), - a signal E33 indicating the active or inactive state of the LC A function and the ACC function, and - an E34 signal relating to the friction torque detected on the steering system.

[0074] Based on this information, this block is able to first provide a signal S33 relating to whether or not the driver is holding the steering wheel. This signal is presented, for example, in the form of a Boolean equal to 0 as long as the driver has his hands on the steering wheel and 1 otherwise.

[0075] This fallible block U3 is also able to provide two signals S31, S32 which will be used to check whether the signal S33 is reliable. These two signals are preferably formed by forcing the fallible block U3 to execute operations. The reliability of this fallible block U3 can thus be checked by verifying that the results of these calculations are correct.

[0076] In practice, one of these signals S31 is equal to the average of the torque exerted by the driver on the steering wheel over a predetermined period, for example of the order of a second. Another of these signals S32 comes from a signal coding operation S33. In this case, it is a mirror version of the S33 signal, which is therefore presented in the form of a boolean equal to 1 as long as the driver has his hands on the steering wheel and 0 otherwise.

[0077] At this point, we can describe in more detail how the signal S33 is generated here, relating to whether or not the driver is holding the steering wheel.

[0078] The faulty block U3 here comprises three units U31, U32, U33.

[0079] The first and second units U31, U32 are designed to determine in parallel, and on the basis of the received signals, two evaluations of the signal S33.

[0080] Alternatively, only one of the two evaluations could be performed, in which case signal S33 would be equal to that evaluation.

[0081] Here, one of these assessments is performed by thresholding.

[0082] For this operation, the driver is considered to have their hands on the steering wheel when the difference between the measured torque and the friction torque exceeds a predetermined threshold. This threshold may vary, for example, depending on the vehicle speed.

[0083] The other of these evaluations is performed using a neural network. It is based on some of the inputs, here on all of them.

[0084] This neural network could be of any type. This is a feedforward / recurrent neural network ("RNN").

[0085] This neural network has an input layer, at least one hidden layer, and an output layer, with several artificial neurons on the hidden layers.

[0086] The activation functions used within the hidden layers are, for example, of the sigmoid type.

[0087] The neural network will be trained, for example, by backpropagation of the error gradient on a training set. The training set will correspond to data values ​​that are already known.

[0088] We will not define this neural network further here, but we can only specify that it is very difficult to qualify at ASIL B level. This is also the reason why the fallible block U3 is not qualified here at ASIL B level.

[0089] Based on the two evaluations, it is possible to determine the S33 signal, for example by considering one or the other of the two evaluations when they differ, depending on the configuration in which the vehicle is located (for example, thresholding works better at low speed but less well at high speed).

[0090] The third unit U33 integrated into the faulty block U3 is designed to select one or the other of the two evaluations. It also makes it possible, on the basis of the signal S2, to determine the average of the torque exerted on the steering wheel over a predetermined period (the signal S31). It also makes it possible, on the basis of the signal S33, to determine a mirror version of this signal S33 (i.e. the signal S32).

[0091] As explained above, these two signals S31 and S32 will allow check that the U3 fault block is functioning correctly. Here, two separate signals are used to check that the U3 fault block is functioning correctly, these signals preferably being formed using operations of different types on separate signals. Alternatively, more or fewer signals could be used to check that the U3 fault block is functioning correctly.

[0092] We can now focus on the security block U4 which receives all the output signals from the fallible blocks U3 and safe blocks Ul, U2.

[0093] This security block U4 is designed to validate or not the signal S33, under at least one condition. In the embodiment described and shown, three conditions are necessary to validate the signal S33.

[0094] The first condition is controlled by a block U41, which receives as input the signal SI (relating to the presence or absence of a fault, both software and hardware).

[0095] This block U41 practically checks whether a fault has been detected or not. As long as no fault is detected, this block U41 delivers a signal S41 corresponding to a boolean equal to 1. Otherwise, the signal is zero.

[0096] The second condition is controlled by two blocks U42 and U43.

[0097] Block U42 receives signal S2 (the measured torque) as input and deduces an average of the torque measured over the predetermined period.

[0098] Block U43 compares this average with that calculated by block U3 (signal S31). In practice, it delivers a signal S43 corresponding to a boolean equal to 1 if the two averages are of the same order. Otherwise, the signal is zero.

[0099] It should be noted here that the consistency check of the two average torque values ​​is done by allowing a margin of error over a maximum duration. Typically, a maximum margin of 0.1 Nm can be allowed for a maximum of 100 ms.

[0100] The advantage of this mechanism is that it will allow the validity of the S33 signal to be checked by verifying that the U3 block calculates a reliable torque average.

[0101] The third condition is controlled by block U44, which receives signals S32 and S33 as input, which are assumed to be complementary. If this is the case, the third condition is validated. This block U44 then outputs a signal S44 corresponding to a Boolean equal to 1. Otherwise, the signal S44 is zero.

[0102] The advantage of this mechanism is once again to be able to check the validity of the S33 signal by verifying that the U3 block gives reliable results, thus meaning that the component is not corrupted and that there was no transmission error between these two components.

[0103] Then, if the three conditions are simultaneously fulfilled, that is to say if all the signals S41, S43 and S44 are equal to 1, the consolidation block U45 provides at the output of the electronic module 20 a signal S4 equal to the signal S33 calculated by the block U3. In other words, it is thus considered that the signal S33 from the fallible block U3 is reliable. and that it reliably indicates whether or not the driver has his hands on the steering wheel.

[0104] Otherwise, signal S4 takes a different value from that of signal S33. This is by default a value that should allow the LC A and ACC functions to be deactivated. In other words, it is considered that the signal S33 from the faulty block U3 is not reliable and that, not being able to determine with certainty whether or not the driver has his hands on the steering wheel, it is necessary to deactivate the LCA and ACC functions. It should be noted that this deactivation may be progressive, and take place after several alerts to the driver (displayed on the screen and emitted by the speakers).

[0105] It is understood that the U4 security block, which responds to ASIL B level and which is based on data from secure blocks, makes it possible to transform an S33 signal at QM level into an S4 signal at ASIL B level.

[0106] The present invention is in no way limited to the embodiment described and shown, but those skilled in the art will be able to provide any variation in accordance with the invention.

Claims

Claims

1. Electronic module (20) for assisting in driving a motor vehicle (1), comprising: - at least one safe block (Ul, U2) adapted to generate a first output data (SI, S2) which has a high level of reliability, and - at least one faulty block (U3) which receives at least one input data item relating to the motor vehicle, and which provides at least one second output data item (S33), said second output data item (S33) being a function of said at least one input data item and having a reliability level lower than that of each first output data item (SI, S2), and - a security block (U4) which receives as input the first and second output data (S1, S2, S33) and which provides as output secure information (S4) whose reliability level is higher than that of said second output data (S33).

2. Electronic module (20) according to claim 1, wherein said secure information (S4) indicates whether a driver of the motor vehicle (1) is attentive, preferably by providing information on whether or not he has his hands on a steering wheel (3) of the motor vehicle (1).

3. Electronic module (20) according to claim 2, wherein said secure information (S4) is determined as a function of the torque exerted by the driver on the steering wheel (3).

4. Electronic module (20) according to one of claims 1 to 3, wherein said at least one input data item relates to the torque exerted by a driver of the motor vehicle (1) on a steering wheel (3) of the motor vehicle (1), and said at least one second output data item (S33) is determined by comparing said at least one input data item with a threshold.

5. Electronic module (20) according to one of claims 1 to 4, wherein said at least one second output data (S33) is determined by means of a neural network.

6. Electronic module (20) according to one of claims 1 to 5, in which the faulty block (U3) provides at least one other output data (S31, S32), the secure information (S4) being identical to said second output data (S33) if at least one condition is met, said condition being that said other output data (S31, S32) is comparable to said first output data (S1, S2).

7. Electronic module (20) according to claim 6, wherein said other output data (S31, S32) is calculated by the fallible block (U3) and is considered comparable to said first output data (SI, S2) if it is equal to a value which is a function of said first output data (SI, S2).

8. Electronic module (20) according to one of claims 6 and 7, wherein said other output data (S31, S32) is calculated by the fallible block (U3) and is considered comparable to said first output data (SI, S2) if it is complementary to a function of said first output data (SI, S2).

9. Electronic module (20) according to one of claims 1 to 8, wherein the secure information (S4) is identical to said second output data (S33) if at least one condition is met, said condition being that said first output data (S1, S2) indicates an absence of hardware error.

10. Motor vehicle (1) comprising a chassis and bodywork elements which delimit a passenger compartment, at least two steered wheels, a steering system comprising a steering wheel (3) which is located in the passenger compartment and which is connected to the steered wheels, and a torque sensor adapted to measure the torque exerted by the driver on the steering wheel, characterized in that it further comprises an electronic module (20) according to one of claims 1 to 9.