​​Functional Scope (What Digital Twin + Analytics Does)

Primary functions (project-dependent):

​

1. Twin-ready model structuring (BIM → Ops)
   Asset hierarchy, naming, and metadata rules so model elements map cleanly to real equipment, zones, and systems.

2. Asset + system graph mapping
   Equipment ↔ zones ↔ meters/sensors ↔ control points mapping that makes telemetry interpretable and actionable.

3. Telemetry normalization + historian readiness
   Time-synced point naming, units, sampling intent, retention rules, and data-quality checks so analytics are defensible.

4. Dashboards + role-based views
   Energy, IAQ/comfort, utilization, equipment health, alarms/anomalies, and system status—configured to stakeholder needs.

5. Diagnostics + anomaly detection workflows
   Baseline → trend → anomaly → root-cause workflow with evidence and traceability (what changed, when, and why).

6. Performance optimization loop
   Continuous improvement via setpoint/schedule recommendations, exception tracking, and verified “before/after” outcomes.

7. Lifecycle record + auditability (where required)
   Durable change history for models, KPIs, and operational events; optional Web3 verification where audit trails matter.

​

Twin Architecture + Analytics Loop

Digital twin value is defined by measurable structure and repeatable workflows:

​

1. Asset structure
   What is an asset, how it is named, and how it relates to systems and spaces.

2. Point/telemetry schema
   Which signals matter, how they are labeled, what units apply, and how they align with KPIs.

3. KPI definitions + thresholds
   What “good” looks like (targets, bounds, exceptions) and how the math is calculated.

4. Baselines + comparisons
   Seasonal baselines, operational modes, and comparators (model vs measured; before vs after).

5. Exception handling
   Clear routing: flag → classify → assign → verify correction → document outcome.

6. Change control
   Model updates, retuning, and system changes captured as lifecycle events so performance history stays interpretable.

​

System Interfaces (Required Integration Points)

Digital Twin + Analytics is designed to interoperate with NexGen systems through explicit interfaces:

​

• BAS/BMS: points list, schedules/modes, alarms, setpoints, trend logs, sequences of operation alignment

• IAQ + Environmental Sensing: thresholds, alerts, comfort indicators, calibration/validation markers

• Microgrid + Controls: PCC metering, mode states, dispatch events, export limits, island-ready events

• Energy systems (wind/solar/storage): production/curtailment states, charge/discharge states, constraints

• Cybersecurity / Data Governance: segmentation, identity/access control, logging, retention, and secure data handling

• Robotics (where used): evidence packages, event tags, time/location stamps, and structured outputs for the twin

​

Design Inputs (Twin Feasibility + Data Constraints)

Digital twin feasibility and analytics quality are driven by measurable inputs:

​

1. BIM completeness + asset intent
   Asset naming standards, model LOD/LOI intent, and what must be represented as an operational asset.

2. Owner/operator objectives
   Top KPIs (energy, IAQ, resilience, uptime, lifecycle cost), reporting needs, and decision cadence.

3. Controls + telemetry availability
   Point exposure (what’s readable/writable), trend frequency, and alarm/event access.

4. Metering + sensor coverage
   Where measurement exists (and where it doesn’t), calibration intent, and accuracy requirements.

5. Data architecture
   Network segmentation, time sync requirements, historian/retention intent, and integration boundaries.

6. Success metrics + acceptance criteria
   What constitutes “usable twin handover” (mapping completeness, data quality, dashboard correctness, workflow readiness).

 

These inputs are established during Discovery + Feasibility and become the basis for mapping rules, dashboards, analytics workflows, and commissioning acceptance.

​

Commissioning and Verification

Digital Twin + Analytics is commissioned as an operational subsystem with defined acceptance criteria.

​

Commissioning scope typically includes:

1. Asset mapping verification
   Model-to-asset alignment, naming compliance, and relationship graph correctness.

2. Point mapping verification
   Tag/point alignment, units validation, sampling intent, and time sync confirmation.

3. Data quality verification
   Completeness, latency, dropouts, outlier handling, and retention checks.

4. Dashboard + KPI validation
   Math verification, threshold logic, and role-based view correctness.

5. Scenario verification
   Known events (mode changes, dispatch events, alarm triggers) appear correctly in histories and dashboards.

​

Acceptance criteria examples:

1. Verified asset registry + mapping coverage for defined scope (systems and critical assets).

2. Validated telemetry schema (names, units, time sync, retention) with defined data-quality thresholds.

3. Verified KPI math and dashboard correctness against sample datasets and known scenarios.

4. Confirmed anomaly workflow produces traceable evidence (flag → cause → correction → verified outcome).

5. Confirmed lifecycle logs capture changes so performance history remains interpretable over time.

​

Digital Twin Deliverables

Digital Twin + Analytics produces consistent, operations-ready outputs:

​

1. Twin-ready model package
   Asset-structured BIM with naming standards and required fields.

2. Asset data dictionary
   What each field means, who owns it, and update rules.

3. System relationship map
   Equipment ↔ zones ↔ meters/sensors ↔ control points mapping.

4. Dashboards
   Energy, IAQ/comfort, equipment health, utilization (as applicable), alarms/anomalies, and mode status.

5. Event + alarm histories
   Time-stamped lifecycle record of modes, exceptions, and key operational events.

6. Analytics loop artifacts
   Baselines, trend reports, anomaly logs, corrective action tracking, and verified “before/after” results.

​