ISO 19650? Eurocodes? Standards? Standards are long. They are boring. And obscure. I still vividly remember myself shuddering at the University at the mere mention of standards and Eurocodes. I am still flinching at the name Eurocode 2. Now…. It hasn’t changed that much, though. But! You have often asked to shed some info about CDE and ISO 19650 in the surveys. Therefore I have plodded through this code from cover to cover. And do, believe me, it’s not an engrossing lecture. This and the following entries serve as a summary, conclusions, and some practical observations.
Table of contents
1. Definition of Common Data Environment
Let’s fire off from the definition. Quoting ISO 19650-1, p. 3.3.15, Common Data Environment is:
Agreed source of information for any given project or asset, for collecting, managing and disseminating each information container through a managed process.
- Note 1 to entry: A CDE workflow describes the processes to be used and a CDE solution can provide the technology.
- Information: re-interpretable representation of data in a formalized manner suitable for communication.
- Information container: named persistent set of information retrievable from within a file, system, or application storage.
It’s merely a beginning and already so confusing. That’s how it is with definitions: they are hard to comprehend and come to grips with. Let’s delve deep and paraphrase:
Agreed source of information for any given project or asset,
- The whole design team should agree on the use of CDE.
- It is a source of information.
- Any project or an already existing asset can utilize CDE
for collecting, managing and disseminating each information container
- CDE contains the data utilized in every construction project (information container).
- Information Container may be a file or data subset. This might be structured information (containing metadata, e.g. geometrical models, database, schedules) or unstructured (information with no metadata, such as pdf documents, scans, photos, videos).
- Not only does CDE serve as a repository to store information. It also helps to manage, share and collaborate with others in the project. In other words: information is available to each team member.
through a managed process.
- CDE workflow is a process (look at note 1).
- The process is managed, i.e. there is an appointed manager responsible for CDE.
Now we have broken down the definition into more understandable core elements. I hope you get the concept of what CDE is and what purpose it serves.
2. One CDE or many?
ISO was primarily intended for use in projects with requirements for BIM Stage 2. It is the standard of most companies implementing BIM. There have been however a lot of projects that aim to satisfy the requirements for stage 3.
What impact does it have on CDE? BIM Stage 2 allows to provide a few solutions for one project. Oftentimes it ends up that a designer, contractor, and an investor have their own solutions. This CDE process has already been discussed by Konrad Naborczyk in his article: BIM in construction company and on site – part 2. BIM Stage 3 constitutes one CDE database that is collaborative and common for the whole project.
3. Who is responsible for establishing and managing CDE?
The standard clearly states that an appointing party is responsible for establishing and managing the Common Data Environment for the whole project.
If project implements an outside solution, then CDE should be the first signed contract in the project. Ideally, appointing party should establish CDE before issuing a tender.
The person responsible for keeping information secure, updated, coherent and synchronized for the project is ‘Information Manager’. Please do not confuse with BIM coordinator, as an Information Manager has no responsibility for the design or model coordination.
4. Assumptions a Common Data Environment
In order to manage information, data, and models in a professional manner, Common Data environment should satisfy the following criteria:
- Each project should agree on a naming convention and metadata classifications.
- Information container should have its unique ID in accordance with the agreed naming convention.
- Metadata should have values assigned in compliance with that convention.
- The following values can be assigned to each information container:
- Status,
- Revision,
- Classification.
- Possibility to modify each information container metadata according to its state of development
- Information container history log for each change of status with the following information:
- User name,
- Dates,
- Revisions.
- Possibility to arrange access control at the level of a single information container.
5. CDE process
Let me now present the key elements of the Common Data environment process.
We assign metadata to each information container in order to facilitate the managing of the process. Consequently, we can maintain order and assert control over information that pops up during the investment process. I picture below each of the metadata.
Information container state
Each information container during development might be in a different state. ISO 19650 graphics portray this process in a simplified form.
In practice, I can see three possible solutions for implementation of states of progress:
- Statuses in the form of metadata followed each document. In this case, CDE structure is in a tabular form (more about statuses below).
- Setting up folder structures with the name of statuses (Work In Progres, Shared, Published, Archive).
- Controlling user authorization within the common database.
Work In Progress
Information container exists in this state when the appointed party develops the design. Therefore, no other member of the project team can neither access nor see that information container.
In practice: The MEP designers are preparing another revision of a ventilation model. They are working on a shared model while keeping files and other information on the company’s server.
A solution for WIP state might be for instance Distributed File System or internal CDE.
Check / Review / Approve transition
A transition state in which the information container is checked in regards to project requirements, standards, and procedures. The team generating this information container is responsible for that check.
In practice: The work on the revision of a model has come to an end, so the designers have appointed a specialist responsible for this discipline. This person verifies the compliance with project requirements and accepts the model.
Shared state
Here lies all the documentation that serves for coordinate and further reference among appropriate project teams. Information containers are in the “Shared” state are visible and accessible by any project member. However, they are not editable. This is also a place for all other information that awaits the appointing party approval.
In practice: All discipline models in the IFC format are in the shared state and wait for multi-disciplinary coordination. Other documents waiting for authorization by an investor, such as requests for additional work also lies here.
Review / Authorize transition
A transition state in which the information container is checked in regards to project requirements, standards, and procedures. If the information container does meet the requirements, then it is moved on to the “Published” state. If, however, there are some flaws, then it is going back to the “Work in Progress”. Designers then correct it, give a new revision codes and the process begins from a scratch.
Authorization separates information that is correct. Once they are authorized, they can:
- Serve for detailed design by the project team,
- Be a basis for the contractor,
- Manage the asset.
In practice: After multi-branch coordination, a part of the project (let’s call it: Control Area 1) has been accepted. On the other hand Control Area 2 still needs some finishing touches, and information within this area in the model returns to “Work in Progress” state.
Published state
At this level, there is only information verified and authorized to use by further members of the investment process.
In practice: Once coordinated, Control area 1 changes its state to “Published”. At that time, a contractor can use it to place an order for building materials. If a contractor used the model from the ‘shared’ state, liability for possible errors would rest with him as he is using not authorized source of information.
Archive
This level serves as a journal of all alterations made to the information container during the project development. It might help to settle a dispute between the parties involved.
Unique ID
The name of each information container (document, drawing, model, etc) should be unique and consistent for the whole project (described in e.g. BEP). National Annex gives suggestions for the UK market. Let me describe the format I have been familiar with from a few investments in Norway.
Information container naming follows this pattern:
The number of the building – level – control area – discipline – system classification code – type of drawing – running number
6025-XX-S-A-200-00-001
Revision
All of us might remember working on a document in Word before Microsoft introduced automatic version control. If you saved your document using only ctrl+s you didn’t use version control. Without it you couldn’t get back to the document from the previous session. If you used the option: “save as” and then you named the file differently each time – you used revision. After two days you could find the previous document and checked any changes.
The version control in Google Docs aids me every time when creating new entries in the blog 🙂 The following infographics hit the nail on the head:
In CDE it functions similarly. ISO 19650 in the British version suggests the following solution:
P – non-contractual Preliminary information or C – contractual.
01 – revision of the information container that has been approved for sharing with other teams.
01 – changes introduced within work in Progres state (only one team can see this version).
The revision naming process is portrayed below. Information container in the state of “Work in Progress” changes its last digit as long as it stays inside one team. When it is accepted and hits the “Shared” state the number is changed to revision number P.02.01. If the information container is sent back to the “Work in Progress” level, the revision numbers are changed to P.02.02, P02.03, etc. Once the information container is verified and accepted, it reaches the “Published” level and is renamed into C.01.
In Norway in use is only 1-letter index A-Z, then 2-letter AA, AB, etc.
Of course, they are not the only right solutions. It depends a lot on the used solution – some use dates as metadata revisions, some use numbers. The most essential is again process and agreeing on a common format.
Statuses
Status codes metadata indicates the state of the information container in CDE. To clarify to each member of the team where the information can be used and where it can not. Furthermore, such a description informs about the progress of the information development.
The British National Annex provides codes to the project for each status:
If anybody is interested in delving into this matter, I recommend the documents created by UK BIM Framework – Information Management according to BS EN ISO 19650 Guidance.
On the other hand, Statsbygg (The Norwegian Directorate of Public Construction and Property) recommends in its guidebook PA 0603 using the following statuses:
D – to comment, internal coordination,
I – to comment, multi-disciplinary coordination,
C – for acceptance,
G – accepted,
U – invalid/archives.
Classifications
ISO recommends to assign each information container to a common classification for the whole project. Classification indicates what type of information is inside. It can define for instance a discipline (architecture, construction, ventilation), type of a drawing (model, plan, detail). However, it is vital that this classification does not duplicate other metadata assigned to this container (e.g. unique ID, statuses).
6. Summary
I have presented all that matters in regards to the Common Data Environment process in compliance with ISO 19650. My task has been to put it forth briefly, up to the point, and comprehensible. I am not so sure about the former (over 2000 words), I hope the latter lives up to your expectations. 🙂 Let me know whether you like this article. If so I will deal with other processes described in ISO.
Another entry will be about one of the possible software solutions that not only serves as a CDE solution but also meet other functionality criteria.
Common Data Environment workflow - Infographics
The information contained in the article is based on my own experience but also inspired by the information contained in the guide is based on my own experience, ISO 19650-1 and ISO 19650-2 and a Guidance to ISO 19650created by UK BIM Framework: https://ukbimframework.org/guidance
What actually happens with information containers when they change their status or when changes are made to them (e.g. as in a revision)?
Suppose you get an information container in WIP and want to pass through the Check/Review/Approve gateway. If you change the status code (via metadata, I guess) that applies to the information container as a whole. But I have never seen an information container in my life which I can accept wholly. There are always limitations and remarks.
So I see two options now.
1 – You accept and it gets a SHARED status. That applies to the whole information container? Or could you rather use subsets in a model (which according to the definition are also information containers) and assign the status to those? E.g. the columns on level 2 are now SHARED, but the columns on level 3 are still WIP? Is that how it is intended?
2 – Or you don’t accept the whole information container until every single piece of information can be approved? So you confirm its WIP status and you (or your colleague from the same task team) continues working on it? Nobody else can see that information container in WIP.
Once you have an information container approved it becomes SHARED or later PUBLISHED. Then you start additional work or make a modification. That would be a revision, the status becomes WIP again until approval and the previous revision needs to be assigned an ARCHIVED status. Would that technically be a new container? So do you make copies of an information container when you encounter metadata changes? Seems strange if you use metadata to indicate status.
P.S. Could by misunderstanding from my side… Maybe I’m still not getting the workflow…
Hey Stefan!
I’m very sorry for the lack of response – I must have overlooked a notification. To your question. Option 1 is a correct workflow – the status codes are set on elements. But all the IFC files are moved to the “shared” state so that BIM Coordinator can perform a check.
In practice, there are usually two models in use – one with WIP status (editable file, eg Revit) that is each week exported to IFC and moved to a “shared” state for coordination.
WIP, Shared, Published and Archive are more for files and documents whereas metadata, status codes and revisions are for objects within a model. More about status codes you can read here: http://bimcorner.com/how-status-codes-help-in-coordination-process/
This is a good article. Congratulations.
I’ve got lost a little bit, So, the status is representing the (work in process, shared ..etc) in codes? so it’s used in the file naming?
No worries! Status is in a way “deepening” the state (WIP, Shared, etc.). A document can be in a shared state but have different statuses: first only for coordination, and afterwards for approval.
In a 2D world, statuses were used on drawings (in the table). In the BIM world, statuses are often assigned to each object within the model, to help with filtering objects for coordination, etc.
Hope I clarified a little bit 🙂