DGS/DCS Evolution - A Retrospective

The impetus for this blog comes from observing how our (Summit BIM) Data and Geometry / Data Collection Specification (DGS/DCS) format and name is being adopted and used by the broader AECOO industry.

We thought it might be interesting to revisit our journey, over the past decade, as we have worked to understand how best to define, within the BIM process documents, the required geometry, data and document deliverables, intended for handover to facilities. This definition is linked to level of information need and not to LOD.

This blog sets out the various iterations of our DGS/DCS spreadsheet, how it evolved from feedback and lessons learned on different projects with different teams, as the software tools and industry matured.

It is gratifying to see that the document format we developed is now being adopted by the wider industry, beyond our specific client base.

Starting point: 2012

1 Object List

Our initial attempts, over ten years ago, were to define the output required for FM by generating an ‘object list’, similar to the way LOD was defined, using Revit categories. The assignment of responsibility, the MEA, and when the information is expected to be available within the model dataset, has always been an integral part of defining and holding teams accountable. Managing the granularity of the information was very challenging using this concept.

2 LOD-MPS – 2015

Our next iteration, LOD-MPS, still organized around Revit categories, aligned with the concept of Model progression specification, attempting to clearly identify FM requirements. This did not resolve the granularity issue and generated issues with asset parent/child relationships.

3 DGS

Towards the end of 2015, we had moved away from Revit categories and were defining assets using a classification specification, either OmniClass Table 23 or Uniformat. The classification system approach provided the required granularity for managing the data requirements, especially for mechanical equipment, and provided a structure that clients were more familiar with. However, definition of specific geometry needs was still proving difficult to manage with LOD.

The move to a classification system also supported a consistent approach for the management of rooms, which are critical for asset location.

4 DCS – 2018

By 2018, our DGS had evolved and now not only defined the geometry and data requirements to be provided within the design models for FMO but also all the installed asset information required for handover. This format of identifying assets by classification system made it far easier for clients to easily understand and define the assets they were interested in tracking and the installed asset information that they needed.

5 DGS-DCS – 2019

This version consolidated all of the requirements into a single document, providing a holistic view of what was to be provided. The challenge of this version was that some design firms felt they were responsible for providing installed asset information, rather than that being the responsibility of the construction team. In turn, some construction teams were concerned about the fabrication model having to meet the design model requirements.

6 DGS-DCS – 2019 – 2023

The use of a classification system for the assets was very useful in defining what was required; however, design teams were frequently unfamiliar with the system. To resolve this, a new column was added that included the system classification name and number. In addition to helping to organize where the data could be found, a new column organizing the assets by asset type was introduced, along with a colour to help define how responsibilities were divided between design and construction teams.

The challenge was still the concept of LOD, where design teams had agreed to an LOD 300 or 350. This created pushback around the modeling of some required assets and the data needed. The concept of defining an entire data set to a single level of detail or development does not translate well for facilities. Often, very simple geometry with rich data is what is required.

7 DGS-DCS 2023

In this version, new columns were added as noted below. These new columns provide greater detail aligned very closely with the end users’ requirements.

Asset Group: aligning assets to groupings that are more familiar to the design consultants.
Uses: Identifying the main uses for the data.
Clearances: Identifying those assets where a clearance zone must be included for maintenance and replacement, including vertical access for overhead equipment.
Acronyms: Required by the Owner to help maintain consistency between the data sets of different projects.
Early DGS-DCS included the entire specification list. Later versions reduced this list to those assets likely to be included in the building type. This increased the work effort on a project-by-project basis but reduced potential confusion and work effort for the teams.
The challenges of LOD still persist. In this version, we have clearly defined the level of geometry required relative to:
- Detail – symbolic, generic, detailed, or fabrication
- Dimensionality – 2D or 3D and size
- Representational – approximate, or accurate
Clarification and added specificity around design parameters that must be included within the project dataset, for those assets that require installed information to be captured. This was added to ensure that required design intent asset data was included in the model data set.
Added specificity was also included to define the timing required for the provision of installed asset information, to support the ability of the client to start developing preventative maintenance plans prior to handover.

This latest version of our document, which is an integral part of any BIM Requirements Specification that we generate for our clients, is closely aligned with the requirements of ISO 19650. We are sure that the document will continue to evolve further as the industry matures, and as we all collectively learn how to provide greater clarity around what it is that is required from the teams in a BIM process to meet the lifecycle needs of the project.

This blog links to an earlier blog focusing on the challenges of specifying data and document requirements.