Patent Application
20240190383
In some electronic parking systems in a vehicle (e.g., a truck towing a trailer), the parking brake cannot be released unless certain conditions are satisfied. For example, in some electronic parking systems, the parking brake cannot be released unless the vehicle driver is detected to be in the driver seat, the driver's seat belt is buckled, the driver's door is closed, the foot brake pedal is depressed, and/or the identity of the driver is verified (e.g., through facial recognition or a matching thumbprint or retina scan).
In one embodiment, a non-transitory computer-readable storage medium storing a computer program having instructions that, when executed by one or more processors in a vehicle, cause the one or more processors to: determine whether a driver of the vehicle is an authorized user of the vehicle; determine whether the driver is alert; and allow the vehicle to unpark only if it is determined that the driver is the authorized user of the vehicle and that the driver is alert.
In another embodiment, a method is provided that is performed in a vehicle. The method comprises performing a field sobriety test on the driver of the vehicle using one or more components in the vehicle; and allowing a parking brake controller in the vehicle to unpark the vehicle only in response to the driver passing the field sobriety test.
In yet another embodiment, a system is provided comprising: a parking brake controller configured to unpark a vehicle; and means for allowing the parking brake controller to unpark the vehicle in response to determining that a driver of the vehicle is alert.
Other embodiments are possible, and each of the embodiments can be used alone or together in combination.
In operation, when the controller 30 receive the electronic brake request signals from a brake actuator 20 (e.g., a foot brake module), the controller 30 maps the signals representing the displacement to a requested deceleration and commands electro-pneumatic modules (EPMs) 42, 44, 46 on the undriven, optional, and driven axles to apply the appropriate amount of pressure needed to achieve that deceleration given various variables, such as, but not limited to, vehicle weight, weight distribution, whether a trailer is present, and driving conditions. In an electronic braking system (EBS), relays and modulators on an axle can be combined into an EPM, which is capable of electronically applying, holding, and releasing air to decelerate a wheel end of the axles. The EPMs 42, 44, 46 can cause the vehicle to decelerate in any suitable way. For example, in the embodiment shown in
Turning first to the parking brake controller 90, the parking brake controller 90 is part of a parking system comprising parking brake valves 120, a compressed air supply 140 (e.g., the rear and front reservoirs 4, 5 from
To release the parking brake, compressed air needs to flow from the compressed air supply 140 into the spring brake chambers 160 (via lines 130 and 150) to apply pneumatic pressure to the parking brake springs (via line 170) to release them from the braking position. The supply of compressed air from the compressed air supply 140 to the spring brake chambers 160 to release the parking brake is regulated by a parking brake valve 120, which is controlled by the processor 92 in the parking brake controller 90. In this example, the processor 92 in the parking brake controller 90 provides a signal (over channel 110) to open the parking brake valve in response to both driver demand to unpark the vehicle and a control signal from the processor 32 in the controller 30 indicating that it is ok for the parking brake controller 90 to satisfy the driver's demand. As noted above, the functionality of processors 32, 92 can be combined into one processor or distributed over more than two processors, which is why the phrase “at least one processor” is sometimes used herein.
To provide a driver demand/request to unpark the vehicle, the driver can interact with a user input device in the cabin of the vehicle (e.g., by pushing/pulling a button). However, as mentioned above, in this embodiment, that driver demand to unpark the vehicle will only be acted upon if the controller 30 allows it to. More specifically, the controller 30 can provide one or more safety checks and allow the driver's demand to be acted upon only if those safety check(s) are satisfied. With reference to
In this embodiment, one or both of the following checks can be made: (1) a determination of whether the driver is authorized to use the vehicle and (2) a determination of whether the driver is alert enough to operate the vehicle. Of course, this is only an example, and fewer/more/different checks can be made. This example will now be described with reference to the flow chart in
As shown in
To determine whether the driver is a recognized user of the vehicle, the processor 32 can communicate information with an external server via the transceiver 12 (act 320). For example, the processor 32 can send, to the server, an image of the driver captured by the camera 2, and the server can compare the image to a library of stored images of recognized users of the vehicle and return a response to the processor 32 indicating whether or not the driver is a recognized user (e.g., whether there is a match to the images in the library). Alternatively, the processor 32 can be provided with the relevant information (e.g., from the server or another entity at or before the time the information in needed) to be stored in a local database in the vehicle for the processor 32 to do the image comparison. As another alternative, instead of or in addition to using an image of the driver captured by the driver-facing camera 2, other information about the driver can be used to determine whether the driver is a recognized user of the vehicle. Such other information can include, but is not limited to, a thumbprint or retina scan of the driver, a bar code on a driver's ID card, a password, etc.).
If the driver is not a recognized user of the vehicle, the processor 32 does not allow the vehicle to unpark regardless of driver demand (act 325) (e.g., the processor 32 does not send a release signal to the parking brake controller 90 or affirmatively sends a signal to the parking brake controller 90 not to release the parking brake). The processor 32 can also inform a fleet manager or other entity (in real time or later) of the unauthorized user (act 330). However, if the driver is a recognized user of the vehicle, the processor 32 then proceeds with the next step of determining whether the driver is alert (e.g., awake, sober, etc.) (act 335). To make this determination on whether it is safe for the driver to drive the vehicle, the processor 32 can provide one or more alertness tests to the driver, which may or may not involve exchanging information with the server (act 340). The results of these test(s) can be compared to a threshold to determine whether or not the driver is considered “alert” (e.g., if the results are above the threshold, the driver is considered alert; otherwise, the drive is not considered alert). Multiple thresholds can be used to determine degrees of alertness (e.g., if the results are below a first threshold, the driver is considered not be alert; if the results are above a second threshold, the driver is considered to be alert; but if the results are between the first and second thresholds, the driver may have some alertness impediment, where the driver may or may not be considered “alert enough’ to drive. Of course, this is just one example, and other implementations (e.g., using more threshold level, not using threshold levels, using artificial intelligence to analyze the results, etc.) can be used.
If the driver is not determined to be alert, the processor 32 does not allow the vehicle to unpark regardless of driver demand (act 345) (e.g., the processor 32 does not send a release signal to the parking brake controller 90 or affirmatively sends a signal to the parking brake controller 90 not to release the parking brake). The processor 32 can also inform a fleet manager or other entity (in real time or later) of the driver's condition (act 350). Conversely, if the driver is determined to be alert, the processor 32 can allow the vehicle to unpark in response to driver demand (act 365). Optionally, the processor 32 can provide additional testing. For example, as shown in
Any suitable type of testing can be used to determine an alertness level of a driver, such as a brake interlock field sobriety test. In one embodiment, the processor 32 performs a version of the National Highway Traffic Safety Administration's (NHTSA's) field sobriety test for a seated driver using one or more components in the vehicle. To conduct the test, the processor 32 can cause pre-recorded audio tracks (e.g., instructions) to be played from the speakers 4 and/or cause visual instructions to be displayed on the touch screen display device 22. For example, to emulate a horizontal Nystagmus test, where an object is tracked with the eyes, the processor 32 can cause indicator lights or blinkers in on the dashboard to illuminate, and the characteristic “dancing” movement of the driver's eyes can be tracked by the driver-facing camera 2. If the processor 32 determines that the driver's eye movements exceed a frequency or amplitude threshold, the processor 32 can consider that an indication that the driver's ability to drive the vehicle is impaired.
As another example, the processor 32 can output instructions via the speakers 8 and/or touch screen 22 to test the driver's reaction, thinking, and coordination skills (e.g., as an initial filter for further possible fleet or server examination, camera and other information from the vehicle can be send to the server for analysis). Such instructions can include, but are not limited to, instructing the driver to touch a particular finger to his nose, touch particular fingers of both hands to his nose at the same time (e.g., either both thumbs to the nose or the hands in a chain after each other (“cocking a snook”)). The processor 32 can also recognize “landmarks” on the driver's face (e.g. mouth, nose tip, etc.), as well as a location of the driver's hands, and the processor 32 can analyze images of the driver taken by the camera 2 to determine (locally or through the use of the external server) to determine whether the driver satisfactorily passed the test. The images from the camera 2 can also be used to analyze the driver's head pose (e.g., yaw, roll, pitch) and whether the driver's eyes are open or closed, which can be an indication of alertness.
Of course, many other tests are possible. For example, the processor 32 can instruct the driver to press a certain button on the dashboard (e.g., on the fifth blinking of the right-side indicator, where the left blinker is interspersed into the right-side blinking, which is akin to testing the ability to follow instructions used in the (validated) walk (in a straight line) and turn test). As another example, to test reaction time, the processor 32 can instruct the driver to press a certain button on the dash as soon as it starts blinking, with or without advanced warning as to which side of the dash the test will take place. Other tests that give a stimulus and monitor the response time (e.g., the elapsed time between stimulus and response) can be used. Further, other components in the vehicle can be used to perform the test, such as, but not limited to, the vehicle's turn signals 8, speakers 8, biometric scanner 20 (e.g. a breath analyzer), touch screen 22, and microphone 4 (e.g., to record and analyze the driver's voice to detect slurring; repeating of particularly difficult to pronounce phrases may be requested, for example).
Because field sobriety tests are not necessarily pass/fail tests but rather an indication regarding a person's state, further testing/monitoring of the driver may be desired after “passing” the test after a preliminary brake release is allowed (e.g., if the results are between the first and second thresholds mentioned above). For example, as shown in
Any suitable type of testing can be used to provide further in-vehicle driving quality tests, such as, but not limited to, the type of testing discussed above. Additionally or alternatively, the processor 32 can monitor a standard deviation of lane position (SDLP)) (e.g., using a forward-facing camera to detect lane swerving), monitor how closely the driver is driving to a forward vehicle (e.g., by calculating the percentage of time spent at <X seconds to the forward vehicle ahead), or monitor any other input to look for abnormal deviations from acceptable performance (e.g., as specified in fleet or individual driver standards). Of course, these are merely examples, and other types of testing can be used.
There are many alternatives that can be used. For example, if the vehicle is in an emergency situation and the driver is unable to move the vehicle (e.g., if a tow truck driver needs to unpark the truck), the above checks can be bypassed from a possible message originating from a fleet manager or another authority source.
It should be understood that all of the embodiments provided in this Detailed Description are merely examples and other implementations can be used. Accordingly, none of the components, architectures, or other details presented herein should be read into the claims unless expressly recited therein. Further, it should be understood that components shown or described as being “coupled with” (or “in communication with”) one another can be directly coupled with (or in communication with) one another or indirectly coupled with (in communication with) one another through one or more components, which may or may not be shown or described herein. Additionally, “in response to” can be directly in response to or indirectly in response to.
It is intended that the foregoing detailed description be understood as an illustration of selected forms that the invention can take and not as a definition of the invention. It is only the following claims, including all equivalents, which are intended to define the scope of the claimed invention. Accordingly, none of the components, architectures, or other details presented herein should be read into the claims unless expressly recited therein. Finally, it should be noted that any aspect of any of the embodiments described herein can be used alone or in combination with one another.
