Aspect-oriented modeling for reliable data twin creation in cloud-based ecosystem

Description

ASPECT-ORIENTED MODELING FOR RELIABLE DATA TWIN CREATION IN CLOUD-BASED ECOSYSTEMFIELD OF THE INVENTION

[0001] This application relates to the field of building management systems and, more particularly, to cloud-based systems for managing buildings.BACKGROUND

[0002] An advanced digital building platform is designed to enhance the management and sustainability of diverse built environments. With its wide range of features, the building platform caters to the operation of a broad spectrum of building types, ranging from expansive commercial complexes to residential spaces and intricate industrial facilities. It provides customers with the freedom to tailor its features that precisely caters to their unique needs and preferences.

[0003] On the surface, advanced digital building platforms appears as user-friendly, centralized hub, offering a straightforward and accessible environment. However, beneath this apparent simplicity lies a sophisticated ecosystem approach is concealed, engineered to foster scalability and adaptability.

[0004] Within this ecosystem, specialized domain-specific services take on the responsibility of managing distinct components of a building's digital representation. These services operate autonomously, delivering flexibility and facilitating effortless expansion. This approach empowers ecosystem participants to introduce new services or web applications, utilizing these specialized services as foundational elements, all while preserving the seamless operation of the entire system. Imagine a building as a complex puzzle, with domain services serving as the expert team systematically breaking it down into manageable puzzle pieces, each handled by experts.

[0005] However, challenges surface during the adoption journey, in a phase known as onboarding. In this critical stage, customers are tasked with digitizing their buildings, allowing them to fully utilize the subscribed features. Every piece of the puzzle must be meticulously described and collected, with the integration and merger of preexisting information, such as data from the engineering stage, playing a pivotal role inreducing the required manual effort. The building platform offers to streamline the onboarding process by simplifying complexity, amplifying efficiency, and ultimately delivering unmatched value to its users.

[0006] However, the quality and completeness of these digital twin models are of paramount importance, as these models serve as the foundation for efficient operation within the building platform. Insufficient or flawed digital twin models can result in misguided decision-making and unintended disturbances in the behavior of real-world objects.Challenges include:• Complexity and Scale: The creation of comprehensive digital twin descriptions is hindered by the immense complexity and scale of the data involved. Real-world buildings are multifaceted entities; describing them in detail is a daunting task.• Quality Assurance: Ensuring high-quality, complete digital twin models is crucial for reliable decision-making and operational stability. Inaccuracies or omissions in these models can have severe consequences.• Onboarding Complexity: Onboarding digital twins is resource-intensive, costly, and error-prone, impacting the overall functionality of building platform. Simplifying this process is essential for a seamless user experience.• Data Integration Complexity in Brownfield Scenario: Integrating accurate data from existing operational buildings into digital twin models in brownfield scenarios poses challenges. Fragmented data sources can lead to disjointed models, e.g., structural details in one system and equipment data in another.• Pre-construction Digital Twin Modeling in Greenfield Scenario: In greenfield scenarios, creating digital twins for buildings in the planning phase involves developing digital twins based on architectural plans and design data. Here, the challenge also lies in consolidating information from various sources (e.g., BIM models, engineering data) available during the planning stages.SUMMARY

[0007] In accordance with one embodiment of the disclosure, there is provided an approach to model digital twins of buildings so that they may be used to interact with and control the real-world building without being physically co-located with the building. The approach addresses the challenges in creating comprehensive digital twins for buildings. The approach empowers users to generate accurate and complete digital twins easily, whether dealing with brownfield or greenfield scenarios, ensuring the efficient and reliable operation of the building platform. In summary, the onboarding approach introduces a transformative solution that reimagines digital twin modeling, fostering an aspect-oriented, guided, automated, and decoupled onboarding experience.

[0008] One feature is a view from a certain perspective for creating a reliable digital twin of a building. Digital twin aspects for the building are established, building data associated with the building is collected, the digital twin aspects and building data are processed, and aspects or aspect elements are published into an operative environment. For example, one or more aspect elements may transform into elements that may be efficiently managed within an operational domain service, such as data structures as needed in the operative system to manage the pieces of the twin. The digital twin aspects are established by identifying a digital twin ontology that describe one or more digital twins within a designated domain. Also, the digital twin or twins are identified (e.g., broken down into one or more digital twin aspects) based on the digital twin ontology in which each digital twin aspect of the digital twin aspects offers a data view from a specific angle. The digital twin aspects are modeled in parallel automatically or manually based on a digital twin aspect type ontology, each digital twin aspect as modeled includes aspect elements, attributes of the aspect elements, and a type of relationship between the aspect elements. At least one portion of the aspects representing a particular digital twin element are consolidated into a unified representation based on overlapping aspect elements and a clear association between aspect elements.

[0009] Another feature is a system for creating a reliable digital twin of a building comprising an input component, one or more processors (hereinafter “processor”),and an output component. The input component collects building data associated with the building. The processor establishes and processes a digital twin aspects for the building. In particular, the processor identifies a digital twin ontology that describe one or more digital twins within a designated domain. The processor identifies (e.g., breaks down the digital twin or twins) one or more digital twin aspects based on the digital twin ontology in which each digital twin aspect of the digital twin aspects offers a data view from a specific angle. The processor models the digital twin aspects in parallel automatically or manually based on a digital twin aspect type ontology, each digital twin aspect as modeled includes aspect elements, attributes of the aspect elements, and a type of relationship between the aspect elements. The processor consolidates at least a portion of the aspects representing a particular digital twin element into a unified representation based on overlapping aspect elements and a clear association between aspect elements. The output component publishes the aspects or aspect elements into an operative environment. For example, one or more aspect elements may transform into elements that may be efficiently managed within an operational domain service, such as data structures as needed in the operative system to manage the pieces of the twin.

[0010] The above-described features and advantages, as well as others, will become more readily apparent to those of ordinary skill in the art by reference to the following detailed description and accompanying drawings. While it would be desirable to provide one or more of these or other advantageous features, the teachings disclosed herein extend to those embodiments which fall within the scope of the appended claims, regardless of whether they accomplish one or more of the above-mentioned advantages.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] For a more complete understanding of the present disclosure, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, wherein like numbers designate like objects.

[0012] FIG. 1 is a block diagram of the building automation system 100 in an example implementation that is operable to employ techniques described herein.

[0013] FIG. 2 is a block diagram of example components 200 of a management station for a building automation system of FIG. 1.

[0014] FIG. 3 depicts a metamodeling architecture diagram in an example implementation for defining a digital twin ontology.

[0015] FIG. 4 depicts a metamodeling architecture diagram in an example implementation for breaking down into aspects.

[0016] FIG. 5 depicts a metamodeling architecture diagram in an example implementation for modeling aspects in parallel.

[0017] FIG. 6, including FIGs. 6A, 6B, 6C, and 6D, depicts a metamodeling architecture diagram in an example implementation for consolidating aspects.

[0018] FIG. 7, including FIGs. 7A, 7B, 7C, and 7D, depicts another metamodeling architecture diagram in an example implementation for consolidating aspects.

[0019] FIG. 8, including FIGs. 8A, 8B, and 8C, depicts a metamodeling architecture diagram in an example implementation for transitioning to operation.

[0020] FIG. 9 depicts a metamodeling architecture diagram in an example implementation for the interactive modeling.

[0021] FIG. 10, including FIGs. 10 A, 10B, 10C, and 10D, depicts a metamodeling architecture diagram in an example implementation for automatic modeling.

[0022] FIG. 11 is a flow diagram of an example operation of a process that is operable to employ techniques described herein.DETAILED DESCRIPTION

[0023] Various technologies that pertain to systems and methods that facilitate modeling of digital twins of buildings so that they may be used to interact with and control the real-world building without being physically co-located with the building will now be described with reference to the drawings, where like reference numerals represent like elements throughout. The drawings discussed below, and the various embodiments used to describe the principles of the present disclosure in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the disclosure. Those skilled in the art will understand that the principles of the present disclosure may be implemented in any suitably arranged apparatus. It is to be understood that functionality that is described as being carried out by certain system elements may be performed by multiple elements. Similarly, for instance, an element may be configured to perform functionality that is described as being carried out by multiple elements. The numerous innovative teachings of the present application will be described with reference to exemplary non-limiting embodiments.

[0024] To effectively address the challenges outlined above, the system meets the following critical requirements, primarily from the perspective of the onboarding persona:• Simplicity: The system significantly reduces the complexity associated with digital twin modeling. It provides a user-friendly interface and streamlined processes that make it accessible and straightforward for users of varying technical backgrounds.• Efficiency: The system guides the user through the digital twin modeling process, with a strong emphasis on automation. It minimizes the need for extensive manual input, ensuring that onboarding occurs swiftly and efficiently, optimizing both time and resources.• Extensibility: The system supports the seamless addition of new elements to the onboarding scope. It is flexible and scalable, allowing users to incorporate diverse building types, data sources, and evolving requirements within the building platform ecosystem. This extensibility accommodates the ecosystem's growth.• Parallelism: The system enables modeling in parallel to the operative world and allow for validation before putting the twin into operation. It facilitates modeling and merging of pieces of the twins in parallel, enabling multiple users to work on elements simultaneously or ecosystem participants to integrate elements, thus allowing utilization of available information.One aim of the system is to promote onboarding simplicity, efficiency, extensibility, and concurrency to empower users in creating accurate and comprehensive digital twin models for buildings, regardless of their complexity or development stage within building platform.

[0025] Referring to FIG. 1, there is shown a block diagram of an example system, one of the many entities, that may communicate with the systems and methods for modeling digital twins of buildings. A building automation system (“BAS” or “system”) 100 is one example of such entities and described herein in an example implementation. The system 100 comprises one or more network connections or primary buses 102 for connectivity to components of a management level network ("MLN") of the system 100. For one embodiment, the example system 100 may comprise one or more management level devices or management stations, such as a management workstation 104, a management server 106, a remote management station 108 connecting through a wired or wireless network 110. A management station 104, 106, 108 may also be a portable management station 112 connecting through a wired or wireless link to an individual automation or field level device of the system 100. While a brief description of the system 100 is provided below, it will be understood that the system described herein is only one example of a particular form or configuration for a system. The system 100 may be implemented in any other suitable manner without departing from the scope of this disclosure.

[0026] For the illustrated embodiment of FIG. 1, the system 100 provides connectivity based on one or more communication protocols to subsystems 120, 122 for various building parameters, such as components of environmental comfort, fire safety, security systems, and other building management subsystems. Each subsystem 120, 122 may include various types of automation controllers and field devices 124, 126 for monitoring and controlling areas within a building or group of buildings.Examples of automation controllers and field devices 124, 126 include, but are not limited to, control panels, actuators, field panels, sensors, third-party devices, and the like. These automation controllers and field devices 124, 126 may communicate via one or more communication protocols, such as BACnet, KNX, Lon Works, Modbus, and the like.

[0027] Referring to FIG. 2, there is shown example components 200 of a management station 104-108, 112 for modeling digital twins of buildings. The device components 200 comprise one or more communication lines 202 for interconnecting other device components directly or indirectly. The other device components include one or more communication components 204 communicating with other entities via a wired or wireless network, one or more processors 206, and one or more memory components 208. The communication component 204 communicates (i.e., receives and / or transmits) data associated with one or more devices of the system 100 and its associated devices, such as the automation devices, field devices, and the other building devices. The communication component 204 may utilize wired or wireless technology for communication. Examples of wireless communication technologies include, but are not limited to, Bluetooth (including BLE), ultrawide band (UWB), Wi-Fi (including Wi-Fi Direct), Zigbee, cellular, mesh networks, PAN, WPAN, WAN, near-field communications, and other types of radio communications and their variants.

[0028] The processor or processors 206 may send data to, and process commands received from, other components of the device components 200, such as information of the communication component 204 or the memory component 208. Each application includes executable code to provide specific functionality for the processor 206 and / or remaining components of the management device 104, 106, 108. Examples of applications executable by the processor 206 include, but are not limited to, a data module 210 and an aspect module 212. The data module 210 identifies a digital twin ontology that describe one or more digital twins within a designated domain and breaks down the digital twins into digital twin aspects based on the digital twin ontology. The aspect module 212 models the digital twin aspects in parallel automatically based on a digital twin aspect type ontology and consolidates at least a portion of the aspects representing a particular digital twin element into a unifiedrepresentation based on overlapping aspect elements and a clear association between aspect elements.

[0029] Data stored at the memory component 208 is information that may be referenced and / or manipulated by a module of the processor 206 for performing functions of the management stations 104-108, 112. Examples of data associated with the management station 104-108, 112 and stored by the memory component 208 may include, but are not limited to, ontology data 214 and aspect data 216. The ontology data 214 includes digital twin ontology and digital twin aspect type ontology. The aspect data 216 includes broken down digital twin aspects, modeled digital twin aspects, consolidated digital twin aspects, and published digital twin aspects.

[0030] The device components 200 may include an input component 218 that manages one or more input components and / or an output component 220 that manages one or more output components. The input components 218 and output components 220 of the device components 200 may include one or more visual, audio, mechanical, and / or other components. For some embodiments, the input and output components 218, 220 may include a user interface 222 for interaction with a user of the device. The user interface 222 may include a combination of hardware and software to provide a user with a desired user experience.

[0031] It is to be understood that FIG. 2 is provided for illustrative purposes only to represent an example implementation of the management station 104-108, 112 and is not intended to be a complete diagram of the various components that may be utilized by the device. The device management station 104-108, 112 may include various other components not shown in FIG. 2, may include a combination of two or more components, or a division of a particular component into two or more separate components, and still be within the scope of the present invention. Also, the components 200 may be coupled directly or indirectly to each other to perform the operations of the device management station 104-108, 112.

[0032] A meta-object facility (MOF) metamodeling architecture comprising four layers. An M0 Level deals with real -world objects and data instances, including physical entities like buildings and their digital twins, which are crucial in systems like the building platform. At an Ml Level, abstract models, such as data and domainmodels, describe and relate MO objects. This includes models like the Building Technology Domain Model (BTDOM) and building platform Domain Models. At an M2 Level, languages that describe Ml models are specified. Notable examples include the Unified Modeling Language (UML) and the Web Ontology Language (OWL), used to define the structure and relationships of models in ML An M3 Level is the highest level and defines languages to describe the languages used in M2, focusing on metamodels that define the structure and semantics of the modeling languages.

[0033] The MOF and UML 2.0 employ these four levels (MO, Ml, M2, and M3) to organize and delineate the processes of modeling and metamodeling. At the MO level, one works with real -world data and objects; at the Ml level, models are constructed to represent and describe these real-world entities. The M2 level defines the metamodels that govern the structure of these models, while the M3 level concerns itself with metamodels that define the very languages used to create metamodels in the M2 layer. This architectural framework provides a structured and powerful means for managing complex modeling processes.

[0034] Our innovative onboarding solution revolutionizes the onboarding process by introducing an intelligent assistant that guides users in efficiently modeling digital twins through an automated, aspect-oriented approach. This user-centric system simplifies complexity, automates tasks, and supports collaboration, enhancing the efficiency and effectiveness of the onboarding journey.

[0035] Simplifying Complexity with Aspect-Oriented Onboarding• Traditional Monolithic vs. Aspect-Oriented Approach: The traditional monolithic approach to digital twin modeling can be overwhelming and unwieldy, especially when dealing with large and complex buildings. Our solution introduces an innovative aspect-oriented approach that breaks down digital twins into manageable "aspects."• Modular and Flexible Modeling: Users can focus independently on specific facets of digital twins, streamlining complexity and providing the flexibility to address unique needs.• Independence of Aspects: Each aspect operates autonomously without dependencies to other aspects so that contributions from other ecosystem participants, machines, or the application of copy-templates can be easily integrated.• Bridging User Expectations: Aspects act as intermediaries, bridging the gap between user perspectives and the intricacies of digital twin management. This approach ensures that users can work with digital twins more intuitively.• Cross-Cutting Nature: Aspects transcend domain boundaries, enabling a holistic approach to digital twin management, irrespective of the underlying division into domain services.• Meaningful and Usable: Aspects are designed to cater to a wide range of user needs without excessive complexity. This specialization ensures meticulous curation by experts in relevant fields, enhancing the overall quality of the digital twin.• Standardization and Extensibility: While aspects provide flexibility, they adhere to a certain level of standardization. Plus, aspects can be added at any time to accommodate evolving requirements and ecosystem growth.

[0036] Enhancing Efficiency with Guided Onboarding• Feature-Based Guidance: Users receive recommendations on which aspects to model and to what extent, based on subscribed features, streamlining the onboarding process.• Comprehensive Modeling Instructions: Detailed instructions and templates simplify the modeling process, making it more efficient.• Completeness Checks: Thorough assessments ensure that digital twins are comprehensive, with alerts for missing information, reducing errors and increasing accuracy.• Readiness Assessment: Assessments go beyond modeling to determine when digital twin parts are ready for the operative ecosystem, ensuring smooth integration.

[0037] Boosting Efficiency with Automated Onboarding• Aspect Automation: Aspects are derived automatically from already-modeled information, saving users time and reducing manual effort.• Interactive Modeling: Users receive real-time model proposals as they input additional information, allowing the digital twin to evolve intelligently. This streamlines the modeling process.• Templates and Rules: Users can establish and apply copy templates and onboarding rules for standardization, ensuring consistency across digital twin representations.• Consolidation Assistance: The system actively identifies redundancies within the digital twin model and suggests consolidation solutions, improving efficiency.

[0038] Enabling Concurrency with Decoupled Onboarding• Parallel Aspect Modeling: Users can work on different aspects concurrently, without dependencies, saving time and enabling efficient collaboration.• Integration of Data Sources: Scattered information from various sources can be seamlessly integrated. The collaborative nature of the ecosystem allows various participants to contribute aspects, enhancing the richness of the digital twin.• Lazy Execution of Modeling Results: Users can save draft aspects for later review, refinement, and selective publication, ensuring thorough validation before integration.

[0039] In summary, your smart onboarding assistant solution greatly simplifies the modeling of complex digital twins by providing an aspect-oriented approach that simplifies complexity, enhances efficiency, and supports collaboration. It empowers users to efficiently model digital twins, automates tasks, and ensures a smooth onboarding journey. The modular, flexible, and user-centric features of the solution streamline the process, saving users valuable time and resources, and improving the overall quality and effectiveness of digital twin modeling.

[0040] How It Works in Principle

[0041] In the following sections, we will delve into the core concepts and operational principles of our onboarding solution. This will be illustrated through a step-by-step scenario to provide a comprehensive understanding of how it works.

[0042] Define Digital Twin Ontology

[0043] Definition: A digital twin ontology is a structured vocabulary residing within the Ml Layer, specifically defined to describe digital twins, their interconnected relationships, and characteristics within a designated domain.

[0044] Its primary purpose is to establish a common language for stakeholders to effectively work with digital twins. It ensures precise, consistent, and unambiguous representation, ultimately facilitating seamless collaboration among the stakeholders within the ecosystem. In The building platform, the aggregation of all building platform Domain Models constitutes the digital twin ontology in our onboarding solution.

[0045] Referring to FIG. 3, there is shown a model to describe the holistic twin 302, such as the digital twin of a building. To illustrate this concept, we can consider the three Bx Domain Models 300 introduced in the preceding sections as our assumed digital twin ontology within the context of the building platform. For example, the building structure domain 304 may include locations, subtypes of locations, floors, rooms, and the like. A location may include assets 306, a buildings may include assets, a floor may include assets, etc. in the sense that the assets are physically located at each of those locations. Assets 306 may include equipment and / or devices. Equipment has a type, such as a chiller or boiler. Also, there may be relationships between equipment, such as one equipment being part of another equipment or a medium being fed from one equipment to another. Points 308 of a point domain are used to work the assets 306. Points 308 of point domain are grouped into point groups, and the point groups are assigned to entities. The entities may be in an asset 306. An instance of a building may have floors, in which each floor has rooms, assets, points of the assets. In order to define aspects, the aspects are consolidated in a “picture” as described by the model, i.e., a consolidated model.

[0046] Break down into Aspects

[0047] Definition: A digital twin aspect is a specialized and meaningful perspective on a digital twin, offering a comprehensive view from a specific angle, tailored to domain-specific onboarding requirements. Think of these aspects as interchangeable camera lenses, each zooming in on different facets of a building. For instance, some aspects might delve into energy consumption, structural elements, or equipment. By creating various types of aspects, we have a toolkit of lenses, each tailored for specific onboarding requirements.

[0048] Independence and Modularity: These aspects are intentionally designed to be independent and modular. This means they can be managed separately without concern for interactions with other aspects. This modularity empowers experts to focus on the aspects within their expertise while allowing the integration of diverse sources within the ecosystem. Although they operate independently, aspects are cleverly designed to overlap and merge cohesively, forming a holistic representation.

[0049] Smart Overlapping: Despite their individuality, aspects are designed to work harmoniously by overlapping. When we merge these aspects together, they interlock seamlessly, much like pieces of a puzzle, forming a comprehensive and holistic image of the digital twin.

[0050] Cross-Cutting Nature: Aspects are not constrained to a single domain; they are cross-cutting in nature and can span multiple domains. For instance, modeling something complex like medium consumption involves elements from various domains, including building structures, specific disciplines, and data points for consumption and meter equipment. Well-designed aspects can be tailored to meet these diverse requirements.

[0051] User-Focused Intermediaries: Aspects serve as intermediaries connecting the user's perspective with how the digital twin's components are managed by domain services, ensuring a harmonious bridge between different viewpoints and operational needs.

[0052] Adaptability and Extensibility: As the ecosystem evolves, new types of aspects can be added, making the modeling solution adaptable to changing requirements and accommodating various data sources and participants.

[0053] Definition: A digital twin aspect type delineates a distinct viewpoint on a digital twin, addressing specific requirements of the onboarding process.

[0054] Ensuring Consistency: To maintain consistency and standardization, each aspect type is equipped with an ontology that formally defines the rules and constraints for modeling an aspect.

[0055] Definition: A digital twin aspect type ontology provides a formal description of a certain perspective of the digital twin, defining how aspects of a specific type can be modeled. In The building platform, each aspect's ontology is formalized using the Web Ontology Language (OWL) and described as a JSON schema. This approach allows for easy transformation of a JSON-based aspect description into a JSON-LD document, which can serve as both a JSON document and an RDF graph when needed.

[0056] Referring to FIG. 4, the model may be used to formulate multiple aspects of the model. There is shown an illustration of four digital twin aspect types 402, 404, 406, 408 and their ontologies 412, 414, 416, 418 as examples.• Building Structure Aspect 402, 412: Designed for modeling buildings and their structural components, including elements such as floors and rooms. For a certain class of the model, the system may progress along a path through the model in which there is only one type of path for this progression. For this reason, there cannot be on a particular level multiple types of bubbles.• Location Assets Aspect 404, 414: Dedicated to modeling various locations, such as campuses, buildings, floors, or rooms, along with assets located within these locations, including equipment and devices. Generally, a location may be a building, floor, room, etc., and the location may include assets such as an equipment or device. An instantiation of this aspect would be a particular location has a particular equipment, such as a room having a chiller.• Equipment Parts Aspect 406, 416: Serves the purpose of modeling equipment and its various components, including subcomponents and their constituent parts. There may be equipment with part relationships.• Equipment Device Points Aspect 408, 418: This aspect is utilized for modeling equipment and its associated devices, along with the specific device points relevant to the equipment. For example, an equipment may be controlled by a device, and the device may host points that are relevant to the equipment.

[0057] Hierarchical Structure: Each aspect model operates as a directed graph, establishing a hierarchical structure where aspect elements at one level must be of the same type or a sub-type. Hence, they allow only a single type of relationship between different levels, permitting only one distinct path for navigation through the digital twin ontology. When introducing new aspect types, a typical practice is to designate a specific entry point within the digital twin ontology as starting point from which you navigate along a well-defined path dictated by the established relationships of the ontology. The ontology model is distinguished into smaller parts, and the aspect models define a type of base. The bases are restricted in that, for example, one base may include one type such as a building, floors, and rooms. In this manner, the system may focus on the one base of a particular aspect model without worrying about data associated with other aspect models.

[0058] Example: Starting at "Location," you can traverse the "hasAsset" relation to an "Asset," which may include a variety of items. However, within a specific aspect type, only one path can be traversed, forming a directed graph.

[0059] In summary, the structured and modular nature of aspects simplifies the process of digital twin modeling, ensuring consistency and standardization while accommodating evolving requirements and data sources within the building platform ecosystem. Each aspect offers a unique perspective on the digital twin, enhancing its comprehensiveness and adaptability.

[0060] Model Aspects in Parallel

[0061] Definition: A digital twin aspect model is a structured description of a specific digital twin aspect residing on M0 Layer in compliance with the rules defined by the aspect type’s ontology. It encompasses aspect model elements, their attributes and one type of relationship between them.

[0062] Referring to FIG. 5, there are shown modeled versions of intended aspects 500 in an example implementation.• Building Structure Aspect: The model element "Building Thia" represents the building "Thia, Zug, Switzerland" in the "Building Structure" aspect, providing a description of the building's structure 502, 512.• Equipment Location Aspect: In some “Location” “Room 1” an Equipment "AHU A" is located 504, 514.• Equipment Parts Aspect: Another model element, "AHU 1stFloor," represents the same air handling unit within the "Parts" aspect, offering information about its constituent parts 506, 516.• Equipment Device Points Aspect: Yet another model element, "AHU1" represents an air handling unit within the "Equipment Device Points" aspect, which describes the device controlling the air handling unit and the associated points 508, 518.

[0063] Validate Modeled Aspects

[0064] Each type of aspect comes with a carefully designed set of governing rules. These rules specify what can be represented within the aspect and the restrictions that must be strictly followed.

[0065] Beyond these fundamental rules applicable to all aspects, the aspect's ontology acts as the comprehensive guide for the aspect model. It outlines the permissible types of aspect elements, their associated attributes, and the acceptable relationships between them.

[0066] Consequently, the aspect description must undergo a validation process against its ontology to verify its conformity with the rules. This validation checks serve to confirm that the aspect conforms to the specified rules. Validation assesses the type of elements being represented within the aspect, their attributes, and the relationships they establish.

[0067] Additionally, beyond the structural rules expressed in the aspect's ontology or JSON schema, there may be additional semantic rules in place. These semantic rules ensure that whatever is being modeled makes semantically sense.

[0068] Example: In an "Equipment Parts" aspect, a rule could dictate that a piece of equipment that is part of another equipment cannot simultaneously be part of yet another equipment.

[0069] In essence, these rules serve as essential guides for preserving the integrity and logical consistency of digital twin models, guaranteeing that aspect elements are conceived and described in compliance with the specific rules and constraints established by the aspect category.

[0070] Transform Aspect Elements

[0071] As previously discussed, the process of drafting aspects in a parallel onboarding environment brings forth numerous advantages, including:

[0072] Review and Validation: It enables a comprehensive review and validation of aspects, ensuring they align with requirements before having any direct impact on the building's operation.

[0073] Overlap Detection and Merging: Particularly valuable when dealing with data from ecosystem participants or external systems, this approach facilitates the detection of overlaps and the potential merging of information with previously modeled data before it becomes part of the operational environment.

[0074] Selective Onboarding: Users gain the power to selectively onboard only essential elements, leading to cost optimization, as maintaining an extensive model can be financially burdensome.

[0075] Purpose-Driven Onboarding: Ultimately, this approach promotes purpose- driven onboarding, allowing onboarding personas to meticulously select elements that align with their specific requirements.

[0076] However, the transition from the parallel onboarding environment to the operational domain services necessitates a transformation of the drafted elements into entities and resources that can be effectively managed by the Bx domain services.

[0077] Here, aspects act as intermediaries, facilitating the seamless transition from the broad cross-cutting views tailored to onboarding requirements to elements that can be efficiently managed within the operational domain services.

[0078] To gain a deeper understanding of this transformation process, let's explore how aspects are converted into operational entities, resources, and elements, ensuring a smooth connection between the drafted elements and the operational domain services.

[0079] Initially, aspect model elements are drafted.

[0080] Definition: An aspect model element is a granular building block within an aspect model. It represents specific digital twin elements within a chosen perspective or viewpoint. These elements may establish relationships with other aspect model elements within the same aspect. Each aspect model element adheres to a specific type.

[0081] Definition: An aspect model element type is a precise specification that categorizes a class of certain aspect model elements, providing a clear understanding of their role and attributes.

[0082] To successfully transform an aspect model element into an operational entity or resource, it needs to "know" its target, i.e., it must be aware of the type of digital twin element it aims to become within the building platform. This knowledge is encapsulated within the aspect model element type, which understands its corresponding target digital twin element type.

[0083] Definition: A digital twin element type categorizes elements that can be integrated or depicted within a digital twin model, emphasizing their role as entities or resources managed by the Domain Services.

[0084] These element types clarify what type of elements can be created or targeted through the modeling of aspect model elements.

[0085] Definition: A digital twin element serves as a representation of an entity, resource, or element within a digital twin model, managed by the building platform domain services. It is considered "published" or operational if it contains a reference to its representation in one of the domain services, marking it as part of theoperational environment. The absence of such a reference indicates that it only exists in the decoupled onboarding environment, representing a target or aspiration that has yet to be integrated into the operational world.

[0086] To better understand the mechanics of this transformation, let’s consider the "Equipment Parts" aspect as an example. In this aspect, we have modeled an equipment named "AHU 1st Floor," which has two parts: "Van" and a "Terminal Unit." Importantly, all of these aspect model elements share the type "Equipment."

[0087] Each aspect model element type, in this case, "Equipment," possesses knowledge of its target digital twin element type, which, in this scenario, is an entity of type "Equipment." Consequently, we can derive three digital twin elements targeted by these three aspect models, resulting in three distinct equipment entities within the digital twin.

[0088] Additionally, the equipment "Van" and "Terminal Unit" are functioning as a part of another equipment “AHU 1st Floor”. They actually carry the aspect model element type "Equipment Part." This type is aware that it needs to transform into two things: an equipment entity on one hand and, on the other hand, a "Part" resource associated with the entity "Equipment" of which it is a component. Here, one aspect model element type effectively targets two digital twin model elements.

[0089] The transformation process aligns the aspect elements with their respective digital twin entities and resources in a coherent manner, ensuring a seamless bridge between drafted and operational digital twin elements.

[0090] Referring to FIG. 6, including FIGs. 6A, 6B, 6C, and 6D, the system stitch or combine the distinct parts together into a single graph or unit 600. In FIG. 6, the derivation of target digital twin elements 602 are applied to the example. Each modeled aspect elements 604, 606, 608, 610, as identified with separate and distinct categories 612, 614, 616, 618, targets a particular digital twin element 602 of a specific type, as depicted in the diagram of FIG. 6. Examples 620 of digital twin elements 602 include, but are not limited to, a building structure element, a location assets element, an asset (equipment or parts) element, and points element.

[0091] Consolidate Aspects

[0092] As previously explained, aspects are designed for independent modeling, providing the flexibility for onboarding personas to concentrate on individual aspects. This approach also facilitates the integration of aspects contributed by other ecosystem participants, or those derived from data originating in external systems or available data sources.

[0093] However, the capacity to model aspects independently and to initially draft aspects in a parallel non-operative onboarding environment before introducing them into the operative world necessitates a transformation and consolidation process. Drafted elements must eventually be transformed into operative entity and resource managed by the Bx domain services. Aspects drafted and managed in parallel must be consolidated, while integrating elements that are already operational and managed by the domain services.

[0094] Eventually multiple aspects are to be merged or consolidated into a unified and comprehensive representation. An aspect is self-contained by nature and exists independently from other aspects. However, aspects may overlap, meaning that certain aspect model elements within these aspects represent the same thing. The essential consolidation step is to identify these overlapping elements (duplicates) and establish a clear association between them, signifying that they represent the same Digital Twin Element.

[0095] An instance in our example is considered where there are three different aspects: the "Location Assets Aspect," the "Equipment Parts Aspect," and the "Equipment Device Points Aspect." Each of these aspects contains model elements that represent different aspects of the same physical entity, in this case, an "Air Handling Lfriit" (AHU) labeled "AHU A," "AHU 1st Floor," and "AHU 1." All three of these model elements target or describe the same digital twin element, which is an Air Handling Unit.

[0096] As a result, these multiple Aspect Model Elements that correspond to the same physical AHU can be merged into one comprehensive Digital Twin Element. This consolidated digital twin element now includes a collection of aspect model elements that represent the same AHU. By merging these aspects and their model elements, we achieve a holistic representation of the real-world entity (the AHU) within the digitaltwin framework: the AHU’s location, its parts, and it’s controlling device along with the points.

[0097] This approach is elegantly simple yet remarkably potent. It empowers automated systems to deduce and flag potential duplicate information, particularly when various aspects are integrated from diverse sources. Consider a scenario where the architectural details of a building are derived from a lifecycle twin through the import and transformation of a Building Information Model (BIM). Simultaneously, other components of the same building structure might have been manually modeled, or data related to the building's systems could be contributed from a Building Management System (BMS).

[0098] This approach enables the independent management of these diverse contributions, ensuring that they remain distinct in their origins while still permitting their harmonious consolidation. In practical terms, this methodology allows different aspects to seamlessly merge into a unified and all-encompassing representation of the same real-world entity.

[0099] Referring to FIG. 7, including FIGs. 7A, 7B, 7C, and 7D, when we put this approach into action within our entire scenario and consolidate all duplicated elements into a single digital twin element, the outcome 700 appears as shown in the figure. In consolidation, certain elements 604, 606, 608, 610 represent the same digital twin element 602. For example, a “Dialogue: Room” element 704 and a “Room 1 : Location” element 706 may target the same room. Thus, these specific elements 704, 706 may be associated with a particular digital twin element 720 associated with that room, i.e., “Dialogue: Room”. Accordingly, the one target digital twin element 720 is associated with the two consolidated aspect model elements 704, 706. Similarly, as another example, another target digital twin element 720 “AHU IstFloor: Equipment” may be associated with three consolidated aspect model elements, namely “AHU A: Equipment” 706, “AHU IstFloor: Equipment” 708, and “AHU1: Equipment” 710.

[0100] Transition to Operation

[0101] The process of publishing aspects is a crucial step in the digital twin onboarding journey. Aspects are initially drafted in the parallel onboardingenvironment, where they can be thoroughly reviewed, refined, validated, and consolidated. It is within this environment that the user decides to "publish" aspects or their elements thereof into the operative environment. This publication is the process of evolving digital twin elements from draft status to operational status, where they become entities, resources, or resource elements within the Bx domain services.

[0102] This approach empowers users to choose whether to initially operate within a parallel and isolated onboarding environment, safeguarding the operational domain services from immediate impact. This flexibility enables users to refine the digital twin before introducing it to the productive environment, thereby averting unintended behavior in the operational setting. Additionally, this approach proves invaluable when ecosystem participants contribute elements that may overlap with previously onboarded elements, necessitating validation to prevent unintentional duplications or undesired behavior within the domain service.

[0103] To facilitate this publication process, aspect elements are transformed into entities, resources, or manageable elements within the Bx domain services, as previously detailed. They are then officially "published" (deployed) into the operational environment.

[0104] If the digital twin element is already published, it holds a reference to its published entity or resource in one of the domain services. If not yet published, it lacks such a reference but holds a description resulting from the consolidation of its aspect model elements.

[0105] Referring to FIG. 8, including FIGs. 8A, 8B, and 8C, in our example scenario 800, after aspects have been meticulously modeled in parallel, validated, transformed, and consolidated, they are officially transitioning into the operational world. For each aspect model 810, each aspect knows the relationships 812, 814, 816 to other aspects based on the outcome 700 (including 704-710, 720) of FIG. 7. Accordingly, the aspect oriented modeling provides a holistic twin to a user of the system based on simple detached groupings of the collected data. Data of a facility is collected for the aspect model 810 where aspects are identified and grouped, the groupings are consolidated to form a building digital twin 820, and the consolidated groupings are published as a building information layer 830 for the user. The information layer 830may include one or more services, such as a building structure service, an equipment & device service, and a point service, as well as the relationship between these services.

[0106] How to Boost Modeling

[0107] Interactive Modeling

[0108] Boosting modeling through interactive modeling is like solving a Sudoku puzzle. In Sudoku, you're given a grid with some numbers, and the goal is to fill in the remaining empty cells following specific rules. To do this, you need a systematic approach, logic, and deduction. You start by placing numbers that you're sure of because of the numbers already in the same row, column, or sub-grid. This process gradually uncovers more numbers, making it easier to figure out the right ones.Sometimes, you even keep track of possible options for the empty cells.

[0109] Now, think of the digital twin elements and aspects as another kind of grid that needs filling, but with its own unique rules. Some cells are already filled, which happens when a digital twin element is represented in an aspect. To complete the grid, you use logical thinking and the rules related to aspects to propose how to fill it.Much like Sudoku, every time you add a new aspect model element, it changes the grid, and you can deduce or at least outline more aspect elements.

[0110] Here's how this interactive modeling process works:• Type-Based Exclusions: The onboarding assistant acts as an experienced Sudoku player, well-versed in the game's rules. It knows which types of elements should or shouldn't be placed in certain aspects. For instance, it understands that a "Building" doesn't belong in aspects like "equipment parts" or "equipment device points." This allows you to focus on what can and should be modeled.• Logical Deduction: Similar to making logical moves in Sudoku, when you model an element in one aspect, it helps deduce related elements. For example, if you're modeling equipment, it logically implies the need for a location. Even if you don't know the exact location yet, you can create a temporary placeholder for it, much like considering potential numbers in a Sudoku cell. Another example is whenequipment is part of (contained in) another equipment. In this case, you can logically deduce that it should share the same location as the parent equipment.• Smart Error Detection: Think of it as Sudoku with a guide. If you make modeling errors, it alerts you and offers suggestions for correction. For example, it can notify you if you've placed an equipment, which is part of another equipment, in a different location than its parent, or if you've incorrectly modeled an equipment to be part of multiple other equipment, which isn't possible.• Overlap Detection: If you or another ecosystem participant or the machine has created similar elements, it helps you identify them and suggests merging them. For example, if you've already modeled a building and its floors, and now another contributor provides the entire building structure, the system can merge them into a single structure so that the floors also contain rooms.

[0111] In essence, this interactive modeling experience, guided by semantic rules, prompts you with new elements, much like clues in Sudoku, making the process engaging and logical.

[0112] Referring to FIG. 9, in response to determining the above described metric, the system may perform further analyses 900 to identify missing aspects. As previously explained, each digital twin element 902 may be associated with a building structure aspect 904, a location assets aspect 906, an asset aspect 908, and / or a points aspect 910. The determination of some information may lead to determination of other information. For example, the system may determine that the digital twin elements 902 includes a Van and a Terminal Unit that are associated with the assets aspect 908. By filling-in the assets aspect information, other missing information 912 may be identified since everything in the system is typed and those logical conclusions may be determined. Thus, the system may determine that the Van and the Terminal Unit should be associated with a location assets aspect 906 and a points aspect 910. The system may further determine that other non-missing information 914 for a particular digital twin element 902 should not exist. For example, an equipment should have representation in the location assets aspect 906 and the points aspect 910 but may never have representation in the building structure aspect 904.

[0113] In our example 900, a "Building" Digital Twin Element will never have a matching element in the "Equipment Parts" or "Equipment Device Points" aspect since these cannot represent a building. Conversely, if an "Equipment" exists in the "Equipment Parts" or "Equipment Device Points" Aspect, then it should also exist in the "Location Assets" Aspect, even if initially labeled as "Location" without a specific name. In other words, further Aspect Model Elements can be deduced or excluded.

[0114] Automated Modeling

[0115] Automated digital twin modeling is the automatic creating and expanding aspects within a digital twin based on already modeled elements, also known as semantic enrichment. While interactive modeling, as detailed in the previous chapter, offers one form of automated modeling through intelligent recommendations, automated modeling takes this a step further.

[0116] One of the cornerstones of automated modeling is the use of semantic inference rules. These rules enable the system to autonomously deduce new aspects or expand existing ones, thus significantly augmenting the depth and breadth of the digital twin.

[0117] Referring to FIG. 10, including FIGs. 10A, 10B, 10C, and 10D, imagine you are modeling a relationship where "Equipment A feeds Equipment B" within the "Equipment Feeds" aspect. Here's where automated modeling 1000, driven by semantic inference rules 1010, comes into play. Based on this relationship, the system is capable of deducing the need for a new aspect - the "Connectable Connection" aspect. This aspect is specifically designed for handling aspects related to medium consumption and flow modeling. As a result, from the "feeds" relationship, the system logically concludes that Equipment A 1020 plays the role of a "Connectable" and connects through a "Connection" 1030 to Equipment B 1040, which also serves as a "Connectable." Therefore, this aspect can be automatically derived based on these inferencing rules.

[0118] Another form of semantic enrichment is based on the data points hosted on a device. These data points represent the properties of various elements and are often referred to as qualities of interest. Leveraging logical reasoning, the system automatically associates data points with the entities they most likely belong to.

[0119] Consider this scenario: Given a description of a data point, the system can deduce the type of equipment it interfaces with. This streamlined, automated identification process empowers the system to draft and propose new equipment elements, which users can then accept, modify, or reject. Once these proposals are approved, they undergo the publishing phase, ultimately leading to the creation of operational equipment within the equipment and device service.

[0120] In summary, automated modeling boosts the efficiency of digital twin modeling while also ensuring consistency and standardization.

[0121] Use Copy Templates

[0122] Definition: A Digital Twin Template is a pre-defined copy-template for creating digital twin representations, consisting of multiple Aspects.

[0123] Purpose: The main purpose of a Digital Twin Template is to accelerate the creation of digital twin representations. Users can save modeled elements as templates for consistent and efficient modeling, serving as starting points to streamline the process and promote standardization within the digital twin framework.

[0124] Benefits:• Efficiency and Time Savings: Digital Twin Templates significantly expedite the process of creating digital twin representations, saving time and effort by providing pre-defined templates as a starting point.• Consistency and Standardization: These templates enforce standardization, ensuring that digital twins adhere to established standards and best practices, maintaining consistency.• Reusable Assets: Users can save previously modeled elements as templates, creating a library of templates covering various use cases and scenarios, reducing errors and inconsistencies.• Reduced Learning Curve: Simplifies the modeling process, making it accessible to a wider range of users, including those with limited technical knowledge.• Flexibility and Adaptability: While structured, these templates are adaptable to specific needs, providing flexibility for customization.Quality Assurance: Customers can implement quality control mechanisms at the template level, reducing the risk of errors and ensuring predefined quality standards.

[0125] In summary, Digital Twin Templates provide a structured and efficient approach to digital twin modeling, saving time, enhancing consistency, and promoting standardization.

[0126] Translation Service

[0127] The building platform customers or vendors may provide information for onboarding written in different languages, maybe using one of the external international standards outlined earlier in this document. That's when the Translation Service comes to the rescue. It turns this information into a format that easily fits into the onboarding system, preventing the need for manual data entry and keeping information from getting lost.

[0128] This service works because the building platform follows a set of rules. It uses an internal standard called Building Technology Domain Model (BTDOM) to govern its own Bx domain models to ensure that they are semantically compliant with BTDOM. The mapping of the building platform domain models and BTDOM is well- defined, even formalized in machine-interpretable way as a set of executable translation rules. It means that a machine can automatically turn the building platform descriptions into BTDOM descriptions.

[0129] Also, BTDOM acts as a bridge to connect with external standards, like the ones mentioned earlier. This connection helps translate information from different industry standards into the building platform's language. This bridge facilitates the translation of data initially presented in standards such as Brick and others into the building platform domain model, and subsequently into the realm of aspects' ontology. This versatile approach even extends to information described in languages other than the standard language used in the building platform, ensuring that it can be seamlessly integrated into the digital twin of the structure.

[0130] The foundation of this Translation Service lies in the extensive knowledge and control that the onboarding solution possesses the semantics. This knowledge encompasses a profound understanding of how these aspects interrelate with the building platform domain model, the formalized mapping of this model to the internal standard BTDOM, and, most critically, the successful bridging and connection that BTDOM establishes with a plethora of industry standards.

[0131] In a nutshell, the Translation Service in the building platform is like having a super-smart language and information converter. It makes sure that no matter how people describe things or what language they use, it all fits nicely into the building platform system, creating a complete digital picture of the buildings.

[0132] The system provides a comprehensive solution for digital twin modeling within the building platform an ecosystem that encompasses domain services and web applications, all guided by a Domain Driven Design (DDD) approach. The building platform Information Model defines how different parts of digital twins of buildings are managed by specific domain services. This model serves as a structured representation of information accessible through Domain Service APIs and Domain Events. It essentially represents the target of the process of digital twin modeling, which is known as the building platform onboarding.

[0133] However, manually entering all this data into the respective domain services would be cumbersome, inefficient, error-prone, and user-unfriendly. To address this, the solution introduces an innovative aspect-oriented approach, breaking down the digital twin into modular "aspects." These aspects bridge the gap between user- friendly onboarding perspectives and the structured information required by domain services for effective management.

[0134] The parallel onboarding environment allows independent aspect modeling, ensuring thorough review, validation, and consolidation before transitioning to operational entities and resources.

[0135] The solution combines interactive and automated modeling, providing recommendations, guidance, and semantic enrichment to enhance modeling efficiency. Additionally, digital twin templates contribute to streamlining the process, ensuring standardization and consistency. The Translation Service addresses languageand information barriers by seamlessly integrating data described in external standard vocabularies.

[0136] In summary, this solution offers a multitude of benefits:• Simplicity: The solution simplifies digital twin modeling by breaking it into manageable aspects, offering guidance, and immediate error detection.• Efficiency: It accelerates the process with interactive and automated modeling, templates, and semantic enrichment, reducing errors and promoting consistency.• Extensibility: The solution's flexibility and scalability are evident, as it easily accommodates the addition of new aspects, making it adaptable to evolving requirements and diverse data sources within the building platform ecosystem.• Parallelism: Users have the capability to concurrently model aspects within a parallel onboarding environment, allowing for validation before deployment and the seamless integration of contributions from ecosystem participants.

[0137] Overall, this comprehensive solution streamlines digital twin modeling, enhancing efficiency, quality, and the user experience, thereby empowering the building platform to operate seamlessly and make informed decisions.

[0138] Referring to FIG. 11, there is shown a flow diagram of an example operation 1100 of a process that is operable to employ techniques described herein. The operation 1100 represents a method for creating a reliable digital twin creation of a building. Building data associated with field devices of the building is collected (1102). Digital twin aspects for the building are established and processed (1110). For establishing and processing (1110) the digital twin aspects, a digital twin ontology that describe at least one digital twin within a designated domain is identified (1112). For some embodiments, the digital twin ontology is a structured vocabulary residing in an Ml layer. For some embodiments, the digital twin ontology includes a building structure domain, an equipment domain, a device domain, and / or a point domain. The digital twin ontology may be identified by receiving the ontology from an input component, determining the ontology based on received building information, or a combination of receiving and determining the ontology.

[0139] Also, the digital twin or twins are identified based on the digital twin ontology. Similar to the digital twin ontology, the digital twin may be identified by receiving the identified digital twins from an input component, determining the identified digital twins based on received building information, or a combination of receiving and determining the digital twins. For some embodiment, the digital twin may be identified by breaking them down (1114) into one or more digital twin aspects based on the digital twin ontology. For some embodiments, each aspect is broken down based on a digital twin aspect type delineating a distinct viewpoint on a digital twin, addressing specific requirements of an onboarding process. For some embodiments, each aspect is broken down based on a digital twin aspect type ontology providing a formal description of a certain perspective of the digital twin, defining how aspects of a specific type may be modeled. For some embodiments, each aspect includes energy consumption, a building structure, a location asset, an equipment part, and / or an equipment device point.

[0140] Each digital twin aspect of the digital twin aspects offers a data view from a specific angle. In addition, the digital twin aspects are modeled (1116) in parallel automatically or manually based on a digital twin aspect type ontology. Each digital twin aspect as modeled includes aspect elements, attributes of the aspect elements, and a type of relationship between the aspect elements. For some embodiments, each digital twin aspect as modeled is a structure description of a specific digital twin aspect residing on a M0 layer.

[0141] As described above, the example operation 1100 may include other steps of the process. For some embodiments, modeled aspects may be validated against the digital twin aspect type ontology based on an element type represented within the aspect, an attribute of the aspect, and a relationship established between aspects. For some embodiments, the aspect elements may be transformed to aspect elements that may be efficiently managed within an operational domain service.

[0142] Further, for processing, at least one portion of the aspects representing a particular digital twin element are consolidated (1118) into a unified representation based on overlapping aspect elements and a clear association between aspect elements. As explained above, the system may perform further analyses 900 toidentify missing aspects (FIG. 9) and / or otherwise deducing a new aspect in response to consolidating them into a unified representation. Accordingly, the system may, once again, model (1116) digital twin aspects automatically or manually based on one or more newly identified digital twin aspects as well as the digital twin aspect type ontology.

[0143] In response to establishing (1110) the digital twin aspects, the aspects or aspect elements are published (11120) into an operative environment where one or more aspect elements transform into elements that may be efficiently managed within an operational domain service. For example, each aspect element may become an entity, resource, or source element of domain services to interact with and remotely control the building. For some embodiments, the aspects are published to a building platform information layer including a building structure service, equipment & device service, and / or point service.

[0144] Those skilled in the art will recognize that, for simplicity and clarity, the full structure and operation of all data processing systems suitable for use with the present disclosure are not being depicted or described herein. Also, none of the various features or processes described herein should be considered essential to any or all embodiments, except as described herein. Various features may be omitted or duplicated in various embodiments. Various processes described may be omitted, repeated, performed sequentially, concurrently, or in a different order. Various features and processes described herein can be combined in still other embodiments as may be described in the claims.

[0145] It is important to note that while the disclosure includes a description in the context of a fully functional system, those skilled in the art will appreciate that at least portions of the mechanism of the present disclosure are capable of being distributed in the form of instructions contained within a machine-usable, computer-usable, or computer-readable medium in any of a variety of forms, and that the present disclosure applies equally regardless of the particular type of instruction or signal bearing medium or storage medium utilized to actually carry out the distribution. Examples of machine usable / readable or computer usable / readable mediums include nonvolatile, hard-coded type mediums such as read only memories (ROMs) orerasable, electrically programmable read only memories (EEPROMs), and user- recordable type mediums such as floppy disks, hard disk drives and compact disk read only memories (CD-ROMs) or digital versatile disks (DVDs).

[0146] Although an example embodiment of the present disclosure has been described in detail, those skilled in the art will understand that various changes, substitutions, variations, and improvements disclosed herein may be made without departing from the spirit and scope of the disclosure in its broadest form.

Claims

CLAIMSWhat is claimed is:

1. A method for creating a reliable digital twin of a building, the method comprising: collecting (1102) building data associated with the building; establishing and processing (1110) a plurality of digital twin aspects for the building comprising: identifying (1112) a digital twin ontology that describe at least one digital twin within a designated domain; identifying (1114) the plurality of digital twin aspects based on the digital twin ontology, each digital twin aspect of the plurality of digital twin aspects offering a data view from a specific angle; modeling (1116) the plurality of digital twin aspects in parallel based on a digital twin aspect type ontology, each digital twin aspect as modeled includes aspect elements, attributes of the aspect elements, and a type of relationship between the aspect elements; and consolidating (1118) at least a portion of the plurality of digital twin aspects representing a particular digital twin element into a unified representation based on overlapping aspect elements and a clear association between aspect elements; and publishing (1120) the plurality of aspects or aspect elements into an operative environment.

2. The method according to claim 1, wherein the digital twin ontology is a structured vocabulary residing in an Ml layer.

3. The method according to any of the claims 1 to 2, wherein the digital twin ontology includes at least one domain selected from a group consisting of a building structure domain, an equipment domain, a device domain, or a point domain.

4. The method according to any of the claims 1 to 3, wherein identifying (1114) the plurality of digital twin aspects includes identifying (1114) each aspect of the plurality of aspects based on a digital twin aspect type delineating a distinct viewpoint on a digital twin, addressing specific requirements of an onboarding process.

5. The method according to any of the claims 1 to 4, wherein identifying (1114) the plurality of digital twin aspects includes identifying (1114) each aspect of the plurality of aspects based on a digital twin aspect type ontology providing a formal description of a certain perspective of the digital twin, defining how aspects of a specific type may be modeled.

6. The method according to any of the claims 1 to 5, wherein each aspect of the plurality of digital twin aspects includes at least one aspect selected from a group consisting of energy consumption, a building structure, a location asset, an equipment part, or an equipment device point.

7. The method according to any of the claims 1 to 6, wherein each digital twin aspect as modeled is a structure description of a specific digital twin aspect residing on a MO layer.

8. The method according to any of the claims 1 to 7, further comprising validating modeled aspects against the digital twin aspect type ontology based on an element type represented within the aspect, an attribute of the aspect, and a relationship established between aspects.

9. The method according to any of the claims 1 to 8, further comprising transforming the aspect elements to aspect elements that may be efficiently managed within an operational domain service.

10. The method according to any of the claims 1 to 9, wherein publishing (1120) the plurality of aspects or aspect elements includes publishing (1120) the plurality of aspect to a building platform information layer including at least one service selected from a group consisting of a building structure service, equipment & device service, and point service.

11. A system for creating a reliable digital twin of a building comprising: an input component (218) configured to collect building data associated with the building; a processor (206) configured to establish and process a plurality of digital twin aspects for the building, the processor: identifies (1112) a digital twin ontology that describe at least one digital twin within a designated domain; identifies (1114) the plurality of digital twin aspects based on the digital twin ontology, each digital twin aspect of the plurality of digital twin aspects offering a data view from a specific angle; models (1116) the plurality of digital twin aspects in parallel based on a digital twin aspect type ontology, each digital twin aspect as modeled includes aspect elements, attributes of the aspect elements, and a type of relationship between the aspect elements; and consolidates (1118) at least a portion of the plurality of digital twin aspects representing a particular digital twin element into a unified representation based on overlapping aspect elements and a clear association between aspect elements; and an output component (220) configured to publish (1120) the plurality of aspects or aspect elements into an operative environment .

12. The system according to claim 11, wherein the digital twin ontology is a structured vocabulary residing in an Ml layer.

13. The system according to any of the claims 11 to 12, wherein the digital twin ontology includes at least one domain selected from a group consisting of a building structure domain, an equipment domain, a device domain, or a point domain.

14. The system according to any of the claims 11 to 13, wherein the processor (206) identifies (1114) each aspect of the plurality of aspects based on a digital twin aspect type delineating a distinct viewpoint on a digital twin, addressing specific requirements of an onboarding process.

15. The system according to any of the claims 11 to 14, wherein the processor (206) identifies (1114) each aspect of the plurality of aspects based on a digital twinaspect type ontology providing a formal description of a certain perspective of the digital twin, defining how aspects of a specific type may be modeled.

16. The system according to any of the claims 11 to 15, wherein each aspect of the plurality of digital twin aspects includes at least one aspect selected from a group consisting of energy consumption, a building structure, a location asset, an equipment part, or an equipment device point.

17. The system according to any of the claims 11 to 16, wherein each digital twin aspect as modeled is a structure description of a specific digital twin aspect residing on a MO layer.

18. The system according to any of the claims 11 to 17, wherein the processor (206) validates modeled aspects against the digital twin aspect type ontology based on an element type represented within the aspect, an attribute of the aspect, and a relationship established between aspects.

19. The system according to any of the claims 11 to 18, wherein the processor (206) transforms the aspect elements to aspect elements that may be efficiently managed within an operational domain service.

20. The system according to any of the claims 11 to 19, wherein the output component (220) publishes the plurality of aspect to a building platform information layer including at least one service selected from a group consisting of a building structure service, equipment & device service, and point service.

Images