The Global Archicad Community

[daviddelven]

Hello everyone,

I wonder if someone working using BIMcloud environment and also applying ISO 19650 and openBIM framework to its usual processes

Since the current technology in BIMcloud allows teamwork members to work simultaneously within the same information container (i.e. a *.pln file stored in BIMcloud), this seems to create a conflict with the workflows in an ISO19650-based CDE. This circumstance does not allow to establish a consistent traceability policy.

Revision workflows base on BS EN ISO 19650
Screenshot 2020-10-31 104613.png (1.39 MiB) Viewed 619 times

The diagram shows the journey of a single information container and its progress through different statuses and CDE Areas. The problem appears when teamwork members work on different model areas, such as disciplines, stories, zones... etc.., in the same *.pln file, with each respective BIMcloud roles applied.

There is a need for sharing a Revision from a corresponding per each of the different area progresses. (i.e., publishing an IFC file for the corresponding QC tasks, including also the corresponding native geometry in a different exported *.pln file, if the client also requires that).

Every user performs different progress within the same file when working simultaneously, but there is just one information container unless we apply a Hotlink-base approach using Teamwork, which turns the BIMcloud role permissions exclusively mapped to each of the different information container (single pln files), instead of becoming a feature to distribute edit permissions within the same file.

In my opinion, this is something that collides head-on with the ISO 19650 CDE Revisions.

I would like to know about your experience or thought about this topic.

Take care,

David

[stefan]

If you have a live model, editable by everybody, I’d consider it WIP. When you are ready to share, that would be a time to extract an IFC from it and upload that into gateway 1 - approval (WIP to SHARED).

The ISO 19650 CDE workflow is written for individual information containers which are shared (native or open). Having continuously editable models does not fit the stage 2 approach but would be more suitable for stage 3. And there every revision has to be a traceable transaction. I believe BIMcloud supports this. But then again, in most projects you’d have different model authors in different modeling environments so probably not one single cloud-synced model.

[daviddelven]

If you have a live model, editable by everybody, I’d consider it WIP. When you are ready to share, that would be a time to extract an IFC from it and upload that into gateway 1 - approval (WIP to SHARED).

The ISO 19650 CDE workflow is written for individual information containers which are shared (native or open). Having continuously editable models does not fit the stage 2 approach but would be more suitable for stage 3. And there every revision has to be a traceable transaction. I believe BIMcloud supports this. But then again, in most projects you’d have different model authors in different modeling environments so probably not one single cloud-synced model.

Hello, Stefan

Nice to read your thoughts.
IMO, your statement depends on what WIP you mean. The single Task Team (from a particular Appointed party) has a WIP activity that also has its internal QA/QC procedures that could be based on PLN or IFC intermediate outcomes (it is our case). That means whether you are in a WIP CDE area, you are sharing single information containers. For the ones using BIMcloud solution in that WIP CDE area and required to publish such those IFC files for further QC tasks outside the native environment, there is a conflict with Revisions due to the existence of different progress areas or zones in the same Information Container (as Teamwork workflow covers).

[daviddelven]

Considering the idea of 1 single cloud-synced model when there is just one discipline (task team) involved is, i.m.o., a workflow simplification that in some cases (or many) creates issues regarding QC and change traceability.

In our case, as a single task team, we work in separate files and also disciplines and further federation (MEP, STR and ARCH) since we cover them without third parties. The ifc-based QC activity requires the publication of different outcomes according to the different file progress.

The single cloud-synced model is not suitable for that approach, since it is in continuous progress and you cannot identify partial areas using any Identifier. Maybe in a mid or long term, with the promises of IFC5 and partial information exchanges, technologies such as BIMcloud or others openBIM-based (ACCA and the new UsIFC.server concept) we could be able to apply this traceability policy for internal SHARING.

[Eugenio]

Hi David and everyone,

Great Topic! So what is exactly the reason in your opinion why BIMcloud si not suitable as a CDE? Is it because not all disciplines can be developed alive in the platform?

If is not because of that, then why is it? In terms of Sharing files (weather is WIP, Shared, Published, Archived) it can be organise following these 4 stages I believe. It would be a matter of the permissions that are applied to the different folders.

Would in this sense BIM360, BIMsync or BIMtrack considered CDEs followingthe ISO19650 standards?

Thank you!

[stefan]

When configuring (or trying to configure) BIM 360 Docs in a project, we mostly relied on having separate folders for the different status codes (WIP, SHARED, PUBLISHED), as permissions in this platform are folder-specific. And then we added a review workflow, so to push a model from WIP to SHARED goes at least via a person to authorise (Gateway 1 WIP to SHARED). Once in SHARED, files are visible for all to download (in WIP they are only visible to the party doing the upload).

With a single cloud-model that is continuously updated (Archicad BIMcloud or Revit Cloud Models alike) you may have problems to indicate a single "version" of the model, as there are multiple parallel branches of the model being worked on, not unlike a Github repository. Only when at a certain moment everybody checks in and than extracts a single complete version of the model it seems suitable to push to SHARED.

ISO 19650 is formulated as a container-based approach. In most cases, the information containers will be individual files, but they could be subsets within a file. In that sense, you could consider each commit an information container, but they are impossible to track outside of the native cloud-connected workflow.

So I think it is best to extract container revisions as individual files to upload into the CDE solution when trying to follow ISO 19650.