Levels of development of common data environments for construction projects

For citation in scientific research:

Medvedev D.V., Pronin V.I. Levels of development of general data environments of construction projects // Economy: yesterday, today, tomorrow. 2023. Vol. 13. No. 5A. P. 336-347. DOI: 10.34670/AR.2023.59.18.018

Introduction

The emergence of the concept of teamwork became one of the main directions of development of computer-aided design systems (CAD) back in the 70s of the 20th century. In mechanical engineering, this resulted in the concepts of PDM and PLM. [1]

In construction, this process was introduced later. Its result was the introduction of the concept of CDE – Common Data Environment. In Russia, this concept was strengthened in the term Common Data Environment – CDE.

To date, the topic of the development of the SOD has not been disclosed, there are almost no studies on this subject, especially in the Russian-speaking segment. All available information devoted to the SOD mainly describes the theoretical conceptual or methodological part and does not pay attention to the evolution of shared data environments.

This is what this article is dedicated to.

The question of the evolution of the SOD is important because it allows us to predict how work in construction projects will change in the near future. It also helps us understand what the SOD is and what form it will take in the near future.

This will help in training new employees and students, in improving the knowledge of existing specialists, in improving the work of organizations participating in construction projects and in improving the construction industry as a whole.

What is SOD

Definition

The term common data environment (CDE) was first used by Mervyn Richards and was recorded in the BS1192-2007 standard in the UK.

It was later developed and is currently used in regulatory documents around the world.

The ISO 19650 standard, which is generally accepted in international practice, defines this concept as follows:

ISO 19650 3.3.15 common data environment (CDE): “agreed source of information (3.3.1) for any given project or asset (3.2.8), for collecting, managing and disseminating each information container (3.3.12) through a managed process.” [2]

Russian regulatory documents define this term as follows:

● GOST R 10.0.01-2018. “System of standards for information modeling of buildings and structures. Terms and definitions”:

Common Data Environment (CDE): A software package for managing, storing and exchanging data on information models at all stages of the life cycle. [3]

● SP 471.1325800.2019. “Information modeling in construction. Quality control of construction work”:

Common data environment; CDE: A set of software and hardware tools representing a single source of data, ensuring the joint use of information by all participants in an investment and construction project. [4]

The SOD allows all participants to participate equally in the formation and maintenance of information models of capital construction projects.

The common data environment makes it possible to work with data throughout the entire life cycle of a capital construction project. [5] As a result, the processes of coordination and decision-making by all participants are accelerated. The widespread implementation of information modeling technologies has become only a matter of time. [6]

Identifying conflicts and adjusting the project at later stages entails an increase in the cost of their correction. Timely interaction of project participants helps identify conflicts at earlier stages of the project. [7]

Purpose

The common data environment is one of the fundamental and primary tools from which the implementation of information modeling technology begins. The common data environment is designed to coordinate the work of interorganizational teams, synchronize their activities, and exchange data in the common digital space of the project.

The purpose of using the SOD is to reduce the time and costs of capital construction projects.

Tasks that can be solved with the help of SOD:

• Formation and maintenance of the information model

• Organization of engineering and technical document flow between project participants in electronic form

• Reduction of timeframes for the exchange of documents and information, timeframes for approval and communication

• Increasing transparency and controllability of processes

• Reducing the number of errors in projects and collisions on construction sites, reducing downtime

• Assessment of the current state of the object and its compliance with the plan

• Control of construction processes and execution of works

The key idea in BS 1192 was the flow chart of the SDS processes. This is shown in Figure 1.

In Russian lawmaking, it was rethought and applied in several regulatory documents and, in general, is presented as follows:

The illustration shows a basic diagram of the SOD, which includes 4 file zones:

1. WIP (Work in Progress) — a section of working data (“In progress”). The SOD area for storing current data of one of the project participant groups. Information in the WIP zone is available only to this group of participants. As the level of information development increases, access to it can be provided to other project participants by moving data to other file zones.

2. Shared — General data section (“General access”). The area of ​​the SOD where the materials of the project participants are stored in general access for related departments and contractors. It is used for project coordination.

3. Published Documentation — section of published data (“Published”). The area of ​​the SOD where finished, approved materials are posted for their transfer to the outside – to contractors or the customer.

4. Archive — archive data section (“Archive”). SOD area for long-term data storage after the project is completed. [9]

Working with documents according to this methodology allows for effective interactions between all participants within the construction project.

These are the main theoretical provisions of the SOD. More detailed concepts and definitions concerning the SOD can be found in the regulatory documents of the Russian Federation. [13-18] In this article, we will focus on the SOD levels that demonstrate the development of this tool.

Levels of development of SOD

During their existence, common data environments, as systems for organizing project work and as information systems, have undergone significant changes. The reason for this was the development of process models of construction projects, the development of information technologies and hardware capacities.

Based on the analysis of the development of these systems, five levels of development of common data environments were identified:

The levels demonstrate the history of the development of the SOD, highlight the features of each type of SOD and show past and future trends.

In addition, several ways of organizing the SOD can also be distinguished. With their help, it is possible to observe the development of the SOD technology over time.

1. Internal decision

The first option for organizing the information space for working with project information. For this option, different schemes are used using network local folders or some software that ensures work only within the company itself. This method does not meet the requirements for common data environments in terms of unification for the work of different companies, so it cannot be considered a DMS in the full sense of the word.

2. Client-server solution

In this case, specialized software is already used. The scheme, in general, looks like this: the company's server has software, each of the users' PCs has a client part. Perhaps there is a web application that supports a limited number of functions. This method is better than the first, but has a number of significant drawbacks. First of all, there is no teamwork, it is emulated. Only the company that owns the system can still fully take advantage of the system's advantages.

3. Cloud web solution

The most promising way to organize the SOD today. Its main feature is that it provides full-featured operation of the SOD without being tied to specific PCs. The project can have any number of participants, they can freely come and go. Teamwork is ensured.

Solutions based on web services can ensure high efficiency of the organization of the data processing system. In addition to the absence of problems inherent in local solutions, they provide more opportunities (for example, opening drawings and 3D models in the browser without using special programs) [10]

1. Local SOD

The first level of development of common data environments. Such SDS arises in companies that have decided to streamline their activities related to project documentation. The first level systems are characterized by similarity with document management systems and a high degree of “individuality” because they are designed to optimize the activities of a specific organization and provide the ability to exchange technical project documentation within one organization.

Often such SODs are created as a result of custom development.

This type of organization of the DDS is characterized by a closed structure. Therefore, such a tool is not a DDS, according to the provisions of international standards, but is a local digital workspace of a single organization.

Work with design documentation in terms of creation, verification and making changes is carried out in the usual software products used at the enterprise: CAD systems, office software, etc. Design documentation has the formats of these systems.

Such SOD is used only within the organization. If necessary, project data is transferred in ways standard for the organization's work, including on physical media.

Such systems can have a high level of customization, especially for custom-made systems. In this version, the SOD can be configured as conveniently as possible, taking into account the specifics of the work processes of one specific company that owns the SOD.

However, such systems do not perform the role of the project SOD, but belong to one of the project participants. This is incorrect from the point of view of the SOD theory.

It is impossible to add other project participants to such a SOD; there is no access to it.

2. Local SOD with connection of third-party users

The second level of maturity is a development of the first level. At this level, the possibility of exchanging information between several participants appears.

Such systems appear as a result of the recognition of the need to involve external contractors in working with design documentation.

Often this task is solved by granting access to download or unload information to/from the local SOD of one project participant. This can be called “imitation” of general access, since there are no established permanent communication chains between project participants in different roles.

With this type of organization, the SOD is still the property of one participant, as is all the data within it.

The advantages still include a high level of customization, i.e. system refinement. The system still serves to optimize the organization's own activities. The advantages also include the increased level of control over counterparties with this option of organizing the SOD.

However, such a system is still not a SOD in the full sense of the term – it does not perform the role of a project SOD, and belongs to only one participant.

At the same time, a new risk is added: conflicts arise between project participants’ regulations when handling information.

Conflicts may arise between the systems in which the project participants work, for example, incompatibility of data transfer formats.

Second-level SODs provide the ability to exchange information with external companies in a limited manner.

3. Interorganizational SOD

The third level of maturity includes systems that have the ability to unite all project participants in a single information environment.

Such SODs cannot be obtained from previously local SODs.

Third-level systems have the same functionality for all participants.

An important feature of this type of shared data environment is that they already become an integral part of the project itself. That is, the SOD of this level of development may no longer belong to one of the project participants. However, the maintenance of such SOD is still paid for by one of the project participants.

All participants have equal opportunities to work in the system. This applies to tools, functions, and rights that certain employees may have. This is a unified system that is equally accessible to everyone.

As a rule, a software development system of this level is a product of a specialized supplier, and not of a specific project participant.

Often this is a cloud system, which allows you to work with modern technologies in construction projects and use advanced experience in organizing IT systems.

SOD technologies of this level provide quick access to these systems for existing and new participants.

The disadvantages of such SOD include general functionality, without taking into account the individual needs of the roles of project participants.

Conflicts in the regulations of project participants regarding information handling are eliminated through flexible options for configuring access to information within the SOD.

Such shared data environments are less susceptible to changes at the customer's request, since they are developed by a third-party vendor.

They allow improving the economic indicators of the project – terms, cost, quality. That is, such SODs bring benefits not only to companies, but also to the entire project as a whole.

There is a number of generally applicable functions, it is the same for all project participants. It becomes possible to: receive, store, transfer data; check and approve documents; control project development.

4. Interorganizational DMS with functional modules according to the roles of participants

The fourth level of SOD is a development of the third level, just as the second level is a development of the first.

At the fourth level, individual functionality is added in accordance with the key roles of the project participants. The system interface may also differ depending on the role in the project, but the entire system is a single information field.

It is important that she retains the role of the project's SOD.

The technological stack of such SOD provides quick access to it for existing and new participants. New users get access as quickly as possible and are able to master the new tool and work processes within it as quickly as possible.

There is the possibility of flexible expansion of the functionality of the SOD, if necessary, through additional modules, that is, at this stage it is already possible to integrate some modules of the system that correspond to the tasks of the project participants.

Today, the industry is just beginning to move to this level of DMS. The complexity of such systems and the insufficient level of IT development determine the difficulty of creating and fully using such systems. At the moment, DMS with functional modules for each project participant is not yet on the market. There are systems that can integrate with other systems, there are systems that have a number of functions that meet user requests.

With the use of such SOD, it is possible to further improve the economic indicators of the project – timing, cost, quality.

The organization can be configured to further optimize the activities of each project participant.

Additional functions appear that relate to individual roles: construction control, author's supervision, standard control, schedule, KS, etc.

5. United SOD

This is the final level of maturity of the SOD. This is the very target system that the entire construction industry is striving for.

At this level, it is assumed that various information systems of all project participants will be integrated with each other to organize a single information field.

In general, the scheme looks like this: each organization has its own internal DMS, built on the most convenient tools for this particular company. At the same time, each DMS will have some identical technological and methodological part, allowing the DMS of all participants to be integrated with each other on the basis of common work standards and common data formats.

For each individual project, a SOD will be created that does not belong to any of the participants, but “belongs” to the project itself.

At the same time, the interface, set of tools and functionality of the system of each of the project participants can be absolutely anything and differ from each other.

However, it is necessary to have a common minimum functionality to connect all systems into a single project SOD and to terminate this connection when necessary.

This version of the organization of the SOD combines all the advantages of the previous levels of development.

It is organized by exchanging data via a common communication channel, to which access can be provided as quickly as possible using cloud and web technologies.

At any time during the work on the project, the project participant can restrict access to his own information. It is stored in his circuit, in his SOD, and is transferred to the general part of the project SOD only if necessary.

Data storage security is ensured as efficiently as possible.

Such SODs will be able to provide the maximum positive effect for the economic indicators of the project – terms, cost, quality. They will also maximally optimize the own activities of each of the project participants.

Current industry and technological development levels do not allow for the implementation of such a SOD. This is a task for the future, which must be worked on jointly by participants in the construction and IT sectors.

Conclusion

The topic of SOD in the construction industry is still quite young. Even the theory and methodology of SOD require constant updating, actualization and confirmation in practice.

It is likely that many of the points made in this article will be subject to change over time.

However, today we can already clearly identify the trends in the development of the SOD as a key tool in increasing the efficiency of the activities of participants in construction projects:

• ensuring convenient and quick access to the DMS for new employees, reducing the requirements for software and hardware from the DMS side.

Following the main goal of the SOD – to improve the efficiency of work in construction projects – we can draw a conclusion about the necessary actions that should be taken to speed up the achievement of a successful result.

It is important to note that the development of the SOD cannot be accelerated by skipping any of the stages. This is an evolutionary process, and it must be completed. In order to achieve the target system, the previous stage must first be closed. Currently, most systems on the market correspond to the third level of development.

First of all, it is necessary to focus on accelerating the transition to the next level of development of the SOD – inter-organizational SOD with functional modules according to the roles of participants.

Today, the lack of technological compatibility of services to provide users with the necessary functionality is relevant. The IT industry should focus on this.

At present, in Russia the optimal solution for organizing the information space at all stages of the life cycle is a scheme of sequential processing and exchange of information between automated systems:

CAD ⇔ SOD ⇔ GIS” [11]

To implement this scheme, integration between the specified systems must be ensured.

The construction industry needs to decide on data transfer formats. A unified and open data exchange format between the specified systems must be developed and approved.

Currently, active work is being done in this direction in the Russian Federation – specialized GOSTs are being formed, templates for XML schema data formats are being developed, integrations of various systems at different levels of construction activity support are being tested. However, there is still a lot of work to be done in this direction, and it is far from a successful, generally acceptable result. It is important to agree together – the acceleration of achieving a successful result lies in the joint dialogue between IT and the construction industry.

All this work is very important and necessary, because thanks to the common data environment it becomes possible to improve the progress of construction projects and positively influence the reduction of costs, improvement of quality and reduction of time costs. [12]

Bibliography

1. Skvortsov, A. V. Common data environment as a key element of information modeling of highways / A. V. Skvortsov, V. N. Boykov // CAD and GIS of highways. – 2015. – No. 2 (5). – P. 37-41. – DOI 10.17273 / CADGIS.2015.2.6. – EDN ULNWQR.

2. ISO 19650 Organization and digitization of information about buildings and civil engineering works, including building information modeling (BIM) — Information management using building information modeling

3. GOST R 10.0.01-2018. “System of standards for information modeling of buildings and structures. Terms and definitions”

4. SP 471.1325800.2019. “Information modeling in construction. Quality control of construction works”

5. Belyaev, A. V. Life cycle of construction projects in information modeling of buildings and structures / A. V. Belyaev, S. S. Antipov // Industrial and civil engineering. – 2019. – No. 1. – P. 65-72. – EDN YXHHYL.

6. Features of the implementation of the program for the introduction of TIM technologies in construction / R. Kh. Kuramshin, D. A. Isupova, A. S. Strakhov, A. P. Tregubov // Prospects for the development of the construction complex: Proceedings of the XV International Scientific and Practical Conference of the faculty, young scientists and students, Astrakhan, October 19-20, 2021. Volume 15. – Astrakhan: Astrakhan State University of Architecture and Civil Engineering, 2021. – P. 363-366. – EDN KVXOHG.

7. Akhmetov, D. R. General data environment: practical benefits in the implementation of construction projects / D. R. Akhmetov, N. L. Breus, T. T. Mansurov // Bulletin of Eurasian Science. – 2022. – Vol. 14, No. 3. – EDN QDEVHW.

8. BS 1192:2007. Collaborative production of architectural, engineering and construction information – Code of practice. 2008. 38 p.

9. Savenko, A. I. Common data environment in the implementation of construction projects using BIM / A. I. Savenko, P. V. Cherenkov // CAD & GIS for roads. – 2019. – No. 2 (13). – P. 4-11. – DOI 10.17273 / CADGIS.2019.2.1. – EDN YCCEZG.

10. Petushkova, Ya. D. Common data environment for information modeling / Ya. D. Petushkova, S. V. Pridvizhkin, M. M. Karmanova // Economics and Management: Problems, Solutions. – 2020. – Vol. 1, No. 7. – P. 17-22. – DOI 10.34684/ek.up.pr2020.07.01.003. – EDN KUJYWR.

11. Piskunov, M.V. General data environment as a customer tool / M.V. Piskunov // CAD & GIS for roads. – 2019. – No. 2(13). – pp. 12-17. – DOI 10.17273/CADGIS.2019.2.1. – EDN KYGYKL.

12. Petushkova, Ya. D. Common data environment for information modeling / Ya. D. Petushkova, S. V. Pridvizhkin, M. M. Karmanova // Economics and Management: Problems, Solutions. – 2020. – Vol. 1, No. 7. – P. 17-22. – DOI 10.34684/ek.up.pr2020.07.01.003. – EDN KUJYWR.

13. GOST R 57311-2016 “Information modeling in construction”. Requirements for operational documentation of completed construction projects

14. GOST R 10.0.00– 2018 “System of standards for information modeling of buildings and structures”

15. Article 57.5 of the Urban Development Code of the Russian Federation “Information model of a capital construction project”

16. SP 404.1325800.2018 “Information modeling in construction. Rules for developing project plans implemented using information modeling technology”

17. SP 328.1325800.2020 “Information modeling in construction. Rules for describing components of an information model”

18. SP 331.1325800.2017 “Rules for exchange between information models of objects and models used in software packages”

19. SP 333.1325800.2020 “Information modeling in construction. Rules for the formation of an information model of objects at various stages of the life cycle”

D.V. Medvedev, 2023