OBIX (Open Building Information Exchange)
oBIX is Niagara’s standards-based door to the outside world. When an enterprise system, analytics platform, or third-party application needs building data over a normal web protocol – not a controls protocol – oBIX is often the cleanest answer. Software Pile builds oBIX integrations in both directions.
oBIX Work We Deliver
- Exposing Niagara points, histories, and alarms over oBIX for enterprise and analytics consumers
- Consuming oBIX from other systems into Niagara as typed points
- Authentication, TLS, and access scoping so an open data door is not an open security hole
- Payload and watch design that keeps the interface responsive at real point counts
oBIX, REST, or MQTT?
oBIX is not the only way out of a station. Depending on the consumer, a plain REST interface or MQTT may fit better. Part of scoping is choosing the integration that the receiving system actually wants – we will recommend based on the far end, not habit.
Tell us what system needs the data and which direction it flows. We will pick the right interface and scope it.
What Is oBIX?
oBIX — Open Building Information Exchange — is a standard for exposing building system data over web protocols. It presents control-system data as XML over HTTP, so software that knows nothing about BACnet, LonWorks or Niagara can read points, histories and alarms using ordinary web requests.
Its purpose is the boundary between operational technology and IT. Inside the building, control protocols do their job. When an IT system, an analytics platform or a corporate application needs building data, oBIX is one of the standard ways to hand it over without granting access to the control network itself.
When Should You Use oBIX?
It is a good fit when an external system needs building data in a standard, documented form and you would rather not build a bespoke integration per consumer. Typical cases: an energy management platform, a corporate reporting system, a tenant billing application, or a third-party analytics service.
It is a poor fit for high-frequency real-time data, for anything where the consumer already speaks BACnet natively, or where the requirement is really a full application rather than a data feed. A modern REST API or MQTT is often a better answer for new work — oBIX earns its place mainly where a platform specifically requires it.
How Does oBIX Work in Niagara?
Niagara can act as an oBIX server, exposing selected parts of the station, and it can consume oBIX from other systems. The engineering questions are about scope and control rather than plumbing:
- What is exposed. Publish the points a consumer actually needs, not the whole station. Every exposed point is surface area.
- Authentication and authorization. Who may read what, enforced by the station.
- Read versus write. Whether the external system may only observe or may also command — a decision with real consequences that should be made deliberately.
- Load. An external system polling aggressively can affect station performance; agree rates rather than discovering them.
- Network position. Where the endpoint is reachable from, and through what. This is a security review, not a configuration step.
oBIX and Security
An oBIX endpoint is a documented way into building data, which makes it worth treating as an exposed interface rather than an internal convenience. Restrict what it publishes, require authentication, prefer read-only where writes are not genuinely needed, keep it off the open internet, and log what accesses it.
The common failure is an endpoint set up for one project, granted broad access to make integration easy, and left in place long after the project ended with nobody owning it. Access review should include it.
Related services: BAS and protocol integration services · custom integration development.