Patent Application
20180229744
FIELD
This invention relates to a communication enabled engine monitoring and maintenance dispatch system.
Internal combustion engines typically utilize some type of natural or synthetic oil for lubrication of the engine's internal moving elements. This engine oil, over time, requires periodic maintenance, e.g., it has to be changed. Typically the maintenance interval is measured in hours of operation or in the case of a motor vehicle, on the distance driven. However, other factors such as oil temperature, ambient temperature, engine speed, and the type of oil used will alter the maintenance schedule of an engine.
Further, there are other components of an engine system that also play a crucial part in the smooth operation of an engine based system, such as the battery charging system and air filter components that require periodic maintenance.
Given the foregoing, what is needed is a method and system for monitoring various functions and criteria within a device or vehicle that contains an engine, including internal combustion and electrical, such as oil levels, electrical systems, and environmental conditions. Further, the system needs to communicate, to and from an outside source, information concerning the monitored functions. Such communications provides information for further analysis to a central system and also allows the central system to communicate back to the monitoring system with the ability to dispatch resources as appropriate.
In an embodiment of the present disclosure, an engine platform system that consists of a standard vehicle platform (“SVP”) includes an on-board diagnostic (“OBD”) adapter designed to connect to a vehicle's OBD-II connector, power, sensors and a communications system. The OBD adapter receives information from a vehicle via the OBD-II connector and coupled with information received from sensors, determines a distance traveled by the vehicle. The OBD adapter transmits the vehicle's traveled distance information to a mobile communication device or a cloud-based application, wherein a determination is made whether the vehicle is in need of maintenance. If maintenance is required then that determination is sent to the OBD adapter with the option to automatically dispatch maintenance resources as appropriate.
According to another embodiment, there is provided a method for determining maintenance of a vehicle using a standard vehicle platform. The method includes the connection of an on-board diagnostic (“OBD”) adapter to an OBD-II connector in the vehicle. The OBD adapter generates a request to a computer within the vehicle and receives information related to maintenance of the vehicle via the OBD-II connector and determines an amount of distance traveled by the vehicle. The distance traveled and related maintenance information is sent to a mobile communication device and/or cloud application, wherein a determination is made whether the vehicle is in need of maintenance. The OBD adapter then receives information on regarding the need for maintenance with the option to automatically dispatch maintenance resources as appropriate.
In another embodiment of the present disclosure, an engine platform system that consists of small engine platform (“SEP”) adapter includes a run hour meter designed to connect to a device that includes an engine. The run hour meter includes sensors and a communications system. The run hour meter, using information received from the sensors, determines an amount of time the engine has been running. The run hour meter, using the communication system, transmits the engine's running time information to a mobile communication device or a cloud-based application, wherein a determination is made whether the engine is in need of maintenance. IF maintenance is required, that determination is sent to the run hour meter with the option to automatically dispatch maintenance resources as appropriate.
According to another embodiment, there is provided a method for determining maintenance of an engine using a small engine platform. The method includes the connection of an hour meter to a device with an engine. The hour meter, using its on-board sensors, determines engine maintenance information including an amount of time that the engine has been running. The run time information is sent to a mobile device and/or cloud application, wherein a determination is made whether the engine is in need of maintenance. The run hour meter then receives information on whether the engine is in need of maintenance with the option to automatically dispatch maintenance resources as appropriate.
In an embodiment of the present disclosure, there is an oil use monitoring and maintenance system that includes a vehicle with new oil holding tanks and waste oil storage tanks and an on-board control system. The on-board control system includes a processor with memory, sensors and a communications system. The sensors monitor oil levels in the new and waste tanks and also monitor oil inflow and outflow amounts. The communications system is designed for bi-directional communications with a mobile communication device and/or a cloud computing application and is configured to receive dispatch information and send status information. The system includes a maintenance fluid vacuum system where oil is drained from an engine and collected in a collection container connected to a waste oil tank through a top mounted waste recovery pump.
According to another embodiment, there is provided a method for oil use monitoring. The method includes the receiving of a dispatch request by a control system within an oil use monitoring system to a customer site. The dispatch instruction can be generated by a cloud application based on a maintenance request from a standard vehicle platform or a small engine platform system. The location of the desired SVP or SEP system is determined and the oil use monitoring and maintenance system travels to the appropriate location. Optionally, the location of the SVP or SEP can be included within the dispatch instruction. Maintenance is then performed on the SVP or SEP system where the oil use monitoring and maintenance system monitors inflow and outflow of oil from self-contained new and waste oil tanks. The method includes the transmission of status and oil use information to a mobile communication device and/or cloud.
Further features and advantages of the present disclosure, as well as the structure and operation of various embodiments of the present disclosure, are described in detail below with reference to the accompanying drawings. It is noted that the present invention is not limited to the specific embodiments described herein. Such embodiments are presented herein for illustrative purposes only. Additional embodiments will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein.
The accompanying drawings, which are incorporated herein and form part of the specification, illustrate the present invention and, together with the description, further serve to explain the principles of the present invention and to enable a person skilled in the relevant art(s) to make and use the present invention.
Additionally, the left-most digit of a reference number identifies the drawing in which the reference number first appears (e.g., a reference number ‘310’ indicates that the element so numbered is first labeled or first appears in
Further embodiments, features, and advantages of the present invention, as well as the operation of the various embodiments of the present invention, are described below with reference to the accompanying figures.
While embodiments described herein are illustrative embodiments for particular applications, it should be understood that the invention is not limited thereto. Those skilled in the art with access to the teachings provided herein will recognize additional modifications, applications, and embodiments within the scope thereof and additional fields in which the invention would be of significant utility.
The embodiments described herein are referred in the specification as “one embodiment,” “an embodiment,” “an example embodiment,” etc. These references indicate that the embodiment(s) described can include a particular feature, structure, or characteristic, but every embodiment does not necessarily include every described feature, structure, or characteristic. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is understood that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
The engine monitoring and maintenance system includes a multiple of peer components that are designed to work in concert with each other as part of service jobs. In some embodiments the individual components are self-sufficient, in other embodiments multiple components work in combination. Embodiments are generally directed to two engine platform systems, the standard vehicle platform (“SVP”) and the small engine platform (“SEP”). However, an engine or vehicle is not to be limited, but can apply to any type of mechanical contrivance including those vehicles or devices powered by electricity, gasoline, propone, or any other type fuel.
The SVP includes an On-board diagnostics-II (“OBD-II”) port and a communications element. The OBD-II connection allows the SVP to communicate with a vehicle's self-diagnostic and reporting system. Typical OBD-II implementations provide real-time data on the operating environment within a vehicle in addition of a standardized series of diagnostic trouble codes that identify malfunctions within the vehicle. The OBD-II standard specifies the type of diagnostic connector and pinout functions in the connector. Typically vehicles equipped with an OBD-II connector have the connector located within two feet of the steering wheel. Instead of the OBD-II standard, some embodiments utilize the European On-Board Diagnostic (“EOBD”) standard, which is the European equivalent of the OBD-II standard, or the “JOBD” for vehicles sold in Japan, or the ADR 79/01 and 79/02 for those vehicles using the Australian standard.
In addition to having the SVP communicate with a vehicle using the OBD-II communications link, the SVP can also communicate with a central system using an on-board communications system such as Bluetooth low energy (Bluetooth LE, BLE or Bluetooth Smart), WiFi, cellular, or any other type of wireless communication. The SVP can also communicate with a mobile communication device and corresponding mobile application, a central system via the Internet or using cloud computing. The SVP may also communicate with a mobile service vehicle through the use of a vehicle-mounted control box that will be discussed later in further detail.
The SEP components include an hour-meter with a communications element that can be used to communicate as described with the SVP using Bluetooth low energy (Bluetooth LE, BLE or Bluetooth Smart), WiFi, cellular, or any other type of wireless communication. As with the SVP, the SEP can also communicate with a mobile communication device and corresponding mobile application, a central system via the Internet or using cloud computing.
SVP System
OBD-II adapter 120 can communicate its captured information to cloud 160 in real time for further analysis via multiple pathways. In one embodiment, OBD-II adapter 120 communicates with mobile communication device 130 via Bluetooth pathway 125. Mobile communication device 130 contains an SVP application, either iOS or Android based or any other mobile communication device operating platform, which serves as a user's interface to SVP system 100. The application allows a user to view the information gathered by OBD-II adapter 120 and also allows the user to access a SVP cloud based application to perform various functions such as monitoring and maintenance functions associated with vehicle 110. Such access to cloud 160 would be via cellular pathway 145 and cellular tower 150.
In an embodiment, access to cloud 160 can also be accomplished directly from OBD-II adapter 120 to cloud 160 through cellular connection pathway 135, or through WiFi hotspot 140 using pathways 155 and 157.
SVP system 100 also illustrates communications originating from cloud 160 to OBD-II adapter 120. Such two way communications allows for commands and instructions to be received by OBD-II adapter 120 from cloud 160, such as updating maintenance information data or commands to OBD-II adapter 120. Such communications can also be directed from cloud computing on cloud 160 to mobile communication device 130 running the SVP application, either directly via pathway 145 or routed through OBD-II adapter 120 using pathways 135 and 125.
Air flow sensor 122 monitors the flow of air into the cabin of vehicle 110. Air flow sensor 122 is shown located in the driver's side air vent, but could be located anywhere within the environmental control system of a vehicle. Air flow sensor 122 communicates with OBD-II adapter 120 to pass on its sensor readings pertaining to air flow. Air flow sensor 122, in an embodiment, can also communicate with mobile communication device 130 using Bluetooth pathway 127.
Air flow sensor 122 can be used to detect harmful particulates, including combustible particulates, e.g., from cigarette or cigar smoke. The use of air flow sensor 122 could therefore be used by a fleet management company to monitor compliance with a “no smoking” in the vehicle rule. Or, similarly a car rental company could use the information detected by air flow sensor 122 to levy a “cleaning” fee for smoking in a no-smoking allowed vehicle. Air flow sensor can consists of any of a number of sensor types including but not limited to infra-red (IR), metal oxide gas, or a gas particulate sensor or the like. In an embodiment air flow sensor 122 is placed in the path of an air vent. In another embodiment air flow sensor 122 includes a self-contained fan to draw cabin air into the sensor for analysis. Air flow sensor 122 can exist as a standalone device containing communication capabilities to accept commands and send information. Or, air flow sensor 122 could be incorporated into an OBD-II style module or configured as a Bluetooth accessory to a smart phone. A detection algorithm is used to determine a base line dust and sensor noise level, e.g., threshold, such that an accurate level of particulate detection is achieved. In other words, the “base line” is not necessarily zero as some amount of dust and/or particulates exist in a vehicle, especially based on where air flow sensor 122 is place, e.g., under the dashboard.
OBD-II adapter 220 can also be configured to include one or more multicolor red-green-blue (RGB) light-emitting-diodes (LEDs), in an embodiment (not shown in
OBD-II adapter 220 receives data and power from monitor vehicle 210's OBD-II connector. However, OBD-II adapter 220 could include an auxiliary power source (not shown) so as to not be dependent on monitor vehicle 210's power. Such a power source could include replaceable or rechargeable batteries. OBD-II adapter 220 contains memory 280 that has operating system memory 282 and instructions memory 284. Memory 280 is configured to preserve information for at least 10 different vehicles. OBD-II adapter 220 is able to calculate real-time odometer values, and has the ability to receive new functionality to be stored in instructions memory 284 in the form of firmware updates.
OBD-II adapter 220 receives data via OBD-II connector 274 from vehicle 210 based on the OBD-II publicized standard. However, this standard fails to define an exact odometer reading, e.g., 101,200 miles. To compensate for this lack of actual odometer information, OBD-II adapter 220 receives the “distance (km) traveled since codes cleared” OBD-II PID code, which is a 2 byte read at 0x31 hex, which when added to a baseline value entered by a user or technician, which yields an actual odometer reading. Once OBD-II adapter 220 determines the actual reading that information can be transmitted to cloud 260 and/or mobile communication device 230. Further, cloud 260 and/or mobile communication device 230 can store any baseline value and have knowledge of the distance traveled since codes cleared and determine the actual odometer value.
SVP system 200 is also configured to provide predictive maintenance with respect to machine learning for vehicle service and failure prevention, according to an embodiment. Using OBD-II adapter 220 to actively monitor sensors and non-critical failure notifications from the SVP data bus, SVP system 200 can analyze and predict and anticipate future failures. Thus, preventative maintenance can be performed before an actual failure occurs.
An example predictive maintenance factor is an engine low temperature condition. Typically, such a condition will not cause the “check engine” light to illuminate. However, low engine temperature can impact the engine's efficiency and ability to run the vehicle's cabin heater. A low temperature engine condition can be detected through a P0128 thermostat OBD-II trouble code indicating that the engine's powertrain control module has detected that the engine has not reached the required temperature level within a specified amount of time after starting.
Another example factor is low oil pressure. Low oil pressure can be a sign of contaminated oil and can be detected by reading a P0522 OBD-II diagnostic trouble code when the powertrain control module senses too low of a value in the engine oil pressure sender/sensor.
Another example factor is detection of a low transmission fluid level where early detection can prevent major repairs. A low transmission fluid level condition can be detected through a P070C transmission fluid level sensor circuit low OBD-II trouble code indicating that the transmission fluid is below a threshold level.
Other possible example factors include early detection of a tire leak. Tire air pressure can be monitored over time. By tracking pressure over time, rather than just a limit trigger, a steady decrease in pressure can be indicative of a tire leak. Oil change frequency can be predicted based on driving conditions and driving behavior, rather than just the number of driven miles. And, engine efficiency can be tracked based on monitoring engine air filters, oxygen sensor, and other vehicle sensors.
Predictive analysis includes aggregates data from multiple sources and can include what is known from the vehicle's OBD-II data bus and what is known from separate vehicle sensor. This data can then be compared to known data from larger vehicle fleet failure instances. In addition to the above mentioned OBD-II codes, further diagnostic determinations can be made based on vendor specific OBD-II data bus values and enhanced with other sensor historical data and machine learning data.
As an example, an in-line sensor could be inserted in the power line from a vehicle's battery. The in-line sensor can monitor voltage and current levels during start-up of the vehicle. The levels and timing of the starting voltage and current can be compared with known data of a properly functioning and failing starting system to determine if the battery is beginning to fail. ODB-II adapter 220 could also be used to provide remote access relating to control of windows, lights, horn and other related functionality, via the SVP data bus. Likewise, ODB-II adapter 220 could provide last known vehicle location with respect to GPS data coordinates.
Further, the OBD-II standards currently reset the distance traveled code after 65,535 km to zero or by a two byte 0xFFFF hex value. In addition, the reading can be manually cleared. To compensate for this limitation in the OBD-II standards, OBD-II adapter 220 performs the following:
Once the distance traveled by the vehicle is determined, that information can be sent to mobile communication device 130 or directly to cloud 160. In either case the distance traveled is compared to predetermined information pertaining to the year, make and model of vehicle 110 to determine if maintenance is required. If maintenance is required then an indication can be sent back to OBD-II adapter 120 and/or mobile communication device 130 for further action.
In an embodiment, the further action can include the dispatching of maintenance resources, e.g., a vehicle equipped with the appropriate tools and supplies to service the vehicle. The system can also automatically generate possible service appointment times that would be presented to a user for selection, or it can simply schedule a time to perform the work without the user's input. This “managed” approach to vehicle maintenance is pro-active and self-aware, eliminating the need for the user of the vehicle to constantly monitor the vehicle and make arbitrary maintenance decisions.
Knowing this information, OBD-II adapter 220 can produce a picture of what a good healthy battery/charging system start waveform should look like and determines the proper start voltage, voltage drop depth, voltage recovery, alternator kick-on, etc. OBD-II adapter 220 can also determine if waveforms captured in
OBD-II adapter 220 analyzes the voltage level of vehicle 210 at three specific points. The first is shown at prior to point 320 as a battery open-circuit, e.g., when the vehicle is off The next is the period between points 320 and 330 when the engine is started where the battery cranking voltage drops, prior to the alternator starting. And, then at point 340 and beyond, when the alternator engages and the electrical system starts charging. Such data can then be analyzed by OBD-II adapter 220 by comparing the analysis points to predetermined thresholds in memory 280 to determine if a “fail” trigger should be generated. In the alternative, the data can also be sent to mobile communication device 230 and/or cloud 260 for an application in either mobile communication device 230 or cloud 260 to determine if a “fail” trigger is to be generated. In an embodiment, cloud 260 or mobile communication device 230 makes the “failed” determination and communicates the results back to OBD-II adapter 220.
In addition to odometer and battery/charging system analysis, OBD-II adapter 220 can monitor vehicle 210's air filters, e.g., engine and cabin, and notify when service is required. The quality of the cabin air filter would be accomplished by a battery operated wireless sensor mounted to an air duct in the vehicle that sends data to either OBD-II adapter 220 or to mobile communication device 230 via wireless communications such as Bluetooth (BLE). As it is known when the air filters are installed, a baseline air flow performance is captured and stored in memory 280. Then, through OBD-II connector 274 to vehicle 210, the degradation of the air flow performance of the system over time as compared to the baseline is captured. For the case of the engine air filter, this is accomplished by monitoring the PID values (0x50, 0x66, etc.) and with possible input regarding driving behavior and location/terrain, altitude, etc. For the case of the cabin air filter, the information is sent to OBD-II adapter 220 from the battery operated wireless sensor. When the air flow performance decreases below a predetermined threshold a “failed” air performance determination is generated. Such a determination can be sent to mobile communication device 230 and/or cloud 260. Subsequently, cloud 260 can generate a response and instructions to be sent back to OBD-II adapter 220.
SEP System
Cloud computing 660 can be configured to provide scalable, reliable services and data analysis tools to power applications and devices for SEP system 600. The primary goals of cloud computing 660 include the following:
Cloud computing 660 can also be configured to provide monitoring services to handle data events transmitted from the devices such as mower 672, a weed-eater 674 and an ATV 676. The services are exposed via an API Gateway and then delegated to specific container-based services. The services will use specific analysis functions to evaluate the stream of data and emit events based on decision processing, e.g. what is the trending air quality of air flow sensor 122 or the length of time on run hour meter 622.
Cloud computing 660 utilizes application services to provide authentication, data storage, configuration, analytics and web hosting. Application services are applicable for both technician and consumer applications and include features such as:
Further, the application services and monitoring services of cloud computing 660 interact such that a mobile application running on mobile communication device 630 will expose data and events so the monitoring services can consume them and process accordingly.
Cloud computing 660 is also applicable for fleets of vehicles and includes fleet centric component. Thus, cloud computing 660 includes extensions that allow larger groups of vehicles to be managed and tracked accordingly. These extensions include standalone modules to allow a fleet to:
Run hour meter 622 has the ability to communicate with mobile communication device 630 through a Bluetooth pathway 625 and then from mobile communication device 630 through pathway 645 to cloud 660 (using a cellular communication tower, not shown). Run hour meter 622 could also connect directly to cloud 660 through pathway 635, or via WiFi hotspot 640 through pathway 655. All communication pathways are bi-directional allowing information to flow from run hour meter 622 to mobile communication device 630 and to cloud 660, as well as from cloud 660 back to run hour meter 622. All discussion relating to run hour meter 622 is also completely applicable to the hour meter embodiments shown in 672, 674 and 676. Run hour meter 622 also contains a power source (not shown).
A more detail view of run hour meter 622 is shown in
Run hour meter 720 includes a processor 770, a display screen 775, a generator 777, memory 780, a communication system 790 and sensors 795. Sensors 795 are designed to detect vibration and hence determine the time that SEP system 700 has been running. In addition to detecting vibration, sensors 795 can detect ambient temperature and the actual revolutions per minute of SEP system 700.
In an embodiment, sensors 795 in run hour meter 720 include a vibration sensor 797. The vibration sensor is configured to detect both engine activity as well as user generated control via a series of “taps.” With the engine in a stopped state, the vibration detection sensor can detect a “tap” where run hour meter 720 can be controlled by recognizing one or more taps. The number of taps correlates to a desired function. For example, the detection of 3 taps while the engine is in a non-active state would start the engine. Conversely, for example, 3 taps would instruct the engine to stop if the engine is active. Sensor 795 is configured to discern a difference between a “tap” and the normal vibrations associated with the engine running. Once the engine is running, subsequent taps can also be configured for other functions. For example, a single tap could cause a display panel to cycle through its settings such as the current run time, total run time, status, etc. The use of vibration sensor 797 also eliminates the need for a physical button for such control.
Display 775 is used to communicate information to a user, such as the length of time SEP system 700 has been running, the ambient temperature, the average or maximum revolutions per minute (RPM) of SEP system 700, and the percentage of oil life remaining. Such information can also be sent to cloud 760 or mobile communication device 730 for further analysis. The percentage of oil life remaining can be calculated as the time from the last oil change as compared to the recommended oil change hour interval from the manufacturer. Such information can be obtained by run hour meter 720 through its communication system 790 to mobile communication device 730, or to cloud 760. A more accurate calculation of remaining oil life can be determined taking into account ambient temperature and average RPM. Basing oil changes on just run hours does not take include factors such as the stress level of the engine, e.g., run hours during idling versus those running at high RPM and heavy loads are vastly different, and those hours occurring during high ambient temperatures are also more stressful on the engine, and therefore require a more frequent oil change maintenance schedule. Such determinations can be made by mobile communication device 730 or cloud 760 and then communicated back to run hour meter 720, with the ability to display such information on display 775.
Run hour meter 720 can also include other features such as:
Further, processor 770 executes algorithms stored in memory 780 through instructions 784, under the control of operating system 782. In an embodiment, a detection algorithm is executed that distinguishes, through the use of sensors 795, the difference between real engine/motor vibrations as compared to other movements such as walking with the SEP or having the SEP riding in a truck, with its own engine off. Such an algorithm would also contain a “learn” mode where with run hour meter 720 installed on a device, such as mower 672, in learn mode through sensors 795 and display 775 would instruct the user to take the engine in the SEP from an “off” vibration baseline to an engine/motor “on” snapshot when the motor is running. Such sensor input would then be programmed into an updated algorithm, either directly into instructions 784, or through unlinking to mobile communication device 730 or cloud 760 and downloading the updated algorithm from the same.
Run hour meter 720, in an embodiment, contains generator 777 that is used to charge a power source (not shown) that powers the components within run hour meter 720. Generator 777 can be a piezoelectric electric generator that will charge the internal power source when being vibrated. Processor 770, with instructions 784 can also be configured to execute a battery management program that minimized power draw. The power source in run hour meter 720 may also be serviceable and could be replaced by a user and/or service personnel. Further, the run hour meter 720 housing is intended to be waterproof, uV resistant, and specifically designed so that it can be mounted rigidly to the monitored device and the case is designed in such a way that the vibration is appropriately “transferred and seen” by the vibration sensor(s) within run hour meter 720. Further, the electric generator can either charge the power source and/or power the electronics directly or any combination thereof.
Oil Use Monitoring and Maintenance
Oil Use Monitoring and Maintenance (OUMM) system 900 uses vehicle 905 equipped with a fully contained maintenance fluid vacuum system 910 that includes oil storage tanks, waste oil containers, and control system 920 with multiple sensors and pumps to allow for the monitoring and transfer of fresh and waste oil and their corresponding levels. OUMM system 900 is designed to arrive at a delivery point, e.g., a customer site, as a result of a notification originated by SVP system 100 for a vehicle/engine oil change, or by SEP system 600 for maintenance of a fleet of mowers 672. Such notification by SVP system 100 or SEP system 600 could be automatic, without the need for technician intervention.
Control system 920 is designed to have knowledge of all of the oil inflow and outflow amounts. Further, control system 920 can relay the pertinent information to cloud 960 on an as necessary basis, including real time. Control system 920 also contains power source 924 as an energy store for supplemental surge energy such as for pumps and sensors. Power source 924 ensures that vehicle 905 does not need to be run constantly when at a service site and saves money with fuel cost, etc. accordingly.
Mobile OUMM system 900′, in an embodiment, can be used to perform a mobile oil change on an engine. Currently, mobile oil changes are typically performed using a method commonly referred to as the ‘gravity method.’ This method involves a person placing a standalone drain pan under the engine sump, pulling the sump plug, and allowing the waste oil to drain into the drain pan. The person then has to carefully remove the drain pan, now filled with 4-12 quarts of hot waste oil, by hand, to a larger receptacle, such as a bucket, or by putting a cap on the drain pan itself, which is also now covered in hot oil. The outside surface of this drain pan must be thoroughly cleaned, and the cleaning rags properly disposed of as they are now contaminated. The waste oil is then transported in either the capped off waste receptacle or the sealed drain pan, to a proper facility. Waste oil is a toxic substance to both the environment and the handler. The container could drop and spill, contaminating the environment and injuring or burning the handler.
Another method for changing vehicle oil is a “manual vacuum method,” which usually involves either snaking a tube down the dipstick hole, creating a vacuum with a hand pump, and then drawing out the waste oil into a container. Only vehicles specifically designed for this method should use this method, as particles at the bottom of the sump, could damage the engine as they are drawn up into the suction tube. This method involves a human handling the pressurized container during and after the oil changing process. Further, the container could drop and spill, contaminating the environment and injuring or burning the handler. Another version of the vacuum method involves a tow behind oil vacuum system that replaces the handheld pump; this pump can be connected to a drain pan placed under the vehicle. This method is commonly used in the military, industrial and agricultural fields. It carries its own risks to the environment because it is exposed to the elements, and leaking can occur at the connection points of the drain pan and the hose connecting the drain pan to the system.
In contrast mobile OUMM system 900′ utilizes a fully contained maintenance fluid vacuum system that includes control system 920, power source 924, waste oil tank 960, waste recovery pump 970, waste recovery line 972, maintenance fluid delivery storage tank 980, delivery nozzle 982 and collection container 990, in an embodiment. These components reside in or on service vehicle 905 that is designed to automate the service delivery for consumer and fleet vehicles, which can be performed in an on-demand fashion, triggered by a mobile application as previously discussed. Mobile OUMM system 900′ can utilize rectangular storage tanks, e.g., maintenance fluid delivery storage tank 980 or waste oil tank 960, to make the most efficient use of space within the service vehicle. The system also uses top-mounted pumps, e.g., waste recovery pump 970, so in the event of a leak at the location of the pump, the contents of the tank will not expel. OUMM system 900′ can use dry-brake technology to create leakproof connections from waste recovery pump 970 to a wheeled collection container 990 that can be slid under a vehicle and act as a repository for the waste oil and drain location for the used oil filter. When the job is done, the vacuum is engaged through the use of waste recovery pump 970 and waste recovery line 972 which draws the waste oil from collection container 990 directly into onboard waste oil tank 960 on vehicle 905.
In an embodiment, mobile OUMM system 900′ can dispense fresh oil via onboard dispensing reels and delivery nozzle 982 to receive fresh oil in bulk from shop-based bulk oil tanks, further reducing the need for a human to handle oil in a container, potentially dropping it or contaminating or harming himself
Information from control system 920 can be relayed through mobile communication device 930 to technician 915, or to cloud 960 for further analysis. After analyzing, either the cloud or technician 915 can respond with commands or instructions for control system 920. Information from sensors 928 and feedback from cloud 960 may include of the following:
OUMM system 900 could further include a global positioning system (GPS) that would enable the tracking of the vehicle 905 via cloud 960. Further, a “spill alert” alarm system could be integrated such as if a full tank spills over or any sudden unexpected change in storage level would alert a technician or cloud 960 in real-time of a potential spill issue, thus averting expensive clean-up expenses and possible fines.
Methods
Maintenance information can also include electrical system analysis as illustrated in
Method 1000 continues to step 1015 in determining the distance traveled by the vehicle. This is accomplished, as described in
Method 1000 continues to step 1025 that includes determining, by the mobile communication device and/or a cloud based application if the vehicle is in need of maintenance. For example, in
In step 1115 the running time information and related maintenance information are sent to a mobile communication device and/or cloud application for further analysis. For example, SEP system 700 includes run hour meter 720 that can communicate with mobile communication device 730 through pathway 725 and then through pathway 745 to cellular tower 750 and then through pathway 752 to cloud 760. Run hour meter 720 can also communicate directly with cloud 760 through pathway 735 to cellular tower 750 and then through pathway 752. In step 1120, the mobile communication device or cloud application determines if the engine is in need of maintenance based on the information sent in step 1115. For example, display 775 is used to communicate information to a user, such as the length of time SEP system 700 has been running, the ambient temperature, the average or maximum revolutions per minute (RPM) of SEP system 700, and the percentage of oil life remaining (such information can also be sent to cloud 760 or mobile communication device 730 for further analysis). The percentage of oil life remaining can be calculated as the time from the last oil change as compared to the recommended oil change hour interval from the manufacturer. Such information can be obtained by run hour meter 720 through its communication system 790 to mobile communication device 730, or to cloud 760. A more accurate calculation of remaining oil life can be determined factoring in ambient temperature and average RPM. Basing oil changes on just run hours does not take into account the stress level of the engine, e.g., run hours during idling versus those running at high RPM and heavy loads are vastly different, and those hours occurring during high ambient temperatures are also more stressful on the engine, and therefore requiring a more frequent oil change maintenance schedule.
At step 1125 the hour meter receives communications from the mobile communication device or cloud application on the need for engine maintenance. For example, in
Method 1200 continues to step 1210, where the dispatch request is a result of a maintenance request based on a SVP or SEP system. The request for maintenance could also include GPS coordinates or an address where the system is located. In step 1215 the location of the SVP or SEP is determined. Such a determination would be the result of information received whether from the SVP or SEP directly, or from another source such as mobile communication device 930 or cloud 950 as described in
Method 1200 continues with step 1230 that includes transmitting a service status and oil use information to a mobile communication device and/or cloud application. For example, information from control system 920 can be relayed through mobile communication device 930 to technician 915, or to cloud 960 for further analysis. After analyzing, either the cloud or technician 915 can respond with commands or instructions for control system 920. Information from sensors 928 and feedback from cloud 960. Method 1200 then ends.
Example Computer System Implementation
Aspects of the present invention shown in
If programmable logic is used, such logic may execute on a commercially available processing platform or a special purpose device. One of ordinary skill in the art may appreciate that embodiments of the disclosed subject matter can be practiced with various computer system configurations, including multi-core multiprocessor systems, minicomputers, and mainframe computers, computer linked or clustered with distributed functions, as well as pervasive or miniature computers that may be embedded into virtually any device.
For instance, at least one processor device and a memory may be used to implement the above described embodiments. A processor device may be a single processor, a plurality of processors, or combinations thereof. Processor devices may have one or more processor “cores.”
Various embodiments of the invention are described in terms of this example computer system 1300. After reading this description, it will become apparent to a person skilled in the relevant art how to implement the invention using other computer systems and/or computer architectures. Although operations may be described as a sequential process, some of the operations may in fact be performed in parallel, concurrently, and/or in a distributed environment, and with program code stored locally or remotely for access by single or multi-processor machines. In addition, in some embodiments the order of operations may be rearranged without departing from the spirit of the disclosed subject matter.
Processor device 1304 may be a special purpose or a general purpose processor device. As will be appreciated by persons skilled in the relevant art, processor device 1304 may also be a single processor in a multi-core/multiprocessor system, such system operating alone, or in a cluster of computing devices operating in a cluster or server farm. Processor device 1304 is connected to a communication infrastructure 1306, for example, a bus, message queue, network, or multi-core message-passing scheme.
Computer system 1300 also includes a main memory 1308, for example, random access memory (RAM), and may also include a secondary memory 1310. Secondary memory 1310 may include, for example, a hard disk drive 1312, removable storage drive 1314. Removable storage drive 1314 may include a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, or the like. The removable storage drive 1314 reads from and/or writes to a removable storage unit 1318 in a well-known manner. Removable storage unit 1318 may include a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive 1314. As will be appreciated by persons skilled in the relevant art, removable storage unit 1318 includes a computer usable storage medium having stored therein computer software and/or data.
Computer system 1300 (optionally) includes a display interface 1332 (which can include input and output devices such as keyboards, mice, etc.) that forwards graphics, text, and other data from communication infrastructure 1306 (or from a frame buffer not shown) for display on display unit 1330. Computer system 1300 is not limited to a particular design and can be a microcontroller, microprocessor, System on integrated circuit (SOIC), application specific integrated circuit, any combination thereof.
In alternative implementations, secondary memory 1310 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 1300. Such means may include, for example, a removable storage unit 1322 and an interface 1320. Examples of such means may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units 1322 and interfaces 1320 which allow software and data to be transferred from the removable storage unit 1322 to computer system 1300.
Computer system 1300 may also include a communication interface 1324. Communication interface 1324 allows software and data to be transferred between computer system 1300 and external devices. Communication interface 1324 may include a modem, a network interface (such as an Ethernet card), a communication port, a PCMCIA slot and card, wireless communications including WiFi and cellular, or the like. Software and data transferred via communication interface 1324 may be in the form of signals, which may be electronic, electromagnetic, optical, or other signals capable of being received by communication interface 1324. These signals may be provided to communication interface 1324 via a communication path 1326. Communication path 1326 carries signals and may be implemented using wire or cable, fiber optics, a phone line, a cellular link, a WiFi link, or any other RF link or other communication channels.
In this document, the terms “computer program medium” and “computer usable medium” are used to generally refer to media such as removable storage unit 1318, removable storage unit 1322, and a hard disk installed in hard disk drive 1312. Computer program medium and computer usable medium may also refer to memories, such as main memory 1308 and secondary memory 1310, which may be memory semiconductors (e.g. DRAMs, etc.).
Computer programs (also called computer control logic) are stored in main memory 1308 and/or secondary memory 1310. Computer programs may also be received via communication interface 1324. Such computer programs, when executed, enable computer system 1300 to implement the present invention as discussed herein. In particular, the computer programs, when executed, enable processor device 1304 to implement the processes of the present invention, such as the stages in the methods illustrated by flowchart 1000, 1100 and 1200 of
Embodiments of the invention also may be directed to computer program products comprising software stored on any computer useable medium. Such software, when executed in one or more data processing device, causes a data processing device(s) to operate as described herein. Embodiments of the invention employ any computer useable or readable medium. Examples of computer useable mediums include, but are not limited to, primary storage devices (e.g., any type of random access memory), secondary storage devices (e.g., hard drives, floppy disks, CD ROMS, ZIP disks, tapes, magnetic storage devices, and optical storage devices, MEMS, nanotechnological storage device, etc.).
Conclusion
The summary and abstract sections may set forth one or more but not all exemplary embodiments of the present invention as contemplated by the inventor(s), and thus, are not intended to limit the present invention and the appended claims in any way.
Embodiments of the present invention have been described above with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed.
The foregoing description of the specific embodiments will so fully reveal the general nature of the invention that others can, by applying knowledge within the skill of the art, readily modify and/or adapt for various applications such specific embodiments, without undue experimentation, without departing from the general concept of the present invention. Therefore, such adaptations and modifications are intended to be within the meaning and range of equivalents of the disclosed embodiments, based on the teaching and guidance presented herein. It is to be understood that the phraseology or terminology herein is for the purpose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled artisan in light of the teachings and guidance.
The breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments.
Exemplary embodiments of the present invention have been presented. The invention is not limited to these examples. These examples are presented herein for purposes of illustration, and not limitation. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the invention.
This application is a non-provisional application that claims the benefit of U.S. provisional Application No. 62/457,362, filed on Feb. 10, 2017, the contents of which are herein incorporated by reference in their entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62457362 | Feb 2017 | US |
