Binding: Introduction

Getting started

Training

The binding is the step that connects the 3D view (graphic objects on the map) to the DOM of equipment (supervised business entities). In concrete terms, we create stable links between a visual object and an immersive device, so that any action or data (state, variable, alarm) impacts the good visual representation — and vice versa (selection, focus, equipment sheets).

Immersive Object Model: faithfully representing reality

The Immersive Object model aims to translate, without distortion, the operational reality of a site in the system. Immersive is based on a MCD (conceptual data model) to ensure a Representation Exact and usable actors Professions (elevators, probes, vehicles, cameras, etc.) and actors Techniques (protocols, variables, states, events) that will be monitored. Understanding these actors upstream is essential: it is this analysis that makes it possible to Transform business sources and Translate correctly in the Immersive object model.

Why this modeling is essential

Fidelity to the terrain: A digital object corresponds to a real object (or a defined aggregate), without ambiguity.
Interoperability: heterogeneous data (CMMS, BMS, IoT, files) are unified in a single structure.
Traceability & supervision: Each piece of data, event or alert is attached to the "right" object.
Scalability: a clear MCD facilitates extensions (new families, new properties, new sites).

Model Overview

Immersive organizes entities around four key concepts: Equipment family, Equipment Instance, Properties/Handles and Scope.

Equipment family

A Family describes a homogeneous type of objects (e.g.:Elevator, Temperature sensor, Vehicle). It defines the Structure (standard properties, variables, semantics) and serves as a template for its instances.

Equipment Instance

A Instance is a concrete piece of equipment belonging to a single family. Example: Elevator "ATR5910" of building B of the Bidule factory. The instances carry the identity, location, and supervisory links.

Properties / Handles

A body exposes Properties (configured values) and handles (dynamic data points published by the Hub). Handles represent the status, measurement, or alarm data of the equipment (e.g.: Landing door defect, Current floor, Door Open/Closed).

A family can also declare Handles. These family handles are Legacy by all the bodies of this family, which guarantees a common base (names, types, semantics) and greatly simplifies scripting and integration.

Scope

A Scope groups bodies according to a logic Profession (response team, type of activity) or Geography (site, building, floor, area). The same equipment can belong to several scopes to reflect different operational points of view (e.g., "Elevator Maintenance", "Building B").

Inheritance of the Handles (Family → Instance)

Common Data Contract: Setting handles at the family level creates a stable API for all instances.
Reducing gaps: Less name/type variations, less mapping and testing effort.
Scalability: Each instance can add specific handles if necessary (without breaking the base contract).
Simplified scripting: Scripts can target family handles by assuming their presence on all instances.

Structural relations and rules

Family → Instances : 1 family includes N instances (cardinality 1..*).
→ Handles Family : family handles are Legacy by all bodies.
Instance → Handles : An instance can add its own (specific) handles in addition to inheritance.
Scopes ↔ Instances : N↔N relation allowing flexible and multiple groupings.

Security and perimeters

The Equipment families and the scopes are Securable : we can control who sees, who configures or who operates a perimeter/family. This granularity of access is crucial to compartmentalize uses (e.g., operators, maintenance, safety, management) and respect responsibilities.

Transforming business knowledge into an immersive model

Identify the actors (real objects to be supervised) and their Attributes useful.
Defining Families corresponding to the actual types observed; List expected properties and handles.
Instantiate each concrete equipment (identity, location, belonging to scopes).
Map data (protocols, APIs, files) to the instance handles.
Validate traceability (one event = one exact object) and adjust the MCD if necessary.

Summarized example

Family : Elevator → Proceedings : "ATR5910" (Building B) → Handles : DoorFault, DoorState, Floor → Scopes : "Elevator maintenance", "Building B".

Best practices

Stable Naming (IDs, families, handles) to avoid breaks during evolutions.
Shared repositories (sites, buildings, areas) to guarantee cross-functional coherence.
Explicit Handles (type, unit, semantics) to facilitate scripting rules and UI.
Relevant scopes to reflect real uses (operation, safety, maintenance, management).
Regular checks (cover, orphans, duplicates) to maintain the quality of the model.

Binding — sample model (BuildingSensorSimulator)

To illustrate the binding 3D ↔ DOM, we rely on the example project BuildingSensorSimulator. Let's imagine that we are working for a Condominium management company : it is necessary Import equipment in Immersive and therefore List The Families, the Instances and the handles that will serve as a data contract for binding.

Reminder

The BuildingSensorSimulator project, the source code of which is as follows:

📦 BuildingSensorSimulator — v1.0 • 1.8 MB • ZIP

simulates a set of sensors and equipment that support the various tutorials on our pages dedicated to the developers of the Immersive solution.

This project, after analysis, instantiates and creates a number of equipment that can be determined after analysis of the source code for those who master the C# language:

private void Seed()
{
    var now = DateTime.UtcNow;

    int lastId = 0;
    int NextId() => ++lastId;

    //function for simple device with one variable
    Device Single(string name, string type, string unit, string value, int? fixedId = null)
    {
        var id = fixedId ?? NextId();
        return new Device
        {
            Id = id,
            Name = name,
            Type = type,
            Value = value,              // valeurs normalisées en string
            Unit = unit,
            TimestampUtc = now
        };
    }

    //function for elevator
    Device Elevator(string name, int? fixedId = null)
    {
        var id = fixedId ?? NextId();
        return new Device
        {
            Id = id,
            Name = name,
            Type = "elevator",
            Variables =
            [
                new() { Name = "floor", Path = $"floor", Kind = "numeric", Unit = null, Value = "0",      TimestampUtc = now },
                new() { Name = "state", Path = $"state", Kind = "enum",    Unit = null, Value = "Idle",   TimestampUtc = now },
                new() { Name = "door",  Path = $"door",  Kind = "enum",    Unit = null, Value = "Closed", TimestampUtc = now },
            ]
        };
    }

    //function for garage door
    Device GarageDoor(string name, int? fixedId = null)
    {
        var id = fixedId ?? NextId();
        return new Device
        {
            Id = id,
            Name = name,
            Type = "garageDoor",
            Variables =
            [
                new() { Name = "door",     Path = $"door",     Kind = "enum", Value = "Closed", TimestampUtc = now },
                new() { Name = "obstacle", Path = $"obstacle", Kind = "bool", Value = "false",  TimestampUtc = now },
            ]
        };
    }

    // ---------------------------------------
    Devices.AddRange(
    [
        Single("Temp S1",               "sensor",     "°C",  "27.5"),
        Single("Parking Humidity",     "humidity",   "%",   "50"),
        Single("Corridor Light Level",  "light",      "lux", "300"),
        Single("Office Presence",       "presence",   "bool","0"),
        Single("Main Electric Counter", "energy",     "kWh", "1250"),
        Single("Smoke Detector",        "smoke",      "bool","0"),
        Single("Parking Temperature",  "temperature","°C",  "21"),
        ]);

    // Rooms supplémentaires (temp + humidity)
    foreach (var room in new[] {101, 102, 103, 104, 201, 202, 203, 204, 301, 302, 303, 304 })
    {
        Devices.Add(Single($"Room {room} Temperature", "temperature", "°C", "21"));
        Devices.Add(Single($"Room {room} Humidity", "humidity", "%", "50"));
    }

    // 5 détecteurs de fumée
    for (int i = 1; i <= 5; i++)
        Devices.Add(Single($"Smoke Detector S{i}", "smoke", "bool", "0"));


    //start id farther for complex devices
    lastId = 101;
    Devices.Add(Elevator("Lift A"));
    Devices.Add(Elevator("Lift B"));
    Devices.Add(GarageDoor("Garage G1"));

}

You don't need to be familiar with this code for this tutorial. But if you want to create a digital twin of this example of a condominium association, it is necessary to know which objects will need to be supervised. Thus, the following point lists all the Immersive actors to be created, whether they are:

Equipment family
Equipment Instance'
Handle

Equipment families (offered)

The example syndicate of co-ownership sets out the following families of objects:

Elevator (elevator)
GarageDoor (garage door)
TemperatureSensor
HumiditySensor
LightSensor
PresenceSensor
EnergyCounter
SmokeDetector

As a reminder, the families can report handles (common base): these handles are Legacy by all their instances, which standardizes scripting and UI (same names, same types).

Simulated Instances (extract)

Elevators & Garage Doors

Elevator : Lift A, Lift B
GarageDoor : Garage G1

Single-value sensors

TemperatureSensor : Temp S1, Parking Temperature, Room 101 Temperature, Room 102 Temperature, Room 103 Temperature, Room 104 Temperature, Room 201 Temperature, Room 202 Temperature, Room 203 Temperature, Room 204 Temperature, Room 301 Temperature, Room 302 Temperature,Room 303 Temperature, Room 304 Temperature
HumiditySensor : Parking Humidity, Room 101 Humidity, Room 102 Humidity,Room 103 Humidity, Room 104 Humidity, Room 201 Humidity, Room 202 Humidity,Room 203 Humidity, Room 204 Humidity, Room 301 Humidity, Room 302 Humidity,Room 303 Humidity, Room 304 Humidity
LightSensor : Corridor Light Level
PresenceSensor : Office Presence
EnergyCounter : Main Electric Counter
SmokeDetector : Smoke Detector, Smoke Detector S1 … S5

Family Handles (inherited by instances)

Elevator

	Path	Kind	Unit	Description
Handle	`Elevator/Floor`	numeric	—	Current floor (0, 1, 2 ...)
Handle	`Elevator/State`	enum	—	Status: Idle, Moving, Alarm…
Handle	`Elevator/Door`	enum	—	Door: Open / Closed

GarageDoor

Handle	Kind	Unit	Description
`GarageDoor/Door`	enum	—	Door Position: Open / Closed
`GarageDoor/Obstacle`	bool	—	Obstacle detected (safety)

TemperatureSensor

Handle	Kind	Unit	Description
`Temperature/Value`	numeric	°C	Measured Temperature

HumiditySensor

Handle	Kind	Unit	Description
`Humidity/Value`	numeric	%	Relative humidity

LightSensor

Handle	Kind	Unit	Description
`Light/Level`	numeric	lux	Light Level

PresenceSensor

Handle	Kind	Unit	Description
`Presence/State`	bool	—	Presence detected (1) / no (0)

EnergyCounter

Handle	Kind	Unit	Description
`Energy/Total`	numeric	kWh	Consumption index

SmokeDetector

Handle	Kind	Unit	Description
`Smoke/Alarm`	bool	—	Smoke alarm (true/false)

For each 3D object, store a equipmentRef stable (or a mapping) to the Immersive instance. On the scripting side, listen to the Family Handles (legacy) to apply styles/animations/alerts generically to all instances of the same family.

Downloading sources

📦 BuildingSensorSimulator — v1.0 • 1.8 MB • ZIP

GraphicStream

Immersive

Developer

Learning centre
Launcher
Immersive Script
Immersive Forge
SDK Immersive