Building operators learn on the live building. That is the only training environment most of them get — which means the first time someone sees a genuine plant failure cascade, it is happening for real, at 3am, with occupants affected. You cannot rehearse a chiller failure in a hospital to see how the team responds.
Status: product concept, in active development. This is something we are building, not something you can buy today. We publish our roadmap because the engineering thinking behind it is the useful part — and because we would rather show you the design than imply a finished product.
Designed Capabilities
- 3D facility and equipment simulation — a virtual hospital, school, data centre or office tower.
- Niagara/BAS telemetry emulator — the data behaves the way a real station does.
- Scenario authoring studio — build the failures your team should be ready for.
- Operator workstation and alarm console — trainees work the interface they will use.
- Fault injection and event orchestration — cascading failures, not isolated puzzles.
- Instructor control room — escalate, pause and probe during the exercise.
- Performance scoring and competency model — measurable capability, not attendance.
- After-action replay and certification — review what was missed and why.
Realism Comes From the Building Side
The simulation is only useful if the BAS behaves correctly — wrong data teaches wrong instincts. SoftwarePile supplies the realistic Niagara and BAS behaviour; SoftwareSplash builds the 3D environment and training engine. That division is the reason this is credible rather than a generic training game.
Tell us if this matches a problem you have — early input shapes what we build first, and we will give you an honest view of where it stands.
Related services
- Simulation and Training Software Development — Simulation work we deliver today, while the simulator is in development.
- 3D Visualization and Digital Twin Services — Related: 3D visualization and digital twin services.
What This Is Aimed At, and When a Simpler Option Is Better
The gap this is designed to close is judgment under load, not equipment knowledge. Most operators can describe how a chiller plant or an air handler is supposed to work, and vendor courses already cover what the interface does and what the sequences say. What no classroom produces is the condition where several alarms are true at the same time, one of them is a symptom of another, and somebody has to decide what to look at first while a phone is ringing. That decision is the actual skill, and right now it is only ever practiced during a real event.
This is the wrong tool for some problems that look similar. If the underlying issue is that the graphics are misleading, points are misnamed, or the sequences were never written down, a simulator built from that documentation will reproduce the confusion rather than remove it; the station is what needs fixing first. If a site runs one modest plant with a stable crew who have all worked its failures, a written procedure and time with the senior operator is cheaper and does more.
The conditions where a simulated environment earns its cost look like this:
- Turnover, contract staffing or shift coverage puts people on the console who have never worked a failure on that plant.
- The events that matter cannot be staged on a running building: a generator transfer that does not complete, a smoke control sequence nobody wants to test live, a loss of primary cooling during occupied hours.
- A slow or wrong first move costs patients, product or uptime rather than comfort complaints, so the order of the response matters as much as the eventual fix.
- Response has to be assessed rather than attended, which means somebody needs a record of what the operator actually did and in what sequence.
How the Parts Are Meant to Fit Together
The design keeps three layers separate and has them communicate through point state rather than through the visuals. The telemetry emulator holds the model of the plant and produces point values, alarm behavior and responses to commands. The 3D environment and the operator workstation read that state and show it. Instructor tooling writes into the emulator, not into the scene, so an injected fault propagates the way the model says it should instead of being animated to look like it did.
That separation is the reason a scenario can survive a trainee doing something unexpected. If faults were scripted into the scene, every branch would have to be hand authored, and any action the author did not anticipate would produce nothing at all. Driving the scene from emulated point state means an unanticipated command produces whatever the model produces, including the common real world outcome of accomplishing nothing while the clock runs.
Time is the harder design problem. Real plants respond slowly: thermal mass, valve stroke times and staging delays mean the informative part of a failure can outlast a training session, but the waiting is often the lesson. An operator who overrides because nothing visible happened right away has just made the classic mistake, and a fixed speedup would quietly teach that the mistake was reasonable. The intent is compression that the instructor controls deliberately and that the after action replay reports honestly, so the trainee sees what the real response interval would have been.
What the Design Assumes an Owner Would Supply
SoftwarePile supplies the BAS behavior engine. What that engine has to be configured against is a description of one specific plant, and that description can only come from the people who run it. No vendor can write it from outside, and the design assumes the owner would provide it rather than approve a generic template.
The inputs the design assumes would matter most: a point list with engineering units, ranges and alarm limits; an equipment schedule with capacities, staging and redundancy; the sequences of operations as written and as actually running, which are frequently two different documents; the alarm priority and escalation scheme, including who gets called and when; a short list of failures that have genuinely occurred on the site; and a definition of what a correct response to each of them looks like.
The item most likely to be underestimated is the last one. Scoring requires somebody with authority to state that a given sequence of operator actions was right, and to accept that a defensible alternative should also score. Two facilities can grade the same action differently: isolating a loop is routine in an office tower and unacceptable in an operating suite while a case is running. That is an owner judgment call, so the design treats the competency model as something configured per site rather than a default shipped with the product.
Where This Is Expected to Be Difficult
These are the failure modes we can name from the design, and designing against them is most of what the roadmap is actually solving for. Naming them now is more useful than claiming they are solved, because nothing has shipped and the decisions are still open.
Fidelity chasing is the first. It is tempting to model physics to a depth no trainee will ever perceive, and the training value sits somewhere shallower: point behavior, alarm ordering, and the delay between a command and a visible result. The working rule is to add fidelity only where a trainee could otherwise learn something false, and to stop there.
Model drift is the second. A plant model built from a point list is correct on the day it is built, and a control upgrade, a retrofit or a rewritten sequence makes it wrong without announcing itself. The intent is to version the model against a dated export and make a mismatch visible to the instructor, rather than to promise a model that stays current on its own.
The last two are about what gets rewarded. A naive score favors the operator who acknowledges everything quickly while diagnosing nothing, so the scoring model is designed around the order of investigation and whether an action addressed the cause. And a 3D room that looks like the real mechanical room but places an isolation valve on the wrong wall teaches a spatial habit that will fail in the building, which is why the design distinguishes spaces surveyed from the actual facility from spaces that are only representative, and says which is which.
Frequently Asked Questions
What is the Smart Building Operations Simulator, concretely?
It is a training environment, and it is not a building analytics product, not a commissioning or control program test tool, and not something that attaches to a production plant. A trainee works an operator console against emulated station data while an instructor drives an incident, and what the trainee did is recorded so it can be reviewed afterward. The purpose is to change how people respond under alarm load; it will tell you nothing about how your real building is performing. It is a product concept in active development.
Can we buy it, license it, or join a pilot right now?
No. There is nothing to purchase, no license to sign and no pilot to join, because it is a concept in active development rather than a released product. What a conversation amounts to today is a design review, and the useful output for a facility is a clear written statement of which failures they would want rehearsed and what a correct response to each looks like, which is theirs to keep regardless of what we build. We are not in a position to state a release date and will not imply one.
What is it designed to run on, and what has to already exist on our side?
The design target is workstation class PCs on the customer's own network, with a discrete GPU for the 3D environment and ordinary machines for the instructor view. Headset use is designed as an option rather than a requirement, since equipping and sanitizing headsets for shift based staff is a logistics problem that should not gate the training. What has to already exist is documentation rather than infrastructure: a current point list, the sequences of operations, and an equipment schedule. Nothing here is deployable today; this describes how it is being designed to install.
Does it connect to our live BAS or Niagara station?
No, and that is deliberate. The telemetry emulator is designed to reproduce how a station behaves rather than to read from one, so there is no path from the training environment to real equipment and nothing a trainee does can reach a live plant. What it is designed to consume is exported description: point list, alarm configuration, sequences, equipment data. If the requirement is a live building reflected in 3D rather than a training plant, that is digital twin work and belongs in a different scope.
How would a rollout actually proceed, in order?
The intended order is to model one plant rather than a portfolio, starting with assembling the plant description from the owner's documentation. Next the emulated behavior is checked against expectation, with senior operators confirming that the station reacts the way theirs does before anything is used for training. Then the environment is built for the spaces that matter, typically the mechanical and electrical rooms and the roof rather than the whole building, and a small number of scenarios are authored from events that really happened on site. Scoring stays off through the first instructor led runs until the competency model has been agreed, then it is turned on.
How is it meant to integrate with the training and IT systems we already run?
The design assumption is that it is not the system of record for training. Competency results are designed to export to whatever LMS or HR record already holds them, so a facility is not maintaining a second roster of who is qualified on what. Authentication is designed to use the identity provider the organization already runs, which keeps operator accounts off a separate list that nobody remembers to deprovision. Scenario content is designed as data files the customer can store, version and move rather than content locked inside a vendor service.
Who would control the data, and where would it sit?
There are two kinds and they are treated differently. The plant description is sensitive, because a point list plus sequences plus alarm routing is a description of how to operate and how to defeat a building; the design keeps it the customer's, resident in the customer's environment where the deployment allows, not aggregated across customers and not used to build shared content. Trainee scores and replays are personnel records, so the design treats the employer as the controller, including deletion, with the instructor deciding who can view a session. Since nothing has shipped, no one's plant data or performance records are being held anywhere today.
What would we have to provide or decide before any of this is useful?
What an owner would need to provide is documentation rather than engineering time: point list, equipment schedule, sequences of operations, and the alarm and escalation scheme. What an owner would need to decide is which plant gets modeled first, who holds the instructor role, since running an exercise well is a real job and not a spare duty, and who has the authority to sign off on what counts as a correct response. Decide which failures are worth rehearsing. That list is often shorter and more specific than a generic failure catalog, because it comes from what has actually gone wrong on site.