Simulation and Training Software Development

Some things cannot be learned safely on the real system. You cannot fail a chiller in an occupied hospital to see how the team responds, break live switchgear to teach fault-finding, or rehearse an emergency by causing one. So the training either does not happen, or it happens in a classroom and the real skill is learned slowly in the field at customer expense.

Simulation and training software closes that gap — a realistic environment where practising failure is free.

What We Build

  • Operator training simulators — realistic system behaviour with the interface trainees will actually use.
  • Fault-injection scenarios — cascading, realistic failures rather than isolated puzzles.
  • Procedure and sequence training — practise the process before it matters.
  • Instructor tooling — author scenarios, escalate mid-exercise, control difficulty.
  • Competency scoring — measurable capability rather than attendance records.
  • After-action review — replay what happened and why, which is where the learning actually lands.

Realism Is the Whole Requirement

A simulation that behaves incorrectly teaches incorrect instincts, which is worse than no training. That is why our building-systems work is built with our sister practice SoftwarePile supplying authentic Niagara and BAS behaviour, and security scenarios with BulletproofSoft. Game technology makes it engaging; domain accuracy makes it useful.

Engagement Is Not Decoration

Training that is tedious does not get completed, and completion is the point. The same design craft that keeps people playing a game keeps a technician working through a difficult diagnostic scenario — that is the actual reason to build training on game technology.

Current builds are described under solutions in development. Tell us what your people need to practise and we will scope a simulation around it.

Related services

How Much Fidelity Do You Actually Need?

Fidelity comes in kinds that are worth separating before anyone talks about budget. Physical fidelity is whether it looks and feels like the real equipment. Functional fidelity is whether it behaves correctly when acted on. Psychological fidelity is whether it reproduces the pressure, ambiguity, and time constraint of the real event.

Functional fidelity is what procedural and diagnostic training runs on. Psychological fidelity matters when the real event is time pressured or ambiguous. Physical fidelity is the one to interrogate, because it is expensive and easy to buy before anyone has asked whether it carries the learning. Some of it is functional in disguise. A technician learning alarm triage needs correct system behavior and a console laid out like the one on their desk, because the layout is part of the task. That is targeted physical fidelity, not a photoreal plant room. A crew rehearsing a night callout needs the pressure more than the photorealism.

Deciding which kind of fidelity does the work is the first design conversation, and it changes the cost drivers more than any engine decision will.

Start From the Task Analysis

Before any scenario gets written, three questions need answers. What does a competent person actually do, in what order, with what information available. Where do people get it wrong in the field. Which of those errors is consequential enough to be worth training out.

The answers come from your trainers, your experienced operators, and the people who clean up after incidents. Scenarios written from an equipment manual teach the manual. This is also where assessment criteria come from. Scoring invented after the scenarios exist tends to measure whether someone completed the exercise, which is attendance with extra steps.

When a Simulator Is the Wrong Answer

A simulator is a significant build, and there are cheaper shaped problems that look similar from a distance.

Simulation earns its place when practice on the real system is unsafe, disruptive, or impossible to schedule, and when the skill is procedural or diagnostic enough that repetition is what builds it. Diagnostic reasoning under uncertainty is the clearest case, because there is no way to teach it from a slide deck.

  • The task is a checklist and the failure is people skipping steps. That is a job aid and a supervision question.
  • The knowledge is declarative and stable. A short document and a quiz will cover it.
  • The gap is coordination between people rather than interaction with a system. A facilitated tabletop may get you further.
  • The underlying system changes constantly. Anything modeled may be out of date before a cohort finishes.

Desktop, VR, or Both?

VR buys presence: spatial memory, physical procedure, and a genuine sense of consequence. It also buys logistics. Headsets are shared equipment, and someone has to be responsible for keeping them charged, clean, and available. Sessions need space and usually a facilitator. First time users often need onboarding to the hardware before any training content lands at all.

Desktop delivery reaches more people with fewer moving parts, and it is often the right primary mode with VR reserved for the subset of tasks where being physically in the space is the point. Where the scenario allows it, we build one simulation core and two front ends. AR and VR Development goes into the headset considerations in more detail.

Records, Scoring, and What Your LMS Expects

If completion has to appear in a compliance record, that is a requirement with a technical shape: xAPI or SCORM output, a stable learner identifier, single sign on, and agreement on what constitutes a pass. Decide early whether you are recording completion, competency, or both, because scoring designed for one does not convert cleanly into the other.

Instructor tooling deserves the same scrutiny. If an exercise needs a facilitator to escalate a fault mid run, that facilitator’s time becomes a recurring cost driver in your program. Software that lets a scenario run unattended, or lets one instructor supervise a room, changes what the program costs to operate over its life.

Scenarios Age

A simulator built around a specific plant, fleet, or control system will drift from reality as the real thing is upgraded. Treat content maintenance as a standing activity with an owner, and prefer an authoring approach where your own trainers can edit and add scenarios without coming back to us. That decision belongs at design time. Retrofitting an authoring layer onto hardcoded scenarios is close to a rebuild.

Products we are developing in this space are described under Solutions in Development, including the Smart Building Operations Simulator and the HVAC and Controls Technician VR Academy. They are not available to buy, license, pilot, or schedule today. The custom simulation work on this page is what we deliver now, and it does not depend on any of them shipping.

Where the Budget Actually Goes

Three things dominate the cost of a training build, and none of them is the renderer. Scenario content is first, because every branch, fault, and scoring rule has to be written, reviewed by someone who knows the work, and then tested. Integration is second: identity, records, and whatever your compliance system expects on the other end. Instructor tooling is third, and it is the one most often left until the end, at which point it becomes a spreadsheet somebody maintains by hand.

Pricing a program without those three named separately produces a number that will move. Name them at scoping, even roughly, and the later conversations get much shorter.