Patent Application
20170278313
This disclosure relates generally to the technical field of devices, systems, and methods that remotely monitor terrestrial vehicles (e.g. trucks).
Millions of heavy-duty trucks operate in US and deliver nearly 70% of all U.S. freight, amounting to billion dollars worth of manufactured and retail goods per year. Operating and maintaining a truck or a fleet of trucks is costly, and may be measured not only in fuel, parts and labor, but also in downtime. Truck accidents or breakdowns are also costly. Therefore, it is an object of this invention to reduce accidents and breakdowns by improving safety, spotting risky driver behaviors (e.g. drowsiness and intoxication), and lowering fuel costs; It is further an object of this invention to lower the cost of vehicle maintenance by reducing downtime, negotiating for parts and labor, and improving the effectiveness of maintenance.
In addition, stakeholders in a vehicle, law enforcement, regulatory agencies, revenue agencies, and national security organizations lack automated aids to monitoring truck traffic. Managing trucks and assessing the operating costs and operating risks of truck traffic is largely a manual process involving physical inspections and personal interviews. Therefore, it is an object of this invention to automate remote truck monitoring, in part by transmitting vehicle operating data to an accessible database.
A vehicle monitoring system must support a variety of communication protocols in order to transmit data from a vehicle subsystem to a stationary transceiver. Thus, it is also an object of the invention to use modular components where possible to support component and supplier flexibility.
In one embodiment a device, method, and system may monitor the subsystems of a terrestrial vehicle (e.g. truck). In one embodiment a device may collect data from the vehicle and may use a wireless radio unit to communicate the collected data to a stationary transceiver. The collected data may comprise operating data that may be accepted from the on-board diagnostic (OBD) system of the vehicle, which is the vehicle's self-diagnostic and reporting system. The wireless radio unit and the stationary transceiver may be part of a cellular radio network. The device may also collect and communicate environment data, driver data, and driver status data, including but not limited to an ID of the driver, a head position of the driver, eye activity of the driver, and a heart beat of the driver. The device may act on the collected data to, for example, improve vehicle safety and avoid accidents. The collected data may be accepted from the stationary transceiver by a processor and then stored in a database. From the database the collected data may be compared to threshold data to determine when to schedule maintenance procedures and order parts, and driving distance (i.e. driving time) may be computed to select on-route service locations and estimate arrival times.
Other embodiments will be apparent from the following description and the appended claims.
Example embodiments are illustrated by way of example and not limitation in the figures of accompanying drawings, in which like references indicate similar elements and in which:
Other features of the present embodiments will be apparent from the accompanying Drawings and from the Detailed Description that follows.
In one embodiment a device, method, and system may monitor the subsystems of a terrestrial vehicle (e.g. truck). A device may collect data from the vehicle 100 and may use a wireless radio unit 107 to communicate the collected data to a stationary transceiver 111. The collected data may comprise operating data 207 that may be accepted from the on-board diagnostic (OBD) system 100 of the vehicle and may comprise a timestamp of collected data. An OBD system 100 is a vehicle's self-diagnostic and reporting system that provides access to the status of the various vehicle subsystems.
Vehicle OBD systems 100 support a variety of protocols that have been developed by the automotive industry. A protocol converter 102 comprising a first processing unit may accept operating data 207 from a subsystem 100 of the vehicle using one or more of these protocols 101 and convert the signals into a second (e.g. more general purpose) protocol 103 such as RS232 or USB. The protocol converter 102 may, in turn, communicate the converted data to a second processing unit 104 using the second protocol 103. Alternatively, the protocol converter 102 may be eliminated and the second processing unit 104 may accept the operating data 207 from the vehicle OBD system 100 without the intermediate conversion.
The second processing unit 104 may also interact with and accept data from one or more location sensors 105, one or more status sensors 105, one or more driver sensors 105, and one or more environment sensors 105. In addition, the second processing unit 104 may be communicatively coupled with a monitor 105, a printer 105, a CD/DVD unit 105, speakers 105, microphones 105, or another computer peripheral 105. Any data accepted from these other units 105, any data accepted from the vehicle OBD system 100, and any device status comprise the collected data that may be managed, stored, and communicated by the second processing unit 104.
The second processing unit 104 may store the collected data to a data storage unit 109 having a fourth processing unit and third transceiver, wherein the storing uses a third protocol 108 (e.g. a data storage protocol such as SPI, SD bus, CF) or uses the second protocol 103 (e.g. USB).
The second processing unit 104 may also forward the collected data to at least one wireless radio unit 107 having a third processing unit and second transceiver. That at least one wireless radio unit 107 and the stationary transceiver 111 may be part of a cellular radio network (e.g. GSM, HSPA+, CDMA, EVDO, WiMax, LTE), a satellite radio network (e.g. non-terrestrial microwave network), or another electromagnetic network (e.g. Wifi, IEEE 802.11, Bluetooth). The second processing unit 104 may be communicatively coupled with the at least one wireless radio unit 107 via another wireless radio network. Thus the fourth protocol 106 may be a wireless protocol (e.g. Wifi, Bluetooth) or a wired protocol.
The device may collect and communicate driver ID data 201 from the driver sensor 105. The driver ID data 201 may comprise a unique identity of the driver and other supporting driver information (e.g. address, phone number, driver's license info, emergency contact info, blood type, allergies, other health information, insurance info, safety record, photo, physical description, payroll identity). A driver ID sensor may collect driver ID data 201 using a camera (e.g. facial recognition), biometric reader (e.g. finger print recognition), ID card/fob reader (e.g. bar code, magnetic card reader, smart card, Wiegand card, proximity card), unique vehicle ignition key, unique keypad code, or phone ID (e.g. retrieved via NFC, Wifi, or Bluetooth). The supporting information may be collected by the driver ID sensor or may be previously entered and then associated with the unique driver ID following its collection by the driver ID sensor. The device may take action based on the driver ID data 201, including commanding the vehicle OBD to slow, stop, lock, or disable the vehicle when the driver is unknown.
The device may collect and communicate driver status data 202 from the status sensor 105. The driver status data 202 may comprise a heart beat of the driver (e.g. from video using ballistocardiographic micro-movements of the driver's head, from video using photoplethysmographic micro-changes in the driver's face, from ballistocardiographic transducers on the driver's seat, from conventional skin contact EKG, from EKG leads mounted on driver's seat and/or steering wheel), driver body language extracted from video of the driver (e.g. subdued, restless, angry, sleepy, alert), driver eye activity extracted from video of the driver (e.g. blink interval, blink duration, blink frequency, % of time lid is closed, lid closure speed, lid drooping, eye saccade parameters, eye fixation duration), driver head and mouth position (e.g. extracted from video of the driver head drooping, head nodding, yawning), micro-adjustments of steering wheel (e.g. reduced number of micro-adjustments indicates drowsiness, measured from video of driver, measured from wheel angle sensor), driver respiration (e.g. respiratory photoplethysmography, respirometer), blood pressure (e.g. cuff, pulse arrival time), or activity level of the driver (e.g. accelerometer on the driver's seat). The status sensor 105 may comprise one or more cameras, infra-red illuminators, transducers on the driver's seat, transducers on the steering wheel, respirometers, blood pressure cuffs, accelerometers, or similar sensors. The status sensor 105 may comprise one or more microphones, one or more speakers, or an interface to a vehicle integrated communication system for prompting, alerting, and communicating with the driver. The driver status data 202 may be used to monitor the performance of drivers, spot sleepy drivers, identify inattentive or combative drivers, spot risky health issues, spot risky behaviors, recognize when the driver is absent from the vehicle, and spot drivers under the influence of drugs/alcohol. The device may take action based on the driver status data 202, including alerting the driver (e.g. speaker), alerting a fleet manager, alerting another stake-holder, alerting law enforcement, alerting emergency responders, ranking or rating the driver, storing the data for future use, and commanding the vehicle OBD (e.g. to slow, stop, or lock the vehicle).
The device may also collect and communicate location data 204 of the vehicle from the location sensor 105. The location data 204 may comprise a longitude and latitude of the vehicle, a unique location in another map coordinate system, a street address, and a direction of travel. The location sensor 105 may comprise a GPS/GNSS satellite receiver, a compass, an altimeter, radiolocation (e.g. via cellular basestations or other signals), electromagnetic communication (e.g. beacons/receivers near roads and on vehicles). Action may be taken based on the location data 204, including advising the driver of an upcoming turn; advising the driver of traffic, road closures, an Amber alert, or a road hazards; scheduling maintenance and fuel at a location near the vehicle's location or destination; sorting destinations based on traffic, road closures, weather, travel times, or road hazards; and setting destinations based on the vehicle location.
The device may also collect and communicate vehicle environment data 205 from an environment sensor 105. The vehicle environment data 205 is information from the environment of the vehicle and may comprise video of the space around the vehicle (e.g. dashcam, roofcam, bumper-cam, trailer-cam, side-camera, back-camera, forward-camera), radar imaging of the space around the vehicle, lidar imaging of the space around the vehicle, other imaging of the space around the vehicle (e.g. ultrasonic), and moisture sensors (e.g. humistor). An environment sensor 105 may collect environment data 205 using a camera (e.g. photodetector, optics), transducer (e.g. radio antenna, piezoelectric, actuator, microphone, photoelectric, thermoelectric), electronic sensor, or speed sensor. Action may be taken based on the environment data 205, including alerting the driver, alerting a fleet manager, alerting another stake-holder, alerting law enforcement, alerting emergency responders, storing the data for future use, and commanding the vehicle OBD (e.g. to slow or stop the vehicle).
Once the collected data is communicated to the stationary transceiver 111 it may be accepted from the stationary transceiver 111 by an off-vehicle (i.e. remote) processor and stored (e.g. in a database). From the database the collected data may be compared to threshold data to determine when to schedule maintenance procedures and order parts (e.g. replacement parts). A message may be send to order a part or schedule maintenance when the collected data or a function of the collected data is compared with (e.g. traverses) a threshold. Threshold data may be derived in part from historic collected data that was collected at an earlier time using the same method. For example, brake maintenance may be scheduled using on an algorithm that considers miles driven, elevation traversed, driver ID, traffic encountered, and other collected data. In another example, tire maintenance, replacement, or rotation may be scheduled using an algorithm that considers distance driven, turns made, speed profile, the specs of the tires, and other collected data. In these examples, the thresholds for maintenance may be established in part using historic data, statistical analysis, and e.g. machine learning. Driving distance (i.e. driving time) may be computed to select service locations, part locations, fuel locations, and arrival times estimated.
Technicians may be given access to the collected data to diagnose or investigate service issues. Pricing may be accepted from technicians. Technicians may be selected after considering their pricing, travel times to the location of the service and/or part, and travel times to a destination of the vehicle following the service. For example, prior to tire replacement, tread repair, or tire rotation service, bids may be requested from technicians that are on-route and off-route to a destination of the vehicle, and a bid selected that minimizes the total cost of the service, including parts, labor, taxes, downtime, and travel time. A driving time may be computed between the vehicle location and another location (e.g. destination, service, fuel, food, room) and messages sent to negotiate rates, request pricing, advise personnel of estimated arrival times, provide payment, and reroute the vehicle or another asset.
Access to the collected data may be given to a law enforcement entity, a government agency, revenue agency, and a national security organization in order to assist enforcement activity, avoid a cost, and comply with requests. Access to the collected data may also be given to an owner of the vehicle, a manager of the vehicle, a supplier of vehicle maintenance, a supplier of vehicle parts, an operator of the vehicle, another stakeholder, another vendor, and another interested party. For example, a law enforcement entity may access the weight data for a truck to ensure compliance with weight limits, or phone the truck driver by entering the truck license plate.
The remote processor (i.e. remote server) may communicate a command to the stationary transceiver 111, the wireless radio unit 107 may accept the command from the stationary transceiver 111; the command may be communicated from the wireless radio unit 107 to the second processing unit 104; the command may be communicated from the second processing unit 104 to the protocol converter 102; and the command may be communicated from the protocol converter 102 to the subsystem of the vehicle. The command may, for example, direct the OBD system 100 to slow, stop, turn off, or lock the vehicle. The second processing unit 104 may, based on its own processing, communicate with the driver (e.g. via speaker and microphone) or communicate a command to a subsystem of the vehicle (e.g. via the protocol converter 102) to e.g. slow, stop, turn off, or lock the vehicle.
In the embodiment of
In the embodiment of
In the embodiment of
In the embodiment of
In the embodiment of
