Vehicle with integrated tachograph

Abstract

The present disclosure provides for a "vehicle with integrated tachograph". A vehicle is disclosed that includes a tachograph, a sensor unit, and a processor. The sensor unit can capture inputs associated with an interior portion of the vehicle and a surrounding environment of the vehicle. The processor can determine that a tachograph card is connected to the tachograph. In response to such a determination, the processor can authenticate a driver based on inputs obtained from the sensor unit and driver information obtained from the tachograph card. The processor can perform a predefined action when the driver is not authenticated.

Description

Technical Field

[0001] This disclosure relates to vehicles, and more specifically to vehicles with integrated driving recorders. Background Technology

[0002] A driving recorder (DRL) is a device used in commercial vehicles to record driver activities, such as driving time, rest time, and total mileage. Each driver typically has a DRL card, which the driver inserts into the DRL, and the DRL then records and registers the driver's activities on the card. Commercial vehicles generally expect to record such driver activities. This recording also enables fleet managers to optimize driver driving and rest times and promote healthy working conditions for drivers. Summary of the Invention

[0003] This disclosure describes a vehicle with an integrated driving recorder. By integrating the driving recorder into the vehicle, the recorder can utilize the vehicle's existing sensors, which significantly enhances the recorder's performance and enriches the driver's experience of operating the recorder. Specifically, by integrating the driving recorder, the vehicle can provide several additional features or benefits to drivers, fleet managers, etc., in situations where it might not be possible to attach the driving recorder as an aftermarket accessory to the vehicle's conventional systems. Examples of such additional features are briefly described below.

[0004] In one exemplary aspect, when a driver inserts a driver-associated dashcam card (“card”) into the dashcam and attempts to drive the vehicle, the vehicle can use its existing internal cameras to authenticate the driver. If the driver is not authenticated, the vehicle can output an alert notification to a user device / computing device / server associated with the fleet manager or prohibit the driver from driving the vehicle, thereby preventing unauthorized use of the card and / or the vehicle.

[0005] In another exemplary aspect, the vehicle may enable the card to act as a vehicle key, allowing the driver to start / drive / unlock the vehicle by using the card. The vehicle may also enable the driver to use the vehicle's microphone or sensor units to provide input or record activity to the driving recorder via audible or gesture commands.

[0006] The vehicle can also issue an alert notification when the driver leaves the vehicle while the card remains inserted in the dashcam. In another exemplary aspect, the vehicle can issue another alert notification when it determines that the driver's driving time is approaching or exceeding the remaining allocated driving time on the card. This alert notification can remind the driver to take a break and thus promote healthy driving habits.

[0007] The vehicle can also use input from its sensor units to check if the driver's breathing or heart rate has increased, and can output recommendations for the driver to rest or increase rest time in response to such determination. The vehicle can also use its human-machine interface (HMI, which can have a display much larger than the dashcam's screen) to display driver and / or trip-related information, which can greatly enhance the driver's experience operating the vehicle / dashcam. For example, the vehicle can have the HMI display information associated with the driver's history stored on the card, activities for the upcoming week with permitted driving time, countries visited and historical toll payments, paper left in the dashcam printer, driving records for the most recent 15 or 28 days, etc.

[0008] This disclosure discloses a vehicle that provides drivers (and / or fleet managers) with various additional features and benefits by integrating a driving recorder into the vehicle, which is not possible in conventional systems where driving recorders are added to vehicles as aftermarket accessories. The integrated driving recorder can utilize existing vehicle sensors, which significantly enhances the performance of the driving recorder and the driver's experience using it. This further enables fleet managers to remotely access driver recordings, eliminating the need for fleet managers to travel to the vehicle and obtain printouts from the driving recorder.

[0009] These and other advantages of this disclosure are provided in detail herein. Attached Figure Description

[0010] Specific embodiments are illustrated with reference to the accompanying drawings. The same reference numerals may be used to indicate similar or identical items. Various embodiments may utilize elements and / or components other than those shown in the drawings, and some elements and / or components may not be present in various embodiments. Elements and / or components in the drawings are not necessarily drawn to scale. Throughout this disclosure, singular and plural terms may be used interchangeably depending on the context.

[0011] Figure 1 An exemplary vehicle with an integrated driving recorder according to this disclosure is depicted.

[0012] Figure 2 A block diagram of a system for operating a vehicle with an integrated driving recorder, according to the present disclosure, is depicted.

[0013] Figure 3 An exemplary view depicting a driver leaving a vehicle with a dashcam card inserted in the dashcam, according to the present disclosure.

[0014] Figure 4 An exemplary view of a parked vehicle according to this disclosure is depicted.

[0015] Figure 5 An exemplary view of a human-machine interface (HMI) for a vehicle according to this disclosure is depicted.

[0016] Figure 6 A flowchart is depicted for an exemplary method for operating a vehicle with an integrated driving recorder according to the present disclosure. Detailed Implementation

[0017] The present disclosure will be described more fully below with reference to the accompanying drawings, which illustrate exemplary embodiments of the present disclosure and are not intended to be limiting.

[0018] Figure 1 An exemplary vehicle 100 with an integrated driving recorder 102 according to this disclosure is depicted. Vehicle 100 can take the form of any passenger or commercial vehicle, such as an automobile, work vehicle, crossover, truck, van, minivan, taxi, bus, etc. Vehicle 100 can be a manually driven vehicle or can be configured to operate in a partially / fully autonomous mode. Furthermore, vehicle 100 can include any powertrain system, such as a gasoline engine, one or more electric actuators, or a hybrid system.

[0019] The driving recorder 102 may include multiple components, including but not limited to a driving recorder host unit that may be located on the vehicle's dashboard (such as...). Figure 1 The device includes a driving recorder (as shown), a card reader, a printer, and one or more buttons for receiving input from the driver. It is known that a driving recorder (e.g., driving recorder 102) is used in commercial vehicles (e.g., trucks, buses, etc.) to record interactions with the driver (e.g., ...). Figure 1 The driving recorder 102 is a device that associates driving and rest time, vehicle speed, distance traveled, etc., with the driver 104 depicted in the description. The driving recorder 102 encourages the driver 104 to drive the vehicle 100 according to best practices defined by the authorities and to take the recommended amount of rest during the trip. The driving recorder 102 also facilitates the authorities and / or fleet managers of the vehicle to check whether the driver 104 is driving the vehicle 100 according to defined best practices and adhering to healthy driving and rest behaviors.

[0020] In some respects, a driving recorder card 106 can be assigned to driver 104, which can be a smart card with a digital driving recorder. Whenever driver 104 wishes to drive vehicle 100, driver 104 may need to insert the driving recorder card 106 into the driving recorder card reader of driving recorder 102 (e.g., ...). Figure 1(As shown). The driving recorder card 106 stores driver information, including but not limited to the driver's name and identity, driver's image, historical driving time and rest time, historical driving speed, driving distance, driving location, etc. Most of the information stored on the driving recorder card 106 is determined by the driving recorder 102. For example, when driver 104 is driving vehicle 100, driving recorder 102 determines the driver's driving time, rest time, driving speed, driving distance, driving location, etc., and stores this information on the driving recorder card 106 as driver information or a "record". Such stored information can be accessed by authorities and / or vehicle fleet managers via the driving recorder card 106 to examine the activities and / or performance associated with driver 104.

[0021] In conventional systems, a dashcam is an external unit attached to the vehicle. Such systems include their own antenna and motion sensors, detecting the vehicle's speed, location, rest or shutdown times, etc. While these conventional systems do capture driver activity to some extent, they do not optimally utilize the vehicle's existing sensors and components. Integrating a dashcam with the vehicle's existing sensors can significantly enhance its performance and provide additional features to drivers, fleet managers, and others, enriching the dashcam's user experience.

[0022] In view of this, this disclosure proposes a vehicle 100 in which a driving recorder 102 is integrated. Specifically, the driving recorder 102 is integrated into the vehicle 100 during the manufacturing or assembly stage of the vehicle, thereby eliminating the need to attach the driving recorder 102 externally to the vehicle 100 after purchase. Furthermore, in an exemplary aspect, since the driving recorder 102 is integrated with the vehicle 100, the driving recorder 102 uses the vehicle's existing V2X antenna (or vehicle-to-the-outside antenna) and motion sensors to record the driver's activities. Moreover, due to the integration of the driving recorder 102 with the vehicle 100, the vehicle 100 is able to provide several additional features to the driver 104, fleet manager, etc., which might not be possible in a conventional system. Examples of such additional features are briefly described below and will be discussed later. Figure 2 Detailed description.

[0023] In one exemplary aspect, when driver 104 inserts card 106 into driving recorder 102 and attempts to drive vehicle 100, vehicle 100 can use the vehicle's existing interior cameras to authenticate driver 104. In this case, as an example, vehicle 100 can first obtain an image of the driver recorded on card 106. Vehicle 100 can then compare the obtained driver image with a real-time driver image captured by the vehicle's interior cameras (e.g., when driver 104 enters vehicle 100 and sits in the driver's seating area). When the two images match (meaning driver 104 is authenticated), vehicle 100 can enable driver 104 to use vehicle 100, and when the two images do not match (meaning driver 104 is not authenticated), one or more predefined actions can be performed. For example, in the latter case, vehicle 100 can output an alarm notification to a user device / computing device / server associated with a fleet manager, thereby notifying the fleet manager that an unauthenticated driver is attempting to drive vehicle 100. As another example, when driver 104 is not certified, vehicle 100 can prohibit driver 104 from driving vehicle 100 (for example, in this case, vehicle 100 is not allowed to move out of parking gear).

[0024] In another exemplary aspect, vehicle 100 may enable card 106 to act as a vehicle key, thereby allowing driver 104 to start / drive vehicle 100 by inserting card 106 into dashcam 102. This ensures that driver 104 does not forget to insert card 106 into dashcam 102 before driving vehicle 100. Vehicle 100 may also enable driver 104 to move vehicle 100 out of parking position only when driver 104 inserts card 106 into dashcam 102. In some aspects, vehicle 100 may determine that card 106 is inserted into dashcam 102 based on signals obtained from dashcam 102. As an example, dashcam 102 may generate a trigger signal when card 106 is inserted. Vehicle processor (in...) Figure 2 The processor (shown as processor 242) can receive the trigger signal and, in response to receiving the trigger signal, determine that card 106 is inserted into driving recorder 102. Then, vehicle 100 can enable driver 104 to move vehicle 100 out of parking mode.

[0025] In another exemplary aspect, vehicle 100 may enable driver 104 to use the vehicle's microphone or the vehicle's sensor unit (in... Figure 2The system (shown as vehicle sensing system 230) provides input or recording activity to the driving recorder 102 via audible or gestural commands. For example, driver 104 can provide input to the driving recorder 102 via audible or gestural commands captured by the vehicle's sensor units / microphones, relating to whether driver 104 is performing a task other than driving (e.g., loading, unloading, paperwork, etc.) or taking a break, driver availability, print requests, etc. In this case, the vehicle's sensor units / microphones can capture the driver's audible or gestural commands and transmit them to the driving recorder 102 (which can store these driver inputs as driver information / records on card 106).

[0026] In another exemplary aspect, vehicle 100 may use input obtained from the vehicle's sensor units to check / determine whether driver 104 has left vehicle 100 (or the area immediately adjacent to vehicle 100) and whether card 106 remains inserted in dashcam 102. In this case, for example, vehicle 100 may analyze images of the driver captured by an external camera of the vehicle to determine that driver 104 has left vehicle 100, and use signals obtained from dashcam 102 to determine that card 106 remains inserted in dashcam 102. In response to this determination, vehicle 100 may (e.g., via the vehicle's sound exciter or the driver's user device) output an alarm notification to driver 104, which may remind driver 104 to remove card 106 from dashcam 102 when leaving vehicle 100.

[0027] In another exemplary aspect, when driver 104 removes card 106 from driving recorder 102 (as determined by signals obtained from driving recorder 102), vehicle 100 may have interior and exterior cameras capture images of the vehicle's interior and surrounding environment to record the vehicle's parking position and / or condition. These images may be stored on an external server and / or vehicle memory (and / or on card 106 when driver 104 later reinserts it), allowing authorities and / or fleet managers to retrieve and access them to check whether driver 104 is adhering to defined best practices. In some aspects, in such cases, vehicle 100 may additionally record and store information associated with the vehicle's radar distance from adjacent vehicles, tire inflation values, etc., which may facilitate an overall assessment of the driver's performance by authorities and / or fleet managers.

[0028] In another exemplary aspect, when vehicle 100 determines that the driver's driving time is approaching or exceeding the remaining allocated driving time on card 106, vehicle 100 may output an alarm notification. In this case, as an example, vehicle 100 may base its alert on the control unit of the vehicle (in... Figure 2The input obtained by the vehicle (VCU 208) is shown in the diagram to determine the driver's actual driving time and compare it with the allocated driving time recorded / stored on card 106. When the difference between the actual driving time and the allocated driving time decreases below a predefined threshold, the vehicle 100 can output an alarm notification. This alarm notification can remind the driver 104 to take a break and thus promote healthy driving habits.

[0029] In another aspect, vehicle 100 can output information on the driver's user device associated with rest / break time determined from card 106, such as (when driver 104 may be resting), allowing driver 104 to plan their remaining rest time accordingly. Vehicle 100 can also output daily / weekly driving and rest time reports on user devices associated with driver 104 and fleet manager. Additionally, vehicle 100 allows fleet manager remote access to driver information associated with driver 104, which may be stored on an external server. This eliminates the need for driver 104 to access such information by printing it from driving recorder 102.

[0030] Vehicle 100 can also use input from the vehicle's sensor units to check whether the driver's breathing or heart rate has increased (e.g., has become greater than a predefined healthy / healthy threshold), and can output a recommendation for the driver 104 to rest or increase the rest time in response to such determination. In this case, as an example, vehicle 100 can obtain input or a driver image captured by the vehicle's radar sensor or thermal image sensor, and compare the captured image with pre-stored driver images (e.g., driver images when the driver 104 is likely healthy). If the captured image is substantially different from the pre-stored driver image, vehicle 100 can determine that the driver's breathing or heart rate may have become greater than a predefined healthy threshold. In response to this determination, vehicle 100 can output the aforementioned recommendation.

[0031] Vehicle 100 can also monitor the state of charge (SoC) level of the vehicle battery and perform remedial actions if the SoC level is too low to support (or provide power to) the driving recorder 102 during the expected off or rest period of vehicle 100 / driver 104. In this case, as an example, vehicle 100 can pre-store a typical power draw curve for the driving recorder 102 and use said power draw curve to calculate the expected total power that the driving recorder 102 can draw during the expected off or rest period of the vehicle. Then, when vehicle 100 enters the off or rest period, vehicle 100 can compare the calculated expected total power with the battery's SoC level. When the battery's SoC level may be lower than the expected total power that the driving recorder 102 may draw during the vehicle's off period, vehicle 100 can perform the aforementioned remedial actions. In an exemplary aspect, the remedial actions may include running a rapid idle to charge the vehicle battery or switching / keeping the vehicle engine on for a predefined duration to charge the vehicle battery, so that it can optimally support the driving recorder 102 during the expected off period.

[0032] Additionally, vehicle 100 can (e.g., based on the distance of the trip) predict the estimated amount of driving recorder paper that may be needed during the vehicle's trip / journey and output a notification to instruct driver 104 to carry the estimated amount of driving recorder paper in vehicle 100. This ensures that driver 104 can conveniently print out the driver's driving history and present it to the authorities as needed during the journey.

[0033] Vehicle 100 can also use its human-machine interface (HMI, which may have a display much larger than the dashcam screen) to display useful information associated with driver 104 (which may be stored on card 106 or obtained from an external server). For example, vehicle 100 may have the HMI display information associated with: the driver's history on card 106, activities for the upcoming week with permitted driving time, countries visited historically and tolls paid, paper left in the dashcam printer, alerts when driver 104 attempts to enter disallowed input into dashcam 102, driving records for the past 15 or 28 days, border crossing reminders providing details about country requirements, etc. Understandably, such information would be useful to driver 104 when displayed on a large-screen HMI and could significantly enhance the driver's experience operating dashcam 102.

[0034] In this way, vehicle 100 can provide various additional features and benefits to driver 104 (and fleet manager) by integrating driving recorder 102 into vehicle 100, which is not possible by adding driving recorder as an aftermarket accessory to the conventional system of said vehicle.

[0035] The following text combines Figure 2 Describe 100 details of another vehicle.

[0036] Vehicle 100 shall perform and / or execute the operations described herein in accordance with the owner's manual and safety guidelines. Furthermore, any actions taken by driver 104 based on notifications provided by vehicle 100 shall comply with all rules specific to the location (e.g., federal, state, national, city, etc.) and operation of vehicle 100. Notifications provided by vehicle 100 shall be considered advice and shall be followed only in accordance with any rules specific to the location and operation of vehicle 100.

[0037] Figure 2 A block diagram of a system 200 for operating a vehicle 100 having an integrated driving recorder 102, according to this disclosure, is depicted. In the description... Figure 2 At that time, will refer to Figure 3 , Figure 4 and Figure 5 .

[0038] System 200 may include a vehicle 100, a user device 201, and one or more servers 202 (or servers 204) that can be communicatively coupled to each other via one or more networks 204. The user device 201 may be associated with a driver 104 and may be, for example, a mobile phone, laptop computer, computer, tablet computer, smartwatch, or any other similar device with communication capabilities. Server 202 may be part of a cloud-based computing infrastructure and may be associated with and / or include a Telematics Service Delivery Network (SDN), which delivers services to vehicle 100 and other vehicles that may be part of a vehicle fleet. Figure 2 (Not shown) provides digital data services. In another aspect, server 202 can be associated with a fleet manager that manages vehicle 100 (and other fleet vehicles). Server 202 can also store historical and upcoming trip information associated with vehicle 100 and driver 104. In another aspect, server 202 can store driver information associated with driver 104, which server 202 can obtain from vehicle 100 or via driving recorder 102 / card 106.

[0039] Network 204 illustrates exemplary communication infrastructure in which connected devices discussed in various embodiments of this disclosure can communicate. Network 204 may be and / or include the Internet, a private network, a public network, or other configurations operating using any one or more known communication protocols such as Transmission Control Protocol / Internet Protocol (TCP / IP), Bluetooth, etc. ®Bluetooth Low Energy (BLE), Wi-Fi based on the IEEE standard 802.11, Ultra Wideband (UWB), and cellular technologies such as Time Division Multiple Access (TDMA), Code Division Multiple Access (CDMA), High-Speed ​​Packet Access (HSPDA), Long Term Evolution (LTE), Global System for Mobile Communications (GSM), and 5G, to name just a few.

[0040] Vehicle 100 may include multiple units, including but not limited to vehicle computer 206, vehicle control unit (VCU) 208, and driving recorder control unit 210 (or unit 210). VCU 208 may include multiple electronic control units (ECUs) 212 that communicate with vehicle computer 206.

[0041] In some respects, according to this disclosure, the vehicle computer 206 and / or unit 210 can be installed anywhere within the vehicle 100. Furthermore, the vehicle computer 206 can operate as a functional part of unit 210. The vehicle computer 206 can be or include an electronic vehicle controller having one or more processors 214 and memory 216. Additionally, unit 210 can be separate from the vehicle computer 206 (e.g., Figure 2 (as shown in the diagram), or it can be integrated as part of the vehicle computer 206.

[0042] Processor 214 can communicate with one or more memory devices (e.g., memory 216 and / or memory) of a corresponding computing system. Figure 2 The processor 214 may communicate with one or more external databases (not shown). The processor 214 may utilize the memory 216 to store programs and / or data in code form to execute aspects of this disclosure. The memory 216 may be a non-transitory computer-readable medium or memory storing the driving recorder control program code. The memory 216 may include any or a combination of volatile memory elements (e.g., dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), etc.) and may include any one or more non-volatile memory elements (e.g., erasable programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), etc.).

[0043] According to some aspects, VCU 208 can share a power bus with vehicle computer 206 and can be configured and / or programmed to coordinate the systems of vehicle 100, connected servers (e.g., server 202), user devices 201, and other vehicles operating as part of a vehicle fleet. Figure 2Data between (not shown in the image). VCU 208 may include or communicate with any combination of ECUs 212, such as Body Control Module (BCM) 218, Engine Control Module (ECM) 220, Transmission Control Module (TCM) 222, Telematics Control Unit (TCU) 224, Driver Assistance Technology (DAT) Controller 226, etc.

[0044] VCU 208 may also include and / or communicate with a vehicle perception system (VPS) 228, which has connectivity with and / or controls one or more vehicle sensing systems 230 (or “sensor units”). The vehicle sensing system 230 may include one or more vehicle sensors, including but not limited to radio detection and ranging (radar) sensors, seating area latch sensors, seating area sensors, light detection and ranging (LiDAR) sensors, door sensors, proximity sensors, temperature sensors, wheel sensors, ambient weather sensors, ambient light sensors, vehicle interior and exterior cameras, one or more rain sensors, humidity sensors, tire pressure sensors, ultrasonic sensors, one or more microphones, etc., configured to detect and locate objects inside and outside the vehicle 100 using radio waves. The vehicle sensing system 230 may capture inputs associated with the interior of the vehicle and its surrounding environment (e.g., interior and exterior images, audible or gestural commands from the driver, etc.).

[0045] In some respects, VCU 208 can control vehicle operation aspects and implement one or more instruction sets received from user equipment 201, one or more instruction sets stored in memory 216, including instructions that operate as part of unit 210.

[0046] TCU 224 can provide vehicle connectivity to wireless computing systems on and outside the vehicle 100, and may include a navigation (NAV) receiver 232 for receiving and processing GPS signals, a BLE module (BLEM) 234, a Wi-Fi transceiver, a UWB transceiver, and / or other wireless transceivers that can be configured for wireless communication (including cellular communication) between the vehicle 100 and other systems (e.g., user device 201, key fob, NFC device, etc.), computers, and modules. Figure 2 (Not shown in the image). NAV receiver 232 can be configured to determine the real-time geographical location of the vehicle. TCU 224 can communicate with ECU 212 via a bus. In some respects, a V2X antenna providing location-based input to driving recorder 102 can be part of TCU 224.

[0047] ECU 212 can use inputs from the human driver, inputs from the autonomous vehicle controller, inputs from unit 210, and / or wireless signal inputs received from other connected devices (such as user device 201, server 202, etc.) via wireless connection to control various aspects of vehicle operation and communication.

[0048] The BCM 218 typically integrates sensors, vehicle performance indicators, and variable reactors associated with vehicle systems. It may also include processor-based power distribution circuitry that controls functions associated with the vehicle body, such as lights, windows, safety devices, cameras, fans, headlights, audio systems, speakers, wipers, door locks and entry controls, side mirrors, and various comfort controls. The BCM 218 can also operate as a gateway for bus and network interfaces to communicate with remote ECUs ( Figure 2 Interact with (not shown in the image).

[0049] The DAT controller 226 can provide Level 1 to Level 3 automated driving and driver assistance functionality, which may include features such as active parking assist, vehicle reversing assist, and adaptive cruise control. The DAT controller 226 can also provide various aspects of user and environmental inputs that can be used for user authentication.

[0050] In some respects, the vehicle computer 206 may be connected to the infotainment system 236 (or the vehicle human-machine interface (HMI) 236). The infotainment system 236 may include a touchscreen interface portion and may include voice recognition features, and the ability to identify users based on facial recognition, voice recognition, fingerprint recognition, or other biometric methods. In other respects, the infotainment system 236 may also be configured to receive user commands / inputs via the touchscreen interface portion, and / or display notifications / recommendations, navigation maps, etc., on the touchscreen interface portion.

[0051] As described above, vehicle 100 may also include a driving recorder 102, which may be integrated with vehicle 100 (e.g., during the manufacturing or assembly process of the vehicle). Vehicle 100 may additionally include a battery 238 that can power the driving recorder 102 (and other vehicle components) to enable their operation.

[0052] The computing system architecture of the automotive computer 206, VCU 208, and / or unit 210 may omit certain computing modules. This should be easily understood. Figure 2 The computing environment depicted herein is an example of possible implementations according to this disclosure and should therefore not be considered restrictive or exclusive.

[0053] Depending on some aspects, unit 210 may be integrated with and / or performed as part of ECU 212. Unit 210 may include transceiver 240, processor 242, and computer-readable storage 244, whether it is integrated with vehicle computer 206 or ECU 212, or whether it operates as a stand-alone computing system in vehicle 100.

[0054] Transceiver 240 can receive information / input from one or more external devices or systems (e.g., user device 201, server 202, etc.) via network 204. Transceiver 240 can also transmit notifications / data / signals to external devices or systems. Additionally, transceiver 240 can receive information / input from vehicle 100 components (such as infotainment system 236, driving recorder 102, VCU 208 (e.g., vehicle sensing system 230)). Furthermore, transceiver 240 can transmit notification / command signals to vehicle 100 components (such as VCU 208, infotainment system 236, BCM 218, etc.).

[0055] Processor 242 and memory 244 may be the same as or similar to processor 214 and memory 216, respectively. In some aspects, processor 242 may utilize memory 244 to store programs in code form and / or store data for execution of various aspects according to this disclosure. Memory 244 may be a non-transitory computer-readable medium or memory storing driving recorder control program code.

[0056] During operation, when driver 104 inserts card 106 into the driving recorder's card reader, processor 242 can obtain input from driving recorder 102 (e.g., in conjunction with the following). Figure 1 The processor 242 receives a trigger signal (described) and determines, based on the obtained input, that card 106 may be connected to the driving recorder 102. In response to determining that card 106 is connected to the driving recorder 102, the processor 242 can authenticate driver 104 based on input obtained from the vehicle sensing system 230 and driver information (e.g., an image of the driver) that can be stored on card 106. Specifically, in this case, the processor 242 can first obtain an image of the driver that can be pre-stored on card 106. The processor 242 can also obtain a real-time driver image captured by the vehicle's internal camera and compare the driver image obtained from card 106 with the real-time driver image. When the two images match, the processor 242 can determine that driver 104 is a legitimate user and card 106 belongs to driver 104. In this case, the processor 242 can allow driver 104 to use vehicle 100.

[0057] On the other hand, when the two images do not match, processor 242 can determine that driver 104 may not be a genuine / authorized user, and card 106 may not belong to driver 104. In this case, when driver 104 is not authenticated, processor 242 can perform a predefined action. For example, processor 242 can transmit an alarm notification (or "first alarm notification") to server 202 or a user device associated with the fleet manager via transceiver 240, thereby notifying the fleet manager that an unauthorized user is attempting to drive vehicle 100. As another example, when processor 242 determines that driver 104 may not be a genuine user, processor 242 can prohibit driver 104 from driving vehicle 100 or move vehicle 100 out of parking mode.

[0058] As described above, by integrating the driving recorder 102 into the vehicle 100, the vehicle 100 / processor 242 can provide the driver 104 with several additional features that might not be possible in a conventional system. For example, the processor 242 can enable the card 106 to act as a vehicle key. In this case, the processor 242 can enable the driver 104 to start the vehicle 100 in response to determining that the card 106 is connected to the driving recorder 102. In other words, the processor 242 may not enable the driver 104 to start the vehicle 100 unless the card 106 is inserted into the driving recorder 102. This prevents the driver 104 from unintentionally starting and driving the vehicle 100 without inserting the card 106 into the driving recorder 102. In another aspect, the processor 242 can enable the driver 104 to move the vehicle 100 out of parking position in response to determining that the card 106 is connected to the driving recorder 102. In other words, the processor 242 may not enable the vehicle 100 to move out of parking position until the card 106 is inserted into the driving recorder 102. This feature acts as a secondary prevention measure to ensure that the driver 104 does not drive the vehicle 100 without inserting the card 106 into the driving recorder 102. In some respects, the processor 242 can also enable the driver 104 to open or lock the doors via the card 106 (similar to how a mobile phone acts as a key).

[0059] Furthermore, as described above, processor 242 enables driver 104 to provide input or record activity to driving recorder 102 via audible or gestural commands using the vehicle's microphone or vehicle sensing system 230. In this case, processor 242 can first obtain the driver's audible message or gestural input via vehicle sensing system 230 (e.g., via the vehicle's internal camera or microphone). Then, processor 242 can identify information included in the driver's audible message or gestural input (i.e., information that driver 104 expects to store on card 106). This information may be, for example, an input instructing driver 104 to perform some other task besides driving (e.g., loading, unloading, paperwork, etc.) or to take a break, the driver's availability status, a print request, etc. In response to identifying this information, processor 242 can store the information in memory 244, server 202, and / or card 106, so that driver 104, fleet manager, authorities, etc., can later retrieve and access it for analysis.

[0060] In another aspect, processor 242 can ensure that driver 104 does not leave card 106 inserted in driving recorder 102 when leaving vehicle 100 or its immediate vicinity. In this case, processor 242 can first determine that driver 104 may have left vehicle 100 based on input obtained from vehicle sensing system 230. For example, processor 242 can acquire images captured by external cameras of the vehicle and determine that driver 104 may have left vehicle 100 based on the acquired images. Processor 242 can also determine that driver 104 may have left vehicle 100 based on signals obtained from vehicle seating area sensors (which are part of vehicle sensing system 230). As another example, processor 242 can determine that driver 104 has left vehicle 100 and is moving away from vehicle 100 as the radar distance between driver 104 and vehicle 100 (as determined via signals obtained from radar sensors) gradually increases. In response to this determination, the processor 242 can obtain input or a signal from the driving recorder 102 to check whether the card 106 is still inserted or connected to the driving recorder 102. In response to determining that the driver 104 has left the vehicle 100 while the card 106 is still connected to the driving recorder 102 (e.g., ...), Figure 3 As shown in the exemplary view, the processor 242 can output an alarm notification (or “second alarm notification”) via the vehicle’s sound exciter and / or user device 201 to remind the driver 104 to remove and collect the card 106.

[0061] When driver 104 leaves vehicle 100 with card 106 removed from driving recorder 102, processor 242 can additionally check whether driver 104 has optimally parked vehicle 100. This parking location / information can be stored in memory 244, server 202, and / or card 106, so that it can be retrieved and accessed later by fleet managers and / or authorities for analysis to examine driver performance. In this case, processor 242 can first determine that card 106 has been removed from driving recorder 102 based on input / signals obtained from driving recorder 102. In response to this determination, processor 242 can cause vehicle sensing system 230 to capture images of the vehicle's interior and surrounding environment, determining the distance to one or more adjacent vehicles 402a, 402b (e.g., using signals obtained from radar, lidar, and / or ultrasonic sensors). Figure 4 The distance (as shown in the figure) is used to determine the tire inflation value, etc., based on the input obtained from the VCU 208. Figure 4 An exemplary view of vehicle 100 parked between vehicles 402a and 402b is depicted after driver 104 has left vehicle 100 (after card 106 has been removed from driving recorder 102).

[0062] The processor 242 can then store the captured images, distances to adjacent vehicles 402a, 402b, tire inflation values, etc., in memory 244, server 202, and / or card 106 (when card 106 is reinserted into driving recorder 102), allowing fleet managers and / or authorities to access this information (if needed) to check whether driver 104 has optimally parked vehicle 100. In some aspects, the captured information may be tagged with time and / or location, allowing fleet managers and / or authorities to know the historical times and locations where vehicle 100 was parked.

[0063] If a driver's driving time approaches exceeding their assigned / maximum limit, processor 242 may further alert driver 104. In this case, processor 242 may first determine the maximum driving time associated with driver 104 based on driver information stored on card 106 and / or driver schedule information obtained from server 202. Processor 242 may also obtain the real-time driving time associated with driver 104 based on input from VCU 208 (e.g., vehicle sensing system 230). When the difference between the maximum driving time and the real-time driving time becomes less than a predefined threshold, processor 242 may output an alert notification (or "third alert notification") via HMI 236 and / or user device 201. In other words, processor 242 may output an alert notification when a driver's driving time approaches exceeding their daily assigned / maximum driving limit.

[0064] In another aspect, processor 242 can determine / retrieve information associated with the driver's driving time and rest time from card 106 (e.g., based on driver information stored on card 106) and transmit this information to user device 201. This information can help driver 104 know the driver's remaining rest time when driver 104 may be resting, as described above. Figure 1 As described. Processor 242 may additionally transmit such driver information to server 202, allowing fleet managers to remotely access the information and check driver performance (without having to go to vehicle 100 and print driver information from driving recorder 102).

[0065] In an additional aspect, processor 242 can facilitate driver 104 driving vehicle 100 in optimal health. In this case, processor 242 can continuously monitor the driver's breathing or heartbeat based on input obtained from vehicle sensing system 230 (e.g., images captured by an internal occupancy radar sensor or thermal image sensor). In response to determining that the driver's breathing or heartbeat has become greater than a predefined health threshold, processor 242 can output a recommendation for driver 104 to rest or increase rest time (via HMI 236 and / or user device 201). In this case, as described above... Figure 1 The processor 242 can acquire an input image of the driver, captured by the vehicle's radar or thermal image sensors, and compare the captured image with pre-stored driver images (e.g., driver images when the driver 104 is likely healthy). If the captured image is substantially different from the pre-stored driver images, the processor 242 can determine that the driver's breathing or heart rate may have become greater than a predefined health threshold. In response to this determination, the processor 242 can output the aforementioned recommendation.

[0066] In this way, the processor 242 can prevent the driver 104 from driving the vehicle 100 when the driver 104 may not be fully healthy (or when the driver 104 may feel unwell).

[0067] The processor 242 can also control vehicle operation to ensure that the driving recorder 102 is optimally powered by the battery 238. In this case, the processor 242 can first determine the expected driver rest time or vehicle shutdown time based on driver information obtained from card 106 and / or driver or vehicle schedule information obtained from server 202. Then, the processor 242 can estimate the optimal SoC level of the battery 238 that can power the driving recorder 102 during the expected vehicle shutdown time or driver rest time based on the typical power draw curve of the driving recorder that can be pre-stored in memory 244. The processor 242 can also determine a real-time battery SoC level closer to the vehicle shutdown time or driver rest time based on input obtained from VCU 208. When the processor 242 determines that the real-time SoC level is less than the optimal SoC level, the processor 242 can keep the vehicle engine running or run at a fast idle to charge the battery 238 to the optimal SoC level. In this way, the processor 242 ensures that the driving recorder 102 is optimally powered by the battery 238 during the vehicle shutdown time.

[0068] Processor 242 can further ensure that vehicle 100 has a sufficient supply of dashcam paper for the driver's journey, so that driver 104 can conveniently print it from dashcam 102 if requested by authorities. In this case, processor 242 can first determine the expected distance or duration of the driver's journey based on driver information obtained from card 106 or trip information obtained from server 202. Then, processor 242 can estimate the optimal amount of dashcam paper that the driver's journey may require based on the expected distance or duration (e.g., by using historical trend information on dashcam paper usage in different past trips). In this case, as an example, processor 242 can correlate the expected distance or duration with historical trends in dashcam paper usage and determine the optimal amount of dashcam paper that the driver's journey may require based on said correlation. Processor 242 can also output a notification (or "fourth notification") indicating the optimal amount of dashcam paper on HMI 236 and / or user device 201. Driver 104 can see / hear the notification and accordingly carry dashcam paper during the journey.

[0069] In another aspect, the processor 242 can obtain useful driver and / or trip information from the card 106, memory 244 and / or server 202 and display it on the HMI 236 (which may have a larger screen compared to the screen of the driving recorder 102), thereby significantly enhancing the driver's experience of operating the driving recorder 102 / vehicle 100. Figure 5 An exemplary view of an HMI 236 that displays information to driver 104 is depicted.

[0070] Examples of such information include, but are not limited to, the driver's history or driving record stored on card 106, upcoming trips, countries previously visited by driver 104 and toll payment history, driving recorder paper left in vehicle 100 or driving recorder 102, and border crossing alerts providing details about the requirements of the country driver 104 may be entering. When processor 242 determines that the input provided by driver 104 to driving recorder 102 is an unauthorized input (e.g., input that may not be permitted by fleet management or may not comply with the rules of the country where vehicle 100 is located), processor 242 may further output an alert notification (e.g., a "fifth alert notification") on HMI 236. Processor 242 can make this determination by comparing / associating the input provided by driver 104 with information that may be associated with a plurality of unauthorized inputs stored in memory 244. When the input matches any of the plurality of unauthorized inputs stored in memory 244, processor 242 may determine that driver 104 may be entering an unauthorized input. In this scenario, processor 242 may additionally identify and recommend to driver 104 one or more permissible inputs that driver 104 may provide to driving recorder 102. To provide this recommendation, processor 242 may use information associated with multiple permissible inputs, which may also be pre-stored in memory 244.

[0071] Figure 6 A flowchart depicts an exemplary method 600 for operating a vehicle 100 having an integrated driving recorder 102 according to the present disclosure. Further reference can be made to the preceding figures for further description. Figure 6 The following process is exemplary and is not limited to the steps described below. Furthermore, alternative embodiments may include more or fewer steps than shown or described herein, and may include these steps in a different order than that described in the example embodiments below.

[0072] Method 600 begins at step 602. At step 604, method 600 may include processor 242 determining that card 106 is connected to driving recorder 102 based on input / trigger signals obtained from driving recorder 102. At step 606, method 600 may include, in response to determining that card 106 is connected to driving recorder 102, processor 242 authenticating driver 104 based on input obtained from vehicle sensing system 230 and driver information obtained from card 106.

[0073] At step 608, method 600 may include a predefined action performed by processor 242 when driver 104 is not authenticated. For example, as described above, in response to determining that driver 104 is not authenticated, processor 242 may transmit an alarm notification to server 202 or prohibit driver 104 from driving vehicle 100.

[0074] At step 610, method 600 can stop.

[0075] In the foregoing disclosure, reference has been made to the accompanying drawings, which form a part of the foregoing disclosure, illustrating specific implementations in which the present disclosure may be practiced. It should be understood that other implementations and structural changes may be utilized without departing from the scope of the present disclosure. References to “an embodiment,” “embodiment,” “example embodiment,” etc., in this specification indicate that the described embodiment may include specific features, structures, or characteristics, but each embodiment may not necessarily include said specific features, structures, or characteristics. Furthermore, such phrases do not necessarily refer to the same embodiment. Moreover, when features, structures, or characteristics are described in connection with embodiments, those skilled in the art will recognize such features, structures, or characteristics in conjunction with other embodiments, whether explicitly described or not.

[0076] Furthermore, where appropriate, the functions described herein may be performed by one or more of the following: hardware, software, firmware, digital components, or analog components. For example, one or more application-specific integrated circuits (ASICs) may be programmed to perform one or more of the systems and programs described herein. Certain terms used throughout the specification and claims refer to specific system components. As those skilled in the art will understand, components may be referred to by different names. This document is not intended to distinguish between components with different names but the same function.

[0077] It should also be understood that the word “example” as used herein is intended to be non-exclusive and non-restrictive in nature. More specifically, the word “example” as used herein refers to one of several examples, and it should be understood that there is no undue emphasis or preference for any particular example described.

[0078] Computer-readable media (also known as processor-readable media) include any non-transitory (e.g., tangible) medium that contributes to providing data (e.g., instructions) that can be read by a computer (e.g., by the computer's processor). Such media can take many forms, including but not limited to non-volatile and volatile media. A computing device may include computer-executable instructions, wherein the instructions may be executable by one or more computing devices (such as those listed above) and stored on a computer-readable medium.

[0079] Regarding the processes, systems, methods, heuristics, etc., described herein, it should be understood that although the steps of such processes, etc., are described as occurring in a certain ordered order, such processes can be practiced by performing the described steps in a different order than that described herein. It should also be understood that some steps may be performed simultaneously, other steps may be added, or some steps described herein may be omitted. In other words, the description of processes herein is provided for the purpose of illustrating various embodiments and should in no way be construed as limiting the claims.

[0080] Therefore, it should be understood that the above description is intended to be illustrative rather than restrictive. Many embodiments and applications beyond the examples provided will become apparent upon reading the above description. The scope should not be determined by reference to the above description, but rather by reference to the appended claims and the full scope of their equivalents. Future developments in the techniques discussed herein are anticipated and expected, and the disclosed systems and methods will be incorporated into such future embodiments. In conclusion, it should be understood that modifications and changes are possible with this application.

[0081] Unless expressly indicated otherwise herein, all terms used in the claims are intended to be given their ordinary meaning as understood by one skilled in the art as described herein. Specifically, unless the claims explicitly limit the recitation to the contrary, the use of singular articles such as “a,” “the,” or “the” should be interpreted as one or more of the elements indicated by the recitation. Unless otherwise specifically stated or otherwise understood in the context of use, conditional language such as, in particular, “can,” “may,” “may,” or “may” is generally intended to express that some embodiments may include certain features, elements, and / or steps, while other embodiments may not include certain features, elements, and / or steps. Therefore, such conditional language is generally not intended to imply that one or more embodiments require each feature, element, and / or step in any way.

[0082] According to an embodiment, the driver information or trip information includes information associated with at least one of the following: the driver's history or driving record stored on the driving recorder card, the upcoming trip, the driver's past visits to countries and toll payment history, driving recorder paper left in the vehicle or driving recorder, or a transit alert providing detailed information about country requirements.

[0083] According to an embodiment, the processor is further configured to: determine that an input provided by the driver to the driving recorder is an unallowed input; and output a fifth alarm notification via the HMI in response to determining that the input provided by the driver is unallowed.

[0084] According to the present invention, a method includes: a processor determining that a driving recorder card is connected to a driving recorder of a vehicle; in response to determining that the driving recorder card is connected to the driving recorder, the processor authenticating a driver based on input obtained from a sensor unit of the vehicle and driver information obtained from the driving recorder card; and when the driver is not authenticated, the processor performing a predefined action.

[0085] In one aspect of the invention, performing the predefined action includes transmitting an alarm notification to a server or user device, or prohibiting the driver from driving the vehicle.

[0086] According to the present invention, a non-transitory computer-readable storage medium is provided having instructions stored thereon, which, when executed by a processor, cause the processor to: determine that a driving recorder card is connected to a driving recorder of a vehicle; in response to determining that the driving recorder card is connected to the driving recorder, authenticate a driver based on input obtained from a sensor unit of the vehicle and driver information obtained from the driving recorder card; and perform a predefined action when the driver is not authenticated.

Claims

1. A vehicle comprising: Driving recorder; A sensor unit configured to capture input associated with at least one of the vehicle's interior or its surrounding environment; and Processor, the processor being configured to: Confirm that the driving recorder card is connected to the driving recorder; In response to determining that the driving recorder card is connected to the driving recorder, the driver is authenticated based on input obtained from the sensor unit and driver information obtained from the driving recorder card; as well as A predefined action is executed when the driver is not authenticated.

2. The vehicle of claim 1, wherein the sensor unit comprises at least one of the following: an internal camera, an external camera, a microphone, a radio detection and ranging (radar) sensor, or a light detection and ranging (LiDAR) sensor.

3. The vehicle of claim 2, wherein the driver information includes a driver image, and wherein the processor authenticates the driver by comparing the driver image with a real-time image of the driver captured by at least one of the internal camera or the external camera.

4. The vehicle of claim 1, wherein, to perform the predefined action, the processor transmits a first alarm notification to a server or user device, or prohibits the driver from driving the vehicle.

5. The vehicle of claim 1, wherein the processor is further configured to start the vehicle in response to determining that the driving recorder card is connected to the driving recorder.

6. The vehicle of claim 1, wherein the processor is further configured to enable the driver to move the vehicle out of parking position in response to determining that the driving recorder card is connected to the driving recorder.

7. The vehicle of claim 1, wherein the processor is further configured to: The driver's audible messages or gesture inputs are obtained via the sensor unit; The information to be stored is identified based on the driver's audible messages or gesture input; and The information is stored in at least one of the vehicle's memory, an external server, or the driving recorder card.

8. The vehicle of claim 1, wherein the processor is further configured to: It is determined that the driver has left the vehicle based on the input obtained from the sensor unit; After the driver has left the vehicle, it is determined that the driving recorder card is still connected to the driving recorder; and In response to determining that the driver has left the vehicle while the driving recorder card is still connected to the driving recorder, a second alarm notification is output.

9. The vehicle of claim 1, wherein the processor is further configured to: Confirm that the driving recorder card has been removed from the driving recorder; In response to determining that the driving recorder card has been removed from the driving recorder, the sensor unit captures at least one of the following: images of the vehicle's interior and surrounding environment, distance to one or more adjacent vehicles, or tire inflation value; and The image, the distance, or the tire inflation value are stored in the vehicle's memory, an external server, or the driving recorder card.

10. The vehicle of claim 1, wherein the processor is further configured to: The maximum driving time associated with the driver is determined based on the driver information; The real-time driving time associated with the driver is determined based on the input obtained from the sensor unit; and When the difference between the maximum driving time and the real-time driving time becomes less than a predefined threshold, a third alarm notification is output.

11. The vehicle of claim 1, wherein the processor is further configured to: Information related to the driver's driving time and rest time is determined based on the driver information obtained from the driving recorder card; and The information associated with the driver's driving time and rest time is transmitted to the user device associated with the driver.

12. The vehicle of claim 1, wherein the processor is further configured to: Based on the input obtained from the sensor unit, it is determined that at least one of the driver's breathing or heartbeat has become greater than a predefined health threshold; and In response to determining that the driver's breathing or heart rate has become greater than the predefined health threshold, a recommendation is output for the driver to rest or increase the rest time.

13. The vehicle of claim 1, wherein the processor is further configured to: The expected driver rest time is determined based on the driver information; Determine the state of charge (SoC) level of the vehicle battery; The SoC level was determined to be less than the optimal SoC level required to supply power to the driving recorder during the expected driver rest period; as well as In response to determining that the SoC level is less than the optimal SoC level, the vehicle engine is turned on to charge the vehicle battery.

14. The vehicle of claim 1, wherein the processor is further configured to: The expected distance or duration of the driver's trip is determined based on the driver information or trip information obtained from an external server; The optimal amount of driving recorder paper required for the driver's trip is determined based on the expected trip distance or duration; and The output includes a fourth notification containing information associated with the optimal amount of driving recorder paper.

15. The vehicle of claim 1, further comprising a human-machine interface (HMI), wherein the processor is further configured to display the driver information or trip information on the HMI.

Images