Tracking a piece of industrial equipment is one thing. Understanding what the equipment is doing is quite a bit more challenging.
An RFID reader can tell me that a tool is in the plant. A BLE gateway can tell me precisely where it is. A sensor can tell me how hot or how rough it is. A maintenance system can tell me when it was last serviced.
All of these signals are valuable, but the truly interesting use cases begin when we combine the signals coming from multiple sources.
Let me explain why this is the case with some architectural context and process flow.
A Simple Take on Asset Visibility
The most common view of an asset management architecture is probably something like this:
Asset
↓
RFID / BLE / GPS
↓
Gateway
↓
Location DB
↓
Dashboard
This architecture answers the question of 'Where are my assets?'. That is a good start but the operational questions are usually much more interesting.
- What asset is this?
- Where has it been?
- How often is it being used?
- What is its current condition? When was it last serviced?
- Is its current behavior unusual?
- What should I do with this information?
These are the types of questions we begin to answer when we have more information about the asset and its recent history.
A More Interesting Architecture
This is where it begins to get more interesting; We can take all of this data and operational history and combine it with other information about the asset.
Asset Identity
+
Location Signal
+
Sensor Reading
+
Maintenance History
+
Contextual Data
↓
Preprocessing
↓
Rules / ML Models
↓
Operational Insights
↓
Human or Automated Action
I am not necessarily interested in the ML model itself per se, but rather in what we can do with a stream of contextualized information about the lifecycle of an asset.
What does a vibration signal really mean in the context of what that machine has been doing, where it is, and what it is currently doing?
We might do some kind of analysis on the vibration as a simple example:
Temperature ↑
+
Machine Speed ↑
+
Production Context
↓
Contextual Analysis
Once again, context is valuable because it allows us to separate signals that might be normal from those which might be cause for concern, but there are other reasons for needing to enrich sensor data with contextual information, namely the process for operational decision making.
Taking Action and Adding Feedback
Having an insight into the potential state of the machine is valuable, but it becomes even more interesting when we think about putting that into an actionable format. Here is a simple look at an asset identification and decision architecture:
Sensor Reading
↓
Validation
↓
Contextual Enrichment
↓
AI / Rules
↓
Risk or Recommendation
↓
Human Review
↓
Action or Response
↓
Feedback Loop
In the end, it makes the most sense to create a closed loop feedback system so that these rules or AI suggestions can be tuned based on real-world results.
When the human or machine takes the suggested action, makes a repair, or inspects the equipment they should also be able to record a result as positive, negative, or neutral.
If the technician checks the equipment being flagged for high temperatures, for example, and confirms that everything is normal, that information should be fed back into the system as a learning experience for future inspections.
The Importance of Purpose
The bottom line is that it makes sense to build out a system like this around a decision or a question.
So many times, systems are built around the tools we have; "We have BLE sensors so we will build a tracking application for the plant floor."
That is usually not a great place to start. Instead, we should identify the question we want to ask and answer first, then build the architecture around that.
We should answer something like: 'Which assets are likely to fail within 72 hours?'.
Who cares about the sensors we have? Well, which sensors do we need to answer that question? Do we need to be tracking the equipment? How frequently? Should it be done in real-time, or can it just be hourly? Where is it most useful to us? What confidence level are we looking for? Finally, who should take what action and approve which recommendations?
That approach would build a system around a question we actually want answered instead of building an application about something completely unrelated.
Conclusion
Asset visibility tells us where things are, but we rarely stop there.
The more interesting applications ask how they might understand these assets - their lifecycle, context, and history.
Aperture Venture Studio explores AI and IoT ventures designed around real-world operational problems, connecting intelligent technology with practical business needs.
This is where an IoT architecture begins to take shape, and AI disclosure, or even operational decisions can begin to have value in a closed-loop feedback system.
Top comments (0)