This article was written in response to a request for an overview of the BuildingSMART OpenCDE-API project by the UK and Ireland BuildingSMART committee, in which our CEO, John Egan currently serves as a member. A precursor to this article, an introduction to the OpenCDE-API project, can be read at the link here.

Glossary of terms.

CDE = Common Data Environment - Means the main system for collaboration for project data, often provided by client or lead appointed party.

DCDE = Distributed Common Data Environment - Means any system outside of the CDE environment; including but not limited to "Work In Progress" collaboration environments and systems with special functionality.

Firstly, the OpenCDE-API cannot be used in the way that you would expect i.e "My computer can talk to other computer(s) and can exchange information between them based on predefined rules should they have this protocol implemented". Instead, it requires a human operative to drive the computer, merely making the process less labour intensive when working with documents from another system outside the CDE.

If the CDE or DCDE systems you use have implemented the protocol and you are trying to understand what this means for you, fill in the template below:

"I use [CDE name] and they have implemented the OpenCDE-API protocol" - Means that within the DCDE environment, a user can access and use documents as if they were doing so through [CDE name] itself.

"I use [DCDE name] and they have implemented the OpenCDE-API protocol" - Means that you can access and use documents from [CDE name] without leaving [DCDE name].

To take a real life scenario as an example using CDE and a DCDE system:

A BIM coordinator uses a DCDE for coordination tasks and is working as a part of the client team. The design team has shared design drawings to their CDE and they are ready to coordinate. Traditionally, a BIM coordinator would download the file to the desktop and import it to DCDE using file import (fig. a).

Figure a. Manual download and upload of files

However, as the CDE and DCDE use the OpenCDE-API protocol, the BIM coordinator can choose to import the file to the DCDE system via the newly introduced "import to [CDE name]" feature found in the DCDE system. Using this option, no file download would need to take place and the BIM coordinator would interact with CDE to choose the document to work with (fig. b). Upon selection, DCDE system would go ahead and load the file for the user to begin coordination.

As of April 2022, the group is working towards a completion date of May 2022 for the documents API described above, at which point it will be handed over to BuildingSMART for them to make an official standard. Whilst this article provides a high level overview of the API, more details including step by step examples, user cases targeted and sequence diagrams for the protocol can be found in the latest BuildingSMART general assembly and on the BuildingSMART OpenCDE-API group github.

Whilst the work completed by the group is a step in the right direction, saving time and cost with moving data between CDE/DCDEs, the panacea of CDE/DCDEs seamlessly working together on a project is still very much at large. This will require the protocol to evolve to enable the automated information exchange between CDEs/DCDEs and to solve challenges around data schema alignment, data access protocols and data provenance amongst other things.

BIMLauncher is actively involved with the OpenCDE-API project working group and is leading the next steps to provide upgrades to the protocol that will enable machine-machine communication, and automation, between CDE/DCDEs. As a first step, the workgroup will focus on providing a common language for project document types, configuration of DCDE’s/CDE’s schema definitions and collaboration to enable lossless exchange of Information Containers between CDE/DCDEs.

Stay tuned for more updates on this project and contact us with information and if you would like an introduction to the group.