Why is the path from commissioning data to HMI often inefficient?
On site, an engineer first discovers a BACnet device, checks its Device ID, IP address and objects. The next task may be finding Modbus registers, inspecting KNX group addresses or connecting to a Siemens Climatix OEM controller. Once communications are understood, another project starts: graphical visualization. In a traditional workflow, much of the same addressing information is entered again into an HMI tool.
This is not only a time cost. Every manual copy of an address, instance or label creates another opportunity for error. In a project with hundreds of points, the data model becomes more important than the drawing itself. A useful HMI designer therefore needs context: which device owns the point, how it is addressed and how it was identified in the field.
Step 1: NODVIA Field — Discover, Diagnose, Commission
NODVIA Field is the Android field toolkit. Its primary job is not HMI drawing; it is contact with the real system: device discovery, communication diagnostics, object and register inspection, supported writes and storage of project context.
For BACnet, a project can contain devices, Device IDs, IP/port context and objects such as Analog Input, Analog Output, Analog Value, Binary Input, Binary Output, Binary Value, schedules, trends and accumulators. For Climatix, project data can include the SCOPE hierarchy, normal points, schedules and history/trend objects. Exact availability depends on the project and current NODVIA Field support.
The important outcome is a project point database. That becomes the common language between field work and visualization.
Step 2: NODVIA Studio — a project-aware HMI designer
NODVIA Studio is the Windows visual HMI designer. It is not intended as an isolated drawing package. It opens NODVIA project data and uses the project device and point tree.
The left side contains pages and project points. The center is the visualization canvas. Properties of the selected element are shown separately, together with an element library and a vector automation icon gallery. The designer therefore starts with “which project point do I want on this page?” rather than “which IP address and object instance do I need to type again?”
Searching a large project
Tree navigation alone is not enough in larger sites. Studio therefore includes point search. The goal is to find points by Object Name, description, BACnet object type, instance, Device ID, IP address, units or device/path information instead of manually expanding long branches.
Drag-and-drop design
A point or graphical element can be dragged onto the canvas, moved, resized and configured. Studio supports multi-selection, grouped movement, reuse of visual properties and multiple pages and popups. Pages can include title bars, navigation, backgrounds and portrait or landscape layouts.
HMI elements bound to real automation data
A visualization is more than a picture. An element needs to know which point it represents and what actions are allowed. Examples include live value, mini value, status, setpoint, gauge, trend, schedule, text, action button, navigation button, icon, shape, line and pipe/polyline.
Writable elements require engineering discipline. A point being visible on an HMI page does not mean every point is writable. Writing depends on the protocol, point properties and project configuration.
A vector library for building automation
NODVIA Studio includes vector HVAC and automation symbols. The library can cover fans, pumps, valves, dampers, heating and cooling elements, boilers, chillers, AHUs, tanks, meters, energy, temperature, humidity, pressure, airflow, protocol symbols and navigation icons.
The vector approach has a practical advantage: graphics remain clean at different sizes and the same geometry can be reused consistently between the Windows designer and Android runtime. Some elements can also support animation or state-based appearance, such as a rotating fan or value-dependent styling.
BACnet: from discovered object to visual element
BACnet is a good example of why project context matters. The field tool discovers the device and objects; Studio can use that same information in a structured tree. Where available, a point can carry Device ID, IP, BACnet port, object type, object instance, Object Name, Description and units.
This reduces manual re-entry. Studio does not replace BACnet discovery; discovery remains primarily a NODVIA Field task. Studio's role is to use the collected project data in the HMI design.
Climatix: an unusual bridge between service and visualization
The Siemens Climatix workflow is particularly useful. NODVIA Field SCOPE MINI can collect project hierarchy, points, schedules and trend/history objects. Studio can then use that structure in the design workflow.
A Climatix schedule element can show a useful basic schedule preview on the HMI page. If the service technician needs deeper access, a click can open the detailed Climatix schedule view. The same principle applies to trends: the operator sees a simple graph, while the engineer can open the detailed history view.
The boundary is important: NODVIA Studio is not Siemens Climatix SCOPE. Siemens SCOPE remains the manufacturer's commissioning and service environment. NODVIA uses project data for its own HMI and field workflow.
Step 3: Project Visualization on Android
Project Visualization is currently a Beta runtime inside NODVIA Field. Visualization pages designed in Studio are loaded for the active NODVIA project and rendered on an Android phone or tablet.
Depending on the element and project, the runtime can show live values, status, gauges, graphical equipment, pages, popups, navigation, page selector, fullscreen layouts, portrait and landscape pages, trends, schedules and supported Climatix elements. Where allowed, a setpoint or control can also be writable.
The phone therefore has two roles. In service mode, NODVIA Field is an engineering toolkit. In Project Visualization, the same project can become a simple local HMI for commissioning, demonstration or an operator-facing view.
Why does a shared project model matter?
The real value is not simply “another HMI designer”. The value is data continuity. If a point was already discovered in the field, named, stored in the project and associated with a device, Studio should reuse it as directly as possible. The runtime should then use the same binding.
This has four practical consequences:
- Less duplication. Addresses and names do not need to be typed again at every step.
- Fewer mistakes. Less manual re-entry means fewer wrong Device IDs, object instances or register offsets.
- Faster commissioning. The engineer can move from diagnostics to a customer/operator view more quickly.
- Better service context. HMI elements remain connected to the underlying device and service information.
Practical example: an HVAC project with BACnet and Climatix data
Imagine a project with a BACnet BMS controller and a Climatix OEM controller inside an air-handling unit. Field first discovers the BACnet device, reads the objects and saves the project. SCOPE MINI then collects the Climatix hierarchy and trend/history objects. In Studio, the engineer searches for supply temperature, setpoint, fan status, alarm and trend points.
The first page becomes an overview: temperatures as live values, a fan as an animated icon, setpoint as a writable element, alarm as status and a trend as a graph. A second page contains a Climatix schedule. A third page contains a more detailed service-oriented view.
The project is then opened in Project Visualization. On the phone, the engineer checks whether the layout works at real size, whether navigation is simple enough and whether the bindings are correct. If necessary, the Studio project is adjusted and loaded again.
Designing for a phone is not the same as designing a desktop SCADA
Mobile visualization requires different decisions from a large operator monitor. A phone does not have room for twenty tiny values, complex navigation and long tables. Clear priority matters more: a few key values, touch-friendly elements, obvious alarm state and a simple path to a more detailed page.
That is why Studio supports multiple pages, popups, portrait and landscape layouts and navigation. One page can show the equipment overview, another the schedule, a third the trend and a fourth service values. A tablet can use a wider layout; a phone often benefits from a vertical flow and more pages. The designer should make this choice intentionally rather than simply shrinking a desktop HMI.
Visualization as part of commissioning
Project Visualization is useful before a project becomes a final operator HMI. During commissioning, the engineer can check on the phone whether values refresh, bindings point to the correct object, a setpoint writes to the intended point and navigation makes sense at real screen size. Addressing and binding errors can therefore be found on site, where they are easiest to verify.
This is also why the runtime is currently integrated into Field. The engineer can move from the visualization into a deeper service tool, inspect a BACnet object or Climatix schedule, and then return to the HMI. The operator view and service diagnostics are not two unrelated stories; they are two levels of the same project.
What Project Visualization is not
The current runtime is a Beta feature and should not be presented as a separate standalone NODVIA View APK. It is also not accurate to say that every protocol NODVIA Field can diagnose is already fully visualizable. Runtime bindings and elements continue to develop with the platform.
This matters commercially as well as technically. It is better to state what works today than to promise universal support. NODVIA is intended as an engineering tool, so the boundary between a supported capability and a future option should remain clear.
Field → Studio → Visualization in the wider NODVIA story
This workflow fits naturally inside the wider NODVIA — Universal Automation Platform concept. Field is the first contact with the device. Studio is the design and project visualization environment. Project Visualization brings the HMI back into the field. Connect, Core, Logic, View and Edge extend the same idea toward persistent integration, automation and operation.
The shortest explanation is therefore: Discover. Design. Visualize. For the engineer, that means less manual re-entry and a faster path from a real signal to a useful HMI.