Can Software Understand a Building? From BACnet Points to Semantic Twins, Auto-Generated HMI and Intelligent Diagnostics

Buildings already speak. The problem is that they speak in points.

A modern building may contain thousands of measured and controlled points. A BACnet device can tell us that object AV-17 is 21.4 °C. A Modbus device returns register 40127. KNX exposes a group address, Climatix has its own hierarchy, and another system may provide an MQTT topic or OPC UA node. To software, these are data. To an engineer, the value becomes useful only when its meaning is known.

When an engineer reads Supply Air Temperature, they see much more than a number. They know the point probably belongs to an air-handling unit, may be measured before or after a heating coil, and should be interpreted together with its setpoint, valve command, fan state and water temperatures. Humans create context almost automatically. Traditional BMS software often does not.

This leads to the central question:

Can the next generation of building automation software move beyond reading points and begin to understand their roles and relationships?

If the answer is even partly yes, commissioning, HMI creation, diagnostics, migrations, energy analysis and the use of AI in buildings all change.

From data interoperability to meaning interoperability

BACnet was a major step because it standardizes communications and an object-oriented information model. Systems can access analog and binary values, schedules, alarms and other objects without knowing the internal implementation of a device. But communication interoperability is not the same as semantic interoperability. Two compliant devices may describe the same concept as SA_TMP, SupplyTemp or simply AV-17.

That problem is why semantic approaches such as Project Haystack, Brick and ASHRAE's work on Standard 223 matter. Their common direction is to model entities and relationships as well as values: what is equipment, what is a sensor, what space it serves, what system it belongs to and how components relate to each other.

Project Haystack describes a very practical industry problem: operational data often has poor semantic modelling and must be manually mapped before analytics or visualization can create value. Brick provides an ontology for building entities and relationships. ASHRAE 223 formalizes machine-readable semantic models intended for analytics, automation and control.

So “software that understands a building” is not science fiction without technical foundations. The industry is already building the language required to represent meaning.

What would “understanding a building” mean for software?

The word understand can easily become marketing hype. Software does not experience a room like a human. But it can build a sufficiently rich model to perform useful reasoning. In building automation, five levels are useful:

The key difference is between a semantic model and a point list. The model does not merely know that BO-3 exists. It knows that BO-3 commands the supply fan of AHU-1, that the fan has feedback, a speed signal and airflow measurement, and that the AHU serves a specific zone.

How far is NODVIA already from this idea?

The current NODVIA workflow is already an interesting foundation. NODVIA Field discovers devices and real project points. NODVIA Studio uses those points in the project tree and HMI design. PICALLW Cloud distributes the project to NODVIA View, where it runs as a standalone Android visualization.

Today, this primarily solves the problem of re-entering project data. A future step could add a semantic layer. Instead of Studio seeing only a point, it could see:

Equipment: AHU-1
Point: Supply Air Temperature
Role: sensor
Medium: air
Location: downstream of heating coil
Unit: °C
Related setpoint: SA-T-SP
Related actuator: Heating Valve
Related fan: Supply Fan
Serves: Office Zone 2

That model would not merely improve documentation. It would become input to automatically generated capabilities.

First revolution: automatically generated HMI drafts

NODVIA Studio already works with real project points, allowing a designer to place them on an HMI page. That is more efficient than retyping addresses. But semantic knowledge of equipment could take the workflow further.

If the system recognizes an air-handling unit with sufficient confidence, it could offer:

Detected equipment: Air Handling Unit
Confidence: 94 %
Detected functions:
  Supply fan
  Extract fan
  Heating coil
  Cooling coil
  Supply air temperature
  Extract air temperature
  Filter differential pressure
  Schedule

Suggested action:
  Generate AHU visualization

Studio could select standard fans, valves, sensors and pipes from the vector library, create a base schematic, bind points, and add appropriate trend or schedule elements. The engineer would review and edit the result. A two-hour drafting job might become ten minutes of validation.

This direction is not purely hypothetical. Research on semantic digital twins has demonstrated automated generation of monitoring applications from semantically mapped operational data. The challenge is no longer proving that semantics can drive applications; it is making the inference robust enough for messy real buildings.

Second revolution: diagnostics from relationships, not isolated thresholds

A classic alarm is often simple:

Supply temperature < 14 °C → ALARM

Semantic diagnostics can use context:

Heating valve       = 100 %
Supply fan          = RUNNING
Supply air setpoint = 22.0 °C
Supply air temp     = 16.1 °C
Hot-water supply    = 65 °C
Trend duration      = 18 min

The system should not instantly declare a failed heating coil. But it can provide a structured diagnostic candidate:

The software no longer says only that “temperature is low.” It explains why the combination of signals is unusual and what should be checked next.

AI is not magic – without semantics it can be a very confident guesser

A language model may infer surprisingly much from point names, but unstructured names are ambiguous. TV1 might be a valve, a sensor or something else. AI therefore should not be the sole source of truth.

A more robust architecture combines several layers:

1. deterministic metadata: protocol, object type, units, address and permissions;
2. semantic vocabulary: Haystack, Brick, ASHRAE 223 or a compatible internal model;
3. rules: known relationships and common HVAC structures;
4. time series: correlations, command-response behavior and operating sequences;
5. AI: interpretation of unclear names, suggested classifications and natural-language explanations;
6. human confirmation: validation of ambiguous relationships and critical changes.

Research on semantic digital-twin creation increasingly explores metadata inference from operational time series. Point types, relationships and operating functionality can sometimes be inferred from behavior, not only names.

Example: the valve has a poor name, but its behavior gives it away

Imagine an analog output with no useful description. It ranges from 0 to 100%. When it increases, the air temperature downstream of a coil rises after a delay. The effect is strongest while the supply fan runs. A hot-water temperature sensor exists nearby.

The system can combine object type, range, delayed relationships, project hierarchy and confirmed examples from previous projects. Instead of stating “this is definitely a heating valve,” it can propose:

Candidate semantic role: Heating Valve Command
Confidence: 0.87
Evidence:
  analog output 0–100 %
  positive delayed relation to supply-air temperature
  belongs to AHU-1
  matches 23 previously confirmed patterns
Action: Confirm / Reject / Edit

This creates human-in-the-loop semantic learning. Confirmed classifications can improve future suggestions.

A semantic twin is more than a digital twin with a fashionable name

Digital twin is a broad term and can describe many levels of digital representation. A semantic twin explicitly represents meaning and relationships in machine-queryable form so applications can reason over them.

A future NODVIA architecture could separate:

The long-term value is application portability. If software can query “all supply fans and their status feedbacks,” it matters less whether the site calls them SF1, VENT-D, B01 or Fan_A.

Could the HMI almost create itself?

A fully autonomous HMI can easily become a poor operator interface. A more realistic concept is an auto-generated first draft.

NODVIA Studio could identify equipment type, choose a template, place standard automation symbols, bind measurements and commands, create base trends and schedules, propose navigation and clearly mark uncertain points. The engineer remains the author of the final solution but no longer starts from an empty page.

From HMI generation to continuous recommissioning

Once software understands system structure and has operational history, it can continuously test whether the system still behaves as expected. This goes beyond threshold alarms:

• a valve command changes but the thermal response no longer follows,
• a fan consumes more energy at the same airflow,
• two historically consistent sensors begin to diverge,
• a schedule runs while the space is consistently unoccupied,
• heating and cooling operate simultaneously,
• a setpoint is systematically missed in one operating mode.

Recent ontology-driven digital-twin research is already exploring optimization and recommissioning of real building operations. Semantics can therefore become operational infrastructure, not just richer documentation.

The hardest problem is not the algorithm. It is the real project.

Laboratories have clean names. Real buildings have twenty-year-old devices, mixed languages, copied descriptions, wrong units, undocumented replacements, gateways and several protocol generations. That is why a semantic system should be an evidence model, not a one-time classifier.

Relationship: AHU-1 serves Zone-2
Source: confirmed by engineer
Confidence: 1.00

Point role: Heating Valve Command
Source: name + units + temporal inference
Confidence: 0.87

Point role: Supply Air Temperature
Source: BACnet description + engineer confirmation
Confidence: 1.00

If the system is wrong, the engineer can see where the conclusion came from.

Safety: understanding must not become unrestricted control

The most dangerous interpretation of intelligent building automation would be to give AI unrestricted authority over setpoints and equipment. That is not the goal.

A sensible architecture separates read-only reasoning, recommended actions, bounded automation and safety-critical local control. NODVIA already distinguishes visualization from write permission; the same principle becomes even more important when intelligent diagnostics are added. Understanding is not the same as permission to control.

How could this vision evolve inside NODVIA?

Phase A — Semantic Assist

Studio suggests point and equipment types from names, descriptions, units, object types and project hierarchy. The user confirms or edits.

Phase B — Relationship Builder

The system proposes point-to-equipment, equipment-to-system, equipment-to-space, command-to-feedback and setpoint-to-process relationships.

Phase C — Auto-HMI Draft

Recognized equipment receives a suggested base visualization with automatically bound elements.

Phase D — Diagnostic Graph

NODVIA uses relationships and trends to detect inconsistent operating states and produces an evidence-backed diagnostic candidate.

Phase E — Building Copilot

The engineer asks: “Why is AHU-3 below setpoint?” The answer is grounded in the current semantic model, project signals and historical behavior rather than generic internet knowledge.

What would a good Building Copilot actually look like?

It should begin with evidence rather than a long AI paragraph:

Question:
Why is AHU-3 supply air temperature below setpoint?

Observed:
  Setpoint: 21.5 °C
  Actual: 17.2 °C
  Heating valve command: 100 %
  Hot-water supply: 63.4 °C
  Supply fan: running
  ΔT across heating coil: 1.1 K

Likely causes:
  1. insufficient water flow through heating coil
  2. valve/actuator not following command
  3. incorrect temperature sensor reading

Recommended checks:
  verify valve feedback
  compare return-water temperature
  inspect pump / differential pressure

No automatic write action performed.

This is far more useful than a generic chatbot. It is AI grounded in the actual building.

Why this is bigger than simply “adding AI to the BMS”

If a language model is added on top of an existing BMS without semantic structure, it may only become a better search box. The deeper change happens when software gains a machine-readable building model. The same semantic layer can then support auto-HMI, fault detection and diagnostics, energy analysis, recommissioning, legacy migration, point search, documentation and AI assistance.

That is why standard semantic models matter. If meaning is trapped in a single proprietary application, the industry has only created another data island.

Third revolution: a building that documents itself as it changes

One of the largest problems in building automation is not commissioning but what remains five years later. Project documentation may become outdated after the first substantial retrofit. One technician replaces a sensor, another contractor changes an address, a third adds a valve, and eventually nobody is completely certain what is actually installed. A semantic model could become living documentation that evolves with the real project.

If Field discovers a changed Device ID or a new object during service, the system could compare the observed project with the expected model. Studio might report: “Project model changed since last deployment.” After engineering confirmation, the change becomes part of project history and a controlled View deployment can carry the updated model forward. Documentation stops being a PDF that slowly decays and becomes a verifiable structure with provenance.

This is especially valuable during legacy BMS migration. If software can reconstruct equipment, points and relationships from an older system, part of the building's engineering knowledge can survive the platform change. The semantic model therefore becomes more than infrastructure for AI; it can become a carrier of technical building knowledge.

Fourth revolution: the semantic model as a long-term building asset

Building owners often pay to map the same knowledge repeatedly. The BMS integrator maps it once, the energy platform maps it again, the FDD vendor maps it a third time and the next SCADA migration repeats the work. Each application must rediscover which sensor belongs to which space and what each point means.

A high-quality machine-readable building model can reduce that duplication. A new application no longer starts by asking “which AV is the supply-air temperature?” It can query “give me the supply-air temperature sensors for every AHU.” This is one reason open semantic models such as Brick, Haystack and ASHRAE 223 are strategically important.

For NODVIA, a sensible future approach would avoid turning its internal project model into another isolated proprietary island. Even if the implementation uses a practical NODVIA-native format, mapping to standardized semantic concepts could preserve interoperability while keeping the engineering workflow efficient.

How would we prove that the system understands enough to be useful?

The biggest risk is an impressive demo on five perfectly labelled devices. Real quality appears only across hundreds of messy projects. The vision therefore needs measurable benchmarks.

• Point classification accuracy: how often is the functional role correct?
• Relationship accuracy: how often are sensor, actuator, equipment and space connected correctly?
• Coverage: for what proportion of a project is the system willing to make a suggestion?
• Calibration: does a 90% confidence prediction actually prove correct about 90% of the time?
• Human correction time: how much engineering effort is saved compared with manual modelling?
• Cross-site portability: does the method work on projects from different vendors and integrators?

The last point is particularly difficult. A model that works only on one naming convention has not learned building semantics; it has learned a local dialect. A credible research dataset therefore needs diversity in vendors, languages, building types, countries and documentation quality.

Transparent performance statistics matter more here than the marketing label “AI.” Engineers must be able to see when the system is confident and when it is guessing.

Could open semantics reduce vendor lock-in?

Potentially. When building meaning exists only inside one vendor's project database, migration is expensive because engineering knowledge must be reconstructed. If devices, roles and relationships are represented in a portable semantic model, visualization, analytics or supervisory software can be replaced without rediscovering the entire building from scratch.

This does not make every system identical. Control logic, safety functions, protocol details and vendor-specific capabilities still matter. But the fact that a point is the supply-air temperature of a particular AHU should not need to live only inside one HMI screen.

If NODVIA eventually imports, exports and enriches such models, its value can extend beyond its own View runtime. It becomes a tool for preserving and transferring knowledge about the automation system.

The future of building automation is not more points. It is more meaning.

Building automation has become steadily better at connecting devices. We have more protocols, gateways, APIs and data. The paradox is that more data can make a building harder to understand if its meaning is not represented.

The next layer may therefore not be another protocol. It may be the semantic layer that connects points into a model humans and software can reason about.

For NODVIA, this is a natural research direction. Field already collects real project context. Studio uses project points for HMI design. Cloud connects the project lifecycle. View runs the visualization. A semantic layer above that foundation could let the same project data drive automated design, diagnostics and intelligent assistance.

The strongest version of the idea is not:

“AI will operate the building instead of people.”

It is:

“Software will understand enough of the building's structure and behavior to surface the right information, propose sensible next steps and automate repetitive work – while preserving evidence, limits and responsibility.”

Conclusion

Can software truly understand a building? If “understand” means human consciousness, no. If it means a machine-readable model of equipment, spaces, points, relationships, states and history that supports useful reasoning, the answer is increasingly yes, at least in part.

Semantic standards, ontologies, digital twins, automated metadata inference and AI agents are already assembling individual pieces of this future. The difficult part will be moving from curated research examples into messy, multi-protocol, decades-old real buildings.

That is exactly where the most interesting NODVIA research direction appears:

The future of building automation is not more points. It is more meaning.