Enabling your Project Digital Twin

As the world gears up for delivering digital twins, the progression of a project information model to be utilised fully by the various project control teams is becoming more real.

With this ability to expand the footprint of the information model across the enterprise, the importance of risk identification increases. This article looks to how this can be addressed for the various consumers of a project digital twin and ensure the project controls team can leverage and adopt the investment being made by the engineering teams in richer BIM models and ultimately deliver the complete project digital twin.

Employers Information Requirements

The requirement for a project team to deliver against the stakeholders’ various information demands and ensure a complete data handover is of course a pre-requisite of any engineering project which delivers infrastructure. This is just not an ISO 19650 requirement but has been a common requirement for Process and Power projects for many years. The adoption of the CFIHOS standard (and project) by IOGP highlights the importance of having an industry standard which enables engineering teams to digitise their workflows for an industry rather than individual clients.

However, even with a radical adoption of industry standards, the delivery of these “handover” standards is still not “digital” in the sense that we can link to them and build a compliance matrix digitally. Even the ability to extract the various requirements sees project teams poring over PDF’s or spreadsheets to extract and compile the various information needs.

Enabling a weekly report that can feed the various schedules and aligning these with the design models across the various modelling tools is not a simple process. Certainly those projects that can move to an asset centric delivery can make inroads here in reducing the information that needs to be entered into engineering models, but the requirement to engage with stakeholders or enable visual reports is becoming more prevalent and thus a project expectation.

Project Controls Requirements

Various handover requirements also need to be balanced against the various project controls to enable project control teams to carry out calculations quickly and easily while understanding the level of change that is happening across the engineering project.

The various KPI’s that should ultimately drive the design decisions should be readily available to ensure design changes are aligned with the stakeholders’ operations goals. A change of material can have a significant impact on carbon footprint; or the utilisation of an exotic steel may add a significant cost to a chemical plant but extend the life of the facility by many years. The trade off of design decisions is a continuous process between engineering teams and purse holders but should be driven by the ultimate goal of the asset.

The time between an engineering decision and the next carbon footprint calculation or while life cost calculation can considerably impact the ability to back track or unpick an engineering decision which may have involved some serious re-modelling to cater for the changes. Indeed, the ability to make changes becomes less as project gates are passed to ensure financial and schedule pressures are met.

Design Insights

The move to component based engineering will ultimately enable pre-packaged engineering content to be available to project teams for consumption. The modular driven design will thus be much simpler for project controls to stay aligned with the engineering content. However, while we can come up with a singular bridge design the reality is that the bridge requires a location which requires engineering and so the components need to ensure they can cater for the various project challenges that engineering teams face.

Project teams have access to various trade norms[1] to enable the breakdown of project costs, but early in the lifecycle these still tend to be closely guarded secrets within the various engineering companies.

Aligning engineering components with engineering estimated rates enables project controls to quickly carry out the various estimates required.

These calculations while being able to be rapidly carried out still require that the underlying data is understood and is sufficiently complete to carry out full calculations.

Digital Suitability Index

The Digital Suitability Index is a single calculation which is required to ensure consumers of the engineering model to understand the risk being adopted when basing calculations on the content. Just as https radicalised the trust in web sites, so the Digital Suitability Index needs to do the same for engineering models to ensure consumers can have a direct link to the engineering model and quickly determine if the model is fit for their purpose.

The issue of various suitability models[2] is a standard process and while these are formalised in various workflows the intention is still to indicate the risk from the originating authors.

Therefore the first requirement is to understand what information is available and how this can be assembled into a simple dashboard for consumers.

Querying the schema of an engineering model generally requires a deep understanding of the design tool and indeed requires access to the design tool or one of its dependent products.

To walk the building of Digital Suitability Index portal I am going to enable this through the iModel.js ecosystem.

Starting with imodelconsole[3] which is fundamentally a query portal into an iModel published from the various engineering tools.

SELECT cast(coalesce(schema.name || '.' || class.name, 'NULL') as string) AS ClassName, property.name as PropertyName, REPLACE(cast(coalesce(baseSchema.name || '.' || baseClass.name, 'NULL') as string), cast(coalesce(schema.name || '.' || class.name, 'NULL') as string), 'NULL') AS InheritedFromClass, property.description as PropertyDescription FROM ecdbmeta.ecclassdef class JOIN ecdbmeta.ecclassdef baseClass using ecdbmeta.classhasallbaseclasses FORWARD JOIN ecdbmeta.ecpropertydef property on property.class.id = baseClass.ecinstanceid JOIN meta.ECSchemaDef baseSchema ON baseSchema.ecinstanceid = baseClass.schema.id JOIN meta.ECSchemaDef schema ON schema.ecinstanceid = class.schema.id WHERE class.type = 0 AND (class.ecinstanceid in (select distinct be.ecclassid from bis.element be)) AND (schema.name not like 'BisCore') and (baseSchema.Name not like 'BisCore') and (property.PrimitiveType not like 2049)

Running the above query on a typical engineering model (OpenRoads, OpenBuilding Designer and Revit), advises me there are 5563 properties that may be of interest.

We need to distill this down to a single figure for each and every class.

select 'P01' version, '<class>' as class, count(ecInstanceId) as Instances, count(nullIF(<class>.<property1>, ''))+ count(nullIF(<Class>.<propertyn>, ''))) / (n.00 * count(ecInstanceId)) as TrustIndex from <class>

As you can see with a list of classes and properties this becomes a simple exercise … although identifying the “relevant” properties may not be so trivial, this can be a subscriber exercise where consumers can identify those properties that they want to extract.

Distilling the properties into the 171 class queries becomes a trivial exercise once we know the property and class.

However, running all 171 queries is not so trivial, so here we can leverage the iModel.js platform to run and extract the data[4].

Handling classes with single properties and properties with reserved names may make this a multi-pass exercise, but generally within 5 minutes, we are ready to load our dashboard with the relevant information.

Digital Suitability Index Dashboard

What can we tell from the dashboard ?

Well the first thing I note is that at 73.5% completeness, my model is in fairly good shape, and I can drill into the individual classes to determine which classes have the issues.

I can also see that there are only two applications which have provided the “intelligent” content, suggesting that my civil team have yet to submit their design to the information model.

Also note that we have built in versioning, so as the project progresses, we should expect the Digital Suitability Index to trend up.

In this dashboard we have not broken information out by location / asset / discipline but as the information is enabled, so the ability for consumers to quickly identify what information is available or for Digital Engineers to identify digital laggards is possible.

Hopefully the above gives an understanding of the importance of the quality of the project digital twin to ensure adoption by project control teams as well as driving the quality for handover to operations.

Bentley Systems would be interested in what standards and controls are adopted to ensure adoption of project digital twins and ensure a complete digital twin for handover to operations.

[1] https://bestimator.co.uk/ (for example)

[2] ISO 19650 has adopted national status codes rather than suitability codes

[3] https://imodelconsole.bentley.com

[4] In this instance we wanted to test iModel.js for accessing data, but utilising the Design Insights Data Connector with a UNION query would have been just as valid