Training a controls technician has an awkward economics problem: the useful practice is diagnosing faults, and you cannot break real equipment to create them. So training defaults to classroom theory, and the actual diagnostic skill gets learned slowly, in the field, at customer expense.
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
- Virtual mechanical rooms and panels — equipment you can open and inspect.
- Interactive meters and technician tools — take a reading the way you would on site.
- Wiring and signal tracing — follow the circuit to find the break.
- Sequence-of-operations exercises — understand what the system is supposed to do.
- Fault diagnosis scenarios — the failures that recur in the field.
- Instructor scenario editor — add faults specific to your installed base.
- Skills scoring and remediation — identify who needs which practice.
- Desktop non-VR accessibility mode — training that does not require a headset per trainee.
Diagnosis Is the Skill Worth Training
Anyone can be shown where a component is. The valuable and slow-to-acquire skill is working out why a system is misbehaving from incomplete evidence. Building scenarios around that — and scoring the diagnostic path, not just the final answer — is the design intent. The desktop mode exists because per-seat VR hardware is the usual reason training programmes stall.
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 — Training simulation we deliver today: simulation and training software development.
What a Scenario Library Needs From Your Installed Base
The simulator is only as useful as the faults it can pose, and those faults have to come from your equipment rather than a generic library. A scenario has to name a real machine, a real intended sequence, and a real failure mode, or trainees end up learning to diagnose a piece of software instead of a rooftop unit or an air handler.
Scope is narrower than most people assume. Nobody needs every model in every building modeled at once. The sensible starting scope is a few equipment families that account for most of your service calls, with everything else added later only if the first set proves out in practice.
What that scope needs from you is documentation, and it is specific:
- Sequence-of-operations documents for the equipment you want modeled. Without the intended behavior written down somewhere authoritative, there is no reference against which a symptom reads as a fault.
- Point lists, including your naming conventions, so simulated readings carry the same tags and units a technician will see on a panel or a graphic in the field.
- Wiring drawings or panel photographs at the level of detail a technician would actually use to trace a circuit, not marketing cut sheets.
- An honest list of the failures that recur. Failed sensors, drifting calibration, a valve that fails in position, a reversed transformer landing, communication loss on one branch. The mundane failures carry the training value; the exotic ones are not worth modeling first.
Modeling Symptoms, Not Thermodynamics
A training simulator of this kind does not need to be a physics engine, and treating it as one is a good way to spend the budget in the wrong place. What a trainee interacts with is evidence: a reading that is off, a status that disagrees with a command, a fan running when the sequence says it should be off. The simulation has to be correct at the level of evidence a technician can observe, and no deeper.
That has a concrete design consequence. Readings are derived from a modeled fault state rather than scripted step by step, so if a trainee measures at an unusual point, or takes readings in an order nobody anticipated, the values still agree with each other. Scripted simulations give themselves away exactly there: a trainee goes off the expected path and the tool returns a number that could not physically coexist with the last one.
There is a real boundary to state plainly. Time-dependent behavior, staging, and slow drift need a coarse model of rate of change, because some faults are only visible in how a system settles. That is not energy modeling, and numbers produced inside a training scenario should never be used to size equipment, estimate consumption, or support a commissioning decision.
When a Headset Is the Wrong Answer
Simulation earns its cost when repeated practice on equipment you cannot take out of service is the actual bottleneck. When the bottleneck is something else, cheaper approaches beat it, and it is worth checking honestly which one you have.
The case gets stronger in the opposite conditions: technicians spread across territories, turnover high enough that the mentoring pipeline cannot keep up, equipment that cannot be faulted for practice, and failures that appear seasonally or rarely enough that a technician might go years without seeing one.
- If the gap is product knowledge or code and specification knowledge, documentation, manufacturer material, and classroom time close it faster and for far less money.
- If you run a single site with one system type and have a spare panel in the shop, a live bench trainer is more faithful than any simulation and easier to keep current.
- If your trainees are few and physically together, mentored ride-alongs already supply diagnostic repetitions. Simulation is a way to scale repetitions, not a way to invent them where an easier source exists.
- If nobody will own scenario content after launch, the library goes stale as equipment changes and the tool quietly becomes a demo. That is an organizational prerequisite, not a software feature.
Failure Modes of the Training Program Itself
Projects like this fail in predictable ways, and most of the failures are about the program around the software rather than the software. They are worth designing against from the start.
None of these are exotic. They are the ordinary reasons a training tool sits unused a year after it is installed, which is why they belong in the design rather than in a lessons-learned document afterward.
- The first session measures comfort with the interface, not diagnostic skill. Someone who has never held a controller will look incompetent for reasons that have nothing to do with controls. The handling is an unscored orientation scenario whose only job is learning to move, grab a tool, and take a reading.
- Trainees learn the simulator instead of the system. If the fault always lands in the same subsystem, or the irrelevant equipment is always obviously irrelevant, the fastest strategy becomes pattern matching on the software. Randomizing where a fault sits and including plausible but innocent anomalies keeps the reasoning honest.
- Scores get used as a gate. Output built to show where someone needs practice turns into a pass or fail credential, and people start optimizing for the number. It also has to avoid penalizing measurement-heavy exploration, which is often what a careful technician actually does.
- Comfort limits session length. A real diagnostic scenario runs longer than many people want to spend in a headset, so scenarios have to save state and resume rather than assume one uninterrupted sitting.
Frequently Asked Questions
What exactly is this, and what is it not?
Start with the boundaries, because they are the part people get wrong. It is not a course library, not a video curriculum, and not a replacement for hands-on time on real equipment or for the physical trade skills that go with it: brazing, pulling and terminating wire, working safely around energized gear. It is a practice environment for the reasoning half of the job, and that limit is deliberate. It is also in development, so what exists today is a design we can walk you through, not a license you can purchase.
What has to already exist on our side to use it?
Workstations capable of real-time 3D, and for headset use either cleared room-scale space or a seated configuration that works at a desk. Beyond hardware you need a content owner: an instructor or senior technician with the authority to say what a correct diagnostic path looks like on your equipment, because that judgment cannot come from us. Nothing has to be connected to live building systems. Since the product is still being built, treat hardware expectations as design targets rather than a published requirements list.
Does it connect to our building automation system or our controllers?
No, and that is intentional. Trainees need to drive equipment into states nobody would permit on a production system, which rules out any live link to controllers, a Niagara station, or a front end. Integration is meant to run one direction and only at authoring time: exported point lists, naming conventions, and sequence documents from your existing platform can seed a scenario so tags, units, and graphics resemble what your technicians actually see. Nothing a trainee does inside a scenario reaches real equipment.
How would a rollout proceed, in order?
The scoping decision described above comes first, then gathering the source documents for that scope, then modeling one equipment family and having a senior technician validate it before anything is produced at volume. Faults are authored against the validated model, a small cohort runs the scenarios while scoring rules get tuned against their actual behavior, and only then does it widen, with a named owner for ongoing content. The validation step before volume is the one everyone wants to skip and the one that prevents a library of confidently wrong scenarios. This is the intended sequence for a product still in development, not a schedule being offered.
Would our instructors author the scenarios, or would you?
Either is workable, and the answer changes how the editor has to be designed. If your instructors author, the editor must be usable by someone who knows HVAC and not Unity: choose equipment, choose a failure, set what goes wrong, define what counts as a correct diagnosis, with no scripting anywhere in the path. If we author, the constraint shifts to review, and what you need instead is a way to read a scenario back in plain language and correct it before it reaches trainees. The design assumes the first case, because a library only stays current when the people who encounter the failures can add them.
Where would trainee performance data live, and who controls it?
Trainee results, scenario content, and any models built from your drawings are your material, and the design keeps them under your control: running on your infrastructure, exportable, and deletable. Libraries built from your sequences and point lists stay yours, and the intent is not to pool customer scenarios into a shared catalog. Score records are meant to leave as exports you can load into whatever already tracks training, instead of living only inside a portal someone else hosts. That is stated design intent for a product in development, not a description of a deployed system with agreements already behind it.
Is this aimed at apprentices or at experienced technicians?
Both, but with different scenarios and for different reasons. An apprentice benefits from frequent narrow scenarios with one clear fault and an unambiguous sequence to compare against; an experienced technician learns nothing from those and needs ambiguity, such as two plausible causes, a symptom that comes and goes, or evidence that partially contradicts itself. Experienced technicians are also the better reviewers, because disagreement over the right diagnostic path usually exposes a real difference in field practice worth settling before it gets scored.
Does it need internet access, or can it run on an isolated network?
It is designed to run locally. Training rooms and shop networks are often restricted, and headsets tend to be shared devices with no account per trainee, so the simulation, the scenario library, and result capture should all work with no outbound connection, with updates and content moving as files. A few conveniences are easier with connectivity, such as distributing a scenario between locations, so that split is something to settle per customer rather than a fixed answer. As with the rest of this page, it describes how the product is being designed to install, not something that can be deployed today.