AIoT in Construction: Connecting Site Data With Intelligent Systems
Physical spaces have one advantage over the digital world: they exist in reality.
That has an impact on where information systems are concerned: there is an engineering challenge involved in ensuring that what can be practically measured and used in the physical space is translated effectively to something that can be acted upon within a computer.
The combination of IoT and AI has potential to offer value to commercial construction.
The underlying engineering can be broken down into broad categories to understand how that value might be delivered.
The basic architecture
An oversimplified version of this might be considered as different layers:
- Physical layer
Sensors, equipment, devices, meters, cameras, etc. provide the raw information.
- Connectivity layer
The information from the physical layer is sent, using the appropriate tools, to a local or remote system.
- Data layer
The raw data collected must be stored, normalized (including timestamps), and associated with the relevant project, physical location, asset, or activity.
- Intelligence layer
Analytics tools can now parse this information, detecting patterns, outliers, or other of interest.
Notice that the intelligence layer's job isn't just to detect problems as much as it is to find something that needs human attention: analytics can go beyond simple threshold detection.
Data quality comes first
One of the classic missteps when building out an AI initiative is to focus on the tooling before really understanding the data.
A fancy model isn't going to fix poor input quality.
In construction environments, there can be issues with the sensors:
• Environment: changing conditions
• Connectivity: intermittent failures
• Mobility: equipment moves
• Missing values: sensors didn't report
• Calibration: sensors aren't properly tuned
• Sampling: inconsistent intervals between samples
• Variation: devices aren't consistently configured
This is why there needs to be validation and quality-assurance steps within the pipeline.
For instance, one might separate out the data flow as
Raw sensor data
↓
Validation
↓
Normalization
↓
Storage
↓
Feature extraction
↓
AI/analytics
↓
Human-readable insight
That way, if there's an unexpected analytics result, it's possible to determine whether it's the model or the data that's at fault.
Why edge processing can matter
Not all the data has to be funneled back to some central repository before it can be of use.
Depending on the use case, it can be advantageous to perform some level of processing and transformation closer to the source.
Sometimes, it's about latency: getting information to an end user (or even just presenting it) sooner rather than later.
Other times, it's about reducing bandwidth requirements: transmitting only the information that's needed.
There may also be benefits to reducing the processing load at the receiving end.
Whatever the reason, the appropriate architecture will take that into account.
Some applications don't care about latency, or only need the occasional update; others have a stronger need for timely results.
Turning sensor data into useful features
It's rarely the case that the raw sensor values will be used directly.
Take equipment monitoring, for instance.
Temperature, vibration, run time, position, and other values are captured; rather than passing these directly to the model, some feature engineering might be done to extract
• average operating temperature
• changes in temperature
• vibration variance
• time since last maintenance
• overall utilization
• frequency of abnormal readings
Again, that depends on what's being predicted, what data is available, and what the equipment can provide.
Anomaly detection can be useful
A key limitation in construction environments is that there's rarely enough data to train high-specificity, high-sensitivity models.
This is where anomaly detection becomes valuable: rather than trying to predict whether a specific known failure mode would occur, it can detect when an equipment or process displays behavior that differs enough from the norm to warrant human review.
The value of this approach isn't that high, unless there is an unusual amount of anomalous data (or the anomalies are large enough).
Note that an anomaly is not a failure mode: the equipment might be doing something different (for instance, running a new process) that the model isn't expecting, or another sensor might have had a momentary issue.
AI systems need to recognize when something is happening that the model doesn't fully understand, rather than reacting indiscriminately to every anomalous event.
Connecting AI insights to workflows
A clever model is only useful to the extent that it has actionable outputs.
This is one of the trickiest parts in deploying AI systems in the construction industry.
Let's say that an analytical model detects an anomalous pattern.
Useful processing might involve:
Sensor detects change
↓
Data pipeline validates measurement
↓
Model evaluates pattern
↓
Potential anomaly identified
↓
Relevant team receives notification
↓
Human reviews context
↓
Action is taken if appropriate
That last step - having a human being review the findings- is critical.
There's information available to a human reviewer on the ground that the AI model doesn't have, and an experienced worker might be able to use common sense to determine whether an anomaly is relevant.
This also speaks to why data normalization and quality assurance are so critically important.
A clever AI can identify patterns, but it doesn't necessarily understand what's going on in the bigger picture.
AIoT isn't just about sensors
It's easy to think that bringing AI to the Internet of Things is about bolting analytic tools on to construction equipment.
What people tend to not realize is that the greater engineering challenge is one of integration.
The system as a whole must support the connections between the various components.
Devices don't have any value if they can't communicate (connectivity layer issues), if the data they produce can't be put into a common format (data layer issues), if the analytical tools can't understand it (intelligence layer issues), if there isn't software to consume it (applications layer issues), or if nobody can make sense of it (human layer issues).
The chain is only as strong as its weakest link. Poor connectivity will hurt data collection; poor data modeling will hurt analytic performance; poor interfaces will hurt information consumption; and an insight, no matter how brilliant, won't help if it doesn't fit into the workflow.
In addition, there are always cybersecurity considerations when dealing with connected devices.
Every connected system adds a potential attack vector and something that must be monitored.
Device authentication, access control, encryption, secure communications, software updates, data retention, network segmentation, and similar security concerns should be considered when designing an AIoT implementation.
Measuring whether the system works
Ultimately, these AIoT implementations are being deployed because they're valuable.
To the extent that they can be measured, there's a need to ensure that they're delivering value.
What constitutes value will vary based on the application, but some potential metrics might include:
• Reduction in manual-reporting effort
• Utilization levels
• Time to detect an issue
• Availability of data
• False positives
• Time to maintenance
• Uptime
Note that this creates a feedback loop: the business side can identify what it cares about; the engineering side can measure performance in those dimensions.
There's quite a bit of interest in how such a system would be deployed in the commercial construction space.
A sample implementation is offered by CommCon AI's commercial construction AIoT platform.
Top comments (0)