The expert should know which device you clicked.
Why local BAS specialists need system context, useful tools, and a place in the technician’s existing workflow.
You select a device because something about it needs attention. Maybe it is offline. Maybe a value has stopped changing. Maybe its configuration looks wrong. That selection is already the beginning of an investigation.
I want a local BAS expert to begin there, with the device and its available evidence in view. The product direction I’m developing is an assistant attached to the controls workflow. The integrated experience described here is still development work.
Give the question its context
“Why is this controller offline?” is a thin question. A useful investigation needs more: which controller, when the status changed, what else changed, which path it uses, and whether nearby devices show the same symptom.
The proposed connector would gather what the platform exposes and preserve where each observation came from. A live reading, a cached point value, and an imported event record should carry different labels. A timestamp belongs beside the value, not buried somewhere the model cannot see.
Missing information needs an explicit representation too. If router statistics are unavailable, the expert should know they are unavailable. It should not silently treat that gap as evidence of a healthy router.
That is a design requirement I care about as much as the answer itself. The model’s interpretation can only be judged against the information it actually received.
Keep three jobs clear
The connector handles platform access. It identifies the selected equipment, collects supported information, and reports the outcome of a requested operation.
The local expert interprets the evidence. It decides which explanation deserves attention and which available check would help distinguish it from another explanation.
The interface keeps the investigation attached to the equipment. The technician should be able to inspect the evidence, understand the recommendation, and continue from the same context.
This separation gives us a way to improve the specialist without asking it to reinvent platform communication. It also gives us specific things to test when the final answer is wrong.
Existing platforms offer starting points
Tridium documents support for custom applications, plug-ins, data views, and developer APIs in the Niagara Framework. Siemens’ Desigo CC specification lists northbound RESTful Web Services and an ecosystem for extensions and applications.
Those are potential routes into the workflow. They do not establish that our proposed integration works, that every desired diagnostic signal is exposed, or that the same extension will work across versions. Each target needs its own access proof and compatibility work.
The model’s process also does not have to live inside the controller. My initial direction is a service on a suitable local workstation or on-site computer, connected to the platform interface. That is an architecture to qualify on actual hardware, not a promise that every small device can run the expert.
A compact model still has to earn its place
Running locally is one requirement. Useful technical judgment is another.
The specialist should face unfamiliar problems, working systems that need no repair, incomplete observations, and plausible explanations that turn out to be wrong. It should be compared with the unchanged local model using equivalent evidence. If extra context explains the improvement, we should say so. If training contributes a benefit, that needs its own measurement.
I also want the full episode evaluated. Did it identify the relevant facts? Did it choose a useful check? Did it interpret the result correctly? Did its final explanation stay consistent with the evidence?
A polished paragraph cannot carry an investigation if its next check is useless. The goal is a useful answer attached to the actual system, with evidence a controls engineer can inspect.
Sources
- Tridium: Developer resources and Niagara extension capabilities
- Siemens: Desigo CC system capabilities
Sources reviewed October 5, 2026. The architecture and evaluation requirements above describe this project’s development direction.
Russ
Controls engineer. AI builder.