CROSS REFERENCE TO RELATED APPLICATION

[0001] The present application claims the benefit of and priority, under 35 U.S.C. § 119(e), to U.S. Provisional Application Serial No. 62/488,577, filed April 21, 2017, entitled "Condition Monitoring System and Method," the entire disclosure of which is hereby incorporated herein by reference for all that it teaches and for all purposes.

FIELD

[0002] The present disclosure is generally directed to sensor systems, information reporting, and, in particular, toward methods and systems for intelligently monitoring and reporting conditions of objects.

BACKGROUND

[0003] Monitoring the operational health of objects or systems (e.g., motors, generators, etc.), especially those associated with performing industrial tasks, is very important because failure of such objects or systems can result in costly downtime. Some object failures may be so catastrophic that bodily injury could result. The difficulty with monitoring these objects or systems is that many production facilities have thousands to tens of thousands of objects that may require monitoring.

[0004] Further frustrating the problem is that there are many instances of object failure that cannot be predicted without using precise sensors. While remote sensing systems are currently available, there is a problem with deciding how much data to report, when to report the data, and so on. As can be appreciated, channels for a sensor network may become congested or unusable if sensors are reporting too much data too frequently to an analysis backend.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Fig. 1 is a block diagram of a condition monitoring system in accordance with embodiments of the present disclosure;

[0006] Fig. 2 is a block diagram depicting a sensor of the condition monitoring system in accordance with embodiments of the present disclosure;

[0007] Fig. 3 A is a first communication interaction diagram showing interaction between a sensor and a server of the condition monitoring system in accordance with embodiments of the present disclosure; [0008] Fig. 3B is a second communication interaction diagram showing interaction between a sensor and a server of the condition monitoring system in accordance with embodiments of the present disclosure;

[0009] Fig. 4 A is a flow diagram of a method for monitoring a condition of an object in accordance with embodiments of the present disclosure;

[0010] Fig. 4B is a flow diagram of a method for monitoring a condition of an object in accordance with embodiments of the present disclosure;

[0011] Fig. 5 is a flow diagram of a method for generating data by a sensor in a condition monitoring system in accordance with embodiments of the present disclosure;

[0012] Fig. 6 is a flow diagram of a method for storing and analyzing data received from a sensor in a condition monitoring system in accordance with embodiments of the present disclosure; and

[0013] Fig. 7 is a flow diagram of a method for generating a condition model for a sensor and object in a condition monitoring system in accordance with embodiments of the present disclosure.

[0014] In the appended figures, similar components and/or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label by a letter that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.

DETAILED DESCRIPTION

[0015] Embodiments of the present disclosure propose methods and systems that address the above-noted shortcomings. In particular, and with reference to the figures appended hereto, methods and systems are described for intelligently monitoring the condition of an object (e.g., any mechanical, electromechanical, electrical, or other type of device having one or more components that are susceptible to failure) and intelligently determining how much data about the object should be stored and/or reported to a remote analytics server for further processing. Examples of objects may include, but are in no way limited to, motors, bearings, rollers, conveyors, gearboxes, water pumps, and/or any other device that has one or more moving parts.

[0016] In some embodiments, the methods and systems provide a number of deployed sensors that are attached or mounted to, or near, monitored objects. Each of the sensors may collect motion information associated with a corresponding object. Depending on the operation type, the deployed sensors may include one or more read and report modes, speeds, and/or data output types. In any event, the sensors may report the collected data, via a wireless gateway, for processing by a remote analytics server. In one embodiment, machine learning calculations may be performed by the sensors using only peak-to-peak range of motion data at low-speed (e.g., 10 Hz) and/or high-speed (e.g., 800 Hz, 25kHz, etc.). These motion calculations may be transmitted from the sensor to the cloud (e.g., the remote analytics server, etc.) where the received motion data may be processed and analyzed utilizing machine learning, and/or artificial intelligence techniques. Among other things, processing the motion data received from a sensor over time can allow the remote analytics server to predict potential failures and/or determine a state of health associated with an object. Once a potential failure or wear condition is determined, the remote analytics server may send an alert to report the condition to a user. For instance, a notification, alarm, or similar messaging event may be conveyed from the remote analytics server to a communication device (e.g., smartphone, tablet, computer, etc.) of the user. In response, the user may take action to maintain (e.g., preventative maintenance, etc.) and/or repair the object before it fails, thereby avoiding otherwise costly downtime or injury.

[0017] With reference to Fig. 1, an illustrative system 100 will be described in accordance with at least some embodiments of the present disclosure. The system 100 is shown to include components of a sensor network as well as elements of a

communication/analytics network. Some of these components, such as the sensor network, may be installed at one or many facilities 102 in which monitored objects 108 are periodically or continuously under surveillance of one or more sensors 104. As can be appreciated, the objects 108 may be fixed or movable (e.g., a robot with moving parts, a vehicle, etc.). It should be appreciated that a single sensor 104 may be used to monitor conditions for a single object 108 or multiple objects 108. Similarly, a single object 108 may have multiple sensors 104 associated therewith. The sensors 104 may be used to monitor one or many parameters or conditions of the object 108. As a non-limiting example, sensors 104 may be used to monitor motion (e.g., rotational motion, linear motion, vibrational motion, etc., and/or combinations thereof), temperature, pressure, stress, strain, and/or any other aspect of an object 108. In some embodiments, a single sensor 104 may have multiple transducers for monitoring multiple aspects of an object 108. Alternatively, a single sensor 104 may have a single transducer, in which case multiple sensors 104 may be used to monitor different aspects or conditions of an object. [0018] As shown in Fig. 1, a plurality of sensors 104 may be in communication with a sensor gateway 112. As will be discussed in further detail herein, the communication protocol used to facilitate communications between the sensors 104 and sensor gateway 112 may include a wireless or wired protocol. In some embodiments, the sensors 104 may utilize one or more of a Bluetooth® protocol (e.g., Bluetooth® low energy (BLE) protocol), an 802.1 lx protocol (e.g., WiFi), a Zig-Bee protocol, a wireless personal area network protocol, or any other wireless communication protocol known or yet to be developed. One or more of the sensors 108 may be in a wired communication with the sensor gateway 112 using any type of known communication protocol such as an IP -based communication protocol, OSDP, S MP, etc.

[0019] The sensor gateway 112 provides a communication hub for the multiple sensors 104 deployed throughout the facility 102. In some embodiments, the sensor gateway 112 converts the data received from the sensors 104 into data packets that are capable of being transmitted over the communication network 124. The sensor gateway 112 may be connected to a network border element 120 that provides addressing functionality and/or further protocol conversion functionality. In some embodiments, the network border element 120 and sensor gateway 112 may be integrated into a single device rather than being deployed as separate device as shown in Fig. 1.

[0020] Although most examples of communications described herein will refer to the sensors 104 providing data to the sensor gateway 112 and then the sensor gateway 112 providing data to the network border element 120, it should be appreciated that communications can be bidirectional in the sensor network without departing from the scope of the present disclosure. Moreover, one or more sensors 104 may be enabled to communicate with another sensor using any type of known communication protocol. For instance, one or more commands may be sent to a sensor 104 causing the sensor 104 to perform a basic action (e.g., activate an LED, sound a buzzer, etc.).

[0021] The network of sensors 104 may be in communication with one or more analytics servers 128 and/or a broader communication network 124 via the network border element 120. For instance, the communication network 124 may utilize IP -based communication protocols whereas the sensor network utilizes communication protocols native to the sensors 104. The communication network 124 may comprise any type of known communication medium or collection of communication media and may use any type of protocols to transport messages between endpoints. The communication network

124 may include wired and/or wireless communication technologies. The Internet is an example of the communication network 124 that constitutes IP network consisting of many computers, computing networks, and other communication devices located all over the world, which are connected through many telephone systems and other means. Other examples of the communication network 124 include, without limitation, a standard Plain Old Telephone System (POTS), an Integrated Services Digital Network (ISDN), the Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Session Initiation Protocol (SIP) network, a Voice over Internet Protocol (VoIP) network, a cellular network, and any other type of packet-switched or circuit-switched network known in the art. In addition, it can be appreciated that the communication network 124 need not be limited to any one network type, and instead may be comprised of a number of different networks and/or network types. Moreover, the communication network 124 may comprise a number of different communication media such as coaxial cable, copper cable/wire, fiber-optic cable, antennas for

transmitting/receiving wireless messages, and combinations thereof.

[0022] In addition to providing protocol translation functions and addressing functions (e.g., Network Address Translation or NAT functions), the network border element 120 may also provide security functions for protecting the sensor network from external attacks. In particular, the network border element 120 may include one or more firewall components that help secure/protect the sensor network and components thereof from being accessed by untrusted computational devices. Additionally or alternatively, the network border element 120 may comprise address translation components to provide network address translation functions.

[0023] The analytics server(s) 128 may comprise one or more components that receive sensor information (e.g., acceleration data, position data, temperature data, vibration data, magnetic data, pressure data, etc.) from the sensor network and then correlate that sensor information to a particular object 108 or set of objects. The analytics server(s) 128 may have access to training/learning models 132, object data 136, and policies 140. The training/learning models 132 may enable the analytics server(s) 128 to determine whether a particular object 108 is exhibiting behaviors within an expected behavior range or outside of an expected behavior range. These models may be updated, validated, or trained from time to time. The object data 136 may correspond to specific sensor information stored in association with a particular object 108 at the facility. For instance, each object

108 may have a number of different aspects of its performance measured by one or many sensors. Those aspects may be stored in a database or the like to maintain a historical account of the object's 108 behavior over time. This data can be periodically accessed as part of building or training models 132 and/or in connection with determining whether a particular object 108 is about to experience a failure.

[0024] The policies 140 may be used by the analytics server 128 to help define how much sensor information should be obtained from the sensors 104, when such sensor information should be obtained, etc. Additionally or alternatively, the policies 140 may be used to determine when an alert, or notification, is sent from the analytics server(s) 128 to a client device 116. An alert, or notification, may correspond to a report or a more impactful activation of an alarm (e.g., sounding of a buzzer, lighting of a light, etc.) for transmission to one or more client devices 140 and/or to the sensors 104. The client device 116 may be connected to analytics server(s) 128 via the communication network 124 (although not necessarily required) and may receive the alerts, notifications, or alarms transmitted over the communication network 124. In some embodiments, the alerts, notifications, or alarms may be transmitted to the client device 116 using one or more web-based communication protocols (e.g., HTTP, email, SMS, etc.)

[0025] Referring now to Fig. 2, a block diagram depicting a sensor 104 is shown in accordance with embodiments of the present disclosure. The sensor 104, as discussed above, may correspond to any type of device or collection of devices capable of converting information about an object 104 (or an environment around an object 108) into an electrical signal (e.g., a voltage or current). The sensor 104 may also be capable of reporting the information measured about the object 108 to the sensor gateway 112. The sensor 104 may include one or more components, such as, a memory 204, a processor 208, an antenna 212A-N, a power supply 216, one or more transducers 220, and one or more output devices 224.

[0026] The memory 204 of the sensor 104 may be used in connection with the execution of application programming or instructions by the processor 208, and for the temporary or long term storage of program instructions and/or data. The memory 204 may contain executable functions that are used by the processor 208 to run other components of the sensor 104. In one embodiment, the memory 204 may be configured to store sensing data

228 (e.g., data obtained from transducer(s) 220) prior to the sensor 104 actually reporting the sensing data 228 to the analytics server 128. For instance, the sensing data 228 may include temperature information, pressure information, acceleration information, position information, velocity information, stress information, strain information, etc. This information may be stored in the form of a voltage or current reading or it may be converted back into the appropriate format. For instance, the temperature information can be stored as a raw voltage received from a temperature transducer 220 or it may be stored as an actual representation of temperature (e.g., in degrees Celsius or Fahrenheit). In some embodiments, the memory 204 may comprise volatile or non-volatile memory and a controller for the same. Non-limiting examples of memory 204 that may be utilized in the sensor 104 include RAM, ROM, buffer memory, flash memory, solid-state memory, combinations thereof, or variants thereof.

[0027] The processor 208 may correspond to one or many microprocessors that are contained within the housing of the sensor 104 with the memory 204. In some

embodiments, the processor 208 incorporates the functions of the user device's Central Processing Unit (CPU) on a single Integrated Circuit (IC) or a few IC chips. The processor 208 may be a multipurpose, programmable device that accepts digital data as input, processes the digital data according to instructions stored in its internal memory, and provides results as output. The processor 208 implements sequential digital logic as it has internal memory. As with most known microprocessors, the processor 208 may operate on numbers and symbols represented in the binary numeral system.

[0028] The one or more antennas 212A-N may be configured to enable wireless communications between the sensor 104 and a sensor gateway 112, or with other sensors 104. As can be appreciated, the antenna(s) 212A-N may be arranged to operate using one or more wireless communication protocols and operating frequencies including, but not limited to, Bluetooth®, NFC, Zig-Bee, GSM, CDMA, WiFi, RF, and the like. By way of example, the antenna(s) 212A-N may be RF antenna(s), and as such, may transmit RF signals through free-space to be received by a reading device having an RF transceiver. One or more of the antennas 212A may be driven or operated by a dedicated antenna driver 214.

[0029] The power module 216 may be configured to provide power to the parts of the sensor 104 in order to operate. The power module may store power in a capacitor of the power module. In one embodiment, the sensor 104 may provide its own power. For example, the power module 216 may include a battery or other power source to supply power to parts of the sensor 104. The power module 216 may include a built-in power supply (e.g., one or more batteries, battery cells, capacitors, etc., and/or the like) and/or a power converter that facilitates the conversion of externally-supplied AC power into DC power that is used to power the various components of the sensor 104. In some embodiments, the power module 216 may also include some implementation of surge protection circuitry to protect the components of the sensor 104 from power surges.

[0030] The transducers 220 may include any type of component that is capable of detecting a physical property of an object or of an environment around an object and then converting that physical property into a voltage or current. The types of transducers 220 incorporated into the sensor 104 may depend upon the type of properties that are going to be measured for the object 108. Light transducers, capacitive transducers, inductive transducers, magnetic transducers, and any other type of transducer device can be used without departing from the scope of the present disclosure. A transducer 220 may also include a GPS system or some other device that is capable of determining an absolute or relative position of the sensor 104. Examples of the transducers 220 may include, but are in no way limited to, accelerometers, strain gauges, stress gauges, gyroscopes,

photoelectric sensors, optical encoders, ultrasonic proximity sensors, etc., and/or combinations thereof.

[0031] As can be appreciated, the sensors 104 may be attached or affixed to an object 108, thereby enabling the sensor 104 to measure an aspect of an object. For instance, a motion of the object 108 may be measured by an accelerometer or gyroscope embedded in a sensor 104. That motion can then be reported by the sensor 104 back to the sensor gateway 112. This information can be reported via the antenna 212A or multiple antennas. As will be discussed in further detail herein, the frequency with which such sensing data 228 is reported and the amount of data that is reported may depend upon a determined state of the object 108 and whether or not the analytics server(s) 128 believe that an object 108 is possibly at risk of imminent failure or is progressing out of a normal operational condition.

[0032] In some embodiments, the sensor 104 may include one or more simple user output devices 224. Suitable types of output devices 224 include, without limitation, lights, buzzers, speakers, etc. The output devices 224 may be used to help signal an alert in connection with an object 108, if desired.

[0033] With reference now to Figs. 3 A-7, additional details of condition monitoring methods will be described in accordance with at least some embodiments of the present disclosure. In some embodiments, low-speed sensor readings may be aggregated at the sensor or gateway and reported on a periodic basis to the server(s) 128 as long as the object 108 is determined to be operating within one of a few defined models. Each of the defined models may correspond to a different expected operational condition for the object 108 and may, therefore, have different operating parameters (e.g., motion, temperature, pressure, etc.) associated therewith. For instance, four models may be defined that include a stop operational condition, a low motion operational condition, a mid-motion operational condition, and a high-speed operational condition. As long as sensing data 228 indicates that the object 108 is operating within conformance with one of these defined models, then the sensor(s) 104 associated with that object 108 will only report their data using a low- bandwidth communication channel and the reporting of such data will only occur at a first frequency. As an example, the sensors 104 may report their data using a non-connected Bluetooth® protocol, which only utilizes BLE channels 37, 38, and 39. The payload transmitted by the sensor 104 while operating in this mode may be relatively small as compared to payloads that are allowable using a connected Bluetooth® protocol.

However, since the object 108 is determined to be operating as expected, then the decision is made to conserve otherwise limited bandwidth in the sensor network for other sensors.

[0034] It may be possible to also run the high-speed sensor readings on a scheduled or predetermined basis. Thus, the sensor 104 will operate in the low-speed mode unless: (1) it is time to implement a prescheduled high-speed sensor read process or (2) the low-speed sensor read process identified a deviation away from expected behaviors (e.g., a motion of the object 108 outside of expected motion characteristics, etc.).

[0035] High-speed raw data sensor readings may also be provided back to the analytics server(s) 128 on a more frequent basis as compared to the periodic basis associated with the low-speed sensor reading mode (e.g., in the form of data streamed by the sensor 104). For instance, if an object 108 is determined to not be operating within one of the defined models then the analytics server(s) 128 may instruct the sensor 104 to begin transmitting data in a stream over a higher bandwidth connection, which may correspond to a different physical communication pathway. As a non-limiting example, the sensor 104 may begin transmitting to the sensor gateway 112 using a connected Bluetooth® protocol, which utilizes BLE channels 1-40 and has a higher payload than the non-connected Bluetooth® channel. In some embodiments, only certain types of sensing data may be reported in this connected mode. For example, unprocessed high-frequency motion data may only be reported during the connected mode of operation whereas that data is not transmitted by the sensor 104 in the non-connected mode of operation due to the increased energy usage, larger payload, and bandwidth required to transmit such data.

[0036] Figs. 3 A-3B show communication interaction flow diagrams illustrating an interaction between a sensor 104 and an analytics server 128 of the system 100 in accordance with embodiments of the present disclosure. The sensor 104 and the analytics server 128 may operate as shown and described in conjunction with Figs. 3A-3B and/or the methods described in conjunction with Figs. 4-7.

[0037] In some embodiments, mounted sensors 104 can generate data in at least two formats. The first format of generated data may be referred to herein as "edge features" and the second format of generated data may be referred to herein as "raw data." The edge features may correspond to substantially aggregate statistical metrics calculated on the sensor 104 from data collected by the sensor 104. The calculated metrics may be advertised and/or broadcast over a wireless communication protocol (e.g., BLE, etc.) to a sensor gateway 112 and stored by an analytics server 128. In one embodiment, the raw data may require a direct wireless communication connection (e.g., direct Bluetooth® connection, etc.) between the sensor 104 and the sensor gateway 112. The raw data may correspond to a full waveform of data with no processing done to the data by the sensor 104 prior to streaming the raw data to the sensor gateway 112. Because the raw data stream is more energy intensive than the edge features communication, the raw data may be made on-demand (e.g., based on a condition determined by the analytics server 128 from the edge features received, etc.) and/or according to an interval that is less frequent than the interval associated with the edge features (e.g., an interval of days or weeks for raw data and an interval of seconds or minutes for edge features).

[0038] The edge feature data may be collected and aggregated for low-speed (e.g., 10 Hz) and/or high-speed (e.g., 800 Hz, 25kHz, etc.) sensor data reads. As shown in Figs. 3A- 3B, the sensor 104 performs the low-speed sensor read in step 304 and then calculates the aggregate metrics in step 308. As described herein, the motion of an object 108 may be studied in all three axes (e.g., the X-axis, Y-axis, and Z-axis) using root mean square (RMS), peak-to-peak, providing an entire range of motion for an object 108. The aggregate metrics may be communicated from the sensor 104 to the analytics server 128, by way of the sensor gateway 1 12, in communication 310. The analytics server 128 may store the low-speed aggregate metrics in a memory (e.g., object data 136, etc.) of the system 100 in step 324.

[0039] In some embodiments, the high-speed edge features may be collected based on an interval timing or other triggering event. As illustrated in Fig. 3 A, the sensor 104 performs the high-speed sensor read in step 312 and then calculates the aggregate metrics of the high-speed data in step 316. These aggregate metrics may be communicated from the sensor 104 to the analytics server 128, by way of the sensor gateway 112, in communication 318. Upon receiving the aggregate metrics calculated at step 316, the analytics server 128 may begin processing the data by comparing the high-speed aggregate metrics to one or more learned models at step 328.

[0040] Next, the analytics server 128 may determine if an anomaly is present (e.g., based on the comparison made, etc.) at step 332. An anomaly may correspond to a behavior or motion of the object that does not substantially match, or fit within, a learned behavior or motion associated with the object. In some embodiments, the analytics server 128 may employ a fault detection algorithm, using the high-speed edge features calculated by the sensor 104, to determine if there is a change in vibration state associated with the object 108. In any event, if no anomaly is determined, the analytics server 128 may store the high-speed aggregate metrics in a memory (e.g., object data 136, etc.) of the system 100 in step 336. In the event that an anomaly is determined to be present in step 332, the analytics server 128 may store the high-speed aggregate metrics in memory and proceed to send an alert regarding the anomaly in step 340. In some embodiments, the alert may be a notification or alarm sent to a client device 116. In one embodiment, the analytics server 128 may refer to one or more policies 140 to determine how much time should elapse before an alert is issued. For example, it may be desirable to require up to N days (e.g., 7 days) of motion learning for the object 108 under the one or more of the sensor modes (e.g., low-speed and/or high-speed edge features, and/or high speed raw data, etc.) before an alert is issued. This approach can help avoid alerting on false negatives and it can also develop a larger data set for inclusion with a report that may be provided in parallel with an alert.

[0041] Additionally or alternatively, in response to determining an anomaly is present, the analytics server 128 may schedule a high-speed raw data read by the sensor 104 in step 344. This instruction may be sent (e.g., as a message, etc.) to the sensor 104 from the analytics server 128 in communication 346.

[0042] Upon receiving the communication 346 from the analytics server 128, the sensor 104 may proceed to stream raw data via a direct (e.g., Bluetooth®) connection with the sensor gateway 112 and then to the analytics server 128 along communication 322. As provided above, the raw data is a full waveform of data with no processing done to it by the sensor 104. When the raw data is received by the analytics server 128, the analytics server 128 may store the high-speed raw data in memory in step 348 and perform advanced diagnostics processing at step 352. The advanced diagnostics processing may further identify a severity of the anomaly, a type of anomaly, and/or determine a state of health for the object 108.

[0043] In one embodiment, the sensor 104 may be configured to collect and transmit high-speed edge features only when the sensor 104 senses motion. For instance, as illustrated in Fig. 3B, the sensor 104 may detect motion using the low-speed edge features calculated in step 308. In the event that motion is determined to be present in step 314, the sensor 104 may then initiate the high-speed sensor read at step 312. In some embodiments, the sensor 104 may compare collected range of motion data over time to determine changes indicating motion of the object. The remaining interactions between the sensor 104 and the analytics server 128 may be the substantially the same as described above.

[0044] Fig. 4A is a flow diagram of a method 400A for monitoring a condition of an object 108 in accordance with embodiments of the present disclosure. While a general order for the steps of the method 400A is shown in Fig. 4A, the method 400A can include more or fewer steps or can arrange the order of the steps differently than those shown in Fig. 4A. Generally, the method 400A starts with a start operation 402 and ends with an end operation 444. The method 400A can be executed as a set of computer-executable instructions executed by a computer system (e.g., the sensor 104, analytics server 128, processor 208, etc.) and encoded or stored on a computer readable medium (e.g., memory 204, etc.). Hereinafter, the method 400A shall be explained with reference to the systems, components, devices, environments, methods, etc. described in conjunction with Figs. 1- 3B.

[0045] The method 400A begins at step 402 and proceeds by performing an edge features sensor read process (e.g., in low-speed and high-speed as the sensor 104 is configured) (step 404). As discussed above, in the low-speed mode of operation, the sensor 104 is not reporting its sensing data 228 on a continuous basis. Accordingly, the sensor data 228 may be aggregated and stored in local memory 204 and only reported, advertised, or broadcast to the sensor gateway 112 on a periodic basis using a low- bandwidth communication channel (e.g., reporting in a non-connected Bluetooth® channel) (step 408). As data (e.g., aggregated data, statistical metrics, etc.) is reported, the analytics server 128 will receive the sensing data (perhaps not all of the sensing data that was originally captured by the sensor 104) and may store the data in memory and/or determine a state of the object 108 (step 412).

[0046] If the object 108 is determined to be operating in an expected state (or at least within some tolerance of an expected state) (step 416), then the method 400 A will continue to allow the sensor 104 to operate in the edge features sensor read process (step 404). On the other hand, if it is determined that the object 108 is exhibiting one or more unexpected behaviors, or has one or more unexpected parameters, that deviates from a condition model the method 400 A proceeds by causing the sensor 104 to begin a highspeed raw data sensor read process (step 420). The sensor 104 will continue to store its sensing data 228, but the sensing data 228 will be reported at a higher frequency and/or continuously (step 424). Moreover, additional data that was not being reported during the first sensor read (e.g., the low or high-speed aggregate sensor read process) may be reported during the high-speed raw data sensor read process. During the high-speed raw data read process, the sensor 104 may communicate unprocessed raw data (e.g., motion data, sensor data, etc.) with the analytics server 128 over a dedicated direct wireless communication link (e.g., not the advertising or broadcast communication for the aggregate edge features data). The method 400 A may end at step 422 and/or proceed by performing further processing as described herein.

[0047] Fig. 4B is a flow diagram of a method 400B for monitoring a condition of an object 108 in accordance with embodiments of the present disclosure. In some

embodiments, the method 400B may correspond to the determining of the object state described in conjunction with steps 412-416 of Fig. 4A. While a general order for the steps of the method 400B is shown in Fig. 4B, the method 400B can include more or fewer steps or can arrange the order of the steps differently than those shown in Fig. 4B. Generally, the method 400B starts with a start operation 424 and ends with an end operation 444. The method 400B can be executed as a set of computer-executable instructions executed by a computer system (e.g., the sensor 104, analytics server 128, processor 208, etc.) and encoded or stored on a computer readable medium (e.g., memory 204, etc.). Hereinafter, the method 400B shall be explained with reference to the systems, components, devices, environments, methods, etc. described in conjunction with Figs. 1-4A.

[0048] The method 400B begins at step 424, which may correspond to step 404 or step

408 of Fig. 4 A, and proceeds by reporting the sensor-calculated aggregate metrics to the analytics server 128 (step 428). In some embodiments, the analytics server 128 may receive the sensing data 228 from the sensor 104 collected during a high-speed edge features sensor read process. The analytics server 128 may determine a state of the object

108 and compare that state to models of expected behaviors (step 432). These models may include condition models created based on a previously-monitored behavior of the object

108 over time that define a normal behavior, or operating fingerprint, for the object 108. This comparison may occur the analytics server 128 and, in some cases, may not occur at the sensor 104.

[0049] The method 400B may further continue by logging results of the comparison, logging results of the determine object state, and any other relevant information (e.g., a time at which the comparison was made, other conditions related to the event, etc.) (step 436). If a predetermined amount of time has passed (or a predetermined number of bad readings have been logged) and the object 108 continues to operate outside of a defined model behavior, then the method 400B may proceed with the analytics server 128 issuing an alert or the like to the client device 116 (step 440). The method 400 may end at step 444.

[0050] Fig. 5 is a flow diagram of a method 500 for generating data by a sensor 104 in a condition monitoring system 100 in accordance with embodiments of the present disclosure. While a general order for the steps of the method 500 is shown in Fig. 5, the method 500 can include more or fewer steps or can arrange the order of the steps differently than those shown in Fig. 5. Generally, the method 500 starts with a start operation 502 and ends with an end operation 536. The method 500 can be executed as a set of computer-executable instructions executed by a computer system (e.g., the sensor 104, processor 208, etc.) and encoded or stored on a computer readable medium (e.g., memory 204, etc.). Hereinafter, the method 500 shall be explained with reference to the systems, components, devices, environments, methods, etc. described in conjunction with Figs. 1-4B.

[0051] The method 500 begins at step 502 and proceeds by performing a low-speed (edge features) sensor read operation (step 504). The low-speed sensor read operation may correspond to generating edge features data for an object 108 using low-speed sensor reading. This step (504) may be substantially similar, if not identical, to the low-speed sensor read of step 304 described in conjunction with Figs. 3A-3B. The low-speed sensor reads may be made continually by the sensor 104 at a predetermined rate of speed, for example, in cycles per second.

[0052] Next, the method 500 continues by storing sensor readings in local memory 204 and reporting the sensor readings to the analytics server 128 (step 508). In some embodiments, this step may include calculating aggregate metrics using the data collected from the low-speed read operation of step 504. In any event, this information may be wirelessly communicated to the analytics server 128 by the sensor 104 in step 508. The low-speed calculated aggregate metrics may be advertised or broadcast by the sensor 104, for example, to a sensor gateway 112. Among other things, this type of communication does not require a dedicated connection (e.g., wired or wirelessly) to the sensor 104. Once received by the sensor gateway 112, the low-speed calculated aggregate metrics may be forwarded to the analytics server 128 where it is stored in memory.

[0053] As provided in Figs. 3A-3B, the sensor 104 may operate in an edge features mode and a raw data mode. In the edge features mode, the sensor 104 may perform low- speed sensor reads (304) and, on occasion, high-speed sensor reads (312). Fig. 3 A illustrates an interaction between the sensor 104 and the analytics server 128 where the sensor 104 performs high-speed sensor reads based on a timed interval (e.g., based on a clock, counter, etc., that is internal to the sensor 104). Fig. 3B illustrates an interaction between the sensor 104 and the analytics server 128 where the sensor 104 performs highspeed sensor reads in response to determining, based on the low-speed aggregate metrics calculation, that motion of the object 108 has been detected. In both cases, the sensor 104 performs the high-speed sensor read only when a high-speed operating condition is met (step 512). The high-speed operating condition to be met in Fig. 3 A is a timed interval, and the high-speed operating condition to be met in Fig. 3B is detected motion, at step 314. In either case, if the high-speed operating condition has not been met, the method 500 may return to step 504.

[0054] Once the high-speed operating condition has been met, as determined in step 512, the method 500 may proceed to perform the high-speed (edge features) sensor read operation (step 516). The high-speed sensor read operation may correspond to generating edge features data for an object 108 using high-speed sensor reading. This step (516) may be substantially similar, if not identical, to the high-speed sensor read of step 312 described in conjunction with Figs. 3A-3B. The high-speed sensor reads may be made continually (for a period of time) by the sensor 104 at a predetermined rate of speed, for example, in cycles per second. As can be appreciated, the high-speed sensor reads are made at a greater rate of speed than the low-speed sensor reads performed in step 504. Because the high-speed sensor reads consume more energy and produce more data than the low-speed sensor reads performed by the sensor 104, the high-speed sensor reads are reserved for the timed interval condition or the motion detection condition. It should be appreciated that a sensor 104 may be allowed to operate in both a timed interval and motion detection state.

[0055] The method 500 continues by storing sensor readings in local memory 204 and reporting the sensor readings to the analytics server 128 (step 520). In some embodiments, this step may include calculating aggregate metrics using the data collected from the highspeed read operation of step 516. In any event, this information may be wirelessly communicated to the analytics server 128 by the sensor 104 in step 520. Similar to the low-speed metrics, the high-speed calculated aggregate metrics may be advertised or broadcast by the sensor 104 to a sensor gateway 112. As provided above, this type of communication does not require a dedicated connection (e.g., wired or wirelessly) to the sensor 104. Once received by the sensor gateway 112, the high-speed calculated aggregate metrics may be forwarded to the analytics server 128 where it is stored in memory and processed.

[0056] Depending on the results of the processing by the analytics server 128, the method 500 may receive a high-speed raw data read command at step 524. For example, the analytics server 128 may compare the high-speed edge features to a learned model as described in step 328 of Figs. 3A-3B and step 612 of Fig. 6. In any event, when an anomaly is determined by the analytics server 128, or the motion behavior, or fingerprint, of the object 108 falls outside of a predetermined threshold, the analytics server 128 may schedule a raw data collection connection with the sensor 104 (e.g., as described in step 344 of Figs. 3A-3B). In the event that a raw data collection command is received from the analytics server 128, the method 500 may proceed by performing the high-speed raw data read (step 528).

[0057] In some embodiments, performing the high-speed raw data read operation may include establishing a direct wireless communication link between the sensor 104 and the analytics server 128 that is different from the advertising or broadcast communication of data from the edge features (low or high-speed). Over the direct wireless communication link, the sensor 104 may continuously stream raw data to the analytics server 128 (step 532). The raw data may correspond to high-speed reading of range of motion information and/or other transducer 220 information associated with the monitored object 108. This raw data may be streamed to the analytics server 128, by the sensor 104, without any processing of the raw data performed by the sensor 104. The analytics server 128 may perform advanced processing of the streamed raw data, in real-time, to diagnose the condition of the monitored object 108 as described in conjunction with step 352 of Figs. 3A-3B and step 640 of Fig. 6. In one embodiment, the streamed raw data may be stored, or logged, in a memory associated with the analytics server 128.

[0058] The sensor 104 may be commanded to cease streaming raw data by the analytics server 128. In one embodiment, the sensor 104 may continue to provide the stream until the sensor 104 has consumed all the power in the power supply 216. The method 500 may end at step 536.

[0059] Fig. 6 is a flow diagram of a method 600 for storing and analyzing data received from a sensor 104 in a condition monitoring system 100 in accordance with embodiments of the present disclosure. More specifically, the method 600 may correspond to operations performed by the analytics server 128 upon receiving data from the sensor 104. While a general order for the steps of the method 600 is shown in Fig. 6, the method 600 can include more or fewer steps or can arrange the order of the steps differently than those shown in Fig. 6. Generally, the method 600 starts with a start operation 602 and ends with an end operation 644. The method 600 can be executed as a set of computer-executable instructions executed by a computer system (e.g., the analytics server 128, etc.) and encoded or stored on a computer readable medium (e.g., analytics server 128 memory, training/learning models 132, object data 136, policies 140, etc.). Hereinafter, the method 600 shall be explained with reference to the systems, components, devices, environments, methods, etc. described in conjunction with Figs. 1-5.

[0060] The method 600 begins at step 602 and proceeds upon receiving data from a sensor 104 in the system 100. For example, the method 600 may store aggregated metrics calculated by a sensor 104 in a low-speed edge features operational read mode (step 604). In some embodiments, the information included in the received aggregated metrics may be used, by the analytics server 128, to establish a baseline behavior for the particular object 108 associated with the sensor 104. The aggregated metrics may be stored in a memory associated with the analytics server 128.

[0061] In some embodiments, the method 600 may receive high-speed aggregate metrics calculated by the sensor 104 (step 608). The high-speed aggregate metrics may correspond to the calculations made by the sensor 104 in step 316 of Figs. 3A-3B.

[0062] Upon receiving the high-speed aggregate metrics, the analytics server 128 may compare the information in the high-speed aggregate metrics to one or more learned models in training/learning models 132. As described herein, the analytics server 128 may be trained to recognize acceptable patterns, behaviors, and/or motion profiles associated with a "healthy" and "unhealthy" object 108. During training, the analytics server 128 may receive continuous motion and/or other data from a sensor 104 associated with a monitored object 108 for a period of time. This training allows the analytics server 128 to

"learn" and recognize normal operating behaviors of the monitored object 108. In some embodiments, the data obtained from the sensor 104 during training may be presented to a classifier algorithm for training/machine learning. Classifier algorithms may include, but are in no way limited to, algorithms used in an artificial neural network (ANN), Support Vector Machine (SVM), a Logistic Regression (LR) model, or Random Forest (RF) model, which may be used separately or in combination with one another.

[0063] Based on the learned model, the method 600 may determine whether an anomaly, or deviation from the learned model, exists (step 616). If the comparison provides a result that falls within acceptable predetermined thresholds, the method 600 may proceed by storing the high-speed aggregate metrics and/or the result of the comparison in a memory of the analytics server 128 (step 620). If the comparison provides a result that falls outside of the acceptable predetermined thresholds (e.g., indicating an anomaly is present), the method 600 may proceed by storing the high-speed aggregate metrics and/or the result of the comparison in a memory of the analytics server 128 (step 624) and proceed to sending an alert regarding the anomaly.

[0064] The method 600 may continue by sending an alert from the analytics server 128 to a client device 116 of the system 100 (step 628). The alert may be sent as a notification, a message, an alarm, etc., and/or combinations thereof. In some embodiments, the alert may include information about the anomaly, the sensor 104, the object 108, etc. In one embodiment, the alert may include information that can be used to schedule a maintenance and/or repair operation for the object 108. The alert may be rendered to a screen of the client device 116, played as an audible tone, and/or produce a haptic feedback from the client device 116. It is an aspect of the present disclosure that the alert may be sent as a text message, multimedia messaging service (MMS), email, instant message, and/or other message between endpoints in a communication network. Additionally or alternatively, the alert may be sent from the analytics server 128 to multiple client device 116 registered with the analytics server 128.

[0065] Next, the method 600 may proceed by sending an instruction to the sensor 104 to begin performing a high-speed raw data read mode of operation (step 632). This instruction may cause the sensor 104 to operate as described in step 528 of Fig. 5. In some embodiments, the instruction may cause a direct communication link to be established between the sensor 104 and the analytics server 128 (e.g., by way of the sensor gateway 112, etc.).

[0066] The analytics server 128 may receive and store the high-speed raw data streamed from the sensor 104 to the analytics server 128 in step 636. In addition, the analytics server 128 may perform advanced processing of the raw data received (e.g., as it is received, etc.) to, among other things, diagnose the anomaly associated with the sensor 104 detected by the analytics server 128 (step 640). The diagnostics performed by the analytics server 128 may determine a state of health associated with the object 108 that is monitored by the sensor 104 generating the data. The diagnostics may include determining an expected time to failure, a severity of the anomaly, a type of the anomaly, and/or other information associated with the anomaly. In some cases, this information may be communicated by the analytics server 128 to a client device 116. Additionally or alternatively, the information may include maintenance information, a suggested maintenance or repair type, a suggested time to maintain or repair the object 108, and/or any other information that can be used to return the object 108 to a normal operating state.

[0067] In some embodiments, the advanced, or further, processing may include monitoring deltas and changes in monitored data over time, an amount of time to heat, a cooling time, and then analyze the temperature phase (e.g., distance between peaks) to determine how long it takes to heat/cool. In one embodiment, a temperature profile associated with an object may be analyzed to determine a condition of the monitored object. For example, tracking changes in temperature that differ from day-to-day, week-to- week, etc., may provide predictive data that the remote analytics server can use in determining whether an object is about to fail. The method 600 may end at step 644.

[0068] Fig. 7 is a flow diagram of a method 700 for generating a condition model for a sensor 104 and a corresponding monitored object 108 in a condition monitoring system 100 in accordance with embodiments of the present disclosure. In some embodiments, the method 700 may be performed by the analytics server 128 and/or another computer system to update a condition model for a particular object 108 in the system 100. While a general order for the steps of the method 700 is shown in Fig. 7, the method 700 can include more or fewer steps or can arrange the order of the steps differently than those shown in Fig. 7. Generally, the method 700 starts with a start operation 702 and ends with an end operation 740. The method 700 can be executed as a set of computer-executable instructions executed by a computer system (e.g., the analytics server 128, client device 116, etc.) and encoded or stored on a computer readable medium (e.g., analytics server 128 memory, training/learning models 132, object data 136, policies 140, etc.). Hereinafter, the method 700 shall be explained with reference to the systems, components, devices, environments, methods, etc. described in conjunction with Figs. 1-6.

[0069] The method 700 begins at step 702 and proceeds by generating summary packets per aggregation window for low-speed sensor data (step 704). In some embodiments, one summary packet may be generated per aggregation window. The method 700 may also generate summary packets per aggregation window for high-speed sensor data collected by the sensor 104 (step 708).

[0070] Next, the method 700 may continue by generating an acceleration summary using the peak values, peak-to-peak values, RMS values, etc. (step 712). In some embodiments, these values may be used to create policies and/or alerts for specific occurrences. The policies and alerts may be created for occurrences where the actual motion of a motor is different than its fingerprint. Alerts may be created when a new value exceeds the modeled values. In some cases, the policies may provide an alert when a motion level of a monitored object 108 is growing according to a trend over time. In these instances, alerts may be created when there is a trend line of exceeding values over time.

[0071] The method 700 may continue by comparing the acceleration summary to conditions in a condition model service (step 716). In one embodiment, the condition model service may correspond to a repository for storing one more condition models for an object 108. In some cases, the condition models in the condition model service may be associated with a particular object 108 in the system 100. If no condition model is determined to be available in step 720, the method 700 may end. In a condition model is determined to be available, the method 700 may proceed to determine whether the available condition model has been completed (step 724). In some embodiments, determining whether the condition model has been completed may include determining whether enough data has been collected to train the analytics server 128 about the fingerprint or behavior of the object 108. If the condition model is complete, the method 700 may end at step 740.

[0072] The method 700 proceeds when the analytics server 128 determines that the condition model is incomplete by updating the condition model with the summary packet data (step 728). Once the training interval or time period is reached, the method 700 may continue to complete the condition model (step 736). The completed condition model may be stored in the condition model service or training/learning models 132 repository. The method 700 may end at step 740.

[0073] The exemplary systems and methods of this disclosure have been described in relation to monitored objects in a facility. However, to avoid unnecessarily obscuring the present disclosure, the preceding description omits a number of known structures and devices. This omission is not to be construed as a limitation of the scope of the claimed disclosure. Specific details are set forth to provide an understanding of the present disclosure. It should, however, be appreciated that the present disclosure may be practiced in a variety of ways beyond the specific detail set forth herein.

[0074] Furthermore, it should be appreciated that the various links connecting the elements can be wired or wireless links, or any combination thereof, or any other known or later developed element(s) that is capable of supplying and/or communicating data to and from the connected elements. These wired or wireless links can also be secure links and may be capable of communicating encrypted information. Transmission media used as links, for example, can be any suitable carrier for electrical signals, including coaxial cables, copper wire and fiber optics, and may take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.

[0075] Also, while the flowcharts have been discussed and illustrated in relation to a particular sequence of events, it should be appreciated that changes, additions, and omissions to this sequence can occur without materially affecting the operation of the disclosed embodiments, configuration, and aspects.

[0076] A number of variations and modifications of the disclosure can be used. It would be possible to provide for some features of the disclosure without providing others. For instance, the sensor 104 may include a number of different transducers 220 including, but in no way limited to, temperature, accelerometer, magnetometer, etc. In any event, the accelerometer may be split into various operational modes. In one embodiment, an operational mode may include a motion mode configured to determine when an object 108 is moving or not moving. Motion counters may be in three axes and can be used to define motion along the axes (e.g., six directions) or about the axes (e.g. rotation). In some embodiments, each direction may have a different count value. The motion information may be transmitted with each sensor 104 transmission, for example, in the form of a count value. Another operational mode may include low frequency/vibration where the accelerometer can transmit acceleration values for all three axes and/or send other readings from the accelerometer. Yet another operational mode may include a high frequency mode that only transmits on a directly-connected communication link.

[0077] In some embodiments, the cloud/analytics server 128 makes an automatic signature of motion from received low-speed information. Multiple motion signatures

(RMS, peak-to-peak, etc.) may be received from the sensor 104 for different periods of time. Each peak-to-peak and RMS (defines the energy) over a defined time can be defined for a number of buckets (e.g., stopped, low-speed, medium-speed, and/or heavy load operation, etc.). Every time the machine runs, you go into a loop and see if the machine fits into any of its defined signatures. If it is outside of its norms for low speed, then it will connect and start looking at high speed (in a connected state)

[0078] In some embodiments, for example, over the high-speed raw data connection, the sensor gateway 1 12 may only be able to connect to a limited number of sensors 104 (e.g., one or two at a time) based on bandwidth constraints. When in the high-speed raw data connection, another set of profiles for each operating condition may be provided that is different from the low-speed communication conditions and/or profiles.

[0079] The analytics server 128 may analyze the received raw data and based on the analysis decide whether the low-speed model is not functional, if an abnormality exists (and if so raise a flag, not an alert yet). After continuing to observe the behavior, an alert may be issued by the analytics server 128 only after multiple flags are raised. Among other things, it may be disadvantageous to alert too quickly. In some embodiments, the sensors 104 may be connected, mounted, or otherwise attached to an object 108 using adhesive pads disposed on the sensors 104 (e.g., stickers, double-sided tape, etc.).

[0080] In some embodiments, high-speed reads either in raw data or edge feature operation may be scheduled for one or more intervals (e.g., for once a day or once every other period, etc.). In one embodiment, temperature data may be tied with acceleration data. Using the heat can be important because when heat increases, an observed object 108 (e.g., motor, etc.) may be about to fail, and in some cases, quickly and/or catastrophically. As can be appreciated, the present disclosure provides a number of methods and systems to identify these problems in advance with the accelerometer before a catastrophic failure occurs.

[0081] In yet another embodiment, the systems and methods of this disclosure can be implemented in conjunction with a special purpose computer, a programmed

microprocessor or microcontroller and peripheral integrated circuit element(s), an ASIC or other integrated circuit, a digital signal processor, a hard-wired electronic or logic circuit such as discrete element circuit, a programmable logic device or gate array such as PLD,

PLA, FPGA, PAL, special purpose computer, any comparable means, or the like. In general, any device(s) or means capable of implementing the methodology illustrated herein can be used to implement the various aspects of this disclosure. Exemplary hardware that can be used for the disclosed embodiments, configurations and aspects includes computers, handheld devices, telephones (e.g., cellular, Internet enabled, digital, analog, hybrids, and others), and other hardware known in the art. Some of these devices include processors (e.g., a single or multiple microprocessors), memory, nonvolatile storage, input devices, and output devices. Furthermore, alternative software

implementations including, but not limited to, distributed processing or component/object distributed processing, parallel processing, or virtual machine processing can also be constructed to implement the methods described herein.

[0082] In yet another embodiment, the disclosed methods may be readily implemented in conjunction with software using object or object-oriented software development environments that provide portable source code that can be used on a variety of computer or workstation platforms. Alternatively, the disclosed system may be implemented partially or fully in hardware using standard logic circuits or VLSI design. Whether software or hardware is used to implement the systems in accordance with this disclosure is dependent on the speed and/or efficiency requirements of the system, the particular function, and the particular software or hardware systems or microprocessor or

microcomputer systems being utilized.

[0083] In yet another embodiment, the disclosed methods may be partially implemented in software that can be stored on a storage medium, executed on programmed general- purpose computer with the cooperation of a controller and memory, a special purpose computer, a microprocessor, or the like. In these instances, the systems and methods of this disclosure can be implemented as program embedded on personal computer such as an applet, JAVA® or CGI script, as a resource residing on a server or computer workstation, as a routine embedded in a dedicated measurement system, system component, or the like. The system can also be implemented by physically incorporating the system and/or method into a software and/or hardware system.

[0084] Although the present disclosure describes components and functions

implemented in the aspects, embodiments, and/or configurations with reference to particular standards and protocols, the aspects, embodiments, and/or configurations are not limited to such standards and protocols. Other similar standards and protocols not mentioned herein are in existence and are considered to be included in the present disclosure. Moreover, the standards and protocols mentioned herein and other similar standards and protocols not mentioned herein are periodically superseded by faster or more effective equivalents having essentially the same functions. Such replacement standards and protocols having the same functions are considered equivalents included in the present disclosure.

[0085] The present disclosure, in various aspects, embodiments, and/or configurations, includes components, methods, processes, systems and/or apparatus substantially as depicted and described herein, including various aspects, embodiments, configurations embodiments, subcombinations, and/or subsets thereof. Those of skill in the art will understand how to make and use the disclosed aspects, embodiments, and/or

configurations after understanding the present disclosure. The present disclosure, in various aspects, embodiments, and/or configurations, includes providing devices and processes in the absence of items not depicted and/or described herein or in various aspects, embodiments, and/or configurations hereof, including in the absence of such items as may have been used in previous devices or processes, e.g., for improving performance, achieving ease and\or reducing cost of implementation.

[0086] The foregoing discussion has been presented for purposes of illustration and description. The foregoing is not intended to limit the disclosure to the form or forms disclosed herein. In the foregoing Detailed Description for example, various features of the disclosure are grouped together in one or more aspects, embodiments, and/or configurations for the purpose of streamlining the disclosure. The features of the aspects, embodiments, and/or configurations of the disclosure may be combined in alternate aspects, embodiments, and/or configurations other than those discussed above. This method of disclosure is not to be interpreted as reflecting an intention that the claims require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed aspect, embodiment, and/or configuration. Thus, the following claims are hereby incorporated into this Detailed Description, with each claim standing on its own as a separate preferred embodiment of the disclosure.

[0087] Moreover, though the description has included description of one or more aspects, embodiments, and/or configurations and certain variations and modifications, other variations, combinations, and modifications are within the scope of the disclosure, e.g., as may be within the skill and knowledge of those in the art, after understanding the present disclosure. It is intended to obtain rights which include alternative aspects, embodiments, and/or configurations to the extent permitted, including alternate, interchangeable and/or equivalent structures, functions, ranges or steps to those claimed, whether or not such alternate, interchangeable and/or equivalent structures, functions, ranges or steps are disclosed herein, and without intending to publicly dedicate any patentable subject matter. Any one or more of the aspects/embodiments as substantially disclosed herein.