Future Value to Model-Based Deliverables
Clients are beginning to require an integrated approach to enhance their existing Asset Management solutions. In response, the AEC industry has started to evaluate multiple vendors, organizations, and technologies to develop proven solutions that allow for seamless migration of all design intelligence data into a federated model. These solutions will be leveraged for interdisciplinary coordination, Model-Based QC, Model-Based Deliverables, and most importantly enable a streamlined continuation of asset management, well beyond design.
Where are we now?
Often times I hear that we in the AEC industry are in the paper business and that our jobs essentially all come down to producing drawings. With that in mind, there has always been a heavy focus on ensuring that the sheets of paper displaying our designs, those that are expected to be constructed/built from, are of the utmost quality and held to a very high standard. Although Building and Civil Information Modeling (BIM | CIM) has been around for over half a century, wide-scale adoption and implementation across the entire AEC industry has only truly been increasing over the past couple decades, to varying degrees. Although we’ve all be anticipating and preparing for this digital transformation into BIM | CIM, we have continued our reliance on printouts and paper processes to be the “Official Form” of design submittals, design reviews, communications, and overall coordination/collaboration between all project stakeholders.
We’ve also been witnessing, over the past few years in particular, the many advancements being made in cloud collaboration, mixed reality, as well as design and review platforms and technologies, that are enabling us to maintain some level of digital integrity throughout the project lifecycle. Technology enthusiasts and evangelists have been attempting to push adoption for several of these new solutions, even when faced with major skepticism and pushback among some within the industry. There’s a saying that it takes an outside disruptor to force change. There couldn’t be any more truth to that statement, than in this case.
Recent events have pushed AEC firms to shift Business Strategies and focusing on increased adoption and implementation for these new cloud-based solutions and digital transforming technologies. What was once considered as a “Nice Have” by the vast majority has quickly become a “Must Have” and essential to operations. Where the industry still appears to be falling short though, is in the development of a proven solution for transferring all design intelligence into a federated model that can, not only be leveraged for interdisciplinary coordination, Model-Based QC, and Model-Based Deliverables, but also one that will allow for a streamlined continuation of upkeep through construction and asset and facility management.
Over the past couple decades, we’ve seen a growing trend in requests for electronic files to be delivered in addition to hard copy deliverables upon completion of major project milestones. Model-Based Deliverables alone has many different interpretations, as AEC firms are being requested to submit anything from PDFs representing the hardcopy deliverables, to Design Files (DWGs, RVTs, DGNs, etc.), to static exports of modeled design elements/components (LandXML, DTM, TIN, SHP, etc.). Although there is potential for these Model-Based Deliverables to provide a comprehensive digital design package, they often times require reconstruction, supplementation, and manipulation to integrate with platforms and technologies being leveraged for Construction, AI/ML, AR/VR/MR, Asset Management, etc.
In the meantime, Software Vendors continue to upgrade their respective products/platforms to streamline the Model-Based Deliverable hand-off process. Recent updates to major platforms are allowing for a more fluid, connected, and dynamic, workflow that AEC firms can leverage to deliver models to additional project stakeholders with minimal data loss. In order to accommodate these additional stakeholders, we need to establish a workflow matrix detailing what types of content, Level of Detail (LOD) of content, Metadata translations required, potential integration solutions, etc. that can be presented to additional stakeholders at project initiation, to ensure that all stakeholders fully understand the level of effort required for the anticipated Model-Based Deliverable itself.
To ensure that AEC firms are providing additional project stakeholders an accurate model, there will need to be additional levels of Quality Assurance and Quality Control (QA/QC) being implemented throughout the project life-cycle prior to delivery for the next phase. At a minimum, QA/QC Model Checks should be performed prior to each major project milestone, where level of QA/QC will be contingent on the LOD of the Model-Based Deliverable agreed upon at project initiation. Traditional QA/QC checks of design models have been heavily focused on paper processes. Recent advancements with cloud-based collaboration platforms are allowing for a seamless approach to maintaining the digital integrity of BIM | CIM designs. As we embrace this digital transformation in Model-Based Deliverables, we can begin to incorporate new workflows and processes for checking our BIM | CIM models via a model-based approach, instead of continuing to rely on paper processes and visual checks to verify conformance and constructability of our designs. We can begin to incorporate Automation processes that can tap into APIs and interrogate our models and associated metadata built into BIM | CIM elements being developed. Embracing the Automation aspect will allow for streamlined Model-Based QA/QC and Deliverable solutions to be implemented and will also provide enough flexibility for adjustable criteria to be incorporated, yielding varying results based on agreed upon LOD of Model-Based Deliverable at project initiation.
The Challenge
The First big question right now is “What is the best approach to incorporate a streamlined solution that is capable of such integrations?” Taking a huge step back, we must consider all formats in which we can properly exchange our design models and associated data. When repetitive use of specific design and collaboration tools are part of your everyday workflow, it’s way too easy to keep the blinders on and focus only on what is in front of you, and only leverage what you know. Client project requirements often dictate preferences of vendor solutions and software applications to be leveraged throughout the project lifecycle. From a design standpoint, there is typically a heavy focus on streamlining integrations between all applications being leveraged throughout the design and pre-construction collaboration phases of a project. Beyond design, there has been a separate focus on streamlined integrations with extended design software platforms and technologies to enable Rendering, AI/ML, AR/VR/MR, Asset Management, etc. Instead of thinking about these as an after-thought, we need to develop strategies from the get-go that will allow for streamlined integration throughout the entire project life-cycle, well beyond design.
The Second big Question right now is “What format of data can be read in all phases of a project life-cycle?” We know that there are many limitations when it comes to translating and transferring modeled components and associated data across many products and platforms. Some formats are easier to translate/transfer, and are specifically tailored to work well with any one vendor’s solutions. But is that a reality? Can we force all project stakeholders to leverage only one vendor’s solutions? Yes, there are some instances where this type of cohesion can occur, but those situations are very rare in this day and age, and certainly should not be considered an end-all solution.
Going beyond the formatted exchange of file and associated data, another major question that needs to be considered is “Where will this data reside and how will it be managed thereafter?” When we think about what a current handoff process looks like, we tend to go back to the paper deliverable mindset where we can now wash our hands of the product once delivered. As we start having discussions with all project stakeholders at project initiation and develop the workflow matrix detailing integrations required throughout the project life-cycle, we also need to take into consideration the Common Data Environment (CDE) in which these model and data exchange files will reside in, that will facilitate, and act as a gate keeper for, continued maintenance and upkeep. CDE determinations can be equally as important as determining the data exchange format, as some CDE’s are limited in file and data format integrations and support.
The Solution
As we investigate model and data translations that can be read in the majority of platforms and technology solutions in today’s world, we come across LandXML and IFC as being the most frequently leveraged formats that will allow for some level of streamlining model and data translations. LandXML has been heavily relied on, from a Civil standpoint that is, throughout the AEC industry for over two decades. It has been welcomed by many major vendors supporting AEC, with varying levels of integration into their respective technology solutions. LandXML lives and breathes for everything being mentioned thus far, but is not an option when it comes to the vertical (building/structure) side. On the horizontal side, LandXML supports intelligently modeled components fairly well, but lacks support for all accompanying/supporting design elements and geometry. LandXML provides a solution that will essentially take your Civil-Based modeled components and associated metadata, and then export it to a document organized by a Schema that deconstructs the modeled components in written format. LandXML leverages a Standard or Universal Schema, which is absolutely necessary when it comes to driving consistency with how we are integrating our models into other platforms and technologies.
Similarly, IFC provides a solution much like LandXML where modeled components and associated metadata can also be translated/transferred via a Schema that deconstructs your modeled components. Although IFC has been around for slightly longer than LandXML, there has historically been a primary focus on integrations supporting the vertical (buildings/structures) side of AEC…until recently that is. There is currently a huge development and focus underway to build up the Model-View Definitions (MVDs) and Schema to account for major components being created in support of the horizontal (civil) side of AEC. Furthermore, IFC does provide translation for additional modeled components that aren’t necessarily intelligent in nature. In our quest for developing a streamlined model and data exchange solution, taking into account for LOD requirements along with involved disciplines and anticipated integrations, we have 2 potential options in front of us: LandXML (in limited situations) and IFC.
Thinking about the handoff process itself, and establishing an agreed upon CDE in which our federated model will ultimately reside in, IFC can streamline model and data exchanges on a much wider range than LandXML. We are also witnessing many major vendors supporting IFC and focusing on integration capabilities within their design and collaboration platforms. The overall AEC support of IFC has been gaining a lot of traction over the past few years, and is providing an environment where all project stakeholders have enough flexibility to leverage the products/platforms that they are most comfortable with, and not have to worry as much about loss of model and data exchange fallouts. This overall IFC support is also promoting a tremendous amount of Innovation as we shift from the Paper to Digital processes and workflows across the industry.
Conclusion
As mentioned, on the horizontal side, IFC is still relatively new and there are a lot of unknowns. With that being said, I can understand some of the hesitation for firms to fully jump on board as it is another new technology solution that is currently facing some level of skepticism. Although IFC for horizontal designs is still in its infancy, there are many benefits in its current state to incorporate IFC into your workflows and deliverables. One of the key components to strategizing IFC adoption for all project stakeholders, is to take into consideration model and data preparation itself. IFC can only go so far at this stage and requires varying levels of model and data preparation for it to be a viable solution. Model and metadata translations from native to IFC format will need to be fully vetted to ensure that we are integrating these digital solutions best we can.
Probably the biggest shortfall I’m still seeing though, is that IFC is still another static export, ultimately producing a snapshot of current state. Yes, we have the ability to import IFC back into native software, but requires us to manually remove previous versions of modeled components within our existing files. Ideally, I’d like to see some level of conflict/version resolution being incorporated into the import process. With IFC MVDs, Schemas, integrations and tools still being developed, we have opportunities left and right to develop innovative approaches to integrate and streamline model and data exchanges through all required digital processes. This will allow for model and data exchange to ultimately fulfill our quest for producing a fully federated model.
