Condition monitoring system and method

Abstract

A method for state monitoring of a device, the method comprising determining a desired state or event for the device, acquiring sensor data at the desired state or event; determining an indicator (20) indicating the desired state or event; monitoring the indicator (21); sending (22) instructions to one or more sensors associated with the device to trigger activation of the sensors when the desired state or event, as indicated by the indicator, has occurred; receiving (25) data from the activated sensors; and, after the data has been received from the sensors, returning the sensors to a sleep mode.

Description

Technical Field

[0001] The present invention relates to a condition monitoring system and a method of operating the same. Background Art

[0002] Condition monitoring of equipment, particularly rotating machinery, is becoming increasingly important, for example, to extend operational life by performing proper maintenance and detecting faults at an early stage that could lead to longer downtime or other component damage. Traditional condition monitoring relies on the use of industrial sensors mounted on the equipment and powered by mains electricity. These sensors can take readings continuously or at fixed intervals. However, while effective, this type of industrial sensor is expensive. Increasing cost pressures have led to the use of battery-powered sensors, but batteries have a limited lifespan and need to be recharged or replaced, so it is desirable to extend battery life to reduce the frequency of recharging or replacement.

[0003] Typically, industrial condition monitoring sensors are set to read sensor data at fixed intervals throughout the day, such as every 5 minutes or every 10 minutes. Some systems that use battery-powered sensors but are based on this fixed-interval approach attempt to address the issue of improving sensor battery life by still performing regular sampling but changing the period based on specific inputs. For example, US8416726 describes wireless sensor devices in a network that have high-power and low-power modes, and if the state is such that the device is likely to consume more power, it switches to low-power mode for a longer period of time. Another approach is to allow nodes of a wireless sensor network to independently determine their sleep schedules, as described in US9986502, so that they can save energy when needed, or, as described in US20180139698, to provide wake-up circuitry, which means that the sensor is only awakened when a request to use the sensor is received.

[0004] However, these systems do not address another problem that arises in rotating machines, namely, significant variability in the operating behavior of the monitored system.There is a need for an improved condition monitoring system and method. Summary of the Invention

[0005] According to a first aspect of the present invention, a state monitoring method for a device includes: determining an expected state or event of the device, and obtaining sensor data under the state or event; determining an indicator indicating the expected state or event; monitoring the indicator; sending instructions to one or more sensors associated with the device to trigger activation of the sensor when the expected state or event as indicated by the indicator has occurred; receiving data from the activated sensor; and, after receiving the data from the sensor, returning the sensor to sleep mode.

[0006] The indicator may include a Boolean operator, or a bit in a database, particularly a time series database.

[0007] Data received from activated sensors may be stored in a database.

[0008] The method may further comprise determining whether further data is required from the sensor in accordance with the instruction and, if so, activating the sensor and receiving the further data before instructing the sensor to return to the sleep mode.

[0009] The desired state may include a state that occurs a predetermined number of times during an operating cycle.

[0010] According to a second aspect of the invention, a computer-implemented method for performing predictive maintenance of an industrial device comprises performing condition monitoring according to the first aspect; comparing data received from activated sensors with stored reference data; and sending a notification if the comparison indicates that maintenance or repair is required.

[0011] According to a third aspect of the present invention, a condition monitoring system for performing condition monitoring on a device for fault diagnosis or predictive maintenance includes a plurality of components configured to perform condition monitoring operations according to the first aspect, the components including a database and a memory for storing condition monitoring sensor data.

[0012] These components may include software components, or a combination of software and hardware components.

[0013] The database may include a time series database.

[0014] The system may further include reference data and a comparator for comparing the condition monitoring sensor data and the reference data.

[0015] The system may further include one or more processors configured to execute the plurality of software components, or a cloud-based processing facility, or a combination of both.

[0016] The system may include a multi-sensor data device for collecting equipment-specific status data for analysis.

[0017] The multi-sensor device may comprise a plurality of sensors for transmitting operating parameters, in particular vibration sensors, temperature sensors or speed sensors; a wireless communication module; and a battery.

[0018] According to a fourth aspect of the invention, a method for operating a multi-sensor data collection device, which includes multiple sensors for transmitting operating parameters, in particular vibration sensors, temperature sensors or speed sensors; a wireless communication module; and a battery, the method including receiving instructions to trigger one or more sensors associated with the monitored device; when a determined or expected state or event of the device for which sensor data is to be obtained occurs, receiving instructions in response to an indicator indicating that the expected state or event of the device has occurred; and, after receiving data from the sensor or each sensor, receiving instructions in the same instruction or a subsequent instruction to return the sensor to sleep mode. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Examples of condition monitoring systems and related operating methods according to the present invention will now be described with reference to the accompanying drawings, in which:

[0020] Figure 1 is a block diagram of an example of a system according to the present invention;

[0021] Figure 2 is a flow chart of a method for operating a condition monitoring system according to the present invention; and

[0022] Figure 3 is based on Figure 2 Flowchart of the predictive maintenance method of the condition monitoring method shown. DETAILED DESCRIPTION

[0023] As mentioned above, traditional battery-powered sensor systems cannot account for the variability in the operational behavior of the monitored system. Networked wireless sensor nodes, such as those mentioned above, consider reducing transmission frequency and envision acquiring data at modified intervals. In contrast, for condition monitoring or predictive maintenance applications in mechanical equipment (such as rotating machinery), numerous variables can affect the sensor data being collected, and these variables are variable. For example, in a rotating machine's motor, the vibration, current draw, and / or operating temperature of the machine and associated equipment can vary depending on the load under which the motor operates. This is not a problem with mains-powered industrial sensors, which are the norm, as data can be read continuously and the results subsequently processed to account for variability. To properly apply such data for condition monitoring or predictive maintenance, it is important to ensure that data is sampled when the system is in a similar state—for example, always taking measurements when the motor is unloaded. Therefore, when requesting a sensor measurement, the system state during the sampling period must be considered.

[0024] Although samples collected at fixed intervals can be classified as usable or unusable through data processing, this still does not solve the need to collect the same samples under repeatable conditions. In extreme cases, due to the constraint that useful data can only be obtained when the system is unloaded, the fixed sampling interval may not actually produce samples collected at the time when the machine is not under any external load (if such a state is relatively rare). In any case, a large number of samples are unlikely to be useful, which is wasteful in terms of battery consumption.

[0025] The present invention changes the sampling basis to select specific events, such as when the device is unloaded. A database (such as a time series database) is monitored to determine when a Boolean value (or bit) appears that describes the device being in the desired monitoring state. The Boolean value (or bit) in question depends on the device itself and is selected based on an understanding of the device and its functions. A Boolean value (or bit) is a value that can indicate whether the device is in a specific state, which means that a measurement that provides the required data is taken. If measurements are taken when the device is not in the correct state, then they may not be of any use for further processing. When the device reaches the desired state, a script is triggered to make an API call to the server, effectively telling the server to take a measurement. For relatively infrequent events, relying on a fixed sampling interval or an interval that can vary but is not based on any specific state of the machine may never actually produce a measurement that is taken in the desired state.

[0026] The present invention addresses these issues by combining event-based triggering with periods of inactivity, so that the sensor is active only when a measurement is likely to be needed, and only when a predetermined event occurs. The present invention addresses this issue by monitoring a specific status indicator and using that indicator to increase the chances of consistent measurements when the machine is in a selected state. The status indicator can take many forms, for example, when the machine is in a "steady state," e.g., for a variable speed drive, having reached its speed setpoint, in which case the measured Boolean value will be IF (deviation < threshold).

[0027] Optionally, equipment can operate in several different “states,” performing specific tasks in each given state. Therefore, monitoring and measuring the machine as it moves from one state to another can provide a good indicator of how the equipment is performing in a particular state. Depending on the application, this change-of-state option is suitable for most types of measurements, including vibration, temperature, current, or pressure of the equipment as a whole, the environment in which it is installed, or a specific part of the equipment.

[0028] However, the most convenient status indicator is a bit from a database. The bit to be monitored is selected to be the bit that most closely correlates with the predetermined state of the device. One type of database that can be used is a time series database. This type of database stores time series data, which means that for each measurement, there is a measurement value (and possibly measurement quality and metadata), and a corresponding timestamp indicating when the measurement was taken. However, other types of databases can also be used, as long as the data can be obtained when the device or machine is in the correct state and is stored in a retrievable manner.

[0029] A Boolean value (or bit) (0, 1) can be set to determine whether a measurement should be taken. Boolean values ​​can be customized as needed in the script that monitors the database. For example, when determining whether a vibration measurement is to be taken in a system that is performing a milling process, a bit (a Boolean value; 0 or 1) indicating whether the device has currently completed the milling process is used, i.e., a specific value is monitored directly. In other examples, it may be necessary to calculate the Boolean value to be monitored. For example, if a measurement is to be taken when the motor has reached a steady state (i.e., the speed has reached its set point), it may be necessary to convert the two variables (speed and set point) into a single Boolean value, which can be simply done in the following way:

[0030] If((absolute value(speed-set value)~0):

[0031] MeasuredValue = True

[0032] otherwise:

[0033] Measured value = False

[0034] Thus, the present invention changes the sampling basis from a fixed time used in prior art systems and methods to a specific event selected. An example of an event suitable for monitoring the system when such an event occurs is when a device or machine is unloaded. As mentioned above, other events may include steady state or completion of a specific process.

[0035] Figure 1 A block diagram illustrating a system to which the method of the present invention may be applied is shown. Figure 2is a flow chart illustrating an example of a method according to the present invention. A particular device 1 is provided with one or more wireless sensors 2 to sense data related to the device's status, such as vibration, typically determined by measuring acceleration, or the status can be determined based on data related to temperature or current. More generally, any measurable value that can be measured using an Internet of Things (IoT) sensor can be selected depending on the application. The wireless sensor 2 communicates with a server 4 via a wireless communication network 3. The wireless sensor can be implemented as a multi-sensor data collection device to collect device-specific status data to be analyzed and determined. For example, such a multi-sensor device can be installed on the monitored device, such as a motor, to determine the motor's health status. Other applications include fleet management, providing performance profiles or electronic rating boards. The multi-sensor device can include multiple sensors for acquiring data related to operating parameters, a wireless local area network (WLAN) communication module, and a battery for powering the device. The sensors can, for example, use an onboard temperature sensor, a three-axis vibration sensor, an acceleration sensor, and a single-axis magnetic sensor to determine status such as vibration, cooling status, or speed. The communication module can include a Bluetooth or Wi-Fi interface.

[0036] The server can be a third-party server, such as a server provided by a third-party company responsible for providing sensors or device maintenance on the device, or it can be a server run by the device. The server receives communication 10, such as an instruction to read, and then the server 4 communicates with the sensor 2. Communication of instructions to the server typically uses an application program interface (API). The wireless communication network 3 can be an industrial process network. Normal operating data associated with the device 1, such as in a programmable logic controller (PLC) 11 or a processor of a cloud-based system, is generated from the PLC of the device 1, from a multi-sensor data collection device 2, or from the cloud via a communication gateway server 5 and is transmitted to a timing database 6 in this example. Each transmission from the device 1 to the communication gateway server 5 and from the communication gateway server 5 to the timing database 6 involves bit state changes 8 and 9. The server 4 can be commanded to trigger the measurement of a specific sensor 2 in the device by sending an API post-command 10 via an API available on the network.

[0037] The system includes a database 6 in which readings from the sensor 2 are stored. This information is transmitted to the database 6 via a communication gateway 5, which can be any time-series database, such as an influx database. The triggering of the sensor reading includes multiple steps. A bit with a high correlation to a specific system state is selected 20, such as a bit associated with a system state of "no load", although other states can also be selected. The selected bits are then monitored 21, for example using a structured query language (SQL) script 12. Whenever the state of the monitored bit changes, i.e. from low to high or from high to low, this change can be detected to indicate that a specific part of the process has been completed. Taking the "no load" state as an example, "no load" means that the motor runs for a certain time without any external load. Taking the grinding process as an example, when the device has completed grinding an anode, a reading is triggered 13. The device then prepares the next anode (i.e., moves it into the grinding "chamber" so that it is ready for grinding). The change of state 8 of this bit is then used to trigger a simple executable file 13 which sends 22 a POST request 10 to the server 4 in order to trigger a sensor measurement of a specific sensor 2 .

[0038] In addition, if necessary, the executable is used to verify 23 that the requested sensor is available on the network, and the executable limits the number of times the sensor is triggered to a configurable value, thereby further reducing battery usage. For example, only a certain number of measurements can be taken per day so that the frequency of measurement does not exceed the frequency required to receive an appropriate amount of data to monitor the status of a given device. In this way, enough data can be obtained to perform analysis while keeping battery consumption as low as possible. The script allows the user to configure the number of measurements to be taken. Once this number is reached, the script will not take another measurement even if the monitored bit changes from low to high (0 to 1). After the sensor 2 has taken a reading 24 as requested, a subscription system in the communication gateway 5 ensures that the new sensor data is correctly transmitted 25 to the database 6 for permanent storage. By monitoring a known system state and ensuring that sensor readings are taken in this known system state, the battery life of the sensor is greatly increased.

[0039] This feature of monitoring the database to determine when a bit describing a device in a desired monitoring state appears, and when the device reaches the desired state, then triggering a script to make an API call to the server, effectively instructing the server to take a measurement, helps extend the battery life of the sensor. This is because the selected triggering events mean that only a limited number of measurements may need to be taken in any given operating cycle. For example, the system can be run based on a daily routine or a portion of a day, such as between 12 and 36 hours, and particularly 24 hours. Within the selected period, events may only occur occasionally, such as fewer than five times a day, and these events may be unevenly distributed throughout the day, for example, they may be separated by a few minutes or as much as an hour. Therefore, if an event only occurs once or twice a day (in a machine that only occasionally reaches the desired state), and the sensor is then placed into an extended sleep period until the next day, or the start of the next measurement cycle, significant battery savings can be achieved compared to methods based on fixed or regular intervals, if not based on a daily cycle. During the next measurement cycle, the sensor can periodically wake up to check whether it has received an instruction from the server 4 to take a measurement. Once the sensor 2 has completed the required measurement, the server 4 will instruct the sensor to sleep for a long time until the next measurement check cycle begins. For a system that operates 24 / 7, the next measurement check cycle is usually the next day. This helps the battery maintain energy and reduces the frequency with which the battery needs to be charged or replaced. Monitoring a representative bit and using the state change of this bit to trigger a sensor measurement through the API can increase the probability that the sensor will take a measurement every time the system is in a similar system state (such as no load).

[0040] The acquired sensor data, along with stored data that provides a reference operating state, can then be used in a software-based system to enable condition monitoring or predictive maintenance of the machine. Deviations from expected readings can be classified, and when they exceed a certain range or threshold, notifications can be sent indicating what action is needed, such as inspection of parts, scheduled maintenance such as lubrication, or replacement of parts or consumables.

[0041] Figure 3 The basic approach to predictive maintenance is shown, which utilizes sensor data acquired during condition monitoring, e.g., as described above with reference to Figure 2 Described. Depending on the type of sensor data available and the type of equipment being monitored, specific analysis is performed for predictive maintenance. Using the method of the present invention helps ensure that the correct data is obtained so that predictive maintenance analysis can be performed. Figure 3 In the example shown, reference data relating to the monitored conditions and equipment are stored 30 .

[0042] The sensor data 24 read during the monitoring phase can be compared 31 with stored reference data, and the result of the comparison evaluated 32 against a predetermined threshold or range. If the threshold or range is exceeded 33, further checks are performed to determine the result and type of notification required, and the notification is sent 34. This notification can take various forms, such as providing information about a maintenance event that needs to be performed within a specific time frame, automatically ordering consumables that must be replaced (if necessary), or an alert indicating a serious fault that must be addressed immediately. If the result is within the predetermined threshold or range 35, the monitoring cycle continues without taking further action.

[0043] Although the present invention has been described above with reference to various embodiments, it should be understood that many variations and modifications may be made to the described embodiments. Therefore, the above description should be considered illustrative rather than restrictive, and it should be understood that all equivalents and / or combinations of the embodiments are intended to be included in this specification.

[0044] It should be understood that the actions associated with the above-described methods, features, and functions (except any manual actions described) can be performed by one or more data processing systems (e.g., a central control system) via the operation of at least one processor. As used herein, a processor corresponds to any electronic device configured to process data by hardware circuits, software, and / or firmware. For example, the processor described herein may correspond to one or more (or a combination) of a microprocessor, a central processing unit, or any other integrated circuit or other type of circuit capable of processing data in a data processing system. The processor may correspond to a central processing unit that executes computer / processor executable instructions stored in a memory in the form of software and / or firmware to perform the process or function described / claimed as such. However, it should also be understood that such a processor may correspond to an integrated circuit hardwired to a processing circuit (e.g., a field programmable gate array or an application specific integrated circuit) to perform the process or function described / claimed as such.

[0045] Furthermore, it should be understood that a processor described or claimed as configured to perform a particular described / claimed process or function may correspond to a combination of a processor and executable instructions (e.g., software / firmware application) loaded / installed into memory (volatile and / or non-volatile), which are currently being executed by the processor and / or are executable by the processor to cause the processor to perform the described / claimed process or function. Thus, a processor that is powered off or is executing other software but has data memory (e.g., on a hard drive or solid-state drive) installed on a processor operatively connected to the processor in a manner configured to be executed by the processor (when activated by a user, hardware, and / or other software) may also correspond to a processor described / claimed as configured to perform the particular processes and functions described / claimed herein.

[0046] Furthermore, it should be understood that reference to a "processor" may include multiple physical processors or cores configured to perform the functions described herein. Additionally, it should be understood that a data processing system may also be referred to as a controller that is operable to control at least one operation.

[0047] It is also important to note that while the present disclosure includes descriptions in the context of fully functional systems and / or series of actions, those skilled in the art will appreciate that at least a portion of the mechanisms of the present disclosure and / or the described actions can be distributed in the form of computer / processor executable instructions (e.g., software and / or firmware instructions) contained in a data store corresponding to any of a variety of non-transitory machine-usable, computer-usable, or computer-readable media. Computer / processor executable instructions can include routines, subroutines, programs, applications, modules, libraries, and the like. Furthermore, it should be understood that computer / processor executable instructions can correspond to and / or be generated from source code, bytecode, runtime code, machine code, assembly language, Java, JavaScript, Python, Julia, C, C#, C++, or any other form of code that can be programmed / configured to cause at least one processor to perform the actions and features described herein. Furthermore, the results of the described / claimed processes or functions can be stored in a computer-readable medium and displayed on a display device, etc. It will be apparent that the various methods, algorithms, and modules disclosed herein can be implemented on a computer-readable medium that is appropriately programmed for a computing device. The module realizing the method and algorithm disclosed herein can be stored and transmitted in various ways using various media (such as computer-readable media).In one embodiment, hard-wired circuits or custom hardware can be used to replace or combine software instructions to realize the process in various embodiments.Therefore, the embodiment is not limited to any specific combination of hardware and software.Usually, the module including computer-executable instructions can be implemented with any programming language.The module can be stored on or in one or more media as object code.Aspects of the method and system disclosed herein can be implemented in a non-programming environment, and the non-programming environment includes, for example, with hypertext markup language (HTML), extensible markup language (XML) or when viewed in the visual area or window of a browser program, presenting a document created in other formats of the aspect of a graphical user interface (GUI) or performing other functions.Aspects of the method and system disclosed herein can be implemented as programming elements, non-programming elements or any suitable combination thereof.

[0048] When describing a database including data points, one skilled in the art will appreciate that (i) alternative database structures to the described database structure can readily be used, and (ii) other memory structures besides databases can readily be used. Any illustrations or descriptions of any sample database disclosed herein are illustrative arrangements for information storage. In addition to the arrangements suggested in tabular form in the figures or elsewhere, any number of other arrangements may be employed. Similarly, the entries in any diagram of the database represent only exemplary information; one skilled in the art will appreciate that the number and content of the entries may vary from those disclosed herein. Furthermore, although the database is described as a tabular database, other formats, including relational databases, object-based models, and / or distributed databases, may also be used to store and manipulate the data types disclosed herein. Similarly, the database's object methods or behaviors can be used to implement various processes, such as those disclosed herein. Furthermore, the database can be stored locally or remotely from the device accessing the data in such database in a known manner. In embodiments where multiple databases are present in a system, these databases can be integrated to communicate with each other when any data in one of the databases is updated, thereby enabling simultaneous updates of data linked across the databases.

[0049] The present invention can be configured to work in a network environment that includes one or more computers communicating with one or more devices via a network. The computer can communicate directly or indirectly with the device via a wired medium or wireless medium (such as the Internet), a cellular network (such as 4G or 5G, etc.), a local area network (LAN), a wide area network (WAN) or Ethernet, a token ring network, or via any appropriate communication medium or a combination of communication media. Each device includes a processor suitable for communicating with the computer, some examples of which are disclosed above. In one embodiment, each computer is equipped with a network communication device, such as a network interface card, a modem, or other network connection device suitable for connecting to the network. An operating system is executed in each computer and device, some examples of which are disclosed above. Although the operating system may vary depending on the type of computer, the operating system will continue to provide the appropriate communication protocol to establish a communication link with the network. Any number and type of machines can communicate with the computer.

[0050] The present invention is not limited to a particular computer system platform, processor, operating system, or network. One or more aspects of the present invention may be distributed across one or more computer systems, such as a server configured to provide one or more services to one or more client computers or to perform a complete task in a distributed system. For example, according to various embodiments, one or more aspects of the present invention may be performed on a client-server system that includes components distributed across one or more server systems that perform multiple functions according to various embodiments. These components include, for example, executable code, intermediate code, or interpreted code that communicate over a network using a communication protocol. The present invention is not limited to being able to be performed in any particular system or group of systems, and is not limited to any particular distributed architecture, network, or communication protocol.

[0051] The foregoing embodiments are provided for illustrative purposes only and are in no way to be construed as limitations on the invention disclosed herein. Although the invention has been described with reference to various embodiments, it should be understood that the words used herein are descriptive and illustrative, not restrictive. Furthermore, although the invention has been described herein with reference to specific devices, materials, and embodiments, the invention is not limited to the details disclosed herein; on the contrary, the invention extends to all functionally equivalent structures, methods, and uses, for example, within the scope of the appended claims. Those skilled in the art, having benefit of the teachings of this specification, may make various modifications to the invention and may make variations without departing from the scope of the invention in all its aspects.

[0052] It should be noted that the term "comprising" does not exclude other elements or steps, and "a" or "an" does not exclude a plurality. Elements described with respect to different embodiments may be combined. It should also be noted that reference numerals in the claims should not be interpreted as limiting the scope of the claims. Although the present invention has been described and illustrated in detail through preferred embodiments, the present invention is not limited to the disclosed embodiments, and those skilled in the art may derive other variations therefrom without departing from the scope of the invention.

Claims

1. A method for state monitoring of a device, the method comprising determining an expected state or event of the device, acquiring sensor data under the expected state or event; and determining an indicator indicating the expected state or event. monitoring the indicator; sending instructions to one or more sensors associated with the device to trigger activation of the sensors when the desired state or event, as indicated by the indicator, has occurred; receiving data from said activated sensors; and, returning the sensor to a sleep mode after the data has been received from the sensor, wherein the indicator comprises a bit in a timing database.

2. The method according to claim 1, wherein The data received from the activated sensors are stored in the database.

3. The method according to claim 1, wherein The method further includes determining whether further data from the sensor is required based on the instruction, and if so, activating the sensor and receiving the further data before instructing the sensor to return to a sleep mode.

4. The method according to claim 1, wherein The desired state includes a state that is reached a predetermined number of times in one operation cycle.

5. A computer-implemented method for performing predictive maintenance of an industrial device, the method comprising performing condition monitoring according to any preceding claim; comparing data received from the activated sensors with stored reference data; And, if the result of the comparison indicates that maintenance or repair is required, a notification is sent.

6. A condition monitoring system for monitoring the condition of a device for fault diagnosis or predictive maintenance; the system comprises a plurality of components configured to perform the condition monitoring operation according to any one of claims 1 to 4, the components comprising a database and a memory for storing condition monitoring sensor data.

7. The system according to claim 6, wherein: The components include software components.

8. A system according to claim 6 or claim 7, wherein: The database includes a time series database.

9. The system according to claim 6, wherein: The system further includes reference data and a comparator for comparing the condition monitoring sensor data with the reference data.

10. The system according to claim 6, wherein: The system further includes one or more processors or cloud-based processing facilities configured to execute the plurality of software components.

11. The system according to claim 6, wherein: The system includes a multi-sensor data collection device for collecting device-specific status data for analysis.

12. The system according to claim 11, wherein The device includes a plurality of sensors for transmitting operating parameters, the plurality of sensors including a vibration sensor, a temperature sensor, or a speed sensor; a wireless communication module; and a battery.

13. A method for operating a multi-sensor data collection device, the multi-sensor data collection device comprising a plurality of sensors for transmitting operating parameters, the plurality of sensors comprising a vibration sensor, a temperature sensor or a speed sensor; a wireless communication module; and a battery, the method comprising receiving an instruction to trigger one or more of the sensors associated with the monitored device; when a determined or expected state or event of the device for which sensor data is to be acquired occurs, receiving the instruction in response to an indicator indicating that the expected state or event of the device has occurred, wherein the indicator comprises a bit in a timing database; and, after receiving the data from the sensor or each sensor, receiving an instruction in the same instruction or a subsequent instruction to return the sensor to sleep mode.

Images