How it Works
One model of your operation.
Three stages of what you can do with it.
TwinWorX connects the systems you already own into a live model of your physical operation. What you do with that model changes as you go: see everything first, find what is wrong second, hand over control third. Most of our clients spend their first year at the first stage, and that is the way it should work.
This page walks the whole path.
The Model
Start with the model, not the dashboard
Most operational software treats your facility as a list of points. A temperature reading here, a valve position there, a meter total somewhere else. The software knows the values. It does not know that the valve feeds the coil that conditions the air that serves the room the reading came from.
TwinWorX builds the second thing. Every asset, every space, and every relationship between them, held in one model. Pump feeds riser. Riser serves floor. Floor contains rooms. Meter measures panel. Panel serves equipment. Sensor reports on all of it.
That structure is what lets the platform trace a comfort complaint back to a stuck valve two systems upstream, compare one air handler against every similar unit you own, and answer a question about your operation without a person first explaining how your operation is wired. The relationships are written down once, in a standard format, instead of living in the heads of the three people who have been there longest.
Everything below this point runs on that model. Dashboards read from it. Fault rules run against it. AI queries it. Reporting frameworks draw from it. Build the model correctly and every layer above it gets easier. Skip it and you have another dashboard.
The Path
Three stages, and you set the pace
Digital twin projects fail when the ambition arrives before the foundation. TwinWorX is built in three stages, and you can hold at any one of them for as long as you need to. Nearly every client starts at the first stage with one building or one site, and expands from there.
1
Stage 1 of 3
Situational awareness and command control
Connect everything. See everything. Control what needs controlling.
This is the stage nearly every client starts at, and there is nothing embarrassing about staying here. Analytics has nothing to work on without it. Autonomy has nothing safe to control.
Connect what you already own
Building automation, metering, lighting, elevators, access control, fire panels, network gear, process equipment, clinical systems. Different vendors, different decades, different protocols, including the ones the original installer described as closed. Point discovery is handled by the platform wherever the protocol allows it: connect to the device, scan it for available points, read the properties of each one, and map it into the model. What arrives as AHU3_SAT_1 becomes a supply air temperature on a named air handler in a named building, tagged the same way as every other supply air temperature you own. That normalization step is what makes the same question answerable across your whole portfolio. Nothing is ripped out. TwinWorX sits above the control layer you already have, which keeps doing the job it was installed to do.
See it in one place
One interface covers a single building or a portfolio spread across continents. Geospatial map views for the portfolio, floor and system views for the building, live schematics for the equipment.
Equipment views are drawn as live vector schematics with real values on them, reading from the model and updating as the equipment does. Where a 3D view helps, as it usually does for air handling, heating, and cooling plant, the platform renders a lightweight model carrying live values rather than dropping a full design file into a browser and hoping. Thermal distribution and occupancy density can be laid over floor plans as heat maps. Views are built per role rather than one screen for everyone. What an energy manager needs on open is not what a shift engineer or a security operator needs.
Alarms with priorities that mean something
Alarms from every connected system are normalized into one common format and land in one list, aligned to ISA-18.2, with priority tiers you define and routing decided per alarm type and per user group. Facilities, security, engineering, and operations each receive what they need to see and are left out of what they do not. Delivery is configured, not coded, so it changes as your operating model changes.
Every alarm is logged whether it was routed to anyone or not, which is what makes the record usable for analysis and for compliance. Acknowledgment, latching, and inhibition are handled in the platform rather than in each source system. Each alarm carries the context the model already holds: which asset, which space, what it serves, what is upstream of it, and what happened the last time this one fired. Click the alarm and the platform takes you to the equipment graphic with the component in focus. Click the component on the graphic and it takes you back to the alarm, the trend, or the diagnostic history. Nobody has to hold the correlation in their head or keep three tabs open to make it.
From a Phone
None of this requires being at a desk. An alarm reaches whoever is on call as a notification, and from there they can open the equipment, read its live values, check the trend, and acknowledge the alarm without going back to a screen in a control room.
Control what needs controlling
Setpoints, schedules, overrides, and equipment commands, issued from the same interface. Command execution requires authentication, respects role-based permissions, and writes a transaction record every time, so there is an audit trail of who changed what and when. Multi-step sequences hold their state, so a procedure that takes four actions across two systems can be run as one procedure.
Keep the record
Connected points are trended into a time-series store built on PostgreSQL, with retention set by policy rather than by whatever someone configured three years ago. Roll-ups are maintained continuously at minute, hourly, and daily resolutions, so a question about last year does not have to read every raw sample to answer. Because the store is standard PostgreSQL, your own reporting and analysis tools can read it directly. Nobody needs a vendor-specific client to get at your own history. Trend charts support multiple axes for comparing unlike measures, annotation for marking events and thresholds, and export to PNG, SVG, or CSV. Reports are generated and delivered on a schedule.
2
Stage 2 of 3
Analytics
Find what is wrong, what it costs, and what to do about it.
The first stage tells you what is happening. This one tells you what it means.
Fault detection you can configure yourself
Fault detection watches equipment behaviour against rules, continuously, across every connected asset. The difference is who writes the rules. You describe the condition in plain English. The platform turns it into logic and runs it against the model. No programming, no consultant, no change order, and no waiting for a vendor release. Rules are written once and pointed at a list of assets, and the platform creates one live rule per asset. Fifty rules aimed at two thousand assets is fifty things to maintain, not a hundred thousand. Adding a building means adding its assets to the list, not rewriting the library. Rules can reason over history as well as live values: an average, a minimum, a standard deviation, or a rate of change across a window of minutes, hours, or months. A fault has to hold true for a set number of consecutive checks before it is raised, and hold false before it clears, which is what keeps a single bad sample from generating a phantom fault at three in the morning.
Root cause, not symptom
A conventional system tells you an air handler is in fault. TwinWorX tells you that floor three is heating and cooling at the same time, and that it traces to a VAV valve that has been stuck open since Tuesday. That chain comes from the relationships in the model. The platform walks upstream and downstream from the fault, checks what else in that chain is behaving oddly, and separates the primary problem from the alarms it caused. Each fault arrives with probable causes, the fixes worth trying, and an estimate of what the fault is costing you while it goes unresolved.
Know which fault to fix first
Faults are ranked two ways at once: by the money they are costing, and by how often they recur. Those two lists are rarely the same, and the difference is the useful part. One list surfaces the chronic bad actors draining your labour hours. The other surfaces the quiet, expensive faults nobody has complained about because nobody is uncomfortable. Faults can be pushed to your work order system with the equipment, location, and diagnostic detail already filled in, so the technician arrives knowing what they are walking into.
Energy, with dollar figures attached
Consumption by building, by system, by meter, by tenant. Actual against expected, so a change in behaviour shows up as a gap rather than as a number nobody has a reference for. Weather normalization is applied to heating and cooling comparisons, which is what makes a year-over-year figure defensible when last winter was mild. Buildings and sites are compared against each other on the same basis, which is usually where the first real savings come from. When two comparable buildings run well apart, that difference is a work list.
Reporting that draws from the model
Sustainability and energy reporting frameworks read from the same model as everything else, including STARS, Energy Star Portfolio Manager, and the UN Climate Commitment. Each framework wants the same underlying data in a different shape. Assembling it by hand once a year is where most of the effort goes, and most of the error.
Test the change before you make it
Because the model holds how things relate, it can be asked what-if questions. What happens to the plant if we reset that loop. When is the best window to take this unit down, given how the space is used. If this drift continues unaddressed, where does it end up. The answers are estimates, and they are considerably better than a meeting.
You can also just ask
The platform includes an assistant that answers questions against your model in plain language. Why is this alarm active. Has this happened before, and on what. What is unusual about this month's consumption. Summarize this report for someone who will not read it.
The point is not novelty. It is that a second-year operator on a night shift can get an answer that would otherwise require the one engineer who knows the plant, and that the answer comes from your model rather than from general knowledge about buildings.
3
Stage 3 of 3
Autonomous operation
Earn the autonomy before you hand over the keys.
Most of this market sells full autonomy as the opening pitch. We do not, and the reason is not caution for its own sake.
The platform starts by recommending
It watches how equipment actually behaves, compares that against what the model and the history say it should be doing, and proposes the change. A person reviews the recommendation and approves or rejects it. Every one of those decisions is training data. Approve a recommendation and the platform learns that this is acceptable in your environment, with your equipment, your tolerances, and your occupants. Reject one and it learns the boundary. The loop closes because the platform also sees the result of the actions it took, which means it is learning from consequences rather than from a model of consequences. Your team watches it get things right, on your equipment, for as long as it takes to believe it. Then, when your team has seen enough, the platform can act without waiting for approval. Full autonomy is not a switch we flip on your behalf. It is a state you arrive at, and you decide when. This is the slower answer. It is also the only version of this we have seen survive contact with a working operations team.
A note on AI
An honest word about AI in buildings
Sensors drift. Meters fail quietly and keep reporting a plausible number. Points get renamed during a retrofit and nobody updates the drawing. Unlike aviation, oil and gas, or process manufacturing, almost no building has the triple redundancy that lets you trust a reading without checking it against something else.
This is the part of the problem the market does not discuss, and it is the reason so many analytics projects quietly stop being used in year two. The dashboard was never wrong. The data was.
A meaningful share of what TwinWorX does is hold that foundation steady. Values are normalized and tagged against open standards so they mean the same thing everywhere. Communication health is monitored, so a device that stopped talking is flagged the day it stops rather than at the end of the reporting period. The health of the data itself is reported daily, as its own output, because it is the thing everything else depends on.
Fault rules carry the same discipline into the analytics layer. A rule will not evaluate on a reading that has gone stale, which means a dead sensor produces a data fault rather than a false equipment fault.
Get that right and analytics becomes defensible. Skip it and you have an expensive interface telling you confident things that are not true.
Technical Foundation
Underneath all of it
You don't have to buy the whole path
Almost nobody starts at stage three, and we would talk you out of it if you tried. The usual shape is one building or one site at stage one, connected properly, with a model built to a standard that the rest of the portfolio can be added to later. Analytics goes on top of that when the data underneath it is worth analysing. Autonomy comes when your team has watched the recommendations long enough to trust them.
Each stage is worth having on its own. None of them is a down payment on the next one.
Built for where you are going. Deployed for where you are.
Bring us your systems list and your worst recurring problem.
Thirty minutes with one of our engineers, not a sales development rep. We will tell you which stage you are actually ready for, and if TwinWorX is not the right answer for you, we will say so.
Prefer to read first? Why e-Magic | Where TwinWorx is used