TwinWorX Platform Technical Overview
TwinWorX: An Open, Intelligent Digital Twin Platform for Operating and Optimizing the Built Environment.
This overview is for the architects, engineers, and procurement teams who need more than the website gives them. Every capability below reads from the same model of your operation. Connect it once. Name it once.
1. Connectivity
Any vendor, any protocol. Building, plant, and utility protocols run through one connectivity layer: BACnet/IP, Modbus, OPC, DNP3, SNMP, MQTT, REST, SOAP, HL7, IEC 60870 and IEC 61850, and the major controller families, including Siemens, Allen-Bradley, Mitsubishi, Omron, Yokogawa, GE, and Honeywell. Drivers are licensed individually or in suites, and more can be added as needs change. Where nothing off the shelf fits, a configurable driver handles the source.
Edge or cloud. The connectivity layer runs at the edge or in the cloud, in hot or cold standby where requirements call for it. If the link drops, the edge stores data and forwards it when the link returns: a delay, not a gap in your history.
Point discovery. Wherever the protocol allows it, the platform discovers points itself. It connects to the device, scans for available points, reads the properties of each one, and maps it into the model.
Nothing is ripped out. TwinWorX sits above the control layer you already have, which keeps doing the job it was installed to do. Brownfield is the normal case: most estates are a decade of decisions by different contractors, and that is the starting condition the platform is designed for.
2. The semantic model
One identity per measurement. Vendor naming is solved once, at the data layer. AI-12, AHU01_SAT, and supplyTemp become one normalized, tagged variable with a consistent identity, so the same question gets a comparable answer across the whole portfolio.
A knowledge graph, on open ontologies. Assets, spaces, systems, and the relationships between them are held as a knowledge graph, using the ontology your domain calls for: RealEstateCore, ASHRAE 223P, and BRICK for buildings; Project Haystack for energy and building systems; ECIM for industrial and utility infrastructure; SSO for sensor networks; and others as a sector requires. Where you already have a model, TwinWorX maps to it rather than replacing it.
The model is yours. Not an e-Magic schema, and not one vendor's specification. If you replace us in ten years, you keep the asset you paid to build and hand it to whoever comes next.
3. Operational views
Portfolio to asset: map views for the estate, floor and system views for each building, live schematics for equipment, and heat maps over floor plans.
Lightweight 3D models with live values where they help, typically for air handling, heating, and cooling plant.
Views built per role. What an energy manager needs is not what a shift engineer or a security operator needs.
Mobile: an alarm reaches whoever is on call, who can open the equipment, read live values, check the trend, and acknowledge it from a phone.
4. Alarms
Alarms from every connected system are normalized into one format and one list, following ISA-18.2 practice.
Priority tiers you define; routing per alarm type and per user group, configured rather than coded.
Every alarm is logged, whether it was routed to anyone or not, so the record is usable for analysis and compliance.
Acknowledgement, latching, and inhibition are handled in the platform rather than in each source system.
Each alarm carries its model context: asset, space, what it serves, what is upstream, and what happened the last time it fired. Click the alarm and you land on the equipment with the component in focus.
5. Command and control
Setpoints, schedules, overrides, and equipment commands are issued from the same interface. Every command requires authentication, respects role-based permissions, and writes a transaction record. Multi-step sequences hold their state, so a procedure that takes four actions across two systems runs as one procedure.
6. Historian
Included with the platform: no tag limit, no retention limit, no separate licence.
PostgreSQL-native, so your own reporting tools read it directly with no vendor-specific client.
Roll-ups at minute, hourly, and daily resolution; retention set by your policy.
Trends compare unlike measures on multiple axes, carry annotations, and export to PNG, SVG, or CSV. Reports run on a schedule.
Where you already have a historian, TwinWorX uses it.
7. Analytics
Fault detection. More than 1,000 fault rule templates across more than 120 equipment classes, with generic, role-based variable names so one template works against any vendor's controller. Rules reason over history as well as live values (average, minimum, standard deviation, rate of change), and a fault must hold for a set number of consecutive checks before it is raised, and hold false before it clears.
Extending the library. An engineer describes a fault in plain English and the platform drafts a complete rule, constrained by the model to properties the asset actually has. Every rule runs against historical data before it goes live.
Root cause. The platform walks upstream and downstream through the model from a fault, and tracks which faults fire together, which fires first, and how long the others take to follow. From that it separates the primary fault from its symptoms and groups them. Each rule carries probable causes and first-line checks your team can rewrite.
Ranking and work orders. Faults are ranked by cost and by recurrence, and pushed to your work order system with equipment, location, and diagnostics attached. Closure returns to the rule that raised it.
Energy. Consumption by building, system, meter, or tenant, as actual against expected. Heating and cooling comparisons are normalized against degree days from your local weather station. Buildings and sites are compared on the same basis.
Reporting. STARS, ENERGY STAR Portfolio Manager, and the UN Climate Commitment read from the same model as everything else.
What-if. Because the model holds how things relate, it can estimate the effect of a change before anyone touches the plant.
Stated plainly. Duration-sensitive rules need two to three months of normal operation before they are fully enabled. Dollar figures are engineering estimates, derived from sensor data and rule-based waste rates, not sub-metered before-and-after isolation. Where you need IPMVP-grade measurement and verification, this is the input dataset for it.
8. Data quality
Values are normalized and tagged against open standards. Communication health is monitored, so a device that stops talking is flagged the day it stops. The health of the data is reported daily as its own output. A rule will not evaluate on a stale reading, so a dead sensor produces a data fault rather than a false equipment fault.
9. AI governance
The language model authors; it does not act. It writes rules your engineers can read before they run.
The rule engine governs. Every proposed rule is checked against hard safety limits, interlocks, and your model, then executed deterministically. Where they conflict, the limit wins, on the record.
Machine learning calibrates; the engineer diagnoses. It learns what "high" means for a specific asset, season, and load. The rule carries the engineering knowledge, so the result names a cause.
TwinWorX Copilot runs on any LLM endpoint, including the model you already govern. On your own endpoint: no AI sub-processor, no new approval, no training on your data, and no inference markup.
10. Autonomy and writeback
Autonomy is a ladder of four steps: advise, approve, execute reversible, execute. A strategy is promoted only on accumulated evidence and your sign-off, and any step can be demoted at any time, by you, without e-Magic.
Life-safety and code-mandated functions remain wholly within their native systems, connected read-only.
Every writeback runs behind seven controls:
Per-point enablement
Elevated authorization
Rate limiting
Mandatory readback confirmation
Automatic reversion to local control if communication is lost
Immutable audit
Manual override, always available
11. Deployment and data ownership
Your Azure tenant | e-Magic's Azure tenant | On premise | |
Runs | In your subscription, under your identity provider, security controls, and data residency | Hosted and operated by e-Magic, not shared with other clients | On your own servers, with no cloud connection required |
Best for | Organizations with their own Azure governance, buying through an existing Microsoft agreement | The fastest path to value, with no Azure capability to build and no operational load to carry | Regulated, secure, or air-gapped environments |
In your own tenant: you own the subscription, you hold the identity provider, your data stays in your region, and e-Magic sees only what you grant.
12. Security
Encrypted in transit over TLS and encrypted at rest.
Every user authenticates; access is role-based; audit logs record both data access and command execution.
The edge sits on your OT network and opens every connection outbound, so nothing on the cloud side can open a session into your building systems.
Topology, network segmentation, and identity are designed with your IT and security teams.
13. Procurement
TwinWorX is listed on the Azure Marketplace and Microsoft AppSource and co-sold by Microsoft, so committed Azure spend can be applied to it. U.S. public sector buyers can purchase through Carahsoft.
Your infrastructure. Your model. Your data.
Bring your security questionnaire, and thirty minutes with one of our engineers will cover the rest.
