Say we have a motor in an industrial facility that runs and runs and runs until one evening we notice that it runs hotter than usual, vibrating differently than we expect.
A simple rule based monitoring system could alert us when any one metric exceeds an acceptable range; however, what if our changes of interest are more complex, take time to develop, or require contextual information to decide if an event has occurred in order to alert human operators?
These are some of the problems at which the combination of artificial intelligence (A.I) and the internet of things (IoT) can be productively applied.
IoT can help collect the information that AI needs to find patterns, while also defining what constitutes an actionable insight.
Let's explore how we might build monitoring and alerting functionality around such a system, beginning with basic rules and moving toward AI-assisted operations.
1. Basic Architecture Layers
We can think about an industrial monitoring system as having four broad layers:
Sensors gather data about the monitored system, such as temperature, pressure, humidity, equipment status, and vibration
Connectivity: Each monitored device communicates its current sensor values through appropriate means to a gateway, local service, or cloud application
Preprocessing: Our application layer validates, timestamps, and stores sensor values for later analysis
Decision making: Rules or an AI model analyze sensor values and take appropriate action, such as raising an alert
Ideally, a system like this is architected to allow for separate development of these different components: the data collection and preprocessing layers should not make assumptions about which particular AI model they are supporting, while the alerting rules should ideally also be comprehensible and modifiable by domain experts.
2. Begin with Simple Rules
AI assisted monitoring is not a given for a business critical system.
We can productively begin by asking: What monitoring rules would be most useful, given the data we intend to collect?
Let's begin with a very simple example involving temperature and vibration:
def check_motor_status(temperature, vibration):
if temperature is None or vibration is None:
return "Invalid or incomplete sensor data"
if temperature > 80 or vibration > 7:
return " Inspection recommended"
return "No threshold exceeded"
Again, we must keep in mind that the values shown here are examples.
In practice we would determine the relevant metrics' values, units, ranges, and acceptable operating windows by equipment specifications sheet, the type and accuracy of sensors being used, and applicable engineering standards and practices.
The above example shows us how simple alerts based on monitored data can be constructed, but it does not account for outlying readings, changing baseline conditions, or incorporate any machine-learning capabilities in its analysis.
That said, rules and threshold-based monitoring do bring certain strengths and limitations:
We know what criteria our alerts are based on when they are triggered
If our rules are simple enough, they may be modified with little additional analysis or equipment
Rules can fire based on any combination of criteria, including changing, aggregating, or nonlinear functions of our input variables
Thresholds may not account for slowly drifting baselines or anomalous sensor readings
A single rule often cannot easily account for a variety of different abnormal conditions
Rules require relatively careful specification in order to be effective; they are not self-improving
We therefore ask ourselves more practical questions, such as the following, before even beginning to draft alert rules:
How do we want the system to behave when a sensor becomes unresponsive or reports values incorrectly?
Do we want to consider one anomalous reading to be sufficient for raising an alert, or wait for consistency across readings?
Who is supposed alert take priority, and who do we expect to receive and process such an alert? What should they do in response?
How do we, as developers, evaluate whether a rule-based system has been helpful or wasted time and resources?
To implement a working rule-based system we may find ourselves considering these same questions, whether or not we eventually incorporate additional methods.
3. Introducing AI Assisted Monitoring
We may find that rules are appropriate for some alerts and entirely inadequate for others.
A good example of the latter is equipment behavior whose normal variations are difficult to separate from abnormal patterns.
A particular motor vibration signature might, for instance, be largely dependent on the equipment's load, whereas a simple range check would raise too many false positives or fail to account for changes in the system's "voice" over time.
In such a case, we might train an anomaly detection model based on known normal behaviors.
A possible implementation path may involve the following steps:
Collect training samples from the monitored equipment
Label normal operating periods or equipment states based on sensor data
Clean training data to identify and remove outliers, null values, etc.
Identify and train an appropriate model (see below) based on cleaned data
Test and iteratively refine based on held-out test data and developer judgment
Evaluate potential false positives and negatives with maintenance staff to establish operational value
Even in this context, a detected anomaly does not necessarily indicate a developing fault - it may represent an abnormal operating condition or sensor error.
This kind of modeling task, however, does illustrate how rules and basic statistical analysis might be combined with a trained machine learning model to achieve monitoring goals.
4. Evaluation: Not Just Accuracy
An operational monitoring system can generate accurate predictions without being genuinely useful, simply by overwhelming operators with unactionable insights and false positives.
We therefore have standards beyond mere model accuracy when it comes to evaluating our systems.
Among the most basic are the following:
- Precision : Among predicted positive examples, what percentage of them were actually positive?
- Recall : Among true positive examples, what percentage of them did the model correctly predict as positive?
- False alarm rate : Among predicted negative examples, what percentage of them were in fact positive?
- Operational impact : Does our system really make a practical difference, or is it largely ignored once deployed?
- Detection latency : How quickly does our system react to an oncoming true positive?
We identify metrics most relevant to our particular situation in order to evaluate how best to proceed.
A false negative may be much more concerning than a false positive, depending on context, while other situations may have different cost ratios or operational requirements.
5. Considerations and Constraints
Creating a working prototype is one thing; getting it reliably deployed is another.
Data quality
Sensor data is often noisy, with missing, duplicated, or out-of-order values.
Such data must be validated and filtered before further processing in most cases.
Timestamps, calibration, and clear null value conventions help when creating reliable preprocessing pipelines.
Edge cases and latency
Some systems require low-latency responses or operate in environments where communication is not guaranteed.
Applications requiring such capabilities should consider using distributed computing or edge processing methods, while cloud-based technologies remain appropriate for other contexts.
This decision is not made in isolation but rather based on each application's operational realities.
Security
The more interconnected a system is, the more points of attack it has for malicious actors.
Authentication, encryption, auditing, and compartmentalization become more important as more networked devices are added to an AIoT system.
Security concerns must be considered for every aspect of system design.
Drifting baselines
Equipment, workload patterns, and environmental conditions change, which may make models outdated or ineffective over time.
We should continuously monitor drift in either our input data or the results of our models during operation.
Operations integration
Without concrete action to follow up on an alert, such a feature is not likely to be genuinely useful.
In practice, an effective operational alert must be integrated directly into relevant human operators' workstreams and followed up afterwards.
We return to this topic shortly.
6. A Development Roadmap
When building such a system, we may productively follow a phased development plan that allows us to make meaningful progress while avoiding premature generalization - in other words, we begin with specific objectives rather than attempting to accomplish everything at once.
1. Identify one specific goal : Determine which particular objective we wish to accomplish, e.g.: finding anomalous vibration patterns
2. Identify equipment : Understand the system we are working with; determine which kinds of sensor values we need
3. Develop a trustworthy data pipeline : Make sure the system reliably records, timestamps, and categorizes sensor values as appropriate
4. Establish baseline behavior : Develop simple, transparent rules to detect abnormalities and establish their limitations
5. Determine whether AI provides benefits : Based on baseline rules, explore what value a trained AI might provide to this particular use case
6. Account for failure scenarios during test runs : Introduce null values, communication issues, and rapidly shifting operating conditions to test preparedness
7. Consider post deployment monitoring : Based on results, determine relevant evaluation metrics and track ongoing performance
We examine these practices more closely below, but this overall plan avoids getting bogged down on any one particular aspect of the system before sufficiently understanding the domain as a whole.
For general information about Industrial AI and related operations concepts, we encourage you to visit (https://apertureventurestudio.com/) and explore additional resources.
Conclusion
Industrial AIoT systems involve pairing physical monitoring equipment with software that helps humans understand changing system states.
The best practices in this space tend to favor systems that collect useful information on a consistent basis, provide actionable insight with minimal disruptions, and integrate productively with relevant operational considerations rather than focusing exclusively on model performance.
Begin with a clear understanding of what we want to accomplish, develop a strong baseline, determine whether AI provides real benefits, and only then move ahead and implement more complex rules or neural network models.
Question for developers: When developing an industrial system, would you prioritize raw sensor data quality, low-latency responses, or reducing false alarms first? Why?
Top comments (0)