Through the pages, we demonstrated how a Virtual Construction Brick (VCB) is composed as a multi-trade generative assembly with embedded AEC expert knowledge. We've shown how to manage both the standard and bespoke content of a VCB on 3DEXPERIENCE across a project team. Now with this Best Practice, we delve into the process of using a VCB on a AEC project through a Virtual Construction Twin (VCT). It will cover the most common uses of a Virtual Construction Twin to create production data from design input.
To understand what a Virtual Construction Twin is in the context of the AEC industry, it's important to see how it differs from Building Information Modeling (BIM). There are two important characteristics of a VCT that go beyond the capabilities of BIM: a continuous Level of Development (LOD) and the deep associativity of building model elements (traceability).
Continuous LOD
The following are typical stages of a building project with their associated LOD:
- Concept/Schematic (LOD 100)
- Design Development (LOD 200)
- Construction Documents (LOD 300/350)
- Fabrication/Installation (LOD 400).
A typical Building Information Model only contains content within the middle range (LOD 200 to 350) and excludes the early design (LOD 100/200) and fabrication (LOD 400) information.
A Virtual Construction Twin is able to contain and manage the entire range of LOD. Generative assemblies are built on top of previous stage content (provided it has been reviewed and managed) as separate Parts meaning both LODs are accessible.
Associativity/Connectivity
In a typical Building Information Model, the building elements have limited associativity--building levels and grids are often the basic organising components that are able to affect change in a model. In a Virtual Construction Twin, just as it can contain the full range of LOD, it can maintain connectivity across all scales and LOD. This means that at any point in a project life-cycle a design change can automatically drive change at every scale (e.g. from overall building massing down to the attachment hardware for a façade panel).
Virtual Construction Twin Organisation
Model content is managed through the CATIA model in the tree. All components and geometry are organised into hierarchical products that can be reordered and assembled to suit a project's organisational requirements. This is called a Project Breakdown Structure.
Project Breakdown Structure
At the top level, a Virtual Construction Twin contains four primary elements:
- The Drivers (as a Construction Driver) node contains the overall Levels and Grids for the building project.
- The Architecture and Engineer nodes comprise all the design input data. These would primarily be the 3D BIM information from the Architects and Project Engineers.
- The Construction node organises 3D construction data ranging from Preconstruction to General Arrangement documentation, Interfaces and Workpackages where the Virtual Construction Bricks would be instantiated.
Design data from the Architecture and Engineering nodes are distributed to the Preconstruction node in order to compose the input scope for the Virtual Construction Bricks. The Preconstruction node provides an intermediate step where constructability and compliance analysis can occur. Then any results or changes can inform the composition of the final Virtual Construction Bricks for fabrication and field execution.
Project Composition Variations
The breakdown of a VCT requires careful planning at the start of any new project. Influences can include (but are not limited to) contractor subdivision, design complexity, trade composition and manufacturing process. In the context of a Productization Approach, this includes capturing defined interfaces between models to align and embed coordination logic.
In the diagrams below, we explore the same project based through two different construction strategies. In the first, the project is decomposed by offsite manufacturing with each subcontractor subsequently dividing the model according to their own requirements. The second diagram is a more traditional construction strategy divided by primary structure and each subsequent workpackage.
Both models are valid but have implications for collaboration between workpackages. Careful consideration should also be paid to update cycles and dependencies--an exclusive Part for interfaces (defined below) helps manage this process.
Virtual Construction Twin Workflow
We describe two key stakeholders in the construction of a VCT: the Project Designers (PD) and the Prime Integrator (PI). Project Designers are the architects and engineers who create the design intent information. The Prime Integrator owns the VCT and is responsible for Brick instantiation.
Process Steps + Responsibility Matrix
| Title | PI | PD | Description | ||
| 1 ) | Parse Project Scope | R | The Prime Integrator selects and distributes the project design scope necessary Virtual Construction Brick input. | ||
| 2 ) | Generate Preconstruction Analysis | R | C | The project scope is analyzed for construction requirement conformance. Issues are flagged to prompt a project design update. | |
| 3 ) | Instantiate Virtual Construction Bricks | R | I | Virtual Construction Bricks (VCB) are instantiated from the project design inputs with user interactions for further project configuration. Quantification (e.g.EBOM / MBOM ) and Documentation (e.g. Fabrication Drawings) are both derived from the instantiated VCB. | |
| 4 ) | Coordinate Interfaces | R | C | Interface objects are added from VCB interface locations (e.g. Axis Systems). Their impact on the project design is automatically assessed within the appropriate work package. | |
| 5 ) | Create Layout Documentation | R | I | The Prime Integrator creates documentation to show VCB locations and relationship to overall project context. |
Process Stakeholders
- PI - Prime Integrators
- PD - Project Designers
Process Involvement
- R - Responsible: The one who performs the work to complete the task.
- C - Consult: Subject matter experts whose input is required before a decision or action.
- I - Inform: Needs to be kept updated on progress or outcomes.
Project Inputs + Instantiation
Project Scope for Brick Inputs
The Prime Integrator of the Virtual Construction Twin first needs to understand what specific inputs are required for the Virtual Construction Bricks they will be instantiating. Then they will search through the project design information and identify the specific scope needed. If the VCB inputs are not directly available in the design information then the Prime Integrator will need to locate the project scope which can be used to derived the inputs.
For example, in the case of the Service Riser Brick, a space volume is required as input to establish the size and location of the service riser in the project. If the Project Designer has not provided that information directly in 3D, then it is up to the Prime Integrator to derive it from walls and slabs in the project information.
Preconstruction Analysis
Once the project scope for Brick input has been captured then constructability analysis may be conducted prior to instantiating the Virtual Construction Brick. This can occur through a Declarative Brick for analysis that is instantiated in the Preconstruction portion of the VCT prior to the main VCB instantiation. It may include requirements and/or limitations related to the fabrication and/or installation process. If any project scope is found to be out of conformance then this information should be sent back to the Project Designers for update. The Prime Integrator then includes these design changes and confirms that the project scope is ready for VCB use.
Demonstration of Design Update from Analysis Results
Interfaces
The main purpose of Interfaces are to manage the intersection of different trades and their driving relationships in a centralised way. One way this is done is by first instantiating a VCB that contains interface locations in the Declarative Brick, such is the case with the Service Riser Brick.
Once the location of the interface is established, the project scope is identified that will be impacted by the interface. In the case of the Service Riser example, this is the slab it sits on. A Declarative Brick containing the interface is instantiated with an Opening and a Pipe Sleeve. It provides both the opening in the impacted scope (e.g. slab) and the product which would provide the means for that opening (e.g. pipe sleeve).
The results of the impacted scope are shared with the Project Designers and other workpackages so that they can incorporate these changes into the project design for to avoid downstream conflicts.
Project Outcomes + Deliverables
Documentation
2D documentation is connected and automatically updated through the 3D Virtual Construction Bricks. There are different levels of detail and scale which are derived from the VCBs. This documentation is intended to support procurement, fabrication and installation of the VCB scope within the project.
Fabrication
Documentation for fabrication is setup within the Virtual Construction Brick template. It may include various 2D views of the detailed assembly and a BOM of the parts needed. Since this is already included in the template, the drawing is ready to use once the VCB is instantiated. In the instantiation process, the 2D views and BOM will be automatically updated. Multi-Discipline Drafting can be used to update the BOM automatically by creating a Table Template that uses a Knowledge Report.
Layout Drawings
Once the the Virtual Construction Bricks are each instantiated throughout the project it can be necessary to provide an overall view of their placement. Layout Drawings (aka General Arrangement Drawings) help to identify each unique instantiated VCB and their relationship to the overall project context. It also provides a more holistic view of the VCB scope to be installed.
Because this type of documentation includes the project context, it is helpful to have a driving logic for how model elements appear in drawings. Multi-Discipline Drafting provides automated methods for this logic with View Update Rules. In addition, the annotations to call out the VCBs in the drawing can be populated through Smart Annotations.
Quantification
An accurate and up-to-date Bill of Materials for all the instantiated Virtual Construction Bricks can be produced on 3DEXPERIENCE using Product Release Engineer (XEN-OC). 3D views in 3D Navigate and tabular views in Engineering Release can be linked so that items cross-highlight when selected. Any standard and custom attributes on 3DEXPERIENCE can be displayed in the tabular view and then exported in spreadsheet format.
Traceability
The Construction Virtual Twin is a searchable repository of project information that is fully traceable. Any item can be located through keyword searches or attribute data filtering. Once an item is found, all related items can be easily traced since their connections are inherent in the 3DEXPERIENCE data model. For example, by locating the top product of a Service Riser we can see it's Relations within Information and quickly pull up it's fabrication drawing. This drawing can be viewed directly on 3DEXPERIENCE or a PDF can be automatically generated through the Derived Format conversion process.
Project Update Management
On an AEC project, each stakeholder (Architect, Engineers, Contractor, and Subs) controls their own model scope in the Virtual Construction Twin. Depending on the scale and complexity, there can be many project updates from design all the way through construction. Each project update can be managed as new life-cycle versions on 3DEXPERIENCE (a future best practice will address this is more detail). For now, here is a simple outline of the steps to manage updates on 3DEXPERIENCE:
Incorporate new project design information by importing BIM data or from building design in CATIA.
Compare versions to identify changes.
Update the VCBs and create revisions to keep traceability between versions.
Demo on How to Use a Virtual Construction Twin
