Most companies fall into one or more of the following groups:

• Smart BMS / Lighting – controls companies with a parallel software solution for aggregating data and providing analytics. Most of these companies now provide a cloud-hosted environment for aggregating data from multiple sites and providing widespread user access.
• Energy Management – with or without metering hardware. There are dozens of companies, especially those founded around 2010 during the CleanTech revolution, that ingest energy data from utilities, meters and sub-meters for detailed energy reporting and analysis.
• FDD and Analytics – companies specializing in connecting to BMS equipment and applying analytics to identify faults and opportunities for optimization. These specialized analytics are commonly referred to as Fault Detection and Diagnostics (FDD).
• IoT Sensors – a wide range of companies that provide IoT sensors and corresponding software to measure, monitor and report on indoor air quality (IAQ), temperature, moisture, occupancy, density, people counting and more.
• Data Ingestion and Aggregation – companies that specialize in acquiring building data, normalizing and contextualizing it, and making that data available for customers or other technology providers to build applications and business intelligence.
• Digital Twins – platforms focused on creating digital representations of buildings and their assets, often combining BIM, spatial models, asset information, documentation and, increasingly, live operational data.

We know many of the companies operating in these areas and they do great work. Some describe themselves as smart building platforms, and in some cases that description is entirely reasonable. The distinction we would make is between a specialist smart building application and a platform capable of supporting the broader digital operations of a building or portfolio.

There is some great work being done by research and market commentators to map the PropTech ecosystem. We particularly like the work done by Memoori.

A smart building platform isn't defined by one application or technology. It is the technology layer that connects, contextualizes, analyzes and enables action across the building's many systems.

The broad use of the term “smart building platform” can create a significant barrier for building owners seeking to digitize their portfolios. The market is fragmented, technologies frequently overlap and some solutions are either locked down or too limited to support digital transformation at scale.

Why the industry is difficult to navigate?

The smart building technology environment is highly fragmented and, by its nature, highly technical. The required skills are not taught to any one profession but are generally accumulated over a career in the industry, with the right exposure and a fair amount of individual curiosity.

Smart building technology sits at the intersection of mechanical, electrical, controls, networking, software and data, yet no single profession traditionally owns all of these disciplines.

We still see building specifications separated across these disciplines, with relatively little consideration given to the increasing integration between them.

For building owners, this makes technology selection unusually difficult. Evaluating a smart building platform requires knowledge spanning mechanical, electrical, controls, networking, software and data, expertise that rarely sits within a single role or discipline.

In our article What Is a Smart Building?, we described a smart building as progressing through five stages: Connected → Contextualized → Intelligent → Automated → Increasingly Autonomous. The smart building platform is the technology layer that enables that progression.

What should a smart building platform actually do?

To qualify as a smart building platform, we believe the technology should be capable of delivering across each of these five areas.

CONNECT

A smart building platform must be able to connect to the diverse range of systems and data sources found across modern building portfolios.

• On-Premise System Integration (at the edge): Connection to modern and legacy equipment within buildings. This can be achieved using protocol translators, third-party secure gateways such as Neeve or Tridium, or proprietary IoT appliances. The important factor is whether data using a wide range of protocols (BACnet, Modbus, MQTT and others) can be securely ingested.
• APIs and B2B Connectors: Connectivity to newer-generation sensor platforms and enterprise systems such as utility billing, work order, workplace and ticketing systems.
• Flat Files: The ability to ingest flat files from other data sources remains surprisingly important. Utility interval data, for example, may be delivered once a day in a CSV file. Waste data may be collected by a service provider and periodically sent to the building operator. Not everything in a smart building arrives through an API.
• Data Resolution and Data Quality: Building data arrives at very different resolutions. Utility billing data might contain one record per month, while motor vibration monitoring could generate 1,000 records per minute. A smart building platform must be able to ingest data at different resolutions, make it meaningful for comparative purposes and identify and manage poor-quality or missing data.

CONTEXTUALIZE

Normalization → Ontology → Local Naming → Common Portfolio Model

Connecting data is only the beginning. The platform must understand what that data represents and establish enough context for it to be consistently used across applications, buildings and portfolios.

• Data Normalization: Different systems describe the same things differently. Normalization maps data from different manufacturers, systems and naming conventions into a consistent structure so it can be understood, compared and analyzed in the same way.
• Data Ontology: Ontology establishes what things are and how they relate. There have been several significant efforts to develop standards for building data, notably Project Haystack, Brick Schema and RealEstateCore. Ontology is more than naming or tagging data points; it should also describe relationships between equipment, systems and spaces. The richer the ontology, the more context is available to the applications using the data.
• Preserving Source and Local Naming: Every manufacturer, systems integrator and commissioning professional has their own naming conventions, methods and standards. Across a large portfolio, that can result in thousands — or millions — of data points with little consistency from one building to another. Local naming remains important to the people who maintain those systems, so a smart building platform should add a common contextual layer without removing useful local information.
• Common Portfolio Model: These standards and disciplines need to be applied consistently across the portfolio. An AHU-1 in Sydney and an AHU-West in Denver can both be understood as an air handling unit, even though their local naming conventions and underlying BMS technologies are completely different.

ANALYZE

The ingestion, normalization and organization of data is critical, but the usefulness of that data depends on building-centric applications that enable end users to derive value from it.

• Trend Analysis: Users should be able to select data points from the model and view them over time, by day, week, month or year, and compare performance across periods. For example, this month versus the same month last year.
• Building Analytics and FDD: Building equipment analytics can identify faults, anomalies, performance drift and optimization opportunities. Fault Detection and Diagnostics is particularly valuable for small operational teams managing large portfolios, or for large and complex buildings containing hundreds of equipment assets. Rather than waiting for equipment to fail, FDD helps teams identify where performance is deviating from expected operation and where attention is required.
• Visualization and Reporting: The platform should turn underlying data into useful information for different stakeholders across the organization and its service providers. The information required by an energy manager, sustainability team, asset manager or building operator will be different from that required by a CFO. Visualization can range from highly technical operational dashboards through to executive reporting and visitor engagement displays.
• Portfolio Intelligence: Common metrics and contextualized data allow buildings to be benchmarked regardless of their underlying systems. Measures such as energy use per square foot, performance by climate zone, fault frequency or operational performance can help owners identify which buildings, and which service teams, are performing well and where intervention is required.

ACT

Once the data is hosted, contextualized and analyzed, the real value comes from acting on that information. Turning opportunities into savings.

Notify → Workflow → Human-Approved Control → Automated Control → Measure the Outcome

• Notifications: Users are busy people and don't necessarily have time to dig through dashboards and reports looking for something that requires action. Notifications via email, SMS or integrations with workplace tools such as Microsoft Teams or Slack can summarize and deliver information to the right people through their preferred medium.
• Automated Workflow: As organizations gain confidence in the technologies they have implemented, more of the operational workflow can be automated. An alert becomes an opportunity; the opportunity generates a work order; the work order system records the action taken; the technology confirms whether the issue has been resolved; and the resulting savings in cost, energy or effort can be tracked and reported. Closing this loop between insight, action and measured outcome is one of the defining capabilities of a mature smart building platform.
• Proactive Automation: As trust grows between the insights surfaced by the platform and the recommended outcomes, technology can begin to automate tasks that would otherwise require human intervention and significant time. Examples include:
  • adjusting building schedules for a public holiday or planned maintenance event;
  • adjusting heating and cooling in response to forecast weather;
  • using room bookings and occupancy to condition spaces when they are actually required rather than heating or cooling them continuously; and
  • scheduling system testing, executing the test and automatically reporting the results.

Automation does not have to mean removing people from the process. Depending on the action and operational risk, it can range from recommending an intervention for human approval through to fully automated control.

SCALE

Scale means being able to apply common integrations, data models, analytics, applications and operational standards across hundreds or thousands of buildings without engineering every building from scratch.

• Portfolio Architecture: Selection, selection, selection. Every technology within the stack needs to be chosen with scale in mind: sensors, edge devices, networking equipment, IoT appliances, cloud infrastructure, analytics and applications. The technologies should be complementary without becoming unnecessarily co-dependent. An owner should be able to remove or replace one component without having to replace everything around it.
• Repeatable Deployment: Technologies should not require highly specialized or proprietary installers at every site. Standards, specifications and installation documentation should make it possible for a building in California to be deployed consistently with one in Florida — or Sydney, Singapore or London.
• Templating: Buildings, floors, equipment, analytics and applications should use repeatable templates so that operational and service teams recognize the environment regardless of who originally configured it. Common equipment types can share analytics, schedules and control strategies while still allowing for legitimate local differences. At portfolio scale, this consistency cannot be achieved by engineering every site individually.
• Different Building Types and Levels of Maturity: The technology stack should accommodate brand-new buildings as well as buildings that are decades old. A portfolio should not need to wait until every building has the same systems or level of technology before beginning its digital transformation.
• Localization: Global portfolios need to account for time zones, languages, currencies and units of measure used by both the organization and its service providers. The selected technologies should be capable of supporting those local requirements while maintaining common portfolio standards.
• Security and Access Control: A platform deployed across an enterprise and its service providers requires role-based access controls so that each user can access the appropriate buildings, data and functionality. Single sign-on, multifactor authentication, auditability and appropriate privacy and security controls should form part of the enterprise architecture.

What shouldn't a smart building platform require?

A smart building platform should not require:

• a proprietary hardware ecosystem;
• one particular BMS;
• a new building;
• replacement of systems that are already working;
• one particular cloud architecture; or
• every building in the portfolio to have identical technology.

The purpose of a platform is to create interoperability across a heterogeneous environment, not to make the entire environment proprietary.

How does a smart building platform differ from a BMS?

A Building Management System (BMS) monitors and controls building plant and equipment, typically HVAC and often lighting and metering. A smart building platform sits across a broader technology environment, integrating data from the BMS alongside IoT, occupancy, access control, energy, workplace and enterprise systems.

The two technologies are therefore complementary. In a large commercial building, the BMS will often remain the primary control system while the smart building platform provides the broader data, analytics, applications and operational layer across the building or portfolio.

We've explored this distinction in more detail in Smart Building vs BMS.

Where does AI fit?

AI isn't what makes something a smart building platform. AI is another capability that becomes possible when the platform has connected, contextualized and trustworthy building data.

As smart building platforms become more sophisticated, AI can help operators investigate issues, prioritize opportunities, recommend actions and ultimately support increasingly autonomous operations. But without a trusted data foundation and sufficient building context, adding AI doesn't suddenly make a building, your team or a platform - smart.

10 questions to ask when evaluating a smart building platform

If you are evaluating technologies in this market, these questions can help distinguish a specialist application from a platform capable of supporting broader digital building operations:

1. Can the platform connect to equipment from multiple manufacturers without requiring replacement?
2. Can it integrate both legacy building systems and modern IoT and cloud systems?
3. How does it normalize and contextualize data from different buildings and manufacturers?
4. Which ontology or semantic standards does it support?
5. Can customers access and export their normalized data through open APIs?
6. Does the platform provide applications and analytics, or does it only aggregate data?
7. Can insights trigger notifications, workflows, work orders and control actions?
8. Can common data models, analytics and applications be deployed consistently across an entire portfolio?
9. What proprietary hardware, software or cloud dependencies are required?
10. What happens to the customer's data, integrations and applications if they change technology providers?