BQL

BQL is how you get answers out of a Niagara station. The Baja Query Language pulls points, histories, and component data into reports, dashboards, and exports – and written well, it does so without dragging the station down. Software Pile builds BQL-driven reporting that operators and managers actually use.

BQL Work We Deliver

  • Reports: energy, runtime, alarm summaries, and compliance exports built on BQL queries
  • Live dashboard data feeds that query the station efficiently for the values on screen
  • History and audit queries across large datasets, tuned so they return before the operator gives up
  • Scheduled exports to files, databases, and enterprise systems

Queries That Do Not Punish the Station

A careless BQL query over a large history set can stall a station for everyone. We write queries that scope, filter, and index sensibly – so reporting is fast and the control system stays responsive while it runs.

Tell us what you need to report on and your Niagara version. We will build the queries and the reports around them.

What Is BQL?

BQL — the Baja Query Language — is the query language built into the Niagara Framework. It is used to search a station’s component space and history data: finding components that match a set of criteria, extracting history records for a report, or feeding a live table in a graphic.

If you arrived here looking for Bloomberg’s BQL, that is a different and unrelated language for financial data. This page is about Niagara.

What Can You Query with BQL?

Two broadly different things, and knowing which one you are working with explains most confusion:

  • The component space — the live station tree. Queries that find all points of a given type, all devices in an alarm state, all components carrying a particular tag, or everything under a given folder.
  • History data — the stored records behind trends and reports. Queries that pull a time range, filter it, and aggregate it for an energy or runtime report.

The same language addresses both, but the practical patterns are quite different, and performance behaviour is different too.

BQL Syntax Basics

A BQL query is resolved through an ORD and typically selects a set of components or records, filters them with a where-style clause, and optionally selects specific properties. Queries can be scoped to a subtree rather than the whole station, which is usually the difference between a query that returns promptly and one that does not.

The most useful habit when learning it is to build queries incrementally in Workbench against a real station and watch both the result and the time taken, rather than composing a long query and running it against production first.

What Are the Common BQL Mistakes?

  • Querying from the station root when the answer lives in one subtree. Scope narrowly.
  • Running expensive queries on a live view that refreshes. A query that is acceptable once is not acceptable every few seconds on every open dashboard.
  • Pulling raw history and aggregating in the browser instead of aggregating in the query, moving far more data than necessary.
  • Assuming a query is portable. Behaviour and available syntax differ between Niagara versions; test against the version you will deploy on.
  • Relying on naming conventions that are not enforced. Queries built on point names break the first time someone names one differently. Tag-based queries are far more durable — which is a large part of the argument for Haystack tagging.

BQL for Reporting

Most commercial BQL work is reporting: energy consumption by area, equipment runtime for maintenance planning, alarm frequency by asset, comfort or setpoint compliance over a period, and scheduled exports that land in someone’s inbox or a business system rather than requiring anyone to open Workbench.

The engineering that makes those reports trustworthy is usually not the query itself. It is making sure the underlying histories exist, are collecting at a sensible interval, survived the last migration, and are tagged consistently enough that the query means the same thing in every building.

Related services: Niagara graphics, dashboards and reporting · engineering tools.