Patent Description:
Physical objects and/or devices are increasingly provided with the capability to be networked together. Often referred to as the "Internet of Things", the ability for objects and/or devices to be uniquely identified and integrated into a communication network allows for additional functionality to be provided. Typically, such networked devices/objects are referred to as "smart" devices/objects.

For example, everyday objects/devices may include a module which monitors the performance/operation of the device and a module which communicates information regarding the performance/operation of the device over a network (i.e. the internet) to a remote device/object. Alternatively, a network connection between device/objects may be used to remotely send instructions and/or control signals to an interconnected device/object.

Typically, a smart device/object communicates with a remote device/object over a network. For example, a remote device to which a "smart" devices/object may connect to may be a server, a smart phone app or another "smart" device. Further, the network connection between the devices may be provided by, for example, an internet connection, a wireless internet connection (Wi-Fi), a Bluetooth connection, a mobile internet connection or a combination of the above.

Often, incorporating "smart" functionality into devices/objects requires special design considerations. The module for performing the monitoring and communication may require a power source and/or a means of communicating over a network. Accordingly, devices/objects are often specially designed to incorporate smart features. As such, incorporating smart features into existing devices is often challenging.

In particular, "smart" functionality is increasingly being incorporated into machines that use engines in order to provide improved monitoring thereof.

One known type of device for monitoring such a machine is an engine data logger. Engine data loggers may be used to monitor various engine parameters over time, such as engine speed. Monitoring engine speed over time may help with analysis of various aspects of the engine and its use, for example how a machine operator is typically using the machine's engine, what likely engine wear may be, etc..

Existing engine data loggers tend to be large and costly, either requiring an interface to a Control Area Network (CAN) bus in order to obtain a reading of the current engine speed from an Engine Control Unit (ECU), or requiring additional measurement equipment (such as mechanical, magnetic or laser tachometers, or fuel measurement equipment). Establishing an interface to the CAN bus may be difficult and time consuming, and providing additional measurement equipment may be costly and inconvenient.

Some existing engine data loggers may be configured to establish an internet connection with a server, where engine speed measurements may be stored over time and/or analysed. Establishing such connections can be costly, inconvenient and potentially unreliable, for example when the machine is located at the geographical limits of an internet network (for example, at the geographical limits of a Radio Access Network (RAN) cell, or at the geographical limits of a Wi-Fi network area, etc).

Furthermore, it may also be desirable to obtain data in relation to a legacy machine that does not have appropriate inbuilt sensing and/or communications functionality. Accordingly, it may be desirable to attach such sensing functionality to an engine retrospectively. There may be a desire to achieve the functionality with maximum ease and minimum downtime.

<CIT> discloses a method and system for diagnosing an engine including a crankcase.

<CIT> discloses an engine diagnostic apparatus including a first transducer positioned in the oil filler neck of the engine for translating the crankcase pressure waveform into a corresponding electrical waveform having a frequency component proportional to engine speed.

<CIT> discloses a system that includes a pipe and a device for measuring and storing vibration data related to the use of the pipe and its remaining lifespan. The data can be collected wirelessly using a radio frequency device.

A first aspect of the present disclosure provides a method of monitoring the usage of an internal combustion engine. The method comprises performing an engine monitoring routine using a local monitoring device directly attached to an internal combustion engine. The engine monitoring routine includes generating a plurality of data points representative of the crankcase pressure of the internal combustion engine using a pressure sensor of the local monitoring device, processing the generated data points to determine a first value representative of a firing frequency of the internal combustion engine, generating an aggregated summary of the internal combustion engine usage based on the first value, and transmitting identification data for the local monitoring device and the aggregated summary from the local monitoring device to a remote application. The remote application processes the transmitted aggregated summary based on the transmitted identification data to determine engine speed usage data for the internal combustion engine.

Advantageously, by performing the processing of the aggregated summary using a remote application, the local monitoring device is not required to store engine characterising data relating to the internal combustion engine in order to perform the processing on board the local monitoring device. For example, the local monitoring device does not need to store engine characterising data such as the number of cylinders in the internal combustion engine. Rather, this engine characterising data can be stored in the remote application where it is associated with the identification data of the monitoring device. Thus, according to the method of this disclosure the local monitoring device does not require initialisation in order to begin monitoring the usage of an internal combustion engine. Accordingly, local monitoring devices for performing the engine monitoring routine of this disclosure may be quickly and easily installed on an internal combustion engine.

Furthermore, the local monitoring device is directly attached to the internal combustion engine and therefore directly senses the pressure variation in the crankcase of the internal combustion engine. Accordingly, the method of monitoring according to the present invention provides a highly accurate stream of data for monitoring the usage of the internal combustion engine.

Preferably, the generated data points are also processed to determine a second value representative of an average of the crankcase pressure of the internal combustion engine. Preferably, the aggregated summary is generated based on the first value and the second value. Accordingly, the aggregated summary contains information regarding two parameters of the internal combustion engine. Thus this disclosure provides a method of monitoring two internal combustion engine parameters with a single pressure sensor of a local monitoring device directly attached to an internal combustion engine.

Preferably, the remote application processes the transmitted aggregated summary containing engine crankcase pressure data and engine firing frequency data to determine engine torque output usage data for the internal combustion engine based on the transmitted identification data.

Preferably, the aggregated summary is a generated by updating an element of the aggregated summary based on the first value and optionally the second value. Accordingly, the first aspect provides a method of accumulating usage data about an internal combustion engine in a data efficient manner. The size of the aggregated summary does not increase in size with the monitoring period. Accordingly, the method of monitoring using the local monitoring device may have low power consumption and data processing requirements.

Preferably, transmitting the aggregated summary from the local monitoring device to the remote application includes transmitting the aggregated summary from the local monitoring device to a remote device over a wireless network. Accordingly, the local monitoring device may include means for transmitting the monitored data to the remote application without requiring any wired connections or other communication equipment to be connected to the internal combustion engine. As such, the method of monitoring may be easily retrofitted to legacy engines.

According to a second aspect of this disclosure a computer program comprising instructions to cause a local monitoring device and a remote device running a remote application to execute the steps of the method of the first aspect is provided.

According to a third aspect of this disclosure computer-readable media having stored thereon the computer program according to the second aspect is provided.

Embodiments of the disclosure will now be described, by way of example only, with reference to the accompanying drawings in which:.

According to this disclosure, a local monitoring device and a remote application may be provided for monitoring the usage of an internal combustion engine. For example, the method of monitoring according to this disclosure may be used to monitor the usage of an internal combustion engine of a piece of machinery.

Embodiments of this disclosure may use a local monitoring device to perform a monitoring routine on an internal combustion engine. The local monitoring device may be configured to be directly connected/attached to the internal combustion engine in order to monitor one or more characteristics of the internal combustion engine.

For example, the local monitoring device may be an engine oil "smart" dipstick (smart dipstick) suitable for determining the engine speed and or engine torque of an internal combustion engine. <FIG> shows a diagram of one example of a smart dipstick <NUM> suitable for use as a local monitoring device according to the present disclosure. <FIG> shows a sectional view of a handle <NUM> of the smart dipstick <NUM>.

The smart dipstick <NUM> comprises a handle <NUM>, a dipstick tube <NUM> and a dipstick gauge <NUM>. In this way, the smart dipstick <NUM> provides all the functionality of a prior art dipstick, namely being configured to be received into a dipstick insertion aperture of an internal combustion engine <NUM>. The dipstick tube may comprise an exterior seal <NUM> that is configured to abut a corresponding element within the dipstick insertion aperture. In this way, the dipstick insertion aperture is fluidly sealed with the smart dipstick <NUM> in situ.

The dipstick gauge <NUM> comprises a series of markings (not shown) that correspond with a series of volumes of oil that may be present in the engine. The dipstick gauge <NUM> is configured such that a film of oil is retained on the dipstick gauge when the dipstick is removed from the dipstick insertion aperture. In this way, an operator can remove the smart dipstick <NUM> from the dipstick insertion aperture to check that an appropriate volume of oil is present.

The handle <NUM> comprises a handle body <NUM> and a handle lid <NUM>. The handle <NUM> comprises an interior cavity <NUM>, as shown in <FIG>, defined by an interior volume within the handle body <NUM> and the handle lid <NUM>.

The dipstick tube <NUM> comprises a cylindrical interior cavity <NUM>.

The handle <NUM> comprises a first conduit <NUM> and a second conduit <NUM>. The first conduit <NUM> provides fluid communication between the interior cavity <NUM> and a first opening <NUM> located on an exterior of the handle body <NUM> (see <FIG>). In this way, the first conduit <NUM> provides fluid communication with atmosphere. The second conduit <NUM> provides fluid communication between the interior cavity <NUM> and a second opening <NUM> located in the nose portion <NUM> and positioned between the annular face <NUM> and the distal end. In this way, the second conduit <NUM> provides fluid communication between the interior cavity <NUM> and the interior of the dipstick tube <NUM>.

The second opening <NUM> is located in a slanted face of the distal end that is slanted relative both to a radial plane of the handle <NUM> and to an axial plane of the handle <NUM>. In this way, the second opening <NUM> opens directly and without restriction into the cylindrical interior cavity <NUM> of the dipstick tube <NUM>.

Accordingly, when the smart dipstick <NUM> is received within a dipstick insertion aperture of an internal combustion engine <NUM>, the second opening <NUM> is in direct fluid communication with the interior of the crankcase of the internal combustion engine <NUM>.

Within the interior cavity <NUM> there is provided a differential pressure sensor <NUM> for sensing a difference in pressure between a first sensor port <NUM> and a second sensor port <NUM>. The first sensor port <NUM> is in fluid communication with the first conduit <NUM> while the second sensor port <NUM> is in fluid communication with the second conduit <NUM>.

Overall, the arrangement results in the first sensor port <NUM> being in fluid communication with atmosphere and the second sensor port <NUM> being in fluid communication with the interior of the dipstick tube <NUM>. Accordingly, the differential pressure sensor <NUM> is configured to sense a pressure difference between the interior of the dipstick tube <NUM> and atmosphere. When the smart dipstick is located in a dipstick insertion aperture of an internal combustion engine <NUM>, the interior of the dipstick tube <NUM> is in fluid communication with the interior of the crankcase of the internal combustion engine <NUM>.

The interior cavity <NUM> comprises a first circuit board <NUM> on which are mounted the differential pressure sensor <NUM> and an accelerometer <NUM>. Also within the cavity there is provided a second circuit board <NUM> on which are mounted a microprocessor <NUM> and a communications module <NUM>. The communications module <NUM> may comprise a Bluetooth chip or other communication means.

A battery <NUM> is located within the interior cavity <NUM> and mounted to an interior of the handle lid <NUM>. The battery is connected directly or indirectly to one or both of the circuit boards <NUM>, <NUM> via a pair of supply connectors <NUM>. Further connections for data and/or power are provided between the first and second circuit boards <NUM>, <NUM>.

Replacement of the battery <NUM> is facilitated by removal of the handle lid <NUM>. The handle lid <NUM> may affix to the handle body <NUM> by means of a bayonet or screw connection.

While, in the first embodiment, there is shown and described both an accelerometer and a differential pressure sensor, it may be that in alternative embodiments, only pressure sensor is provided. Furthermore, it may be that an absolute pressure sensor is provided, instead of a differential pressure sensor, for measuring an absolute pressure at the second opening <NUM>.

In use as a local monitoring device, the smart dipstick <NUM> is placed into the dipstick insertion aperture until the exterior seal <NUM> abuts a corresponding sealing element (not shown) within the dipstick insertion aperture.

As with a prior art dipstick, when the smart dipstick <NUM> is in situ in the dipstick insertion aperture of an internal combustion engine <NUM>, it will vibrate in unison with the internal combustion engine <NUM>. Furthermore, the cylindrical interior cavity <NUM> of the dipstick tube <NUM> will be at the same pressure as the dipstick insertion aperture (on the interior side of the exterior seal <NUM> and corresponding element). Accordingly, a pressure at the second sensor port <NUM> of the differential pressure sensor <NUM> is the same as the pressure, or at least predictably related to the pressure, within the crankcase of the engine.

Alternatively, a smart breather filter assembly may be used as a local monitoring device according to this disclosure. <FIG> shows an exploded diagram of a smart breather filter assembly <NUM> suitable for use as a local monitoring device according to the present disclosure.

Similar to the smart dipstick <NUM>, the smart breather filter assembly <NUM> provides all the functionality of a prior art breather filter assembly, namely being configured to receive a breather filter for filtering oil out of the crankcase gases.

The smart breather filter assembly <NUM> further comprises an electronics housing <NUM> fastened to the breather filter casing body <NUM>. The electronics housing <NUM> comprises a lid <NUM> by which the contents of the housing may be accessed. Within the electronics housing <NUM> there is located a differential pressure sensor <NUM> and an accelerometer <NUM> mounted on a first circuit board <NUM>. Also contained within the electronics housing <NUM> are a communications module (not shown) and a microprocessor (not shown) mounted on a second circuit board <NUM>. The communications module may comprise a Bluetooth chip or other communication means. The housing further contains a battery <NUM>. The battery <NUM> is connected directly or indirectly to one or both of the circuit boards <NUM>, <NUM> via a pair of supply connectors (not shown). Further connections <NUM> for data and/or power are provided between the first and second circuit boards <NUM>, <NUM>.

In a further alternative embodiment, a smart engine oil filler cap may be used as a local monitoring device according to this disclosure. <FIG> shows an exploded diagram of a smart engine oil filler cap <NUM> suitable for use as a local monitoring device according to the present disclosure.

Similar to the smart dipstick <NUM>, the smart engine oil filler cap <NUM> provides all the functionality of a prior art engine oil filler cap, namely being configured to provide a seal to the oil filling port of the internal combustion engine <NUM>.

<FIG> shows an "exploded" representation of an example assembly of the smart engine oil filler cap <NUM>. The assembly may comprise a combined processing and communications module <NUM>, a vibration sensor <NUM> and a memory module <NUM>. The assembly may further comprise a battery <NUM> and a battery brace <NUM>. The combined processing and communications module <NUM>, the vibration sensor <NUM> and the memory module <NUM> may all be arranged within a body cavity <NUM> in a filler cap body <NUM>. A cover <NUM> may be fixed to the top of the filler cap body <NUM> in order to close and seal the body cavity <NUM>.

The vibration sensor <NUM> is located towards the bottom of the body cavity <NUM> in the filler cap body <NUM>, such that when the smart engine oil filler cap <NUM> is fitted to the engine, the vibration sensor <NUM> is close to the crankcase of the engine. By arranging these components in this way, the vibration sensor <NUM> may be positioned close to the engine, which may help to improve its accuracy of vibration sensing.

A cover <NUM> may be fixed to the filler cap body <NUM> in any suitable way, for example it may be a removable cover fixed to the filler cap body <NUM> using a screw thread, or by screws or pins that pass through the cover <NUM>, into the filler cap body <NUM>. In an alternative, the cover <NUM> may be removably fixed to the filler cap body <NUM> in any other suitable way, for example using a push-fit fixing. In a further alternative, the cover <NUM> may be fixed to the filler cap body in a non-removable way, for example by gluing or riveting.

The smart engine oil filler cap <NUM> assembly further comprises a sensor module <NUM> comprising a pressure sensor. The sensor module <NUM> may be mounted on a surface on the underside of the smart engine oil filler cap <NUM>, such that when the smart engine oil filler cap <NUM> is fitted to the engine, the sensor module <NUM> is exposed to the crankcase of the engine so that crankcase pressure may be sensed by the sensor module <NUM>. The top surface <NUM> of the smart engine oil filler cap <NUM> may be considered to be a first surface of the smart engine oil filler cap <NUM>, and the opposing surface on the underside of the smart engine oil filler cap <NUM>, where the sensor module <NUM> is mounted, may be considered to be a second, opposing surface of the smart engine oil filler cap <NUM>.

The sensor module <NUM> may therefore be physically isolated from the vibration sensor <NUM>, the other electrical components of the monitoring device. In this way, the other electrical components of the smart engine oil filler cap <NUM> may be protected from exposure to oil or debris from the crankcase, and insulated to some extent from heat generated by the engine, whilst still allowing the sensor module <NUM> to be exposed to the crankcase. The sensor module <NUM> may be connected to the combined processing and communications module <NUM> by a wired connection through the filler cap body <NUM>, or by a wireless connection, in order to output the values indicative of the sensed crankcase pressure and/or crankcase temperature.

Further features of the local monitoring devices will now be described with reference to the features of the smart dipstick <NUM>, but the skilled person will understand that the following description applies equally to any local monitoring device, for example a smart breather filter assembly <NUM> or a smart engine oil filler cap <NUM>.

The local monitoring device may transmit the aggregated summary and the identification data to the remote application using a wireless communication method for at least part of the data transmission process. For example, the communications module <NUM> may transmit data from the local monitoring device directly to a remote device executing the remote application using a wireless communication method. Alternatively, the communications module <NUM> may transmit data from the local monitoring device to an (intermediate) electronic device using a wireless communication method, and the electronic device subsequently forwarding the data on to the remote application via a further communication method.

In one embodiment the communications module <NUM> may include means for transmitting data wirelessly. For example, the local monitoring device may use a near field communication method signal to transmit data to an application being executed on an electronic device within range of the near field communication network. The means for communicating using a near field communication method may be a Bluetooth transmitter, a low energy Bluetooth transmitter, or a Wi-Fi transmitter.

The communications module <NUM> may be configured to support communications with one or more electronic devices local monitoring device according to any one or more communications protocols/architectures. For example, the communications module <NUM> may support one or more types of wired communications, such as USB, Firewire, Thunderbolt, Ethernet, etc and/or one or more types of wireless communications, such as WiFi, Bluetooth, Bluetooth LE, Near Field Communications (NFC), Infra-red (IR) <NUM>, LTE, UMTS, EDGE, GPRS, GSM, or any other form of RF based data communications. The communications module <NUM> enables at least one communications interface to be established between the local monitoring and an external network element. For example, the network element may be an electronic device, such as an internet server and/or a mobile telephone or smartphone and/or a tablet computer and/or a laptop computer and/or a desktop computer, etc. The interface may be a wired or wireless interface.

The data transmitted by the means for transmitting data over a wireless network of the communications module <NUM> may be received by an electronic device within range of the transmitted data. In the embodiments where data is transmitted using a Bluetooth or Wi-Fi transmitter, the electronic device may be a smart phone, laptop or other portable electronic device. The remote application to which the data is being transmitted may be executed on the smart phone, or on another remote device or server.

In embodiments where the remote application is not executed on the electronic device, the transmitted data may be forwarded by the electronic device on to the remote application/remote server executing the remote application using further communication means. For example, a smart phone may use a mobile internet signal to forward the data received from the local monitoring device. A laptop may use a wireless internet connection to forward the data. As such, the skilled person will understand that the remote application may be executed on an electronic device in which directly receives the transmitted data from the local monitoring system, or a further remote server/remote device receives the transmitted data from the local monitoring system via one or more intermediate devices.

Embodiments of this disclosure may use a remote application to receive data transmitted from a local monitoring device and process the data in order to determine data regarding the usage of the internal combustion engine to which the local monitoring device is connected.

As discussed above, the remote application may be executed on an electronic device which is separate (remote) from the local monitoring device. For example, the remote application may be executed on a remote server, or on a processor of a smartphone or a laptop. The remote application may be configured to process the transmitted data received from the local monitoring device in order to determine engine usage data about the internal combustion engine to which the local monitoring device is directly attached.

The remote application may have access to a database or memory comprising engine characterising information relating to a plurality of different types of internal combustion engine. The engine characterising information for an internal combustion engine type may be associated with identification data of a local monitoring device according to the type of internal combustion engine to which it is attached. The engine characterising information associated with the identification data may be used to process the transmitted aggregated summary in order to determine engine usage data for the internal combustion engine.

The association between the identification data and the engine characterising information in the database may be provided by a user upon registration of the local monitoring device.

For example, an application running on an electronic device may prompt a user to register the local monitoring device and enter information for identifying the local monitoring device and information for identifying the internal combustion engine. The application running on the electronic device may be the remote application used in the method of this disclosure, or it may be a separate application. The electronic device may be a smartphone, a tablet computer, a laptop, or any other portable electronic device with processing and wireless communication capabilities.

For example, a user may identify a local monitoring device by entering information such as a serial number of a local monitoring device. Alternatively, a user may scan a matrix barcode (QR code) displayed on the local monitoring device using a camera connected to the electronic device to identify the local monitoring device.

For example, a user may identify an internal combustion engine being monitored by the local monitoring device by entering a model number of an internal combustion engine, a model name/number of a piece of machinery, a serial number of an internal combustion engine and/or a serial number of a piece of machinery containing the internal combustion engine. Alternatively, a user may scan a matrix barcode (QR code) displayed on the internal combustion engine using a camera connected to the electronic device to identify the, internal combustion engine. As such, the information provided may be any information suitable for identifying the type of internal combustion engine being monitored. If the local monitoring device is subsequently attached to a different internal combustion engine the information may be re-entered to the database to update the association.

An embodiment of a method of monitoring the usage of an internal combustion engine according to this disclosure is shown in <FIG> and <FIG>. The method according to this embodiment is performed using a local monitoring device and a remote application. <FIG> shows the method steps performed by the local monitoring device according to this embodiment while <FIG> shows the method steps performed by the remote application according to this embodiment.

The following discussion of the method according to this embodiment will describe the steps taken by a smart dipstick <NUM> performing the engine monitoring routine. As such, the local monitoring device according to this embodiment is a smart dipstick <NUM>. The skilled person will appreciate that the steps according to this embodiment may equally be performed by a smart breather filter assembly <NUM> or a smart engine oil filler cap <NUM>.

In Step S10 of <FIG>, the microprocessor <NUM> wakes from a lower power state. In step S20, the microprocessor <NUM> receives from the differential pressure sensor <NUM> sensed differential pressure data indicative of the difference between the crankcase pressure and the external ambient pressure. The microprocessor <NUM> samples the differential pressure sensor data repeatedly over a time period to generate pressure sensor data (a pressure sensor data set). As such, data is generated in the microprocessor <NUM> which is I representative of the crankcase pressure of the internal combustion engine.

The microprocessor <NUM> samples the differential pressure sensor for a determination period of time, which may be any period of time that is sufficient for obtaining a reliable measurement of the firing frequency of the engine cylinders and/or the crankcase pressure of the internal combustion engine. For example, the determination period of time may be any period of time between <NUM> seconds to <NUM> minutes, such as <NUM> seconds, or <NUM> second, or <NUM> seconds, or <NUM> minute, or <NUM> minutes, or any period of time between <NUM> seconds to <NUM> minute, such as <NUM> seconds, or <NUM> seconds, or <NUM> seconds, or any period of time between <NUM> second to <NUM> minute, such as <NUM> seconds, or <NUM> seconds, etc. The microprocessor <NUM> may comprise a clock for counting the determination period of time, such as a processor clock, or a crystal clock, or a GPS synchronised clock. The microprocessor <NUM> may generate the pressure sensor data set by periodically sampling the value output from the differential pressure sensor <NUM>. For example, it may sample the output from the differential pressure sensor <NUM> every <NUM> (which is a sampling frequency of <NUM>) and record each of the sampled values during the determination period of time in order to generate data indicative of the crankcase pressure of the engine. The generated data may also be suitable for recording a plurality of vibrations indicative of the vibrations of the engine. The sampling frequency may be any suitable frequency, for example any frequency between <NUM>-<NUM>,<NUM>, such as <NUM>, or <NUM>, or <NUM>, or any frequency between <NUM>-<NUM>, such as <NUM>, or <NUM>, or <NUM>, or any frequency between <NUM>-<NUM>, such as <NUM>, or <NUM>, etc. The sampling frequency may be chosen in consideration of the maximum dominant frequency expected for the engine vibration (for example, a sampling frequency that is sufficiently high to accurately measure the maximum expected dominant frequency in the engine vibration).

<FIG> shows an example plot of the differential pressure sensor data generated in Step S20. In this example, the sampling frequency is <NUM> and the determination period of time is <NUM> second. The x-axis on the plot is the time and the y-axis on the plot is the difference between the crankcase pressure of the internal combustion engine and the ambient pressure in kPa.

In Step S30, the microprocessor <NUM> determines the firing frequency of the cylinders of the engine based on the generated pressure sensor data. Every time a cylinder fires in the internal combustion engine, the cylinder pressure increases, forcing the piston downwards. A small amount of this cylinder pressure will leak into the crankcase, past the piston rings and valve seals. Accordingly a pulse in the crankcase pressure is generate every time a cylinder fires. Viewed at high speed, the crankcase pressure pulses occur at a frequency equivalent to the firing frequency of the engine. So, by performing a time domain to frequency domain transformation of the generated pressure sensor data, the firing frequency of the internal combustion engine may be determined. The firing frequency of the internal combustion engine may be the dominant frequency present in the frequency domain transformation of the pressure sensor data. The microprocessor <NUM> may determine the dominant frequency for example by performing a time-to-frequency domain transformation on the recorded engine vibration, such as a Fourier transform, or a Fast Fourier Transform (FFT), or a Laplace transform, etc..

<FIG> shows a plot of the frequency response (i.e., the time-to-frequency transformation) of the generated pressure sensor data shown in <FIG>. The x-axis of the plot in <FIG> is frequency in units of Hz and the y-axis of the plot in <FIG> is a dimensionless measure of magnitude.

The microprocessor <NUM> may determine the dominant frequency by identifying the frequency with the greatest magnitude in the frequency response plot. The microprocessor <NUM> may consider only a particular range of frequencies within the frequency response when finding the dominant frequency. The range may be defined by a lower frequency limit and an upper frequency limit, both of which may be set in consideration of expected engine operation frequencies, in order to exclude any frequencies that fall outside of expected engine operation. The expected range of firing frequencies produced by an internal combustion engine will depend on the range of allowable engine revolution speeds during operation of the engine and the number of cylinders in the specific internal combustion engine. For example, if the idling speed of the engine is expected to generate a firing frequency of about <NUM> and the maximum possible engine speed is expected to generate a firing frequency of about <NUM>, the considered range may be <NUM> (lower frequency limit) to <NUM> (upper frequency limit). Of course, the maximum and minimum frequencies that an engine should generate will vary for different types of engine, for example with cylinder configuration (straight cylinder, V cylinder, Boxer, etc), engine speed limits and engine idle speeds. Therefore, the range of frequencies to be considered during determination of the dominant frequency may be set to allow for a range of different firing frequencies of different types internal combustion engines.

The dominant frequency may be the frequency corresponding to the peak frequency response. Where there are two or more peaks in the frequency response (for example, because the engine cylinder firing frequency changed during the measurement period of time), the dominant frequency may be the frequency corresponding to the peak with the greatest magnitude. Thus, the dominant frequency may be the firing frequency that was generated by the engine for the longest period of time during the measurement period of time.

In Step S40, the microprocessor <NUM> may record the determined firing frequency of the engine cylinders in the memory module of the microprocessor. There are a number of different ways in which the determined firing frequency may be recorded in the memory module. One exemplary way in which the determined firing frequency may be recorded in the memory module is explained below.

The microprocessor <NUM> may look up an element of an aggregated summary stored in the memory module based on the determined engine cylinder firing frequency. The aggregated summary may comprise a plurality elements corresponding to ranges of engine cylinder firing frequencies and the cumulative time for which the engine has been determined to be operating within each of the engine cylinder firing frequency ranges. As such, the aggregated summary is a data table comprising information regarding the usage history of the internal combustion engine for a plurality of ranges of engine firing frequencies. A non-limiting example of an aggregated summary according to this disclosure is set out below:.

It will be appreciated that the aggregated summary may comprise any number of engine cylinder firing frequency ranges, and the ranges may be of any suitable size and spread.

The microprocessor <NUM> may determine which of the plurality of engine cylinder firing frequency ranges the determined engine cylinder firing frequency lies within and then add the determination period of time to the cumulative time for that element of the aggregated summary. As such, the local monitoring device generates an aggregated summary by updating an element of the aggregated summary based on the determined firing frequency of the engine. Accordingly, a picture of the operation of the internal combustion engine may be built up over time.

Preferably, the element of the aggregated summary is updated by incrementing the existing value of the element with an amount corresponding to the determination period of time. The determination period of time may be the amount time elapsed following a previous performance of the engine monitoring routine i.e. the amount of time elapsed since the previous engine firing frequency measurement.

In the example described above in respect of <FIG> and <FIG>, if the determined engine cylinder firing frequency is <NUM> the microprocessor <NUM> may determine that the determined engine cylinder firing frequency lies within the range <NUM> - <NUM>. The microprocessor <NUM> may then add the determination period of time to the cumulative time recorded for that element in the aggregated summary. For example, if the cumulative time recorded in the aggregated summary for the element corresponding to the engine firing frequency range of <NUM> - <NUM> is <NUM> hours, and the determination period of time is <NUM> seconds, the cumulative time recorded in the element representing the range <NUM> - <NUM> will be updated to <NUM> hours.

Having added the determination period of time to the cumulative time for the determined element of the aggregated summary, the microprocessor may then write the updated element to the aggregated summary in the memory module.

It will be appreciated that the engine firing frequency ranges and cumulative times may be saved in the memory module in any suitable way, for example using any known database or matrix techniques.

After recording the determined engine firing frequency to the memory module in accordance with the above exemplary method, the microprocessor <NUM> may return to Step S20. In this way, the engine cylinder firing frequency may be regularly determined, or sampled, (for example, every <NUM> seconds) and then stored in the memory module, such that extensive engine firing frequency data may be stored over time without an increase in the size of the aggregated summary stored in the memory module.

It will be appreciated that after recording of the values indicative of sensed crankcase pressure over the determination period of time is completed in Step S20 and the process proceeds to Step S30, recording of values indicative of sensed crankcase pressure for the next determination period of time may immediately begin whilst Steps S30 and S40 are being performed, such that there is no period of operation of the engine that does not contribute to a determination of the engine cylinder firing frequency. Consequently, whilst Steps S30 and S40 are being carried out in respect of the most recently completed recording of the values indicative of sensed crankcase pressure, the next recording of values indicative of sensed crankcase pressure may already be underway.

In step S50, the microprocessor <NUM> may broadcast/transmit the aggregated summary to a remote application. The broadcasting step may be performed every time the aggregated summary is updated. Alternatively, the broadcasting step may only be performed after at least: <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM> updates to the aggregated summary. For example, the local monitoring device may be configured to broadcast at least once, twice or three times per day. By limiting the number of times the local monitoring device broadcasts the aggregated summary, the local monitoring device may conserve power and not utilise excessive amounts of bandwidth of a communications network.

In step S50, the microprocessor <NUM> also broadcasts/transmits identification data which allows a remote application to identify the internal combustion engine to which the local monitoring device is connected to. For example, the communications module <NUM> may broadcast a unique identification code, for example a serial number of the local monitoring device or a media access control (MAC) address of the local monitoring device.

The microprocessor <NUM> may transmit/broadcast the aggregated summary and the identification data over a wireless network to a remote application which may be executed on a remote server.

After updating the aggregated summary in step S40, or broadcasting the data in step S50, the local monitoring device may optionally sleep for a predetermined period of time before performing the next measurement of the crankcase pressure. For example, the local monitoring device may sleep for <NUM> seconds, <NUM> seconds, <NUM> seconds or <NUM> seconds. According to the embodiment shown in <FIG>, the sleep step S60 is configured to sleep the device for a period of <NUM>. During the sleep step, the local monitoring device may operate in a low power state. The microprocessor <NUM> may consume little or no energy, and the pressure sensor may not be operated/powered until the sleep step is over. By sleeping for a period of time between measurements of the crankcase pressure, engine monitoring by the local monitoring device may be performed for an extended period of time whilst conserving power of the local monitoring device. In order to ensure that the total time in the aggregated summary reflects the usage of the engine, the predetermined period of time for the sleep step duration S60 may be used as the determination period for incrementing the cumulative time recorded in an element of the aggregated summary.

Preferably, the above described engine monitoring routine is repeated over time in order to build up a history of engine usage data over a time period (an aggregated summary of the engine usage). The time period may be at least a single day, a week, a month or a year. The engine monitoring routine may be repeated a plurality of times in a single day. As discussed above, preferably steps S10, S20, S30 and S40 are performed in sequence and repeated relatively frequently, for example every <NUM> seconds in order to build up a profile of the usage of the engine. Step S50 is preferably performed only a few times each day, in order to conserve the battery of the local monitoring device.

With reference to <FIG>; the operation of the remote application according to an embodiment of this disclosure will now be described.

As shown in <FIG>, in step S70 the remote application receives the aggregated summary and identification data from the local monitoring device. The data may be received over a wireless network, or from an intermediate electronic device forwarding on the transmitted data, or other means as discussed previously above. The aggregated summary received may be the most recently updated version of the aggregated summary stored in the memory module of the local monitoring device.

The identification data received by the remote application may be a unique identification code associated with the local monitoring device which allows the remote application to determine the type of internal combustion engine and/or the specific internal combustion engine which the local device is monitoring. For example, the local monitoring device may transmit a MAC address of the local monitoring device which is unique to the local monitoring device. The remote application may then consult a database to determine engine characterising information related to the internal combustion engine being monitored by the local monitoring device.

The database may contain information regarding the local monitoring device and/or the internal combustion engine associated with the local monitoring device. For example, the database may contain a profile associated with the identification code of the local monitoring device which provides engine characterising information about the internal combustion engine such as the type of engine, the number of cylinders, the number of firing events per engine revolution etc. The database may be populated by a user or installer performing an initial registration of the local monitoring device when the monitoring device is fitted to the internal combustion engine. Initial registration may include sending information such as the local monitoring device identification code and the internal combustion engine type to the remote application and/or another remote server which then populates the database with the engine characterising information suitable for the internal combustion engine.

In step S80, the remote application processes the aggregated summary to determine engine usage data about the internal combustion engine. For example, the remote application may process the engine cylinder firing frequency ranges into engine speed ranges for the specific internal combustion engine. Accordingly, the processed engine usage data may be engine speed usage data which reflects the periods of time spent by the internal combustion engine in each engine speed range.

The remote application may process the engine cylinder firing frequency ranges into engine speed ranges by looking up engine characterising information for determining a number of combustion events per engine revolution of the internal combustion engine. The engine characterising information may be obtained from the database by the remote application by looking up an entry associated with the identification data sent by the local application. As such, the remote application uses the identification data to determine the number of cylinders/number of combustion events per revolution of the internal combustion engine which is being monitored by the local monitoring device.

The engine speed ranges may be calculated from the engine firing frequency ranges as the number of cylinder combustion events, or firing events, per engine revolution depends on the configuration of the cylinders. For example, for a four cylinder straight (in-line) engine, there may be two combustion events per engine revolution. Consequently, the firing frequency would be double the engine speed. However, for a three cylinder straight (in-line) engine, there may be <NUM> combustion events for every two engine revolutions (i.e., <NUM> combustion events per engine revolution), and for a six cylinder straight (in-line) engine, there may be three combustion events per engine revolution. Consequently, the firing frequency would be one and a half times the engine speed.

The engine firing frequency may therefore be converted into an engine speed by applying the following formula, where the firing frequency is the firing frequency ranges of the engine usage data, and N is the number of combustion events per engine revolution of the identified internal combustion engine.

Therefore, for a four cylinder straight engine with two combustion events per engine revolution (N=<NUM>), the engine speed in RPM may be calculated as follows: <MAT>.

As an example of the processing technique for calculating engine speed, the recorded engine crankcase pressure represented in the plot of <FIG>, and corresponding frequency domain plot of <FIG>, were made on a four cylinder straight engine (N=<NUM>). As can be seen, the dominant frequency in the frequency response represented in Figure is <NUM>. Therefore, the determined engine speed is <NUM> rpm.

Accordingly, the above engine speed calculation may be made to each of the engine firing frequency ranges transmitted by the local monitoring device to determine engine speed usage data about the internal combustion engine.

In step <NUM>, the engine speed usage data may be output. The engine speed usage data may be output to a memory associated with the remote application where the engine speed usage data is stored. Alternatively, the engine speed usage data may be output to a display for assessment by a user. The engine speed usage data may be displayed as a histogram to allow a user to quickly assess the usage history of the internal combustion engine.

In a further embodiment of this disclosure, the pressure sensor data may also be used to determine information regarding the average crankcase pressure, and preferably the torque output of the engine.

<FIG> shows the method steps performed by the local monitoring device according to this further embodiment while <FIG> shows the method steps performed by the remote application according to this further embodiment.

As shown in <FIG>, the local monitoring device performs a monitoring routine for monitoring the pressure of an engine crankcase. Step S110 of waking, step S120 of obtaining pressure sensor data and step S130 of determining the engine cylinder firing frequency may be performed as described in steps S10, S20 and S30 respectively according to the previous embodiment.

In step S135 of this further embodiment, the average engine crankcase pressure is determined. Preferably, the root mean square (RMS) of the engine crankcase pressure is determined by the microprocessor from the data points recorded from the pressure sensor.

In step S140 the determined values of engine firing frequency and RMS crankcase pressure are used to generate an aggregated summary of the engine usage. As with Step S40 of the previous embodiment, the aggregated summary comprises a plurality of elements which reflect the cumulative usage of the internal combustion engine.

In this further embodiment, the elements of the aggregated summary are provided in a matrix form, whereby the determined values of engine firing frequency and RMS crankcase pressure are used to select an element to be updated.

The aggregated summary may comprise a plurality elements corresponding to ranges of engine cylinder firing frequencies and ranges of crankcase pressures. Each element in the aggregated summary containing a value indicative of the cumulative time for which the engine has been determined to be operating within engine cylinder firing frequency ranges and crankcase pressure range. As such, the aggregated summary is a data table comprising information regarding the usage history of the internal combustion engine for a plurality of ranges of engine firing frequencies and a plurality of crankcase pressure ranges. A non-limiting example of an aggregated summary according to this embodiment of the disclosure is set out below:
<IMG>.

In the aggregated summary above, the columns of the table/matrix represent columns of elements corresponding to ranges of engine cylinder firing frequency. The rows of the table/matrix represent rows of elements corresponding to RMS crankcase pressures (MRS CCPress (kPa)).

As an example of the updating the aggregated summary, in the aggregated summary provided above if the determined RMS crankcase pressure was <NUM> kPa and the determined engine cylinder firing frequency was <NUM>, then the element with a value of <NUM> would be selected to be incremented by the determination time period.

As discussed for the previous embodiment, after step S140, the engine monitoring routine may proceed to a broadcasting step S150, or the engine monitoring routine may proceed to a sleep step S160 if it is not required to broadcast the aggregated summary at that point.

Broadcasting step S150 may be substantially the same as broadcasting step S50 but broadcasting the larger aggregated summary with both crankcase pressure and engine cylinder firing frequency data included.

Sleep step S160 may be substantially the same as broadcasting step S60.

<FIG> shows the steps taken by the remote application to process the transmitted aggregated summary and identification data in order to generate engine usage data according to the further embodiment.

In step S170 the remote application receives the aggregated summary and identification data transmitted by the local monitoring device. As such, step S170 may be substantially the same as step S70 of the previous embodiment.

In step S80 the remote application processes the aggregated summary based on the identification data. As with the previous embodiment, the remote application uses the identification data to determine engine characterising information of the internal combustion engine associated with the local monitoring device.

As discussed previously, the aggregated summary of this embodiment is a matrix of elements. As such, the aggregated summary effectively has axes of engine firing frequency and engine crankcase pressure. In step S180, the remote application processes the ranges in each of these axes to determine engine usage data.

Similar to the previous embodiment, the remote application may process the engine cylinder firing frequency ranges of the aggregated summary into engine speed ranges by looking up an engine characterising information in the database for determining a number of combustion events per engine revolution of the internal combustion engine.

The remote application may also process the engine crankcase pressure ranges to determine engine torque output usage data for the internal combustion engine. The remote application may determine engine torque output usage data based on the engine crankcase pressure, the engine speed and engine characterising information stored in the database.

Crankcase pressure measurements may be converted into engine torque measurements if the engine torque curve is known for the internal combustion engine at that engine speed of operation. An example of an engine torque curve is shown in <FIG>, which shows the maximum torque output of a specific internal combustion engine for a range of engine speeds.

In a closed circuit breather engine (i.e. an engine where the crankcase gasses are filtered and ingested by the engine), as engine torque increases the crankcase pressure decreases. In an open circuit breather engine (i.e. an engine where the crankcase gasses are filtered and vented to atmosphere), as engine torque increases the crankcase pressure increases.

Over a period of time, the local monitoring device will record the crankcase pressure of the monitored internal combustion engine operating at a range of different output torques for a range of different engine speeds. For a given engine speed, the aggregated summary may contain a number of elements indicating engine usage at a range of different crankcase pressures. As such, for a give engine speed the aggregated summary will provide an indication of the maximum and minimum crankcase pressures recorded at that engine speed. As the internal combustion engine may be operated at a range of different engine torque outputs from a minimum output (i.e. <NUM>, <NUM> % of maximum output) to a maximum output (i.e. <NUM> % of the maximum output as indicated by the engine torque curve), the engine crankcase pressure ranges may be to reflect the range of possible torque outputs.

Thus, the maximum torque output of the internal combustion engine for a given engine speed may be related to the maximum or minimum crankcase pressure range recorded for a given speed range in the aggregated summary, depending on the type of internal combustion engine being monitored.

For example, <FIG> shows an example of scaling the RMS crankcase pressure ranges for an engine speed range of <NUM> -<NUM> rpm. As shown in <FIG>, the measured crankcase pressures in the aggregated summary for an engine speed of <NUM>-<NUM> rpm range from <NUM> kPa to <NUM> kPa. Based on the identification data transmitted along with the aggregated summary, an engine torque curve, or corresponding engine characterising information may be identified for the internal combustion engine being monitored. The engine characterising information (engine torque curve) indicates a maximum torque output for the internal combustion engine at a given engine speed. Where the engine speed is a range of engine speeds, the average engine speed for the range may be used. In this example, an engine speed of <NUM> rpm may be used to determine that the maximum torque output for the engine may be <NUM>. In this example, it is also known that the engine is an open circuit breather engine. Accordingly, the element corresponding to the maximum crankcase pressure range is set to be indicative of the maximum torque output (<NUM>) and the element corresponding to the minimum crankcase pressure is set to be indicative of the minimum torque output (<NUM>). The crankcase pressure ranges remaining between the maximum and minimum may be scaled between the maximum and minimum values. For example, as shown in <FIG>, linear scaling is used to determine the crankcase pressure ranges. Alternatively, a non-linear scaling may be used to determine the crankcase pressure ranges.

The above described example for processing the engine crankcase pressure may be repeated for all engine speed ranges and stored or output by the remote application to a display. Accordingly, the high speed crankcase pressure data traces can be processed to extract a value proportional to torque, regardless of breather system. The remote application can therefore generate usage data reflecting the amount of time the internal combustion engine has spent operating at different torque outputs.

The skilled person will appreciate that over time the populated elements of the aggregated summary table will increase over time as the local monitoring device monitors the usage of the internal combustion engine. Accordingly, the accuracy of the engine torque output usage data will increase over time as the aggregated summary is populated.

In a further alternative embodiment the local monitoring device may be connected to the Control Access Network (CAN) bus of a vehicle. This may allow the communications module to make use of the on board communications equipment of the vehicle via the CAN bus in order to transmit the aggregated summary and identification data to a remote application.

In order to connect to the CAN bus, the local monitoring device may further include a connection port for making a wired connection between the CAN bus and communications module of the local monitoring device. By including a connection to the CAN bus, the local monitoring device may communicate with the on-board computer of a vehicle and may make use of any communications modules included in the vehicle. As such, the processor may not need to include its own means for establishing a wireless network connection to send the aggregated summary and identification data, if the CAN bus connection can be provided.

In another alternative embodiment, the local monitoring device may also include a vibration sensor. For example, the vibration sensor may be an accelerometer connected to a processor of the local monitoring device. One example of such an accelerometer is the accelerometer <NUM> of the smart engine oil filler cap <NUM> as discussed previously.

The vibration sensor according to this alternative embodiment may sense a plurality of vibrations of the internal combustion engine. The vibrations may be recorded by the processor of the local monitoring device in a similar manner to the method for obtaining the pressure sensor data. The vibration sensor measurements may be used to determine a dominant frequency of vibration of the internal combustion engine which corresponds to the firing frequency of the cylinders of the internal combustion engine by performing a time domain to frequency domain transformation of the vibration sensor data. This data may be used to improve the accuracy of the engine cylinder firing frequency determined from the pressure sensor data. In one example, the vibration sensor data may be combined with the pressure sensor data and processed using a fast Fourier transform to determine the engine cylinder firing frequency. By increasing the amount of time domain data used to determine the engine firing frequency, the accuracy of the determined frequency may be improved.

An example of an internal combustion engine <NUM> with local monitoring devices attached is shown in <FIG>. As can be seen in <FIG>, the smart breather filter assembly <NUM> and the smart engine oil filler cap <NUM> are attached to the internal combustion engine <NUM>. Although only one of these smart devices may be used to perform the engine monitoring routine according to this disclosure, in some embodiments more than one type of local monitoring device may be attached to the internal combustion engine.

By providing a method of monitoring the usage of an internal combustion engine according to the present disclosure, engine usage data about an internal combustion engine may be gathered by a remote application. In particular, engine speed usage data may be determined from an aggregated summary generated by a local monitoring device. The data gathered by the local monitoring device is processed by the remote application, and so the method of monitoring according to the disclosure does not require any calibration or initial set up of the local monitoring device in order to be performed. Rather, the identification data relating to the local monitoring device and the type of internal combustion it is monitoring can be entered into a database for the remote application at a later date.

Advantageously, as the local monitoring device does not require any initial set up or calibration, it may be easily installed or retrofitted to a wide range of internal combustion engines. For example, the local monitoring device may be provided as part a smart engine oil filler cap, a smart breather filter assembly, or a smart dipstick. Each of these parts are easily accessible and easily replaceable, meaning that old, standard engine oil filler caps/breather filter/engine oil dipsticks may be easily replaced with a local monitoring device for use with the method of the present disclosure.

The method according to the present disclosure may determine engine speed usage data by processing the measured firing frequencies using engine characterising information relating to the number of firing events per revolution of the internal combustion engine. By storing this data in a remote application, the storage and processing requirements of the local monitoring device may be reduced, which in turn means the local monitoring device may save space and or/power consumption.

The engine monitoring routine performed by the local monitoring device may be repeated over a period of time to generate an aggregated summary reflecting the usage of the internal combustion engine over the monitored period of time. Accordingly, the remote application may accumulate and monitor the usage of the internal combustion engine by tracking the updated aggregated summary over time.

The engine monitoring routine performed by the local monitoring device may include updating elements of the aggregated summary based on the determined frequency of the internal combustion engine. By updating the aggregated summary in this way, the amount of data recorded and stored by the local monitoring device is kept to a minimum, as opposed to logging each entry separately. By only updating a single element of the aggregated summary each time the monitoring routine is performed, power consumption may be further reduced, as opposed to writing the entire aggregated summary or individual data entries each time to the memory.

Since the amount of data stored in the aggregated summary does not increase with time (while the count for each data combination increases with time, the actual amount of data does not increase with time), the amount of data to betransmitted remains modest throughout the lifetime of engine use. Also, if data transmitted by the communications module is occasionally not received by the intended recipient, it is of no long term consequence since the next aggregated summary that is received successfully will provide all of the aggregated data up to that point (which includes the previously unreceived data).

The local monitoring device according to the present disclosure may transmit/broadcast the aggregated summary and identification data to a remote application using, at least in part, a wireless network. By using a wireless network to transmit/broadcast the aggregated summary and identification information to the remote application, a wired connection to the local monitoring device may not be required. Furthermore, as the local monitoring device includes means for wirelessly communicating with a remote application, the local monitoring device may be fitted to internal combustion engines where an external communication system is not available. For example, the local monitoring device may be provided as part a smart engine oil filler cap, a smart breather filter assembly, or a smart dipstick. Accordingly, the method of monitoring according to the present disclosure may be applied/retrofitted to legacy internal combustion engines where smart monitoring of engine usage was not previously available.

The method of monitoring according to this disclosure utilises pressure sensor data to from a local monitoring device to determine engine usage data including engine speed usage data and engine torque output data. Accordingly, the method of monitoring generates two sets of usage parameters from a single sensor attached to an internal combustion engine. Thus the method of monitoring is highly efficient in terms of the hardware requirements for the monitoring device and the subsequent processing of the aggregated summary in the remote application.

Claim 1:
A method of monitoring the usage of an internal combustion engine (<NUM>) comprising:
performing an engine monitoring routine using a local monitoring device (<NUM>, <NUM>, <NUM>) directly attached to an internal combustion engine (<NUM>) including:
generating a plurality of data points representative of the crankcase pressure of the internal combustion engine using a pressure sensor (<NUM>, <NUM>) of the local monitoring device (<NUM>, <NUM>, <NUM>);
processing the generated data points to determine a first value representative of a firing frequency of the internal combustion engine characterized by
generating an aggregated summary of the internal combustion engine usage based on the first value; and
transmitting identification data for the local monitoring device (<NUM>, <NUM>, <NUM>) and the aggregated summary from the local monitoring device (<NUM>, <NUM>, <NUM>) to a remote application,
wherein the remote application processes the transmitted aggregated summary based on the transmitted identification data to determine engine speed usage data for the internal combustion engine (<NUM>).