A construction project is full of connected things. Equipment, materials, environment, position, and software can all provide valuable insights through their data.
The challenge, however, lies in connecting that data, transforming it into information, and ultimately providing actionable intelligence to applications and people.
This is where AIoT (Artificial Intelligence of Things) enters the fray.
By tying together connected technologies and data processing, AIoT provides a critical thread between physical operations in the field and the digital space.
A Simple AIoT Architecture
We could depict the architecture as something along the lines of the following, with the left-hand side representing the physical world and the right, its digital twin:
Devices → Connectivity → Edge → Data Platform → Analytics → Applications → Decisions
Every step serves a particular purpose.
For brevity’s sake, however, we’ll discuss the items one by one, using a construction industry-centric angle.
- Devices
Information comes from somewhere — and that could be a wide variety of devices.
What constitutes a device in this context would be different, depending on the use case, however.
Some possible examples for construction could be:
RFID tags
BLE devices
UWB positioning sensors
GPS equipping assets
Environmental sensing
Telemetry from equipment
The device could, perhaps, be something as simple as an on/off switch — or it could represent an event or an entire system state.
The considerations that would be relevant for choosing a particular set of hardware would be informed by the context of their intended use.
- Connectivity
The devices need to provide information — to somewhere.
Whether it be to the edge layer, a database, or even to applications, a certain means of delivery will need to be established.
The considerations for connection would be informed by range, platform requirements, existing infrastructure, data size and format, and more.
For large-scale efforts, the project may involve more than one technology, and one may not be entirely suitable for the intended effort.
The considerations would be informed by the project’s particular context and could involve any number of existing solutions and networks.
- Edge
It may not be necessary to immediately deliver the data somewhere.
Edge processing could be used for situations that call for in-place processing near the source of the information.
Such scenarios could involve manipulating the data, aggregating, summarizing, or taking some other action deemed necessary before sending it further.
- Data
The data, once delivered somewhere, must be stored, normalized across diverse inputs, made accessible to the consuming applications, and so on.
We may need to convert it from one format to another, identify event sources, organize and classify it, and so on.
This is where a data layer could come into play.
It can provide normalization code between the edge and the applications as well as any number of related functions. Those functions could be as simple as providing a common way to read and write data, including access through an API, and possibly some degree of system integration.
A data layer will likely be of most interest when different vendors — and dissimilar information models — need to be integrated.
- Analytics
With the information placed in context, we can now attempt to find patterns and relations between them — this is the realm of data analytics and modeling.
Analytics can be applied to connected information for a variety of purposes, including (but not limited to) equipment analytics, operations and activity modeling, environment modeling, and so on.
Artificial Intelligence (AI) is useful in this context, but it only enters the picture when we have an explicit problem to solve.
As with any architectural decision and technology adoption, AI/ML selection and design have to serve a particular purpose — and we must ensure that we are solving the right problem with the appropriate tool.
Integration as the Connecting Layer
Large-scale construction efforts will likely involve a wide variety of software and solutions.
Some of those systems could be:
- BIM applications
- Project management systems
- Telematics
- Tracking systems
- Field applications
- Enterprise applications
Without integration, it can become increasingly challenging to utilize data effectively, as any one of these solutions could constitute an island of information.
An AIoT architecture, in this context, might provide such vital integration as an intermediary layer between the field operations and the consuming applications. Again, we may not seek to replace existing solutions — but we want to ensure that any existing or future applications that need the information can receive it.
In short: It might not be about finding new ways to solve problems with AI; it might be about giving the project the data and analytical capabilities it needs.
The Developer’s Role
While integrating systems and processes information from numerous sources can seem like a daunting task, it is worth considering what role the developer and their team would play in this particular ecosystem.
Perhaps the things we might consider are:
Things –> what and how
Events –> what and how
APIs –> what and how
Data –> what and how
Message processing –> what and how
Edge to cloud –> what and how
Storage and management –> what and how
Analytics –> what and how
Authorization and authentication –> what and how
Interoperability –> what and how
Systems interaction and reliability –> what and how
Scalability –> what and how
A laboratory setting, while useful, still has very little to do with a construction project in the field.
Conditions will not be ideal, devices will move and/or stop working, there will undoubtedly be hardware failures, and so on.
A system would need to be designed with these potential difficulties in mind.
Designing From the Problem Backward
When considering such a project, it helps to think of the problem first and foremost.
A good question to ask might be not “Where can we apply AI?”, but “What problem do we need solved?”, and “What information do we currently lack or struggle to organize?”.
We might, for example, discover that we need better asset information — or we might find that we need to integrate such data with other tools and systems.
Possibly, the crunch point will not be in the AI or even in processing, but merely in getting enough usable data in the first place.
The technology should be determined by the requirements. Not the other way around.
Summary and Final Thoughts
AIoT provides an infrastructure through which it becomes possible to integrate physical operations in the field with digital applications — one that involves a number of considerations that span things, processing, information modeling, analytics and more.
As a system, that infrastructure can be summarized as:
Sense → Connect → Process → Analyze → Decide → Act
It is always a question of the systems’ design — and their integration.
For the developer, the interesting challenge is in designing systems that enable this sort of connection, application, integration, and information processing infrastructure for heterogeneous software systems.
Which is exactly where AIoT goes from merely plugging things together and starts being an actual engineering challenge worthy of exploration.
AI-assistance disclosure: This article was created with AI assistance and reviewed for structure/accuracy before publication.
Top comments (0)