Hydda Digital Twin Integration Guide
Hydda digital twin is our virtual representation of physical buildings. It is used to create one source of truth for a building's data.
The idea is that we supply the building data (like floor plans, assets, etc.) and you augment it with "your own product".
Real Estate Core
We use real estate core models, sometimes we augment with additional information, but the base model remains the same.
A quick overview of the core entities used:
- Collections: A collection is a container of spaces.
- RealEstate: A real estate object, contains space types of buildings
- Spaces: A space is a container of assets.
- Building: A physical building.
- Level: A floor within a building.
- Room: A space within a floor.
- Zones: A sub zone within or outside a building
- ParkingSpace: Parking space zone type
- Assets: A physical or virtual asset within a space.
- ArchitecturalAsset: An architectural asset, like a door or a window
- Equipment: A piece of equipment, like a light, a camera etc
- Points: A point represents a point in physical space. This usually represents a sensor or devices. There are both input and output points. See Meta entities for more information.
- Sensor: An input point, input data of the physical world. Can send observations to the digital twin.
- Command: An output point, can be used to send commands to the physical world. Example: Open door.
- Events: An event is a point in time when something happens.
- Lease: A lease of a space, in our case a parking zone.
- PointEvent: An event related to a point, like a sensor reading.
- ObservationEvent: An observation of a point, like a sensor reading.
Digital twin structure
Hydda digital twin is a graph representation of a building.
The following basic entities are used:
- RealEstate: A real estate object, contains buildings
- Building: A physical or virtual building.
- Level: A floor within a building.
- Room: A space within a floor.
- Equipment: A physical or virtual asset within a space.
- Sensor: An input point, input data of the physical world. Can send observations to the digital twin.
Meta entities
Meta entities are entities that are not part of the physical structure of a building, but are used to augment the digital twin
Observable Events
We support observable events, which are events that can be observed in the physical world.
Ex.
- TemperatureObservation: An observation of temperature, like a sensor reading
- PowerObservation: An observation of power, like a sensor reading
- DoubleValueObservation: An observation of a double value, like a sensor reading
- IntegerValueObservation: An observation of an integer value, like a sensor reading
All of these readings are related to what real estate core calls "Points". These points are defined within the twin and are attached to "Spaces" - ergo Buildings, Floor,
In this example, we've defined a point type, temperature sensor. The actual sensor is controlled by Freesi, and they push an observation using our observation schema to update the digital twin.
We save this in our time-series database, and also update the "last known value" of the point. This allows other users of the twin to read the latest value of the sensor.
Service Objects
We support service objects, which are meta-information about the building, and are not part of the physical structure of the building.
- WorkOrder: A work order, like a maintenance request
- ErrorReport: An error report, like a fault report
- NotificationObject: A notification object, like a notification that a sensor has detected something
- AlarmObject: An alarm object, like an alarm that is triggered by a sensor
These type of entities are meta-information about the building, and are not part of the physical structure of the building.
We use a concept called Dispatchers, which allows us to setup synchronization between your system and Hydda's systems.
Ex.
If you create a work order in Hydda from EstateLogs, we'll automatically forward it to Spaceflow.
Digital twin API
The digital twin API is a RESTful API that allows you to read the digital twin structure and changes made to it.
By basing your own digital representations of a building on our API, you can easily integrate with other products utilizing the Hydda platform.
All our events are referencing ID's, so you can easily map your own entities to our digital twin. Allowing you to for example know what room or asset a particular event is related to.
Integration examples
Integrating EstateLogs error reports with Spaceflow
In this scenario, we want error reports created within Spaceflow's tenant experience to be automatically created in EstateLogs.
Whenever EstateLogs acknowledges the error report, or they do an update on the error report, we want to let Spaceflow know about the changes.
This flow starts with a customer in Spaceflow reporting an error in their building. They fill out a form, and Spaceflow creates an error report in Room A.
Estate Logs receives this as a new error report, and creates an error report within their own system. Once created they update the error report, setting the status to "acknowledged", and the acknowledgedBy field.
Once Estate Logs is finished with the error report, they update the error report, and set the status to "closed". Spaceflow then receives this update, and updates the error report in their system.
Bring your own twin
Since REC is graph based, it allows us to synchronize data from other REC compliant systems with our own, as long as we support the traversal of the graph.
This setup relies on a receiver, which allows us to pull data from an external system into our own system.
TODO: Insert example of how a receiver works