BIM‐CIM Semantic Interoperability - statnett/Talk2PowerSystem GitHub Wiki

Ontologies For BIM-CIM Semantic Interoperability

Asset Administration Shell

The Asset Administration Shell (AAS for short) is a central concept for data structuring and management of the Digital Twin in the context of Industry 4.0. It not only enables the digital representation of physical objects and their properties, it also allows data on these objects to be retrieved in real time in an open standard. The corresponding information is thematically summarised in submodels with standardised “machine-readable” semantics. There is ASS metamodel mapping to an ontology in RDF

ASS is one of the ontologies capable of covering operational aspects of BIM models. The BIM model represents the building at a specific point in time, while the AAS provides the data over the entire asset life cycle and makes it dynamically usable, for example to determine maintenance intervals based on individual device usage at the respective location.

The responsibility of the BIM model often ends with the transition to building operation, because in this case it is an “as-built” model that no longer represents the continuous changes to a building and, in particular, dynamic data that is relevant for ongoing operation. The Asset Administration Shell documents current information on the machines, control systems, sensors and actuators installed in the buildings, for example the measurement and control technology.

The data structure includes both static information, such as details of the manufacturer or performance characteristics, and dynamic data, such as the measured values recorded by a sensor or the operating hours of a drive in sub-models defined for this purpose.

Two types of Asset Administration Shells are usually used to provide the data:

Information and technical documentation on the type of an asset, identified by a unique product type. This data is comparable with information from product catalogues, for example:
- technical product descriptions;
- technical data such as performance parameters, dimensions, connections, power supply or Environmental Product Declaration (EPD);
- general test certificates and attestations.
Specific data on an individual asset, identified by a unique serial number. The instance AAS documents characteristic information such as:
- specific individual designs / parameterisation;
- management of maintenance and updates to assets:
- storage of application data (such as photovoltaic output).

By using the combined data, building operation can be sustainably optimised. Real-time monitoring enables adjustments to be made that improve energy efficiency and occupant comfort, for example in energy management. By linking the HVAC system with the live data from the digital building twin, the HVAC system can regulate itself accordingly based on occupancy patterns and weather conditions. At the same time, the use of data analyses and machine learning algorithms enables predictive maintenance, which predicts when which components need to be serviced. This approach minimises unplanned outages and extends the service life of building systems. The Digital Twin of a lift system, for example, can monitor usage patterns and wear and tear and predict when maintenance is required before a fault occurs.

Sources:

Metadata Schemas and Ontologies for Building Energy Applications

Pritoni, M.; Paine, D.; Fierro, G.; Mosiman, C.; Poplawski, M.; Saha, A.; Bender, J.; Granderson, J. in Energies 2021, 14, 2024. https://doi.org/10.3390/en1407202

Authors of the review note that the scalability of building applications, such as energy audits, fault detection, and diagnostic and optimal controls, is currently hindered by the lack of standardization in metadata schemas that represent the meaning of the data [21]. This issue is generally referred to as a lack of semantic interoperability.

Several frameworks exist to describe interoperability that define different layers. For example, in the context of the smart grid, the GridWise Architecture Council defines three conceptual layers: organizational, informational, and technical.

The organization layer relates to business objectives and policy context
The information layer deals with the semantics of the data, as well as its integration with business processes and procedures.
Technical interoperability between devices can be achieved through use of the same communication protocol or by using communication gateways that allow messages to be translated between protocols

Existing ontologies could be categorised by the phase of the building life cycle in a following way:

Design and energy modeling:
- Industry Foundation Classes (IFC)
- Green Building XML (gbXML)
- ifcOWL
- Tubes
- SimModel Ontology
- EnergyADE
Operations:
- Sensor networks, Internet of Things (IoT), and smart homes:
  - Semantic Sensor Network/Sensor, Observation, Sample, and Actuator (SSN/SOSA)
  - Web Thing Model (WoT)
  - oneM2M BaseOntology’s
  - One Data Model (OneDM)
  - Smart Energy Aware Systems (SEAS)
  - ThinkHome
  - Building Ontology for Ambient Intelligence (BOnSAI)
  - DogOnt
  - Ontology of Smart Building (SBOnto)
  - Smart Applications REFerence (SAREF)
- Commercial building automation and monitoring:
  - Project Haystack 3
  - BASont
  - Haystack Tagging Ontology (HTO)
  - Brick Schema
  - Google Digital Building Ontology
  - Semantic BMS ontology (SBMS)
  - CTRLont
  - Green Button
  - RealEstateCore (REC)
  - Building Topology Ontology (BOT)
  - Building Automation and Control Systems (BACS)
  - Knowledge Model for City (KM4City)
  - EM-KPI Ontology
- Grid-interactive efficient building (GEB) applications:
  - Facility Smart Grid Information Model
  - RESPOND
- Occupants and behavior:
  - DNAs Framework (obXML)
  - Occupancy Profile (OP) Ontology
  - Onto-SB: Human Profile Ontology for Energy Efficiency in Smart
  - Building
  - OnCom
- Asset management and audits:
  - Building Energy Data Exchange Specification (BEDES)
  - Virtual Buildings Information System (VBIS)
  - Ontology of Property Management (OPM)

As an example use case authors examined an office building and a representation of the HVAC system that serves its spaces.

And distinguished following concepts, properties and relationships needed by typical building energy modelling use cases:

Category:
- Zones and Spaces
  - Concepts:
    - Space
    - Zone
    - Building
    - floor
  - Properties:
    - Function
    - Floor area
    - Orientation
  - Relationships to/from:
    - Composed of spaces
    - Adjacent to spaces
    - Overlaps one or more spaces
    - Overlaps other zones
- Envelope
  - Concepts:
    - Envelope element
  - Properties:
    - Type of envelope element (wall, roof, floor, window)
    - Envelope characteristics (e.g., thermal resistance, storage, solar seat gain coefficient)
  - Relationships to/from:
    - Part of space
- Building Systems and Equipment
  - Concepts:
    - System
    - Equipment
    - HVAC equipment
    - Lighting equipment
    - Other end use
    - Component
  - Properties:
    - Type of system
    - Type of equipment
    - Rated power draw
    - Rated efficiency
    - Remaining lifespan
    - Rated capacity
    - Rated (max.) luminous flux
    - Minimum relative light output
    - Rated (max.) power
    - Correlated color temperature
    - Spectral power distribution
    - Rated input voltage
    - Rated (max.) input currentt
    - Type of end use
    - Type of component
  - Relationships to/from:
    - Composed of components
    - Serves zone
    - Located in space
    - Metered by (internal/external) meter
    - Connected to electrical junction box or other equipment
    - Connected to equipment
    - Part of system
- Control Devices
  - Concepts:
    - Control device
    - Control point
    - Control strategy
  - Properties:
    - Input/Output type
    - Physical/Virtual type
    - Type of virtual point (setpoints, command, alarm)
    - Unit of measure
    - Control interval
  - Relationships to/from:
    - Has points
    - Linked to sensor/actuator
    - Linked to time series data
    - Has inputs
    - Has outputs
- Sensor/Actuator
  - Concepts:
    - Sensor
    - Actuator
  - Properties:
    - Type of sensor
    - Unit of measure
    - Measurement interval
    - Reporting interval
    - Actuation interval
  - Relationships to/from:
    - Senses/Measures point
    - Senses/Measures equipment
    - Aggregates measurements
    - Actuates point
    - Actuates equipment
    - Integrates/Prioritizes actuations

Conclusions

Upper ontologies and domain ontologies address different layers of abstraction and consequently should not be directly compared. Seeing the differences in what can be modeled with each illustrates some of the decisions building energy modelers face. Rather than defining the array of terms required for a use case, upper ontologies like BOT or SSN/SOSA define a framework of generic terms that are common to many different domains. Domain experts can then build on these frameworks to define the concepts they require. This freedom to choose how to represent nuanced concepts creates complexity for a building systems modeler and raises the possibility of inconsistencies between how two modelers might represent the same concept, making semantic interoperability more challenging potentially. In contrast, application or domain ontologies such as RealEstate Core and Brick Schema present a lower-level and more opinionated representation of buildings. These ontologies reduce some of the complexity end users face, by making decisions to include domain-specific concepts in the ontologies themselves (e.g., an Air Handling Unit class).

CityRDF

Still relatively new - currently at OGC incubator stage in preparation for standardisation. Based on OGC CityGML 3.0. CityRDF Building module is lower level than BOT, but higher level than IFC or Brick Schema. It is OWL ontology and could be integrated with Sensor/Actuator ontologies to support operational building modelling use cases. There are also transformations from IFC to CityRDF available, which makes it a good candidate for use cases where operational BIM-CIM semantic interoperability capabilities are required.

cities-and-energy describes how it could be used.