On-vehicle sensing module for monitoring a vehicle

Abstract

On-vehicle sensing module for monitoring a vehicle. Disclosed is an on-vehicle sensing module for monitoring a vehicle, which is advantageous for use in an environment of shared vehicle services such as car rental services, autonomous taxi services or ride-sharing services. The on-vehicle sensing module at least includes a controller, a cellular transceiver and one or more integrated sensors configured to monitor the state of the vehicle. The on-vehicle sensing module interprets the sensor data using appropriate algorithms, models or thresholds, and enriches the data with metadata and event detection. The on-vehicle sensing module uploads relevant sensor data, event data or other metadata to a cloud storage backend, which is made accessible to authorized third parties.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims priority to U.S. Provisional Patent Application Serial No. 62 / 952,618, filed December 23, 2019, entitled "In - Vehicle Sensing Module for Monitoring a Vehicle", U.S. Provisional Patent Application Serial No. 62 / 952,568, filed December 23, 2019, entitled "In - Vehicle Sensing Module for Monitoring a Vehicle", and U.S. Provisional Patent Application Serial No. 62 / 952,623, filed December 23, 2019, entitled "In - Vehicle Sensing Module Having Cloud Connectivity", the disclosures of which are hereby incorporated by reference in their entirety.

[0003] This application relates to U.S. Patent Application Serial No. 17 / 116165 [Attorney Docket No. 1576 - 2492], and to U.S. Patent Application Serial No. 17 / 116142 [Attorney Docket No. 1576 - 2493], the disclosures of which are hereby incorporated by reference in their entirety. Technical Field

[0004] The devices and methods disclosed in this document relate to in - vehicle sensing, and more particularly to electronic hardware for an in - vehicle sensing module. Background Art

[0005] Unless otherwise indicated herein, the materials described in this section are not admitted to be prior art by virtue of inclusion in this section.

[0006] In shared vehicle services such as ride-sharing services, taxi services, and car rental services, shared vehicles are typically driven by a driver or occupied by a passenger who is not the owner of the vehicle. A common problem with such services is that customers may not care about how they treat the vehicle during their short time as a passenger or driver. Given this, operators of such services typically put in place various rules or policies regarding how the vehicle should be treated by customers. However, modern incarnations of these services are technology-driven and often fully autonomous, such that little or no direct interaction with the owner of the vehicle or the operator of the service is required. As a result, effective implementation of these rules or policies can be challenging and sometimes costly. Accordingly, it would be beneficial to provide a system that enables autonomous detection of problems within the vehicle, which would minimize the need for human intervention in implementing rules or policies and remedying violations. Summary of the Invention

[0007] Disclosed is a device for monitoring a vehicle. The device includes a housing configured to be mounted within the vehicle. The device further includes at least one sensor disposed within the housing and configured to capture sensor data. The device further includes a non-volatile memory disposed within the housing and configured to store data. The device further includes a processor disposed within the housing and operatively connected to the at least one sensor and the non-volatile memory. The processor is configured to receive sensor data captured during operation of the vehicle from the at least one sensor. The processor is further configured to detect whether a predetermined condition of the vehicle has occurred based on the sensor data. The processor is further configured to store in the non-volatile memory the sensor data captured during operation of the vehicle and metadata indicating whether the predetermined condition has occurred. Brief Description of the Drawings

[0008] The foregoing aspects and other features of the on-vehicle sensing system are explained in the following description in conjunction with the accompanying drawings.

[0009] Figure 1 A simplified block diagram of a vehicle monitoring system having an on-vehicle sensing module for monitoring a shared vehicle is shown.

[0010] Figure 2 Shows Figure 1 Exemplary electronic components of the on-vehicle sensing module.

[0011] Figure 3 Shows a method for operating Figure 1 The on-vehicle sensing module to monitor at least the cabin of a shared vehicle.

[0012] Figure 4A photo of the compartment of a shared vehicle is shown, with the left-behind objects marked by frames.

[0013] Figure 5 A photo of the compartment of a shared vehicle is shown, with the dirt on the floor of the vehicle marked by frames.

[0014] Figure 6 A photo of the compartment of a shared vehicle is shown, with the debris on the floor and seats of the vehicle marked by frames.

[0015] Figure 7 Shows Figure 1 Exemplary components of the cloud storage backend.

[0016] Figure 8 Shows a method for operating Figure 1 The cloud storage system to manage data uploaded from multiple in-vehicle sensing modules. Detailed Description

[0017] For the purpose of facilitating the understanding of the principles of the present disclosure, reference will now be made to the embodiments illustrated in the accompanying drawings and described in the following written specification. It is to be understood that the scope of the present disclosure is not intended to be limited thereby. Further understood, the present disclosure includes any changes and modifications to the illustrated embodiments, and includes additional applications of the principles of the present disclosure as would typically occur to those skilled in the art to which the present disclosure pertains.

[0018] System Overview

[0019] Figure 1 A simplified block diagram of a vehicle monitoring system 100 is shown, which has an in-vehicle sensing system 104 for monitoring at least the compartment 108 of a vehicle 102. The vehicle monitoring system 100 is advantageous for use in the environment of a shared vehicle service, where the shared vehicle 102 is driven by a driver or occupied by a passenger who is not the owner of the shared vehicle 102. Such shared vehicle services may include, but are not limited to, car rental services, autonomous taxi services, or ride-sharing services. In many such shared vehicle services, customers can use a smartphone application, a website, an on-site kiosk, or the like to engage in the shared vehicle service in an automated manner, which involves little or no direct human intervention by the operator of the shared vehicle service.

[0020] The vehicle-mounted sensing system 104 advantageously enables an operator of a shared vehicle service to monitor the condition of the shared vehicle 102, enforce rules and policies, and provide additional benefits to customers with minimal manual intervention. Such rules and policies can include a rule prohibiting smoking in the shared vehicle 102 or a surcharge for any required cleaning of the shared vehicle 102 after use by a customer. Additionally, the operator can provide additional benefits to customers, such as notifying them of left-behind objects.

[0021] The vehicle-mounted sensing system 104 includes a vehicle-mounted sensing module 112 having at least a controller, a cellular transceiver / modem, and one or more integrated sensors 116 configured to monitor at least the state of the passenger compartment 108, preferably integrated into a common housing mounted to the passenger compartment 108 of the vehicle. In some embodiments, the housing is configured to be mounted on a surface (such as a dashboard or windshield) within the passenger compartment 108 of the shared vehicle 102. Alternatively, in one embodiment, the housing is adapted to be retrofitted to a particular make and model of the shared vehicle 102, such as in place of an eye-glass holder. In some embodiments, the vehicle-mounted sensing system 104 further includes additional external sensors 120 disposed on or throughout the shared vehicle 102 and operatively connected to the vehicle-mounted sensing module 112 via one or more communication buses 124. In some embodiments, the sensors 116, 120 used by the vehicle-mounted sensing module 112 can be specific to a particular make and model of the shared vehicle 102.

[0022] In addition to the vehicle sensing system 104, the shared vehicle 102 includes a vehicle electronic control unit (“ECU”) 128, a drive system 132, and a vehicle battery 136. In one embodiment, the vehicle ECU 128 is configured to operate the drive system 132 as well as various electronic devices of the vehicle, such as lights, locks, speakers, displays, etc. The vehicle ECU 128 can communicate with these various electronic devices, the drive system 132, and the on-vehicle sensing module 112 via one or more communication buses 124. In one embodiment, the vehicle ECU 128 transmits certain telemetry data, such as vehicle speed or direction of travel, to the on-vehicle sensing module 112, and thus, the vehicle ECU 128 can be considered one of the external sensors 120. The drive system 132 of the shared vehicle 102 includes a drive motor that drives the wheels of the shared vehicle 102, such as an internal combustion engine and / or one or more electric motors, as well as steering and braking components that cause the shared vehicle 102 to move in a controlled manner. The vehicle battery 136 is configured to provide operating power to the on-vehicle sensing module 112, the external sensors 120, the vehicle ECU 128, and / or any other vehicle electronic devices of the shared vehicle 102 via a power line 140 (e.g., a 12V power line, such as an always-on power line or a switched / accessory power line of the shared vehicle 102).

[0023] The on-vehicle sensing module 112 is configured to monitor at least the state of the passenger compartment 108 of the vehicle. In particular, the on-vehicle sensing module 112 is configured to process sensor data received from the sensors 116, 120 to infer one or more conditions, qualities, or states of the shared vehicle 102. For example, the on-vehicle sensing module 112 can detect whether the shared vehicle 102 is clean / dirty, whether the shared vehicle 102 has been damaged or involved in a collision, whether the shared vehicle 102 has been affected by cigarette smoke or other unpleasant odors, and / or whether an object has been left in the shared vehicle 102. The on-vehicle sensing module 112 uses appropriate algorithms, models (e.g., artificial neural networks), or thresholds to interpret the sensor data and enriches the data with metadata and event detection. Those of ordinary skill in the art will understand that the term “metadata” refers to any data that describes or gives information about other data (e.g., sensor data).

[0024] Accordingly, depending on the particular condition, quality, or state of the shared vehicle 102 to be monitored, the sensors 116, 120 can include a wide variety of sensors, including cameras, microphones, gyroscopes, accelerometers, smoke detectors, gas sensors or other air quality / particle sensors, temperature sensors, and / or humidity sensors. In one embodiment, the external sensor 120 includes a vehicle camera disposed within the passenger compartment 108 to capture images of the passenger compartment 108, such as native images of the shared vehicle or aftermarket installed images. In one embodiment, the external sensor 120 includes a gyroscope / accelerometer module that can include, for example, a microphone, a gyroscope, and an accelerometer integrated within a single housing attached to the chassis of the shared vehicle 102.

[0025] The vehicle-mounted sensing module 112 is configured to upload relevant sensor data, event data, or other metadata to the cloud storage backend 150 via a cellular Internet connection for storage therein. The data uploaded to the cloud storage backend 150 can be accessed by a third-party cloud backend 160. The third-party backend 160 is associated, for example, with the shared vehicle services discussed above, such as car rental services, autonomous taxi services, or ride-sharing services. In this way, the operator of the shared vehicle service can monitor the condition of the shared vehicle 102, enforce rules and policies, and provide additional benefits to customers with minimal human intervention.

[0026] Vehicle-mounted Sensing Module

[0027] Reference Figure 2 , an exemplary component of one embodiment of the vehicle-mounted sensing module 112 is described. The vehicle-mounted sensing module 112 includes a housing 204 within which at least one printed circuit board (PCB) 208 is received and mounted. The PCB 208 supports and electrically interconnects a plurality of electrical components, which at least include a controller 212 configured to operate the vehicle-mounted sensing module 112.

[0028] The controller 212 includes at least a processor and an associated memory. Those of ordinary skill in the art will recognize that a "processor" includes any hardware system, hardware mechanism, or hardware component that processes data, signals, or other information. Accordingly, the processor may include a system having a central processing unit, a graphics processing unit, multiple processing units, dedicated circuitry for implementing functions, programmable logic, or other processing systems. The memory can be any type of device capable of storing information accessible by the processor, such as a flash card, ROM, RAM, hard disk drive, magnetic disk, or any of a variety of other computer-readable media used as volatile or non-volatile data storage devices, as will be recognized by those of ordinary skill in the art. The memory is configured to store program instructions that, when executed by the processor, enable the vehicle-mounted sensing module 112 to perform various operations, including monitoring the passenger compartment 108 of the shared vehicle 102, as described below.

[0029] In the illustrated embodiment, the controller 212 takes the form of an Internet of Things (IoT) controller 212, which has integrated features and functions in addition to the characteristics and functions of a general-purpose multi-purpose controller. To this end, in the illustrated embodiment, the IoT controller 212 is configured as a system-on-chip (SoC) disposed on the PCB 208. Alternatively, the IoT controller 212 can be equivalently configured as a system-on-module (SoM), where its sub-components are disposed on at least one discreet PCB that is connected to the PCB 208 via cables and / or module connectors. In either case, the IoT controller 212 includes integrated features and functions in addition to the processor and memory.

[0030] In some embodiments, the IoT controller 212 advantageously provides integrated cellular phone functionality. To this end, the IoT controller 212 includes a cellular phone modem and / or transceiver and any other processors, memories, oscillators, or other hardware conventionally included in a cellular phone module. The cellular phone modem is configured to communicate with the Internet via a wireless phone network, such as a Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA), and / or Long Term Evolution (LTE) network. It should be understood that in alternative embodiments, a discreet cellular phone module may be provided on a PCB 208 separate from the controller 212.

[0031] The cellular modem of the IoT controller 212 is connected to the cellular antenna 214 via an antenna connector 216 disposed on the PCB 208. In at least one embodiment, the cellular antenna 214 is disposed within the housing 204 but separated from the PCB 208 and may include, for example, a flexible antenna mounted along the inner sidewall of the housing 204 or otherwise designed to improve the cellular reception of the in-vehicle sensing module 112. The cellular modem is further connected to a subscriber identity module (“SIM”) card 220 that is inserted into a SIM card holder 222 disposed on the PCB 208 and configured to connect the SIM card 220 to the IoT controller 212. The SIM card 220 provides identification information to enable the cellular modem to access a wireless telephone network, as is commonly known in the art.

[0032] In some embodiments, the IoT controller 212 advantageously provides integrated global navigation satellite system (GNSS) functionality. To this end, the IoT controller 212 includes a GNSS receiver and any other processors, memories, oscillators, or other hardware conventionally included in a GNSS module. The GNSS receiver is configured to receive signals from GNSS satellites from which position data can be determined. The GNSS receiver is configured to support, for example, one or more of GPS, GLONASS, BeiDou, and Galileo or any other GNSS. The GNSS receiver is connected to a GNSS antenna 224 to enable reception of GNSS signals. In the illustrated embodiment, the GNSS antenna 224 is disposed within or on the PCB 208, but may alternatively be disposed separately inside or outside the housing 204. It should be understood that in alternative embodiments, a well-thought-out GNSS module may be provided on a PCB 208 separate from the controller 212.

[0033] In some embodiments (not shown), the IoT controller 212 may further include an integrated and / or transceiver configured to communicate locally with a smart phone or other smart device owned by a passenger or driver using the shared vehicle 102. Similarly, in some embodiments, a well-thought-out and / or transceiver may be provided on a PCB 208 separate from the controller 212.

[0034] Finally, in some embodiments, the IoT controller 212 advantageously includes a variety of integrated data / peripheral interfaces for operably connecting to a variety of additional components of the vehicle-mounted sensing system 104, the integrated data / peripheral interfaces including general-purpose input / output (GPIO), serial peripheral interface (SPI), inter-integrated circuit (I 2 C or I2C), Inter-IC Sound (I 2 S or I2S), secure digital input / output (SDIO), universal serial bus (USB), USB high-speed inter-chip (HSIC), and universal asynchronous receiver-transmitter (UART). In this way, the IoT controller 212 provides easy compatibility with a variety of external sensors 120 that may be available within the shared vehicle 102, as well as compatibility with a variety of configurations of the integrated sensors 116.

[0035] As described above, the vehicle-mounted sensing module 112 includes one or more integrated sensors 116 that are configured to monitor the state of the shared vehicle 102 or at least its passenger compartment 108. These integrated sensors 116 can be directly integrated with the IoT controller 212, arranged on the PCB 208, or otherwise arranged within a housing 204 separate from the PCB 208. The IoT controller 212 is configured to receive sensor data from the integrated sensors 116 as well as any external sensors 120 and write the sensor data to non-volatile memory. Additionally, the IoT controller 212 is configured to process the sensor data to determine a variety of metadata, which is also written to non-volatile memory. To this end, in the illustrated embodiment, the IoT controller 212 is connected to a removable memory storage device 228 that is inserted into a removable storage media holder 230 that is arranged on the PCB 208 and configured to connect the removable memory storage device 228 to the IoT controller 212 (e.g., via SDIO). The removable memory storage device 228 can include, for example, a secure digital (SD), SD high-capacity (SDHC), or SD extended capacity (SDXC) memory card, as well as any equivalent type of removable memory card or other non-volatile storage technology.

[0036] In the illustrated embodiment, the integrated sensor 116 includes an inertial measurement unit (IMU) 232 that is arranged on the PCB 208 and connected to the IoT controller 212 (e.g., via I 2C). The IMU 232 includes one or more gyro sensors and one or more accelerometers. In one embodiment, the IMU 232 includes an integrated 6-axis inertial sensor that provides both three-axis acceleration measurements and three-axis gyro measurements. As will be discussed further below, in at least some embodiments, in response to measurements from the IMU 232, the vehicle-mounted sensing module 112 switches from a low-power mode to an active state. In other words, the IMU 232 can provide a wake-up signal for the IoT controller 212.

[0037] In the illustrated embodiment, the integrated sensor 116 includes an ambient sensor 236 that is disposed on the PCB 208 and connected to the IoT controller 212 (e.g., via I 2 C). The ambient sensor 236 is configured to detect properties indicative of the air quality in the passenger compartment, such as relative humidity, atmospheric pressure, temperature, and the presence of organic compounds (more specifically volatile organic compounds (“VOCs”)). Accordingly, the ambient sensor 236 includes a plurality of separate sensors integrated into a single package. However, it should be understood that separately considered sensors, including a VOC sensor, a humidity sensor, an atmospheric pressure sensor, and a temperature sensor, may alternatively be provided.

[0038] In the illustrated embodiment, the integrated sensor 116 includes at least one microphone 240 that is disposed on the PCB 208 and connected to the IoT controller 212 (e.g., via I 2 S and / or I 2C). The microphone 240 includes any type of acoustic sensor configured to record sounds within the passenger compartment 108. In at least one embodiment, the integrated sensor 116 includes at least two microphones 240 spaced apart from each other on the PCB 208 to record stereophonic audio of the passenger compartment 108. In one embodiment, the microphone(s) 240 take the form of a microelectromechanical system (MEMS) microphone directly mounted on the PCB 208. In at least one embodiment, the microphone(s) 240 are connected to the IoT controller 212 via a hardware audio codec 242, which is configured to, for example, perform analog-to-digital conversion of the audio from the microphone(s) 240, amplify the audio from the microphone(s) 240, filter the audio from the microphone(s) 240, or otherwise encode or process the audio from the microphone(s) 240 for proper use by the IoT controller 212. In one embodiment, the housing 204 defines an opening or group of openings 244 that is located near the microphone(s) 240 on the PCB 208 and that allows for the exchange of air between the exterior of the housing 204 and the interior space of the housing 204 near the microphone(s) 240. In one embodiment, each of the microphone(s) 240 is surrounded by an acoustic gasket (not shown) with one end of the acoustic gasket sealed against the PCB 208. The acoustic gasket acoustically isolates the microphone(s) 240 to reduce interference in the sounds transmitted through the opening 244 and detected by the microphone(s) 240.

[0039] In the illustrated embodiment, the integrated sensor 116 includes a particulate sensor 248 connected to the IoT controller 212 (e.g., via UART). The particulate sensor 216 is configured to sense the concentration of particulate matter in the ambient air of the passenger compartment 108. The particulate sensor 248 is at least configured to detect particulate matter having a size or mass associated with smoke and particularly with tobacco smoke, but may also detect particulate matter associated with other airborne particles or water vapor. In at least one embodiment, the particulate sensor 248 is disposed within a housing 204 separate from the PCB 208 and is connected to the IoT controller 212 by a cable that connects a connector 250 disposed on the PCB 208 to a connector 252 of the particulate sensor 248. In one embodiment, the housing 204 defines an opening or group of openings 254 that is located near the particulate sensor 248 and that allows for the exchange of air between the exterior of the housing 204 and the interior space of the housing 204 near the particulate sensor 248.

[0040] In the illustrated embodiment, the vehicle-mounted sensing module 112 includes an indicator light (e.g., an LED) 258 mounted on the PCB 208 or the housing 204. The indicator light 258 is arranged to be visible through a transparent lens or an opening 260 of the housing 204. The IoT controller 212 is configured to operate the indicator light 258 to emit light indicating the operating state of the vehicle-mounted sensing module 112.

[0041] In the illustrated embodiment, the vehicle-mounted sensing module 112 further includes a power supply 264 configured to convert the power from the vehicle battery 136 into an appropriate voltage for powering the IoT controller 212 and other components of the vehicle-mounted sensing module 112. In at least one embodiment, the power supply 264 includes a low-power supply configured to power only a selected subset of the components of the vehicle-mounted sensing module 112 in the low-power mode of the vehicle-mounted sensing module 112. The power supply 264 is connected to an external I / O connector 266, and the power supply 264 receives input power from the vehicle battery 136 via the external I / O connector 266. It should be understood that in some embodiments, if the power supply from the vehicle battery 136 is interrupted, the PCB 208 includes or is operatively connected to a battery (not shown) as an auxiliary power supply.

[0042] In the illustrated embodiment, the vehicle-mounted sensing module 112 further includes an external cable 268 that is connected to the external I / O connector 266 and exits the housing 204 via an opening 270 defined therein. In one embodiment, the external cable 268 includes a grommet 272 disposed at the opening 270, and the grommet 272 is configured to attach the external cable 268 to the housing 204 at the opening 270 to provide strain relief. The external cable 268 is configured to be connected to one or more vehicle interfaces, buses, or systems (including at least the power line 140) of the shared vehicle 102 via one or more wire harnesses or equivalents to receive a vehicle battery voltage 274 (e.g., 12V) from the vehicle battery 136. Additionally, in at least some embodiments, the external cable 268 is configured to be connected to one or more communication buses 124 to receive data from the external sensors 120 and / or from the vehicle ECU 128.

[0043] In the illustrated embodiment, one or more external sensors 120 include a vehicle camera 276 that is disposed within the shared vehicle 102 and configured to capture images of the passenger compartment 108. The vehicle camera 276 can be a pre-existing camera that is native to the make and model of the shared vehicle 102, or can be a camera that has been installed in an aftermarket shared vehicle 102. The on-vehicle sensing module 112 includes a camera trigger circuit 278 disposed on the PCB 208 that is connected to the external I / O connector 266 and to the IoT controller 212 (e.g., via GPIO). The IoT controller 212 is configured to operate the camera trigger circuit 278 to activate the vehicle camera 276 to capture one or more images or videos within the passenger compartment 108. The IoT controller 212 is configured to receive the captured images from the vehicle camera 276 via the camera trigger circuit 278 or via another data connection.

[0044] In the illustrated embodiment, the on-vehicle sensing module 112 further includes an ignition sensing circuit 282 that is disposed on the PCB 208 and connected to the external I / O connector 266 and to the IoT controller 212. The ignition sensing circuit 282 is configured to monitor the voltage of the power line 140 provided via the external I / O connector 266 and determine when the ignition of the shared vehicle 102 has been activated. The ignition sensing circuit 282 then transmits an ignition signal to the IoT controller 212, thereby indicating that the shared vehicle 102 has been started. As will be discussed further below, in at least some embodiments, in response to the ignition signal, the on-vehicle sensing module 112 switches from a low-power mode to an active state. In other words, the ignition signal can serve as a wake-up signal for the IoT controller 212.

[0045] In the illustrated embodiment, the on-vehicle sensing module 112 further includes a battery monitoring circuit 286 that is disposed on the PCB 208 and connected to the external I / O connector 266 and to the IoT controller 212 (e.g., via GPIO and / or ADC input). The battery monitoring circuit 286 and / or the IoT controller 212 are configured to monitor the voltage and current of the power line 140 provided via the external I / O connector 266. In some embodiments, the power state (e.g., off, on, low-power mode, active mode) of the on-vehicle sensing module 112 is controlled or changed based on the voltage and current of the power line 140.

[0046] Finally, in the illustrated embodiment, the vehicle-mounted sensing module 112 further includes an external device connector 290 that is disposed on the PCB 208 and connected to the external I / O connector 266 and to the IoT controller 212 (e.g., via USB). The external device connector 290 enables an external computing device such as a diagnostic tool or the like to be temporarily connected to the vehicle-mounted sensing module 112 to read or receive data from the vehicle-mounted sensing module 112. The external device connector 290 may take the form of, for example, a USB connector (e.g., USB-A, USB-C, micro-USB, etc.) or the like, which is configured to enable wired communication between the IoT controller 212 and the external computing device.

[0047] Operation of Vehicle-mounted Sensing Module

[0048] Various methods and processes for operating the vehicle-mounted sensing module 112 are described below. In these descriptions, statements that a method, processor, and / or system is performing some task or function refer to a controller or processor (e.g., the IoT controller 212 of the vehicle-mounted sensing module 112) executing programming instructions stored in a non-transitory computer-readable storage medium (e.g., the memory of the IoT controller 212 of the vehicle-mounted sensing module 112 or a removable memory storage device 228), which is operably connected to the controller or processor to manipulate data or operate one or more components in the vehicle monitoring system 100 to perform the task or function. Additionally, the steps of the method may be performed in any feasible order of time, independent of the order shown in the figures or the order in which the steps are described.

[0049] Figure 3 A method 300 for operating the vehicle-mounted sensing module 112 to monitor at least the passenger compartment 108 of the shared vehicle 102 is shown. The method 300 advantageously captures sensor data during operation of the shared vehicle 102 and stores it in non-volatile memory, such as in an environment of a shared vehicle service, such as a car rental service, an autonomous taxi service, a ride-sharing service, or the like. Additionally, the method 300 advantageously processes the sensor data to provide metadata, which is also stored in non-volatile memory. The method 300 advantageously enables an operator of such a shared vehicle service to monitor the condition of the shared vehicle 102, enforce rules and policies, and provide additional benefits to customers with minimal manual intervention.

[0050] Method 300 begins by powering on the vehicle sensing module (block 310). In particular, as described above, the battery monitoring circuit 286 is configured to monitor the voltage and current of the power line 140 provided via the external I / O connector 266. In some embodiments, the power line 140 connected via the external I / O connector 266 is a normally open power line that shares the vehicle 102 and directly provides the battery voltage of the vehicle battery 136. It will be understood that if measured precisely, the battery voltage of the vehicle battery 136 can be used to estimate the state of charge of the vehicle battery 136. In one embodiment, the battery monitoring circuit 286 measures the battery voltage provided via the power line 140 and, in response to the battery voltage exceeding a predetermined threshold voltage, provides an enable signal to the IoT controller 212 to at least partially power on the vehicle sensing module 112. The predetermined threshold voltage is the battery voltage corresponding to a predetermined state of charge of the vehicle battery. In one embodiment, the predetermined state of charge is the state at which the vehicle battery 136 can still provide sufficient current intensity to start the vehicle. In this way, if the vehicle battery 136 is fully charged, the vehicle sensing module 112 will operate only on battery power and will not cause the vehicle battery to be unnecessarily depleted if the shared vehicle 102 is not started for an extended period of time.

[0051] In an alternative embodiment, the power line 140 connected via the external I / O connector 266 is a switched / accessory power line that shares the vehicle 102 and provides the battery voltage of the vehicle battery 136 only when the ignition has been activated to start the shared vehicle 102 (typically by actuating the ignition operating element while depressing the brake) or only when the accessory power of the shared vehicle 102 has been activated (typically by actuating the ignition operating element without depressing the brake). Accordingly, in response to detecting the battery voltage from the vehicle battery 136, the battery monitoring circuit 286 provides an enable signal to the IoT controller 212 to at least partially power on.

[0052] Method 300 continues to operate the vehicle sensing module in a low power mode until a wake-up condition occurs (block 320). In particular, in response to the enable signal, the vehicle sensing module 112 begins operating in a low power mode in which the IoT controller 212 activates a subset of the components of the vehicle sensing module 112 to power on. In particular, in one exemplary embodiment, in the low power mode, only the IMU 232, the environmental sensor 236, the ignition sensing circuit 282, and the low power supply of the power supply 264 are activated. Additionally, the IoT controller 212 itself can operate in a low power state in which certain functions or sub-components (such as those related to the cellular phone and GNSS) are disabled.

[0053] The vehicle-mounted sensing module 112 operates in a low-power mode until a wake-up condition is met, or more specifically, until the IoT controller 212 receives a wake-up signal. In response to receiving the wake-up signal, the vehicle-mounted sensing module 112 begins to operate in an active mode, in which the IoT controller 212 activates all components of the vehicle-mounted sensing module 112 to turn on. In one embodiment, in response to detecting that the ignition of the shared vehicle 102 has been activated, the ignition sensing circuit 282 sends a wake-up signal to the IoT controller 212. In one embodiment, the IMU 233 sends a wake-up signal to the IoT controller 212 in response to detecting interference with the shared vehicle 102 (e.g., acceleration or gyroscope measurements exceeding a threshold or matching a predetermined profile), indicating, for example, that the driver has unlocked the shared vehicle 102 and entered the passenger compartment 108. In one embodiment, if the cellular phone function of the IoT controller 212 is operable during the low-power mode, a wake-up signal can be received from the cloud storage backend 150.

[0054] Method 300 continues to receive sensor data from the integrated sensors and the external sensors and write the sensor data to the local non-volatile memory (block 330). In particular, in the active mode, after receiving the wake-up signal, the IoT controller 212 begins to record / write the sensor data from the integrated sensors 116 and from the external sensors 120 to the removable memory storage device 228 or some other non-volatile memory. In one embodiment, the IoT controller 212 implements one or more circular buffers (which may also be referred to as circular buffers, circular queues, or ring buffers) on the removable memory storage device 228 to manage the storage of newly measured sensor data and the deletion of old sensor data.

[0055] Method 300 continues to process the sensor data to determine metadata including event data and write the metadata to the local non-volatile memory (block 340). In particular, the IoT controller 212 is configured to process the sensor data received from the integrated sensors 116 or from the external sensors 120 to enrich the data with metadata and in particular event detection. As discussed above, the sensors 116, 120 can include a variety of sensors, including cameras, microphones, gyroscopes, accelerometers, smoke detectors, or other air quality / particle sensors, temperature sensors, and / or humidity sensors. The IoT controller 212 processes the sensor data to determine one or more conditions, qualities, or states of the shared vehicle 102 and / or detect the occurrence of one or more events related to one or more conditions, qualities, or states of the shared vehicle 102. The IoT controller 212 stores the determined conditions, qualities, or states and the detected events related thereto on the removable memory storage device 228 as metadata of the stored sensor data.

[0056] In at least some embodiments, the IoT controller 212 is configured to use an algorithm or model such as a machine learning model (e.g., an artificial neural network) to determine one or more conditions, qualities, or states of the shared vehicle 102 and / or to detect the occurrence of one or more events related to one or more conditions, qualities, or states of the shared vehicle 102. In one embodiment, the IoT controller 212 is configured to receive updates for the algorithm or model from the cloud storage backend 150 via its cellular modem.

[0057] In some embodiments, in response to detecting a particular quality, condition, state, or event, the IoT controller 212 operates the camera trigger circuit 278 to cause the vehicle camera 276 to capture an image or video of the passenger compartment 108. The IoT controller 212 stores the captured image on the removable memory storage device 228 as metadata for the sensor data and detects the particular quality, condition, state, or event from the sensor data.

[0058] In some embodiments, the IoT controller 212 is configured to determine whether the shared vehicle 102 has been involved in a collision or has otherwise been mechanically damaged based on acceleration and gyroscopic measurements provided by the IMU 232 or by a similar external sensor 120. In one embodiment, the IoT controller 212 is configured to detect a collision or damage event in response to the acceleration and / or gyroscopic measurements exceeding a predetermined threshold or matching a predetermined acceleration profile. In one embodiment, the IoT controller 212 executes a machine learning model (e.g., an artificial neural network) to detect a collision or damage event based on the acceleration and / or gyroscopic measurements. In one embodiment, the IoT controller 212 determines where the damage has occurred (e.g., left front) and classifies the severity or level of the damage (e.g., severe) based on the acceleration and / or gyroscopic measurements or other sensor data. In one embodiment, the IoT controller 212 executes a machine learning model (e.g., an artificial neural network) to classify the detected collision or damage based on the acceleration and / or gyroscopic measurements. In one embodiment, in response to a collision or damage event, the IoT controller 212 operates the camera trigger circuit 278 to cause the vehicle camera 276 to capture an image or video of the passenger compartment 108.

[0059] In some embodiments, the IoT controller 212 is configured to determine whether the passenger compartment 108 of the shared vehicle 102 has an unpleasant or abnormal odor based on the VOC measurements provided by the environmental sensor 236. In one embodiment, the IoT controller 212 is configured to detect an unpleasant / abnormal odor event in response to the VOC measurement exceeding a predetermined threshold or matching a predetermined profile. In one embodiment, the IoT controller 212 executes a machine learning model (e.g., an artificial neural network) to detect an unpleasant / abnormal odor event based on the VOC measurements. In one embodiment, in response to an unpleasant / abnormal odor event, the IoT controller 212 operates the camera trigger circuit 278 to cause the vehicle camera 276 to capture an image or video of the passenger compartment 108.

[0060] Additionally, in some embodiments, the IoT controller 212 may be configured to identify and / or classify the odor or stench present in the passenger compartment 108 of the shared vehicle 102 based at least on the VOC measurements provided by the environmental sensor 236. For example, based on the chemical profile of the VOCs sensed in the passenger compartment 108, and in some embodiments, in combination with the sensed temperature, humidity, atmospheric pressure, and particulate concentration, the IoT controller 212 identifies the odor as corresponding to a particular class of odor. For example, in some embodiments, the IoT controller 212 is configured to identify and classify odors corresponding to one or more of the following: tobacco, perfume, food, beverage, alcohol, urine, vomit, feces, animal odor, mold, gasoline, and other odors that may be detectable to a user of the vehicle 102. In one embodiment, the IoT controller 212 is configured to execute a machine learning model (e.g., an artificial neural network) to identify and classify the odor in the vehicle passenger compartment 108 based on the detected VOCs and in some embodiments further based on temperature, humidity, pressure, and / or particulate measurements. In some embodiments, in response to detecting certain classes of odors, the IoT controller 212 operates the camera trigger circuit 278 to cause the vehicle camera 276 to capture an image or video of the passenger compartment 108.

[0061] In some embodiments, the IoT controller 212 is configured to determine whether a driver or passenger is smoking inside the passenger compartment 108 of the shared vehicle 102 based on particulate matter measurements provided by the particulate sensor 248. In one embodiment, the IoT controller 212 is configured to monitor the curve of the particulate matter concentration over time and detect a smoking event in response to the curve of the particulate matter concentration matching a reference curve or exceeding a threshold concentration. In one embodiment, the IoT controller 212 executes a machine learning model (e.g., an artificial neural network) to detect a smoking event based on the particulate matter measurements. In one embodiment, in response to a smoking event, the IoT controller 212 operates the camera trigger circuit 278 to cause the vehicle camera 276 to capture an image or video of the passenger compartment 108.

[0062] In some embodiments, the IoT controller 212 is configured to detect whether an object such as a phone, keys, or glasses has been left behind by a passenger of the vehicle based on an image or video of the passenger compartment 108. Specifically, after a driver or passenger has left the shared vehicle 102, the IoT controller 212 operates the camera trigger circuit 278 to cause the vehicle camera 276 to capture an image or video of the passenger compartment 108. The IoT controller 212 executes an image analysis algorithm such as a machine learning model (e.g., an artificial neural network) to analyze the captured image or video of the passenger compartment 108 and detect lost or left-behind objects in the shared vehicle 102. If a lost or left-behind object is detected, the IoT controller 212 stores the lost or left-behind object event in the metadata. In one embodiment, the IoT controller 212 modifies the captured image or video to mark the lost or left-behind object in the captured image or video, such as shown by the box 342 as Figure 4 shown, and also lists the object in the metadata of the image or video. In one embodiment, the IoT controller 212 differentiates and classifies the lost or left-behind objects, for example using a machine learning model (e.g., an artificial neural network), and includes these classifications in the metadata.

[0063] In some embodiments, the IoT controller 212 is configured to detect whether the passenger compartment 108 of the vehicle is clean or dirty based on an image or video of the passenger compartment 108. Specifically, after a driver or passenger has left the shared vehicle 102, the IoT controller 212 operates the camera trigger circuit 278 to cause the vehicle camera 276 to capture an image or video of the passenger compartment 108. The IoT controller 212 executes an image analysis algorithm such as a machine learning model (e.g., an artificial neural network) to analyze the captured image or video to detect dirt or debris in the shared vehicle 102. Dirt can assume several forms, including dust, different types of soil, debris, or pieces of scattered trash or wreckage. Common examples include as Figure 5sand or grass on the floor of the car 108 as shown, and debris or other fragments on the floor or seats of the car 108 as shown in Figure 6 debris or other fragments. If dirt or debris is detected, the IoT controller 212 stores the dirt or debris event in the metadata. The IoT controller 212 modifies the captured image or video to mark the dirt or debris in the image or video, such as shown in Figure 5 and Figure 6 by boxes 344, 346, and also lists the dirt or debris in the metadata of the image or video. In one embodiment, the IoT controller 212 classifies the detected dirt or debris (e.g., removable / non-removable, garbage, hazardous, liquid, etc.) using, for example, a machine learning model (e.g., an artificial neural network) and includes these classifications in the metadata.

[0064] Returning to Figure 3 , method 300 continues to upload at least the metadata to the cloud storage backend for storage there (block 350). In particular, the IoT controller 212 is configured to operate its cellular phone modem to upload at least the determined metadata to the cloud storage backend 150. The uploaded metadata includes at least the detected events and may include corresponding timestamps indicating the time at which each event occurred there, as well as other environmental information about the detected events (e.g., images captured in response to detecting the events). In some embodiments, the IoT controller 212 is configured to also upload the original sensor data from which it detected the events, or intermediate data determined during processing the sensor data to detect the events. In some embodiments, the IoT controller 212 is configured to upload all of the original sensor data, regardless of whether the sensor data corresponds to any detected events. In one embodiment, the in-vehicle sensing module 112 uses public key infrastructure (PKI) or the equivalent to utilize a secure and encrypted (TLS V1.2 encryption) connection to the cloud storage backend 150. In one embodiment, authentication is ensured by using a certificate signed by an appropriate certificate authority.

[0065] Cloud Storage Backend

[0066] Now referring to Figure 7 , exemplary components of the cloud storage backend 150 are described. It will be understood that the components of the cloud storage backend 150 shown and described herein are merely exemplary, and the cloud storage backend 150 may include any alternative configuration.

[0067] As Figure 4As shown, an exemplary embodiment of the cloud storage backend 150 includes one or more cloud servers 400 and one or more cloud storage devices 420. The cloud server 400 includes at least one or more database servers configured to manage sensor data, event data, and / or other metadata received from the vehicle-mounted sensing module 112 and stored in the cloud storage device 420. Additionally, depending on the features provided by the cloud storage backend 150, the cloud server 400 may further include servers configured to serve various other functions for the cloud storage backend, including a web server or an application server. Each of the cloud servers 400 includes, for example, a processor 402, a memory 404, a user interface 406, and a network communication module 408. It will be understood that the illustrated embodiment of the cloud server 400 is only one exemplary embodiment of the cloud server 400 and represents only any one of the various ways or configurations of a personal computer, a server, or any other data processing system operable in the manner set forth herein.

[0068] The processor 402 is configured to execute instructions to operate the cloud server 400 to enable the features, functions, characteristics, and / or the like described herein. To this end, the processor 402 is operably connected to the memory 404, the user interface 406, and the network communication module 408. The processor 402 generally includes one or more processors that may operate in parallel or otherwise cooperate with each other. Those of ordinary skill in the art will recognize that a "processor" includes any hardware system, hardware mechanism, or hardware component that processes data, signals, or other information. Accordingly, the processor 402 may include a system having a central processing unit, a graphics processing unit, multiple processing units, dedicated circuitry for implementing functions, programmable logic, or other processing systems.

[0069] The cloud storage device 420 is configured to store sensor data, event data, and / or other metadata received from the vehicle-mounted sensing module 112. The cloud storage device 420 may be any type of long-term non-volatile storage device capable of storing information accessible by the processor 402, such as a hard disk drive or any one of the various other computer-readable storage media recognized by those of ordinary skill in the art. Similarly, the memory 404 is configured to store program instructions that, when executed by the processor 402, cause the cloud server 400 to perform the various operations described herein, including managing sensor data, event data, and / or other metadata stored in the cloud storage device 420. The memory 404 may be any type of device or combination of devices capable of storing information accessible by the processor 402, such as a memory card, ROM, RAM, hard disk drive, magnetic disk, flash memory, or any one of the various other computer-readable media recognized by those of ordinary skill in the art.

[0070] The network communication module 408 of the cloud server 400 provides an interface that allows communication with any of a variety of devices including at least the vehicle sensing module 112. In particular, the network communication module 408 may include a local area network port that allows communication with any of a variety of local computers housed in the same or nearby facilities. Typically, the cloud server 400 communicates with remote computers via the Internet through a separate modem and / or router of the local area network. Alternatively, the network communication module 408 may further include a wide area network port that allows communication via the Internet. In one embodiment, the network communication module 408 is equipped with a Wi-Fi transceiver or other wireless communication device. Thus, it will be understood that communication with the cloud server 400 may occur via wired communication or via wireless communication. Any of a variety of known communication protocols may be used to accomplish the communication.

[0071] The cloud server 400 may be operated locally or remotely by an administrator. To facilitate local operation, the cloud server 400 may include a user interface 406. In at least one embodiment, the user interface 406 may suitably include an LCD display or the like, a mouse or other pointing device, a keyboard or other keypad, a speaker, and a microphone, as would be recognized by one of ordinary skill in the art. Alternatively, in some embodiments, the administrator may operate the cloud server 400 remotely from another computing device that communicates with it via the network communication module 408 and has a similar user interface.

[0072] The cloud storage backend 150 is configured to store and manage sensor data, event data, and / or other metadata on the cloud storage device 420 in a secure manner and provide access to the sensor data, event data, and / or other metadata by the operator of the shared vehicle service and other authorized third parties via the third-party backend 160 or via a web interface or API including controlled access and identity management. To this end, in at least some embodiments, the cloud storage backend 150 communicates bidirectionally with the third-party backend 160 of the shared vehicle service provider.

[0073] Operation of Cloud Storage Backend

[0074] The following describes various methods and processes for operating the cloud storage backend 150. In these descriptions, statements that a method, processor, and / or system is performing some task or function refer to a controller or processor (e.g., processor 402 of the cloud storage backend 150) executing programming instructions stored in a non-transitory computer-readable storage medium (e.g., the memory of processor 402 of the cloud storage backend 150), which is operably connected to the controller or processor to manipulate data or operate one or more components in the vehicle monitoring system 100 to perform the task or function. Additionally, the steps of the method can be performed in any feasible temporal order, independent of the order shown in the figures or the order in which the steps are described.

[0075] Figure 8 Method 500 for operating a cloud storage system 150 to manage data uploaded from multiple on-vehicle sensing modules 112 is shown. Method 500 advantageously enables an operator of a shared vehicle service to access metadata regarding the monitoring of shared vehicles used by the shared vehicle service. In this way, method 500 advantageously enables an operator of such a shared vehicle service to monitor the condition of shared vehicles 102 in which multiple on-vehicle sensing modules 112 are installed, enforce rules and policies, and provide additional benefits to customers with minimal manual intervention.

[0076] Method 500 begins by receiving sensor data and / or its metadata from multiple on-vehicle sensing modules, each of which is installed in a respective vehicle (block 510). In particular, the processor 402 of the (one or more) cloud servers 400 of the cloud storage backend 150 operates the network communication module 408 to receive sensor data and / or metadata uploaded by each of the multiple on-vehicle sensing modules 112 installed in the multiple shared vehicles 102, such as those of a fleet of a shared vehicle service. As described above, the metadata indicates whether various conditions or events have occurred with respect to the shared vehicle 102 in which the on-vehicle sensing module 112 is installed. This metadata is determined by each on-vehicle sensing module 112 based on the sensor data captured by the sensors of each on-vehicle sensing module 112.

[0077] Method 500 continues to store the sensor data and / or its metadata in a database in association with the vehicle-mounted sensing module from which the data was received (block 520). In particular, processor 402 stores the received sensor data and / or metadata in a database on cloud storage device 420 in association with the particular vehicle-mounted sensing module 112 from which the data was received. As used herein, storing data "in association with" some other data or concept means defining a relationship or correlation between the data and the other data or concept, such as using tags, headers, tables, flags, indexes, data structures, or similar techniques. For example, in one embodiment, processor 402 tags or otherwise associates the sensor data and / or metadata in the database with the unique identifier of the particular vehicle-mounted sensing module 112 from which the sensor data and / or metadata was received, or equivalently, with the unique identifier of the shared vehicle 102 in which the corresponding vehicle-mounted sensing module 112 is installed. In this way, the source of each set of sensor data and / or metadata is identifiable in the database.

[0078] Method 500 continues to transmit an alert to a third-party backend in response to the metadata indicating that a predetermined condition or event has occurred with respect to a particular vehicle (block 530). In particular, as described above, vehicle-mounted sensing module 112 is configured to process sensor data to detect the occurrence of various predetermined conditions or events with respect to the corresponding shared vehicle 102. The metadata includes the results of this processing and can indicate, for example, whether the shared vehicle 102 has been involved in a collision or has otherwise been mechanically damaged, whether the passenger compartment 108 of the shared vehicle 102 has an unpleasant or abnormal odor, whether a driver or passenger is smoking in the passenger compartment 108 of the shared vehicle 102, whether an object has been left behind by a passenger in the shared vehicle 102, and whether the passenger compartment 108 of the shared vehicle 102 is clean or dirty.

[0079] If the metadata indicates that a predetermined condition or event (such as one of those mentioned above) has occurred with respect to the corresponding shared vehicle 102, then processor 402 is configured to operate network communication module 408 to transmit an alert message to third-party backend 160 or other remote third-party computing device (e.g., associated with an operator of the shared vehicle service) in response to receiving the metadata indicating the occurrence of the predetermined condition or event. In at least one embodiment, the alert message includes: (1) an indication of what predetermined condition or event has occurred, (2) a timestamp indicating when the predetermined condition or event occurred or was detected, and (3) the unique identifier of the vehicle-mounted sensing module 112 through which the predetermined condition or event was detected, or the unique identifier of the shared vehicle 102 in which the predetermined condition or event occurred. In one embodiment, the alert message is an email.

[0080] In this way, in the case of a customer's violation of a rule or policy (e.g., a rule prohibiting smoking in the shared vehicle 102), the operator of the shared vehicle service is immediately notified and can take action against the customer, such as by imposing a fine or banning the customer. Similarly, the operator of the shared vehicle service can take action to remedy the condition of the shared vehicle 102 (e.g., bringing the shared vehicle 102 in for repair, maintenance, or cleaning). Finally, in the case of a detected lost or left-behind object, the customer can be immediately notified.

[0081] Method 500 continues by receiving a request for sensor data and / or its metadata associated with a particular vehicle from a third-party computing device (block 540). In particular, as mentioned above, the cloud storage backend 150 is configured to provide access to sensor data and / or metadata by the operator of the shared vehicle service and other authorized third parties via the third-party backend 160 or via a web interface or application programming interface (API) including controlled access and identity management. To this end, the processor 402 operates the network communication module 408 to receive a request message that requests sensor data and / or metadata uploaded by a particular vehicle sensing module 112 or associated with a particular shared vehicle 102. The request message can be received from the third-party backend 160 or from some other authorized third-party computing device. The request message identifies a unique identifier of the particular on-vehicle sensing module 112 or a unique identifier of the particular shared vehicle 102.

[0082] Method 500 continues by transmitting the sensor data and / or its metadata associated with the particular vehicle to the third-party computing device in response to the request (block 550). In particular, the processor 402 identifies the sensor data and / or metadata stored in the database of the cloud storage device 420 that is associated with the unique identifier of the particular on-vehicle sensing module 112 or the unique identifier of the particular shared vehicle 102 indicated in the request. Then, the processor 402 of the (one or more) cloud servers 400 of the cloud storage backend 150 operates the network communication module 408 to transmit the identified sensor data and / or metadata to the third-party backend 160 or other authorized third-party device, or otherwise make the identified sensor data and / or metadata available to it.

[0083] Method 500 continues to receive corrections to metadata associated with a particular vehicle from a third-party computing device (block 560). In particular, a processor 402 of the (one or more) cloud servers 400 of the cloud storage backend 150 operates a network communication module 408 to receive a correction message that includes a correction to metadata uploaded by a particular on-vehicle sensing module 112 or associated with a particular shared vehicle 102. The correction message can be received from a third-party backend 160 or from some other authorized third-party computing device. The correction message identifies a modification or change to metadata uploaded by a particular on-vehicle sensing module 112 or associated with a particular shared vehicle 102. For example, the metadata can indicate that a particular event occurred, but upon further review by the shared vehicle service provider, it may be determined that the event did not occur. The correction can include a correction value for some portion of the metadata. Alternatively, the correction can simply identify some portion of the metadata that was incorrectly determined or otherwise incorrect, without providing a corrected or true value. An operator of the shared vehicle service can provide feedback by providing corrections to the metadata to the cloud storage backend 150.

[0084] Method 500 continues to update a model, algorithm, or threshold used to determine the metadata based on the correction to the metadata (block 570). In particular, as mentioned above, an IoT controller 212 of the on-vehicle sensing module 112 utilizes multiple models, algorithms, or thresholds to process sensor data and determine metadata. In response to receiving a correction to the metadata, a processor 402 of the (one or more) cloud servers 400 of the cloud storage backend 150 determines an update or improvement to one or more of these models, algorithms, or thresholds. Next, the processor 402 operates the network communication module 408 to transmit the update or improvement to one or more of these algorithms, models, or thresholds to each of the on-vehicle sensing modules 112 for use thereat as appropriate.

[0085] Embodiments within the scope of the present disclosure may also include a non-transitory computer-readable storage medium or machine-readable medium for carrying or having computer-executable instructions (also referred to as program instructions) or data structures stored thereon. Such a non-transitory computer-readable storage medium or machine-readable medium can be any available medium accessible by a general-purpose or special-purpose computer. By way of example and not limitation, such a non-transitory computer-readable storage medium or machine-readable medium can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store the desired program code means in the form of computer-executable instructions or data structures. Combinations of the above should also be included within the scope of the non-transitory computer-readable storage medium or machine-readable medium.

[0086] Computer-executable instructions include, for example, instructions and data that cause a general-purpose computer, special-purpose computer, or special-purpose processing device to perform certain functions or groups of functions. Computer-executable instructions also include program modules executed by computers in stand-alone or networked environments. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The computer-executable instructions, associated data structures, and program modules represent examples of program code means for performing the steps of the methods disclosed herein. A particular order of such executable instructions or associated data structures represents an example of corresponding acts for implementing the functions described in such steps.

[0087] Although the present disclosure has been described in detail in the drawings and the foregoing description, it should be regarded as illustrative rather than restrictive in character. It is to be understood that only the preferred embodiments have been presented and that all changes, modifications, and further applications falling within the spirit of the present disclosure are desired to be protected.

Claims

1. A device for monitoring a vehicle, the device comprising: a housing configured to be mounted within a vehicle; at least one sensor disposed within the housing and configured to capture sensor data; a non - volatile memory disposed within the housing and configured to store data; and a transceiver configured to communicate with a remote server; a processor disposed within the housing and operably connected to the at least one sensor, the transceiver, and the non - volatile memory, the processor being configured to: receive sensor data captured during operation of the vehicle from the at least one sensor; detect whether a predetermined condition of the vehicle has occurred based on the sensor data; store in the non - volatile memory the sensor data captured during operation of the vehicle and metadata indicating whether the predetermined condition has occurred, wherein the metadata includes the detected event, a corresponding timestamp indicating the time at which each event occurred, and other environmental information about the detected event; operate the transceiver to upload the metadata to the remote server; wherein the remote server transmits an alert message to a third - party computing device in response to receiving the metadata indicating the occurrence of a predetermined condition or event, the alert message including: (1) an indication of what predetermined condition or event has occurred, (2) a timestamp indicating when the predetermined condition or event occurred or was detected, and (3) a unique identifier of the on - vehicle sensing module through which the predetermined condition or event was detected, and at the remote server the following operations are performed: receive a correction to the metadata from the third - party computing device; update a model, algorithm, or threshold used to determine the metadata based on the correction to the metadata; and transmit the update to each of a plurality of devices for monitoring the vehicle, wherein the processor is further configured to: operate the transceiver to receive the update from the remote server.

2. The device according to claim 1, wherein: the at least one sensor includes a smoke particle sensor; and the processor is configured to detect whether a passenger in the vehicle is smoking based on sensor data received from the smoke particle sensor and store metadata indicating whether a passenger in the vehicle is smoking in the non - volatile memory.

3. The device according to claim 1, wherein: the at least one sensor includes a volatile organic compound sensor; and the processor is configured to detect an odor within the vehicle based on sensor data received from the volatile organic compound sensor and store metadata indicating the detected odor in the non - volatile memory.

4. The device according to claim 1, wherein: the at least one sensor includes at least one of an acceleration sensor and a gyroscope; and the processor is configured to detect damage to the vehicle based on sensor data received from at least one of the acceleration sensor and the gyroscope and store metadata indicating the detected damage to the vehicle in the non - volatile memory.

5. The device according to claim 4, the processor being further configured to: determine a classification of the severity of the damage to the vehicle, a metadata classification.

6. The device according to claim 1, wherein The at least one sensor includes a camera configured to capture an image of the passenger compartment of the vehicle.

7. The device according to claim 6, wherein the processor is further configured to: Trigger the camera to capture an image in response to detecting that a predetermined condition has occurred.

8. The device according to claim 6, wherein the processor is further configured to: Detect whether the vehicle's compartment is clean; and Store metadata indicating whether the vehicle's compartment is clean in the non-volatile memory.

9. The device according to claim 6, wherein the processor is further configured to: Detect whether a passenger has left an object in the vehicle's compartment; and Store metadata indicating whether a passenger has left an object in the vehicle's compartment in the non-volatile memory.

10. The device according to claim 1, wherein the processor is further configured to: Operate the transceiver to upload sensor data to a remote server.

11. The device according to claim 1, wherein the processor is further configured to: Use a model to detect whether a predetermined condition of the vehicle has occurred based on the sensor data; and Operate the transceiver to receive an update for the model from the remote server.

12. The device according to claim 11, wherein, The update for the model is determined by the remote server at least in part based on the metadata uploaded by the device.

13. The device according to claim 1, wherein the processor is further configured to: Switch the device from a first power mode to a second power mode in response to receiving a wake-up signal, Among them, In the first power mode of the device, at least one sensor is powered off and does not capture sensor data, and in the second power mode of the device, at least one sensor is powered on and captures sensor data.

14. The device according to claim 13, further comprising: A circuit connected to the vehicle's power line and configured to (i) detect that the vehicle's ignition has been activated, and (ii) transmit a wake-up signal to the processor in response to detecting that the vehicle's ignition has been activated.

15. The device according to claim 13, wherein, At least one sensor includes an acceleration sensor configured to transmit a wake-up signal to the processor in response to detecting an acceleration exceeding a predetermined threshold.

16. The device according to claim 1, further comprising: A transceiver configured to communicate with a remote server, Wherein the processor and the transceiver are configured together as one of the following: (i) a system-on-chip and (ii) a system-on-module.

17. The device according to claim 16, wherein, The transceiver is a cellular transceiver configured to communicate with the remote server via a cellular network.

18. The device according to claim 16, further comprising: A Global Navigation Satellite System (GNSS) receiver configured to determine the global position of the device, Wherein the processor, the transceiver, and the GNSS receiver are configured together as one of the following: (i) a system-on-chip and (ii) a system-on-module.

19. The device according to claim 16, further comprising: A printed circuit board disposed within a housing, Wherein at least one sensor and the non-volatile memory are disposed on the printed circuit board, and Wherein one of the following: (i) the system-on-chip is disposed on the printed circuit board, and (ii) the system-on-module is connected to a connector disposed on the printed circuit board.

Images