-
Consolidating Concepts: Gemini Principles
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:Â
- ScopeÂ
- Normative ReferencesÂ
- Terms and DefinitionsÂ
-
Overview of Digital Twin for the Built Environment Â
- Concept of the Digital Twin Â
- Digital Twin for the Built Environment Â
- Applications (Uses) of Digital Twin for the Built Environment Â
- Benefits of Digital Twin for the Built Environment Â
- Observable Built Environment Elements Â
-
General Principles of the Digital Twin Framework for the Built Environment Â
- Overview Â
- Standardization Scope of the Digital Twin Framework for the Built Environment Â
- Requirements of the Digital Twin for the Built Environment Â
- 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.Â
-
1 Reply
-
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.
Log in to reply.