Cloud connectivity for in-vehicle sensing modules

Abstract

Cloud connectivity for onboard sensing modules. A cloud storage backend for managing data of an onboard sensing module is disclosed, which is advantageous for use in the context of a shared vehicle service, such as a car rental service, an autonomous taxi service, or a ride sharing service. The onboard sensing module is configured to monitor the state of the vehicle and interpret the sensor data using appropriate algorithms, models, or thresholds and enrich the data with metadata and event detection. The cloud storage backend receives relevant sensor data, event data, or other metadata from the onboard sensing module and stores the data in a database that 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, entitled “In-Vehicle Sensing Module for Monitoring a Vehicle” and filed on December 23, 2019, claims priority to U.S. Provisional Patent Application Serial No. 62 / 952,568, entitled “In-Vehicle Sensing Module for Monitoring a Vehicle” and filed on December 23, 2019, and claims priority to U.S. Provisional Patent Application Serial No. 62 / 952,623, entitled “In-Vehicle Sensing Module Having Cloud Connectivity” and filed on December 23, 2019, the disclosures of which are incorporated herein by reference in their entireties.

[0003] This application is related to U.S. patent application Ser. No. filed on the same date 17 / 116133 [Attorney Docket No. 1576-2491], and relates to U.S. Patent Application Serial No. filed on the same date 17 / 116165 [Attorney Docket No. 1576-2492], the disclosure of which is incorporated herein by reference in its 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 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 ridden by a passenger who is not the owner of the vehicle. A common problem with such services is that customers may not care how they treat the vehicle during the short time they are a passenger or driver. In view of this, operators of such services typically put in place various rules or policies on how the vehicle should be treated by customers. However, modern incarnations of these services are technology-driven and are typically fully autonomous, so that little or no direct interaction with the owner of the vehicle or the operator of the service is required. Therefore, the effective implementation of these rules or policies may be challenging and sometimes costly. Therefore, 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 when implementing rules or policies and remediating violations. Summary of the invention

[0007] A method for managing data of a vehicle monitoring system is disclosed. The vehicle monitoring system has a plurality of monitoring devices, each of the plurality of monitoring devices being installed in a corresponding vehicle and having at least one sensor configured to capture corresponding sensor data. The method further includes: receiving, at a server, corresponding metadata indicating whether at least one predetermined condition of the corresponding vehicle has occurred from each corresponding monitoring device of the plurality of monitoring devices, the corresponding metadata being determined by the corresponding monitoring device based on the corresponding sensor data. The method includes: storing, on a storage device connected to the server, corresponding metadata associated with each corresponding monitoring device of the plurality of monitoring devices. The method further includes: providing, by at least one remote computing device, access to the corresponding metadata received from each corresponding monitoring device of the plurality of monitoring devices.

[0008] A system for managing data of a vehicle monitoring system is disclosed. The system includes a transceiver configured to communicate with a plurality of monitoring devices of the vehicle monitoring system, each of the plurality of monitoring devices being installed in a corresponding vehicle and having at least one sensor configured to capture corresponding sensor data. The system further includes a storage device configured to store data received from the plurality of monitoring devices. The system further includes a processor operably connected to the transceiver and the storage device. The processor is configured to operate the transceiver to receive corresponding metadata indicating whether at least one predetermined condition of the corresponding vehicle has occurred from each corresponding monitoring device of the plurality of monitoring devices, the corresponding metadata being determined by the corresponding monitoring device based on the corresponding sensor data. The processor is further configured to operate the storage device to store, for each corresponding monitoring device of the plurality of monitoring devices, corresponding metadata associated with the corresponding monitoring device. The processor is further configured to operate the transceiver and the storage device to provide access to the corresponding metadata received from each corresponding monitoring device of the plurality of monitoring devices by at least one remote computing device.

[0009] A non-transitory computer-readable medium for managing data of a vehicle monitoring system is disclosed. The vehicle monitoring system has a plurality of monitoring devices, each of the plurality of monitoring devices being installed in a respective vehicle and having at least one sensor configured to capture respective sensor data. The computer-readable medium stores program instructions, which when executed by a processor cause the processor to: operate a transceiver to receive respective metadata indicating whether at least one predetermined condition of the respective vehicle has occurred from each respective monitoring device of the plurality of monitoring devices, the respective metadata being determined by the respective monitoring device based on the respective sensor data. The computer-readable medium further stores program instructions, which when executed by the processor cause the processor to: operate a storage device to store, for each respective monitoring device of the plurality of monitoring devices, respective metadata associated with the respective monitoring device. The computer-readable medium further stores program instructions, which when executed by the processor cause the processor to: operate a transceiver and a storage device to provide, by at least one remote computing device, access to the respective metadata received from each respective monitoring device of the plurality of monitoring devices. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0012] Figure 2 Shows Figure 1Example electronic components of an in-vehicle sensing module.

[0013] Figure 3 Shows the operation Figure 1 A method for using an on-board sensing module to monitor at least a cabin of a shared vehicle.

[0014] Figure 4 A photograph of the cabin of a shared vehicle is shown, with the objects left behind marked with a box.

[0015] Figure 5 A photograph of the cabin of a shared vehicle is shown, with dirt on the floor of the vehicle marked with a box.

[0016] Figure 6 A photograph of the cabin of a shared vehicle is shown with debris on the floor and seats of the vehicle marked with boxes.

[0017] Figure 7 Shows Figure 1 Example components of a cloud storage backend.

[0018] Figure 8 Shows the operation Figure 1 A method for managing data uploaded from multiple vehicle-mounted sensing modules using a cloud storage system. DETAILED DESCRIPTION

[0019] For the purpose of promoting an 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 no limitation of the scope of the present disclosure is intended thereby. It is further understood that 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 normally occur to a person skilled in the art to which the present disclosure pertains.

[0020] System Overview

[0021] Figure 1 A simplified block diagram of a vehicle monitoring system 100 is shown having an onboard sensing system 104 for monitoring at least a cabin 108 of a vehicle 102. The vehicle monitoring system 100 is advantageous for use in the context of a shared vehicle service, where the shared vehicle 102 is driven by a driver or ridden 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 may use a smartphone application, a website, an on-site kiosk, or the like to engage the shared vehicle service in an automated manner, which involves little or no direct human intervention by the operator of the shared vehicle service.

[0022] The onboard sensing system 104 advantageously enables the operator of the shared vehicle service to monitor the condition of the shared vehicles 102, implement rules and policies, and provide additional benefits to customers with minimal human intervention. Such rules and policies may include a rule prohibiting smoking in the shared vehicles 102 or a surcharge for any required cleaning of the shared vehicles 102 after use by a customer. In addition, the operator may provide additional benefits to customers, such as notifying them of objects left behind.

[0023] The onboard sensing system 104 includes an onboard 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 cabin 108, preferably integrated into a common housing mounted in the cabin 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 cabin 108 of the shared vehicle 102. Alternatively, in one embodiment, the housing is adapted to be retrofitted to a specific brand and model of the shared vehicle 102, such as in place of an eye-glass holder. In some embodiments, the onboard sensing system 104 further includes additional external sensors 120 disposed on or throughout the shared vehicle 102, which are operably connected to the onboard sensing module 112 via one or more communication buses 124. In some embodiments, the sensors 116, 120 used by the onboard sensing module 112 may be specific to a specific brand and model of the shared vehicle 102.

[0024] In addition to the onboard 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 and the drive system 132 and with the onboard 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 onboard 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, such as an internal combustion engine and / or one or more electric motors, that drives the wheels of the shared vehicle 102, as well as steering and braking components that enable the shared vehicle 102 to move in a controlled manner. The vehicle battery 136 is configured to provide operating power to the onboard sensing module 112, the external sensor 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 switch / accessory power line of the shared vehicle 102).

[0025] The onboard sensing module 112 is configured to monitor the state of at least the cabin 108 of the vehicle. In particular, the onboard sensing module 112 is configured to process sensor data received from sensors 116, 120 to infer one or more conditions, qualities or states of the shared vehicle 102. For example, the onboard 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 onboard sensing module 112 interprets the sensor data using appropriate algorithms, models (e.g., artificial neural networks), or thresholds and enriches the data using metadata and event detection. One 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).

[0026] To this end, depending on the particular condition, quality, or state of the shared vehicle 102 to be monitored, the sensors 116, 120 may include a 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 cabin 108 to capture images of the cabin 108, such as inherent images of the shared vehicle or images installed by an aftermarket. In one embodiment, the external sensor 120 includes a gyroscope / accelerometer module, which may include, for example, a microphone, a gyroscope, and an accelerometer integrated in a single housing attached to the chassis of the shared vehicle 102.

[0027] The onboard 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 with, for example, the shared vehicle service discussed above, such as a car rental service, an autonomous taxi service, or a ride sharing service. In this way, the operator of the shared vehicle service can monitor the condition of the shared vehicle 102, implement rules and policies, and provide additional benefits to customers with minimal human intervention.

[0028] Vehicle sensing module

[0029] refer to Figure 2 , describes exemplary components of one embodiment of the vehicle sensing module 112. The vehicle sensing module 112 includes a housing 204, and at least one printed circuit board (PCB) 208 is housed and mounted within the housing 204. The PCB 208 supports and electrically interconnects a plurality of electrical components, including at least a controller 212 configured to operate the vehicle sensing module 112.

[0030] The controller 212 includes at least a processor and associated memory. One 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, a plurality of processing units, a dedicated circuit for implementing a function, a programmable logic, or other processing system. The memory may be any type of device capable of storing information accessible by a processor, such as a flash card, ROM, RAM, a hard drive, a disk, or any of a variety of other computer-readable media used as volatile or non-volatile data storage devices, as one of ordinary skill in the art will recognize. The memory is configured to store program instructions that, when executed by the processor, enable the onboard sensing module 112 to perform various operations, including monitoring the cabin 108 of the shared vehicle 102, as described below.

[0031] In the illustrated embodiment, the controller 212 takes the form of an Internet of Things (IoT) controller 212 having integrated features and functionality in addition to the features and functionality of a general purpose multi-purpose controller. To this end, in the illustrated embodiment, the IoT controller 212 is configured as a system on a chip (SoC) disposed on the PCB 208. Alternatively, the IoT controller 212 may be equivalently configured as a system on a module (SoM), wherein its subcomponents 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 functionality in addition to a processor and memory.

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

[0033] The cellular telephone modem of the IoT controller 212 is connected to a 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 separate from the PCB 208, and may, for example, include a flexible antenna mounted along an interior sidewall of the housing 204 or designed in some other manner to improve cellular reception of the onboard sensing module 112. The cellular telephone modem is further connected to a subscriber identity module (“SIM”) card 220, which is inserted into a SIM card holder 222, which is disposed on the PCB 208 and is configured to connect the SIM card 220 to the IoT controller 212. The SIM card 220 provides identification information to enable the cellular telephone modem to access a wireless telephone network, as is generally known in the art.

[0034] In some embodiments, the IoT controller 212 advantageously provides an integrated global navigation satellite system (GNSS) function. To this end, the IoT controller 212 includes a GNSS receiver and any other processor, memory, oscillator or other hardware conventionally included in the GNSS module. The GNSS receiver is configured to receive signals from GNSS satellites, and position data can be determined from the signal. The GNSS receiver is configured to support one or more of, for example, 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 arranged in or on the PCB 208, but may alternatively be separately arranged inside or outside the housing 204. It should be understood that in alternative embodiments, a thoughtful GNSS module may be provided on the PCB 208 separated from the controller 212.

[0035] In some embodiments (not shown), the IoT controller 212 may further include an integrated and / or A transceiver configured to communicate locally with a smartphone or other smart device owned by a passenger or driver using the shared vehicle 102. Likewise, in some embodiments, a discreet PCB 208 may be provided separate from the controller 212. and / or Transceiver.

[0036] Finally, in some embodiments, the IoT controller 212 advantageously includes a variety of integrated data / peripheral interfaces for operatively connecting with a variety of additional components of the vehicle sensing system 104, including general purpose input / output (GPIO), serial peripheral interface (SPI), inter-integrated circuit (IC) and the like. 2 C or I2C), Inter-IC Sound (Inter-ICSound) (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 in the shared vehicle 102, as well as providing compatibility with a variety of configurations of integrated sensors 116.

[0037] As described above, the onboard sensing module 112 includes one or more integrated sensors 116 configured to monitor the status of the shared vehicle 102 or at least its cabin 108. These integrated sensors 116 can be directly integrated with the IoT controller 212, arranged on the PCB 208, or otherwise arranged in a housing 204 separated from the PCB 208. The IoT controller 212 is configured to receive sensor data from the integrated sensors 116 and any external sensors 120, and write the sensor data to a non-volatile memory. In addition, the IoT controller 212 is configured to process the sensor data to determine a variety of metadata, which is also written to the non-volatile memory. To this end, in the illustrated embodiment, the IoT controller 212 is connected to a removable memory storage device 228, which is inserted into a removable storage medium holder 230, which is arranged on the PCB 208 and is configured to connect the removable memory storage device 228 to the IoT controller 212 (e.g., via SDIO). The removable memory storage device 228 may include, for example, a Secure Digital (SD), SD High Capacity (SDHC), or SD Extended Capacity (SDXC) memory card, and any equivalent type of removable memory card or other non-volatile storage technology.

[0038] In the illustrated embodiment, the integrated sensor 116 includes an inertial measurement unit (IMU) 232 that is disposed on the PCB 208 and connected to the IoT controller 212 (e.g., via I 2C). The IMU 232 includes one or more gyroscope 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 gyroscope measurements. As will be discussed further below, in at least some embodiments, in response to measurements from the IMU 232, the onboard 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.

[0039] In the illustrated embodiment, the integrated sensor 116 includes an environmental sensor 236 that is disposed on the PCB 208 and is connected to the IoT controller 212 (e.g., via I 2 C). Environmental sensor 236 is configured to detect properties indicative of air quality in the cabin, such as relative humidity, barometric pressure, temperature, and the presence of organic compounds, more specifically volatile organic compounds ("VOCs"). Thus, environmental sensor 236 includes a variety of individual sensors integrated into a single package. However, it should be understood that individual, discreet sensors may alternatively be provided, including a VOC sensor, a humidity sensor, a barometric pressure sensor, and a temperature sensor.

[0040] In the illustrated embodiment, the integrated sensor 116 includes at least one microphone 240, which is arranged 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 cabin 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 so as to record stereo audio of the cabin 108. In one embodiment, the microphone(s) 240 take the form of micro-electromechanical systems (MEMS) microphones mounted directly 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 audio from the microphone(s) 240, amplify audio from the microphone(s) 240, filter audio from the microphone(s) 240, or otherwise encode or process audio from the microphone(s) 240 for appropriate use by the IoT controller 212. In one embodiment, the housing 204 defines an opening or group of openings 244 that are located proximate the microphone(s) 240 on the PCB 208 and that allow for the exchange of air between the exterior of the housing 204 and the interior space of the housing 204 proximate the microphone(s) 240. In one embodiment, each of the microphone(s) 240 is surrounded by an acoustic seal (not shown) that seals at one end against the PCB 208. The acoustic seal acoustically isolates the microphone(s) 240 so as to reduce interference in sound transmitted through the opening 244 and detected by the microphone(s) 240.

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

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

[0043] In the illustrated embodiment, the onboard sensing module 112 further includes a power supply 264 configured to convert power from the vehicle battery 136 to an appropriate voltage for powering the IoT controller 212 and other components of the onboard 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 onboard sensing module 112 in a low power mode of the onboard sensing module 112. The power supply 264 is connected to an external I / O connector 266, via which the power supply 264 receives input power from the vehicle battery 136. It should be understood that in some embodiments, if the power from the vehicle battery 136 is interrupted, the PCB 208 includes or is operably connected to a battery (not shown) as an auxiliary power source.

[0044] In the illustrated embodiment, the onboard 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 that 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 connect to one or more vehicle interfaces, buses, or systems (including at least the power cable 140) of the shared vehicle 102 via one or more wiring harnesses or equivalents to receive a vehicle battery voltage 274 (e.g., 12V) from the vehicle battery 136. In addition, in at least some embodiments, the external cable 268 is configured to connect to one or more communication buses 124 to receive data from the external sensors 120 and / or from the vehicle ECU 128.

[0045] In the illustrated embodiment, the 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 cabin 108. The vehicle camera 276 may be a pre-existing camera that is inherent to the brand and model of the shared vehicle 102, or may be a camera that has been installed in an aftermarket shared vehicle 102. The onboard 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 cabin 108. The IoT controller 212 is configured to receive the captured image from the vehicle camera 276 via the camera trigger circuit 278 or via another data connection.

[0046] In the illustrated embodiment, the on-board sensing module 112 further includes an ignition sensing circuit 282, which is arranged 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, 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-board sensing module 112 switches from a low power mode to an active state. In other words, the ignition signal can act as a wake-up signal for the IoT controller 212.

[0047] In the illustrated embodiment, the onboard sensing module 112 further includes a battery monitoring circuit 286, which is arranged 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 onboard sensing module 112 is controlled or changed according to the voltage and current of the power line 140.

[0048] Finally, in the illustrated embodiment, the onboard 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 onboard sensing module 112 to read or receive data from the onboard sensing module 112. The external device connector 290 may, for example, take the form of a USB connector (e.g., USB-A, USB-C, micro USB, etc.) or the like that is configured to enable wired communication between the IoT controller 212 and the external computing device.

[0049] Operation of the vehicle sensing module

[0050] Various methods and processes for operating the onboard 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 onboard sensing module 112) executing programmed instructions stored in a non-transitory computer-readable storage medium (e.g., the memory of the IoT controller 212 of the onboard sensing module 112 or the removable memory storage device 228) that 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. In addition, the steps of the method can be performed in any feasible time order, regardless of the order shown in the figure or the order in which the steps are described.

[0051] Figure 3 A method 300 for operating an onboard sensing module 112 to monitor at least a cabin 108 of a 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, for example in the context of a shared vehicle service such as a car rental service, an autonomous taxi service, a ride sharing service, or the like. In addition, the method 300 advantageously processes the sensor data to provide metadata, which is also stored in the non-volatile memory. The method 300 advantageously enables operators of such shared vehicle services to monitor the condition of the shared vehicles 102, implement rules and policies, and provide additional benefits to customers with minimal human intervention.

[0052] The method 300 begins by powering on the onboard 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 of the shared vehicle 102, which directly provides the battery voltage of the vehicle battery 136. It will be understood that if accurately measured, 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 open signal to the IoT controller 212 to at least partially open the onboard sensing module 112. The predetermined threshold voltage is a battery voltage corresponding to a predetermined state of charge of the vehicle battery. In one embodiment, the predetermined state of charge is a 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 sufficiently charged, the onboard sensing module 112 will operate solely on battery power and will not cause the vehicle battery to be unnecessarily drained if the shared vehicle 102 is not started for a long period of time.

[0053] In an alternative embodiment, the power line 140 connected via the external I / O connector 266 is a switch / accessory power line of the shared vehicle 102, which provides the battery voltage of the vehicle battery 136 only when the ignition has been activated to start the shared vehicle 102 (usually by toggling the operating element of the ignition while the brake is pressed) or only when the accessory power of the shared vehicle 102 has been activated (usually by toggling the operating element of the ignition without pressing the brake). Therefore, in response to detecting the battery voltage from the vehicle battery 136, the battery monitoring circuit 286 provides an open signal to the IoT controller 212 to at least partially open.

[0054] The method 300 continues to operate the onboard sensing module in a low power mode until a wake-up condition occurs (block 320). In particular, in response to the turn-on signal, the onboard sensing module 112 begins operating in a low power mode in which the IoT controller 212 activates a subset of the components of the onboard sensing module 112 to turn on. In particular, in an exemplary embodiment, in the low power mode, only the low power supplies of the IMU 232, the environmental sensor 236, the ignition sensing circuit 282, and the power supply 264 are activated. In addition, the IoT controller 212 itself can operate in a low power state in which certain functions or subcomponents (such as those related to cellular phones and GNSS) are disabled.

[0055] The onboard 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 onboard sensing module 112 begins to operate in an active mode in which the IoT controller 212 activates all components of the onboard 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 a disturbance of the shared vehicle 102 (e.g., an acceleration or gyroscope measurement exceeds a threshold or matches a predetermined profile), indicating, for example, that the driver has unlocked the shared vehicle 102 and entered the cabin 108. In one embodiment, if the cellular phone function of the IoT controller 212 is operable during the low power mode, the wake-up signal can be received from the cloud storage backend 150.

[0056] The method 300 continues by receiving sensor data from the integrated sensors and external sensors and writing 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 recording / writing 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 circular buffers) on the removable memory storage device 228 to manage the storage of newly measured sensor data and the deletion of old sensor data.

[0057] The method 300 continues to process the sensor data to determine metadata including event data and write the metadata to local non-volatile memory (box 340). In particular, the IoT controller 212 is configured to process sensor data received from the integrated sensor 116 or from the external sensor 120 to enrich the data with metadata and, in particular, event detection. As discussed above, the sensors 116, 120 may 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 for the stored sensor data.

[0058] 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 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 to the algorithm or model from the cloud storage backend 150 via its cellular telephone modem.

[0059] In some embodiments, in response to detecting a specific 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 vehicle cabin 108. The IoT controller 212 stores the captured image on the removable memory storage device 228 as metadata for the sensor data from which the specific quality, condition, state, or event is detected.

[0060] In some embodiments, the IoT controller 212 is configured to determine whether the shared vehicle 102 has been involved in a collision or has been otherwise mechanically damaged based on acceleration and gyroscope measurements provided by the IMU 232 or by similar external sensors 120. In one embodiment, the IoT controller 212 is configured to detect a collision or damage event in response to acceleration and / or gyroscope measurements exceeding a predetermined threshold or matching a predetermined acceleration line. 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 acceleration and / or gyroscope measurements. In one embodiment, the IoT controller 212 detects where the damage occurred (e.g., left front) based on acceleration and / or gyroscope measurements or other sensor data and classifies the severity or level of the damage (e.g., severe). 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 acceleration and / or gyroscope 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 vehicle cabin 108 .

[0061] In some embodiments, the IoT controller 212 is configured to determine whether the cabin 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 line. In one embodiment, the IoT controller 212 executes a machine learning model (e.g., an artificial neural network) to detect unpleasant / abnormal odor events 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 cabin 108.

[0062] In addition, in some embodiments, the IoT controller 212 can be configured to identify and / or classify odors or odors present in the cabin 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 cabin 108, and in some embodiments, in combination with the sensed temperature, humidity, atmospheric pressure, and particle concentration, the IoT controller 212 identifies the odor as corresponding to a particular category of odors. 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 odors, mold, gasoline, and other odors that may be detectable to the 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 odors in the vehicle cabin 108 based on the detected VOCs and, in some embodiments, further based on the temperature, humidity, pressure, and / or particle 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 vehicle cabin 108 .

[0063] In some embodiments, the IoT controller 212 is configured to determine whether the driver or passenger is smoking in the cabin 108 of the shared vehicle 102 based on the particulate matter measurement 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 line / 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 measurement. In one embodiment, in response to the 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 cabin 108.

[0064] 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 cabin 108. In particular, after the driver or passenger leaves 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 cabin 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 cabin 108 and detect objects lost or left behind 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 Figure 4 342, and also lists the objects in the metadata of the image or video. In one embodiment, the IoT controller 212 uses, for example, a machine learning model (e.g., an artificial neural network) to distinguish and classify the lost or left behind objects and includes these classifications in the metadata.

[0065] In some embodiments, the IoT controller 212 is configured to detect whether the cabin 108 of the vehicle is clean or dirty based on an image or video of the cabin 108. In particular, after the driver or passenger leaves 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 cabin 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 garbage or debris. Common examples include such as Figure 5The sand or grass on the floor of the carriage 108 shown in FIG. Figure 6 108 shown in FIG. 10A . 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 Figure 5 and Figure 6 The IoT controller 212 may further include a list of dirt or debris in the metadata of the image or video, as shown in blocks 344 and 346. In one embodiment, the IoT controller 212 may classify the detected dirt or debris (e.g., removable / non-removable, trash, hazardous, liquid, etc.) using, for example, a machine learning model (e.g., an artificial neural network) and include these classifications in the metadata.

[0066] Return to Figure 3 , the method 300 continues by uploading at least the metadata to the cloud storage backend for storage thereat (block 350). In particular, the IoT controller 212 is configured to operate its cellular telephone 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, as well as other environmental information about the detected events (e.g., images captured in response to detecting the event). In some embodiments, the IoT controller 212 is configured to also upload raw sensor data from which the event was detected, or intermediate data determined during processing of the sensor data to detect the event. In some embodiments, the IoT controller 212 is configured to upload all raw sensor data, regardless of whether the sensor data corresponds to any detected event. In one embodiment, the onboard sensing module 112 utilizes a secure and encrypted (TLS V1.2 encrypted) connection to the cloud storage backend 150 using a public key infrastructure (PKI) or equivalent. In one embodiment, authentication is ensured by using a certificate signed by an appropriate certificate authority.

[0067] Cloud storage backend

[0068] Reference now Figure 7 , describes exemplary components of the cloud storage backend 150. It will be understood that the components of the cloud storage backend 150 shown and described herein are exemplary only, and that the cloud storage backend 150 may include any alternative configurations.

[0069] like Figure 4As shown in , 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 sensing module 112 and stored in the cloud storage device 420. In addition, according to the features provided by the cloud storage backend 150, the cloud server 400 may further include a server configured to serve a variety of 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 an exemplary embodiment of the cloud server 400, and only represents any of the various modes or configurations of a personal computer, a server, or any other data processing system operable in the manner set forth herein.

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

[0071] The cloud storage device 420 is configured to store sensor data, event data, and / or other metadata received from the onboard sensing module 112. The cloud storage device 420 can be any type of long-term non-volatile storage device capable of storing information accessible by the processor 402, such as a hard drive or any of a variety of other computer-readable storage media recognized by a person of ordinary skill in the art. Similarly, the memory 404 is configured to store program instructions that, when executed by the processor 402, enable the cloud server 400 to perform various operations described herein, including managing sensor data, event data, and / or other metadata stored in the cloud storage device 420. The memory 404 can 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 drive, disk, flash memory, or any of a variety of other computer-readable media recognized by a person of ordinary skill in the art.

[0072] The network communication module 408 of the cloud server 400 provides an interface that allows communication with any of the various devices including at least the onboard sensing module 112. In particular, the network communication module 408 may include a local area network port that allows communication with any of the various local computers housed in the same or nearby facilities. Typically, the cloud server 400 communicates with the remote computer via the Internet via 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. Therefore, it will be understood that communication with the cloud server 400 can occur via wired communication or via wireless communication. Any of the various known communication protocols can be used to complete the communication.

[0073] The cloud server 400 can 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 screen or the like, a mouse or other pointing device, a keyboard or other keypad, a speaker, and a microphone, as will be recognized by those of ordinary skill in the art. Alternatively, in some embodiments, the administrator may remotely operate the cloud server 400 from another computing device that communicates with it via a network communication module 408 and has a similar user interface.

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

[0075] Cloud storage backend operations

[0076] Various methods and processes for operating the cloud storage backend 150 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., processor 402 of the cloud storage backend 150) executing programmed instructions stored in a non-transitory computer-readable storage medium (e.g., a memory of processor 402 of the cloud storage backend 150) that 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. In addition, the steps of the method can be performed in any feasible time order, regardless of the order shown in the figure or the order in which the steps are described.

[0077] Figure 8 A method 500 for operating a cloud storage system 150 to manage data uploaded from a plurality of onboard sensing modules 112 is shown. The method 500 advantageously enables operators of a shared vehicle service to access monitored metadata about shared vehicles used by the shared vehicle service. In this manner, the method 500 advantageously enables operators of such a shared vehicle service to monitor the conditions of shared vehicles 102 in which a plurality of onboard sensing modules 112 are installed, implement rules and policies, and provide additional benefits to customers with minimal human intervention.

[0078] The method 500 begins by receiving sensor data and / or metadata thereof from a plurality of onboard sensing modules, each of which is installed in a respective vehicle (block 510). In particular, the processor 402 of the cloud server(s) 400 of the cloud storage backend 150 operates the network communication module 408 to receive sensor data and / or metadata uploaded by each of a plurality of onboard sensing modules 112 installed in a plurality of shared vehicles 102, such as those of a fleet of shared vehicle services. As described above, the metadata indicates whether various conditions or events have occurred relative to the shared vehicle 102 in which the onboard sensing module 112 is installed. The metadata is determined by each onboard sensing module 112 based on sensor data captured by the sensors of each onboard sensing module 112.

[0079] The method 500 continues by storing the sensor data and / or its metadata in a database in association with the onboard sensing module from which the data was received (block 520). In particular, the processor 402 stores the received sensor data and / or metadata in a database on the cloud storage device 420 in association with the specific onboard 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, the processor 402 tags or otherwise associates the sensor data and / or metadata in the database with a unique identifier of the specific onboard sensing module 112 from which the sensor data and / or metadata was received, or equivalently, tags or otherwise associates with a unique identifier of the shared vehicle 102 in which the corresponding onboard sensing module 112 is installed. In this manner, the source for each set of sensor data and / or metadata is identifiable in the database.

[0080] The method 500 continues by transmitting an alert to a third-party backend in response to the metadata indicating that a predetermined condition or event has occurred with respect to the particular vehicle (block 530). In particular, as described above, the onboard sensing module 112 is configured to process the 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 may indicate, for example, whether the shared vehicle 102 has been involved in a collision or has been otherwise mechanically damaged, whether the cabin 108 of the shared vehicle 102 has an unpleasant or unusual odor, whether the driver or passenger is smoking in the cabin 108 of the shared vehicle 102, whether a passenger of the shared vehicle 102 has left an object behind, and whether the cabin 108 of the shared vehicle 102 is clean or dirty.

[0081] 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, the processor 402 is configured to operate the network communication module 408 to transmit an alert message to the third-party backend 160 or other remote third-party computing device (e.g., associated with the operator of the shared vehicle service) in response to receiving the metadata indicating that the predetermined condition or event has occurred. In at least one embodiment, the alert message includes: (1) an indication of the occurrence of the predetermined condition or event, (2) a timestamp indicating when the predetermined condition or event occurred or was detected, and (3) a unique identifier of the onboard sensing module 112 by which the predetermined condition or event was detected, or a unique identifier of the shared vehicle 102 in which the predetermined condition or event occurred. In one embodiment, the alert message is an email.

[0082] In this way, in the event that a rule or policy is violated by a customer (e.g., a rule prohibiting smoking in a shared vehicle 102), the operator of the shared vehicle service is immediately notified and can take action against the customer, such as by fining 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 servicing, repair, or cleaning). Finally, in the event that a lost or left-behind object is detected, the customer can be notified immediately.

[0083] The method 500 continues by receiving a request for sensor data and / or 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 operators of the shared vehicle service and other authorized third parties via a 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 requesting sensor data and / or metadata uploaded by a particular vehicle sensing module 112 or associated with a particular shared vehicle 102. The request message may 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 a particular onboard sensing module 112 or a unique identifier of a particular shared vehicle 102.

[0084] The method 500 continues to transmit the sensor data and / or metadata associated with the specific 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, which is associated with the unique identifier of the specific onboard sensing module 112 or the unique identifier of the specific shared vehicle 102 indicated in the request. The processor 402 of the (one or more) cloud servers 400 of the cloud storage backend 150 then 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.

[0085] The method 500 continues to receive corrections to metadata associated with a particular vehicle from a third-party computing device (block 560). 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 a correction message that includes corrections to metadata uploaded by a particular onboard sensing module 112 or associated with a particular shared vehicle 102. The correction message may be received from the 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 onboard sensing module 112 or associated with a particular shared vehicle 102. For example, the metadata may 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 may include correction values ​​for some portions of the metadata. Alternatively, the correction may simply identify some portions of the metadata that are incorrectly determined or otherwise erroneous, without providing a corrected or true value. The operator of the shared vehicle service may provide feedback by providing corrections to the metadata to the cloud storage backend 150.

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

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

[0088] Computer executable instructions include, for example, instructions and data that cause a general purpose computer, a special purpose computer, or a special purpose processing device to perform certain functions or groups of functions. Computer executable instructions also include program modules that are executed by computers in a stand-alone or network environment. Typically, program modules include routines, programs, objects, components, and data structures that perform specific tasks or implement specific abstract data types. 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 specific sequence of such executable instructions or associated data structures represents an example of corresponding actions for implementing the functions described in such steps.

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

Claims

1. A method for managing data of a vehicle monitoring system, the vehicle monitoring system having a plurality of monitoring devices, each of the plurality of monitoring devices being installed in a respective vehicle and having at least one sensor configured to capture respective sensor data, the method comprising: receiving, at a server, from each respective monitoring device of a plurality of monitoring devices respective metadata indicating whether at least one predetermined condition of the respective vehicle has occurred, the respective metadata being determined by the respective monitoring device based on the respective sensor data; storing, on a storage device connected to the server, for each respective monitoring device of the plurality of monitoring devices, respective metadata associated with the respective monitoring device; providing, by at least one remote computing device, access to respective metadata received from each respective monitoring device of the plurality of monitoring devices; receiving, at a server, a message from at least one remote computing device, the message indicating a correction to corresponding metadata received by a first monitoring device of the plurality of monitoring devices; determining, with the server, an update to at least one of: (i) a model, (ii) an algorithm, and (iii) a threshold used by the first monitoring device to determine the respective metadata based on the respective sensor data, based on the correction; as well as Utilize a server to transmit updates to multiple monitoring devices.

2. The method of claim 1, further comprising: At a server, receiving corresponding sensor data from a first monitoring device of a plurality of monitoring devices, corresponding metadata being determined from the corresponding sensor data; storing, on a storage device for the first monitoring device, corresponding sensor data associated with the first monitoring device; as well as Access is provided by at least one remote computing device to corresponding sensor data received from the first monitoring device.

3. The method of claim 1, wherein storing further comprises: Respective metadata associated with at least one of: (i) a unique identifier of the respective monitoring device, and (ii) a unique identifier of the respective vehicle in which the respective monitoring device is installed is stored on the storage device for each respective monitoring device of the plurality of monitoring devices.

4. The method of claim 1, providing access further comprising: At a server, receiving a request message from at least one remote computing device, the request message identifying at least one of: (i) a first monitoring device among a plurality of monitoring devices, and (ii) a respective vehicle in which the first monitoring device is installed; as well as The corresponding metadata received from the first monitoring device is transmitted, by the server, to at least one remote computing device.

5. The method of claim 1, providing access further comprising: Access to respective metadata received from each respective monitoring device of the plurality of monitoring devices is provided via at least one of: (i) a web interface, and (ii) an application programming interface.

6. The method of claim 1, further comprising: In response to the respective metadata of a first monitoring device of the plurality of monitoring devices indicating that a first predetermined condition of at least one predetermined condition of the respective vehicle has occurred, transmitting, by the server, an alert message to at least one remote computing device. The method of claim 6 , wherein the alert message is an email message.

8. The method of claim 6, wherein: The alert message identifies a time at which the first predetermined condition occurs.

9. The method of claim 1, wherein: The correction includes an indication that the corresponding metadata was erroneously determined.

10. The method of claim 1, wherein: The correction includes a correction value for the corresponding metadata.

11. The method of claim 1, wherein: The at least one predetermined condition of the respective vehicle includes detecting smoking by an occupant of the respective vehicle within the vehicle.

12. The method of claim 1, wherein: At least one predetermined condition of the respective vehicle includes detection of an odor within the vehicle.

13. The method of claim 1, wherein: The at least one predetermined condition of the respective vehicle includes detection of damage to the respective vehicle.

14. The method of claim 1, wherein: The at least one predetermined condition of the respective vehicle includes detection of a collision of the respective vehicle.

15. The method of claim 1, wherein: The at least one predetermined condition of the respective vehicle includes detection of uncleanliness of a cabin of the respective vehicle.

16. The method of claim 1, wherein: At least one predetermined condition of the respective vehicle includes detection of an object left behind by a passenger.

17. A system for managing data of a vehicle monitoring system, the server comprising: a transceiver configured to communicate with a plurality of monitoring devices of a vehicle monitoring system, each monitoring device of the plurality of monitoring devices being installed in a respective vehicle and having at least one sensor configured to capture respective sensor data; a storage device configured to store data received from a plurality of monitoring devices; as well as a processor operably connected to the transceiver and the memory device, the processor being configured to: operating a transceiver to receive, from each respective monitoring device of the plurality of monitoring devices, respective metadata indicating whether at least one predetermined condition of the respective vehicle has occurred, the respective metadata being determined by the respective monitoring device based on the respective sensor data; operating a storage device to store, for each respective monitoring device of the plurality of monitoring devices, respective metadata associated with the respective monitoring device; operating the transceiver and the storage device to provide, by at least one remote computing device, access to respective metadata received from each respective monitoring device of the plurality of monitoring devices; operating a transceiver to receive a message from at least one remote computing device, the message indicating a correction to corresponding metadata received by a first monitoring device of the plurality of monitoring devices; Based on the correction, determining an update to at least one of: (i) a model, (ii) an algorithm, and (iii) a threshold used by the first monitoring device to determine the corresponding metadata based on the corresponding sensor data; and The transceiver is operated to transmit updates to the plurality of monitoring devices.

18. A non-transitory computer-readable medium for managing data of a vehicle monitoring system, the vehicle monitoring system having a plurality of monitoring devices, each of the plurality of monitoring devices being installed in a corresponding vehicle and having at least one sensor configured to capture corresponding sensor data, the computer-readable medium storing program instructions which, when executed by a processor, cause the processor to perform the method of any one of claims 1 to 16.

Images