Most IoT deployments are monitoring and remote control applications, where a microcontroller measures data from one or more sensors, and then these measurements are transmitted to a cloud based server. The monitoring applications are ideal for IoT devices when changes that need to be reported have durations between events in minutes, or ideally longer. Shorter event durations, and the resulting more frequent data publishing from the IoT device to a cloud service drives up cost if a cellular connection is used, and limits low power operation.
In the real world, nearly all mechanical systems occur with events in the 100 Hz or less range, many at 30 Hz or less. Using a proper sampling rate of 10x of the highest frequency to be measured, the sample rate (or continuous data streaming rate) for each sensor could be as high as 300 Hz for a 30 Hz signal being monitored. Continuous streaming of data from an IoT device to a cloud service at a rate of 300 to 1000 samples per second is simply not realistic. However, it is possible use the microcontroller as an edge device to compile a summary of the data with sufficient information for many applications. That compilation can be transmitted by the IoT device to the cloud service very infrequently, perhaps only daily or longer, since it is a cumulative summary.
Ask any engineer of a component or system what data they will need to develop a product that will have the reliability and robustness the customer needs, and they will tell you they need the duty cycle for the component, and a complete understanding of the environmental conditions the component operates in. A duty cycle is the proportion of time during which a component, device, or system is operated. The duty cycle can also be used to account for changes in environmental stress, such as temperature, that may affect the operation of a component. The duty cycle, along with the operating environmental conditions that stress the component are used to perform system reliability modeling and analysis.
One of the best ways to characterize the operation of a component, and the conditions it operates in is to compile a time-at-level histogram (single classification) for each factor. A time-at-level histogram is a chart that plots the distribution of a numeric value (sensor's values) as a series of bars, where each bar covers a range of numerical values called a bin or class, and the bar's height represents the time at that level.
The chart above shows both the raw time-at-level values in one bar chart, along with the same data as a percentage of the total. The former is what the IoT device would send to the cloud service, and then the percentages could be derived at the cloud service. Knowing how much time a device is subjected to a particular operating condition is often sufficient for many reliability models.
Nearly any IoT microcontroller can measure and digitize data at 1 KHz, and the compiliation of that measured data into a time-at-level histogram is well within it's memory and computational capabilities. Sending ten bins of time-at-level histogram data as time in seconds as a uint32_t variable with a maximum value of 4294967295 (seconds) consumes a maximum of only 110 bytes as a IoT transmission payload. Ex. '4294967295;4294967295;4294967295;4294967295;4294967295;4294967295;4294967295;4294967295;4294967295;4294967295'. This data doesn't need to be sent frequently, allowing the microcontroller to minimize the frequent use of power hungry peripherals such as a cellular or WiFi modem, or LoRa radio.
Sometimes it is important to know the conditions for multiple factors (sensors), when one sensor exceeds a predefined threshold, or when one or more factors have values that together represent an event of interest. If these factors and the thresholds to monitor are known, and the event reporting frequency is sufficiently low, then this too can be monitored and reported by an IoT device. If the factors and thresholds to monitor are not known, then it will be necessary to record all of the data at a high sample rate, and then later analyze this data to determine the factors of interest, and those thresholds, as described in the next section.
Modern microcontrollers can easily write recorded data for multiple sensors to an SD card at a sample rate of 1 kHz, providing proper capture of events with frequency content as high as 100 Hz (nearly all mechanical systems). The raw data should be then physically retrieved from the IoT device SD card for subsequent analysis, and perhaps machine learning activities. Once the relationships between any sensors is known, and the thresholds of interest for each are defined, then event reporting and time-at-level histogram monitoring as discussed previously may be employed.
It is not necessary to stream raw data from an IoT device to a cloud service at rates of 300 Hz and higher. A modern microcontroller can be used as an edge device to compile raw data, report level-crossing events, and even record locally raw data. Raw data compiled into a time-at-level histogram, and raw data for level-crossing events can be transmitted by the IoT device to the cloud service infrequently, minimizing cost and IoT power consumption. Microcontrollers can also record at high sample rates directly to an SD card, for subsequent physical retrieval and detailed data analysis.
Do you need help developing or customizing a IoT product for your needs? Send me an email requesting a free one hour phone / web share consultation.
The information presented on this website is for the author's use only. Use of this information by anyone other than the author is offered as guidelines and non-professional advice only. No liability is assumed by the author or this web site.
Sitemap | Copyright © 2014 - 2024 Mechatronic Solutions LLC
Web site by www.MechatronicSolutionsLLC.com | | 5.8220 ms