Tracking construction progress in terms of cost, schedule and quality — at scale — is complicated. It not only involves understanding the physical progress on site at a given time but also aggregating and comparing that data to planned cost, schedule or quality metrics.
Today, subject-matter experts rely on their expertise and years of experience to understand progress and compare that to plans in order to optimize construction projects. However, because this is a manual process, early detection and risk mitigation is difficult and often results in schedule delays and cost overruns. For example, Doxel has found that most progress reports lag by 3–6 weeks and can have up to 30% of line items incorrectly reported.
The solution to this problem is automating a manual process by building a structured, adaptive, and scalable model of the construction domain. This would encode the expertise and years of experience subject matter experts have, enabling risk detection in near-real time based on objective site status.
The Doxel Construction Encyclopedia
To build an efficient and accurate paradigm of construction, Doxel invented the Construction Encyclopedia (patent pending). As with other domain models, it has 3 main components:
Although every construction site is different, Doxel is able to draw a pattern observed across our customers. The basic building block of that pattern is functional and structural object types — this hierarchical ontology encodes the catalog of parts at a higher abstraction level (e.g. trade, system, subsystem, etc.) to draw commonality across sites and types of construction. This includes, but not limited to:
- Physical quantifiable components (eg. pipes, ducts, valves, walls etc.),
- Stages of construction which define quantifiable progress measurement of individual complex components (eg. a wall object can be modeled as a cuboid but it goes through multiple stages before fully done)
- Ways to measure cumulative progress of the site (eg. 10 ducts are installed and 5 walls have been painted).
These concepts can be thought of as the type definition of the domain model — symbols of our ubiquitous language.
Relationships among types define the grammar of the ubiquitous language. Doxel represents these relationships in the form of a n-ary tree of depth m where each edge encodes how decomposed low level objects and related activities/tasks can be rolled up to the higher level for tracking the construction project at different resolutions.
As an example, a piping component can be decomposed into straight pipes and related fittings (subcomponents) where they represent a different quantum of work when rolled up to the higher level.
This powerful representation is the core of the Encyclopedia. The example above (figure 1.1) shows how the quantifiable components are related to each other (every hierarchy is colored differently) so that their dependencies can be explored for different purposes (eg. automated object tracking to track progress of a certain higher level abstraction).
It is easy to imagine the scale of the graph given the number of different types of objects at the construction site. The relationship specification is flexible enough to even work across hybrid node types.
This graph (figure 1.2) represents the component relationship of an under-construction data center which Doxel is currently monitoring. Modeled objects belonging to each trade are colored differently (colored dots) and every relationship is represented with a line of the same color. Concentric circles, which are basically collections of objects belonging to each hierarchy, represent hierarchy layers. This aptly shows the scale complexity (why manual effort won’t be practical) and the relationship patterns found by Doxel at the same time in this interesting representation.
Workflows represent well-written stories in ubiquitous language. Product workflows are usually represented in the form of directed acyclic graphs where edges represent relation or decision flow. This is where Doxel encodes the rich & complex experience of construction experts through rule based and AI based systems which can compute, as an example, the probability that a task will be delayed based on the dependent activities or how current spending and work progress accurately indicates cost at completion. Additionally, prioritized quality issues based on their potential time and cost impact and many more. The potential possibilities are enormous.
This flowchart (figure 1.3) simplistically depicts how Doxel tracks the schedule of a project by analyzing the progress of each and every related node of the encyclopedia tree, tying them to related activities, adding project specific constraints and rules on top of activities, measuring tangible status, and finally aggregating progress across branches of the tree.
Does this look too simple? The animation below (figure 1.4) shows the entire activity graph of an early stage project Doxel is tracking!
The current state of Doxel’s Construction Encyclopedia improved product turn-around time & automation velocity significantly. Given the complexity of the construction domain, this modeling work is a continuous process.
This ubiquitous language helped us not only streamline communication across business units internally, it helped us to generalize the construction process across verticals externally. As a result, it quickly became one of the key ingredients of our success. This generic domain model enabled transfer learning from one vertical to the other seamlessly for product and automation teams.
When onboarding a project, the first step Doxel executes is mapping the customer’s BIM model, project constraints, and customizations to the Construction Encyclopedia. This process is fairly automated with subject-matter-expert review at the end to ensure the highest degree of accuracy and completeness (important given this is the Ground Truth for every report Doxel produces for its customers going forward). Curious to see how this seemingly complex task happens fairly autonomously during onboarding? Stay tuned for our post on user onboarding.