Consolidating Concepts: Gemini Principles

[DRossiter87]

As part of my last post Consolidating Concepts: Scope, I discussed a potential structure that a concepts and principles standard related to digital twin could adopt.  In this post, I’ll consider how this structure aligns to the Gemini Principles.  I’d greatly appreciate your views as to whether I’ve gotten this right! 

Using ISO/DIS 23247-1 (Digital Twin framework for manufacturing. Part 1. Overview and general principles) as a basis, I presented the following structure, now modified to include standard clause numbering: 

1. Scope 
2. Normative References 
3. Terms and Definitions 
4. Overview of Digital Twin for the Built Environment  
   1. Concept of the Digital Twin  
   2. Digital Twin for the Built Environment  
   3. Applications (Uses) of Digital Twin for the Built Environment  
   4. Benefits of Digital Twin for the Built Environment  
   5. Observable Built Environment Elements  
5. General Principles of the Digital Twin Framework for the Built Environment  
   1. Overview  
   2. Standardization Scope of the Digital Twin Framework for the Built Environment  
   3. Requirements of the Digital Twin for the Built Environment  
   4. Hierarchical modelling of Digital Twin for the Built Environment 

 

 

Considering the topics to be covered, a lot of good reference information is available within the Gemini Principles, the values set out by CDBB to aid the development of a National Digital Twin (NDT). 

• Pages 10 include definitions (3) as well distinguishing features of a digital twin (4.1);   
• Page 11 also includes several purposes which could form the basis of (4.3); 
• Pages 12-13 focus on the national digital twin application (4.3) as well as list several benefits (4.4); 
• Pages 16 outline the nine principles at high level (5.1); and 
• Pages 17-23 begin to establish the requirements of these principles (5.3). 

However, it is clear to see that the Gemini Principles does not cover all of these topics.  For example, it does not include any information about what elements a built environment digital twin may wish to observe/monitor (4.5), cover the standardization scope (5.2) or deal with the hierarchical modelling (5.4).  In which case, where can we find this information? 

For example, reports such as Flourishing Systems discuss different levels of aggregation: Component, System, and System of Systems.  Could this form the basis of our Hierarchical modelling? 

I wonder what other good information could also be extracted from Flourishing Systems… 

 

And there we have it, the Gemini Principles appear to be an ideal basis for the production of such a standard.  Reading this:   

• Have I correctly interpreted the content of the Gemini Principles? 
• What other documents could also support the production of such a standard? 

Please let me know in the comments as we consolidate the communities’ views around what concepts and principles are important to capture before the webinar on the 11th February at 10:00. Join us as we delve deeper into  a formalised set of concepts and principles for digital twins in the built environment. 

[Guest]

Hi Dan,

This looks a solid start, and is an area which needs standardising with some urgency. I think there's a lot we can learn here from the vagueness (BIM wash) that was abound around BIM at the beginning of the UK BIM programme whilst also creating an open framework that allows for emergent concepts, ideas, use cases and benefits like we've seen with the World Wide Web.

A crucial role for standardisation is getting to the point where procurement teams can buy Digital Twin services/systems/widgets with confidence and I feel this should be the priority for BSI Standards.

Just looking at the contents and (whilst I'm hesitant to challenge a Young Standard Maker of the Year) it's not totally clear about the scope or purpose of the standard from the contents. Principally I don't think "Benefits of Digital Twin for the Built Environment" belongs in a normative clause - should there be an Introduction clause? 

One of the early priorities should be to standardise the terminology, including defining which should and should not be normative definitions:

• "Digital Twin" - concept? Define which types of standards/clauses/provisions this term should be used in.  
• "a Digital Twin" - a specific instance which conforms with this standard? This is the bit that normative elements can hang off ("A digital twin shall/should/may be...)  
• "the Digital Twin" - conceptual instance of a Digital Twin? Perhaps don't use this term?
• "the Digital Twin for the Built Environment" - e.g. as distinct from the Digital Twin for Automotive Manufacturing?
• "the National Digital Twin" - feel like this is an informative reference
• "Digital Twins" - drafting guidelines required for when to use 
• "the Digital Twin Framework" - ?

For me, the most important aspects are "Applications (Uses) of Digital Twin for the Built Environment" and "Observable Built Environment Elements", because these are the aspects that bring us closest to having something that can be specified in a contract.

Would it also benefit from a "Things that are not Digital Twins" section? 

In my blog I argue that we should also define "Digital Twin Technologies" as the foundations that make a physical or digital object interoperable with other digital or physical objects. Again this would move us closer to standardising aspects that can be specified throughout the NDT programme, e.g. the IMF is a Digital Twin Technology.

[DRossiter87]

Hi @tombartley, thank you for this.  I'm glad you support the general premise, and I agree aspects like Applications (Uses) and Observable elements are important.  The goal of the workshop on the 11th is to test/challenge these headings with the community so Benefits may fall out.  As I mentioned in the previous post, I've (shamelessly) taken the clause structure from the manufacturing standard and adapted the headings to suit.

As the scope relates to an overview and principles standard (like ISO 19650-1) it behaves more like a guide to inform further standardization as opposed to a code of practice or a specification; meaning that a clause on benefits *could* work as guidance can include both recommendations as well as statements of fact.  However, just as Jeff Goldblum says in Jurassic Park:

Quote

"Your scientists standards authors were so preoccupied with whether or not they could, they didn’t stop to think if they should".

I think it'll depend as to whether the benefits we can identify relate specifically to the applications, or are more generic benefits.

Fully agree that the standard needs to formalize terminology.  This has been a strong theme from the CDBB team too.