Quantum Documentation

The Quantum Object Model

Quantum as an information model is based on objects and relations (an object graph), where objects have attributes. An object type in Quantum represents some modular concept in the ontology: a building, a floor of a building, a component of some equipment, or a medium representing a type of liquid. A relation type describes some kind of relationship between two objects. An object may be related to other objects in very specific ways, depending on the object types being related. Relating this back to object oriented programming, an object type is analogous to a class, and an object1 analogous to an instance of a class. Objects and relations are analogous to nodes and directed edges in a graph theory framework. Quantum is more akin to a labeled property graph than a semantic graph2.


We organize the different types of objects into domains. The domains are intended to group object types in a meaningful way. This was motivated by our experience attempting to use different data standards, whose definitions and documentation were primarily flat and required digging to understand how things related to one another. A brief summary of the different domains is provided in the table below.

interconnecting domains that make up the quantum object model
The site domain captures high-level geographic object types and situates a building in the world.
If it weren’t for people, buildings wouldn’t exist. Users and organizations are the two primary object types in this domain. In deconstructing how users interact and engage with buildings (and the things inside them) as well as when they interact with them (at what point in the life cycle), there are many different needs and personas. Users are related to organizations, sites, and other object types in Quantum via different roles.
Asset management is an important aspect of owning and operating Buildings. Assets are related to users, organizations, and buildings in different ways. An asset might be the throughput of a warehouse, but it may be owned by some external organization. Oftentimes, assets have particular needs or environmental constraints (must be kept frozen, etc.).
Buildings exist and operate in many different environments. From a system modeling perspective, it’s crucial to know where a building is located, as this is used to understand the environmental conditions in which it operates.
Understanding the physical construction and topology of a building is a key aspect of implementing autonomous control. The building domain includes floors, zones, surfaces, layers, all of which are characterized with different properties.
A building must be able to reconstruct the 3D landscape that it operates in. Equipment and assets need to be located at some point in space (a sensor on a wall, an air terminal in the ceiling). Shapes and vertices are the key object types in this domain, enabling 3D reconstruction of physical spaces and things.
Systems are key for autonomous control, as they capture an interconnected group of equipment. From this interconnectedness and the designated roles of the equipment in the system, an autonomous agent can deduce subsystems, loops, and operational constraints for the system and its contained equipment.
Equipment, components, and connection nodes are the backbone of this domain. A component is the fundamental building block in Quantum, and is an object that can explain its identity. The identity is determined by the components’ specified actor and quanta type on which it acts. System topology is determined by the interconnectedness of components, both within and across equipment boundaries.
Understanding energy flows between buildings and systems is very dependent on the media, state of that media, and flow of that media. This domain includes quanta, which are defined as packets of substance exchanged between and operated on by components. They are often thought of as the things that capture state information.
Components define their operational characteristics through a series of properties and behaviors. Behaviors are transform operators that act on the properties of a quanta, capturing what a component does. A property is a generic numeric quantity that can be associated with many different types of objects. Similar to a variable in a programming language, a property can be computed (via a series of operators, literals, or other properties) or can have a literal value. When properties are computed, this information is captured in an equation.
Autonomous systems require the ability to understand and learn from the past and understand what the future may hold. Historical or predicted values of properties and events are captured in this domain.
Autonomous systems in industrial environments require decentralized orchestration and computing. Additionally, alerting based on observed data patterns and notifications of relevant parties for time-sensitive error resolution is captured in this domain.
A category of object types that can be generically associated with other objects for the purposes of conveying metadata. These objects can be thought of similarly to MIME types.


Properties are used frequently in Quantum as a generic mechanism to associate quantitative attributes to objects. Properties can have units (or be dimensionless), and can have a literal value or be computed by a series of operators, literals, or other properties. For example, we may wish to express the area, height, and volume (three different properties) of a zone. In a simplistic calculation, we might say that the zone volume property is computed via the expression: volume=area*height, where both area and height are properties with literal numeric values. Quantum’s property and equation object types enable users to express simple and complex mathematical relationships. In addition to a current value, properties can have both historical data (a history) or predicted data (a prediction).

A deeper dive on properties, behaviors, equations and time-series data is forthcoming, however, the primary concept to understand right now is that a property can be associated with many different object types in Quantum.

Site, Environment, and Building

The site, environment, and building domains are highly related to one another. A site has one or more buildings and is associated with a location object type in the environment domain. A building has one or more floors (or stories), each floor has one or more zones (or spaces), a zone has some number of surfaces, surfaces are composed of constructions and layers, which then have an associated media. The design goal for the different object types in the building domain is to capture information pertaining to three primary aspects of a building: the architectural representation (form), the functional representation (purpose), and the thermal representation (energy balance). Other information models may consider one or two of these aspects, leading to the creation and maintenance of multiple building representations throughout the building design process. Our goal in Quantum is to strike the correct balance.

digital twin of building, displaying occupant inside and highlighting various sections and equipment contained within

The architectural form of the building provides detailed 3D geometry and information about materials; the functional representation enables understanding of the design intent for different areas of the building; the thermal representation derives from the architectural form and the function of building areas to enable understanding of how energy moves throughout the building. A deeper dive on understanding the thermal and functional representation of a building (constructions, layers, and media) is forthcoming; the following section on geometry provides an introduction to how 3D geometry is represented in Quantum.

Domain hexagons with interior hexagons in various colors all representing parts of the ontology -- showcasing how things interconnect

The site has a location, which captures the address, elevation, and other geographic information. Since the environment that a building operates in is critical for optimizing equipment operations and achieving its goals, a location should always be associated with at least one weathersource, although multiple weathersources can be used. For example, at the beginning of a project we may know the location of a building, and associate a static TMY33 file as a weathersource for that building. Further in the process, someone may wish to add a near real-time weather api as a weathersource for a building—both of these are possible with Quantum.


The basic element of our building geometry representation is the zone (architectural space), which represents a portion of the building dedicated to a purpose. A key design goal for representing spaces in Quantum was to focus on defining spaces that exist entirely in their own right, without knowing it’s location or context in the building. Rather than spaces being derived from walls, surfaces, or vertices, the shape of the space is defined first, and in coordination with other spaces in the building, the walls, surfaces, and adjacencies are actually derived from the intersection of spaces. Spaces are usually defined by the areas encapsulated by the constructed (physical) walls of the building, such as a typical office. However, building spaces don’t always break up according to physical boundaries and often require logical boundaries. We conceptualize logical boundaries as an “air boundary.”

building floor plan with different zones highlighted in different colors


internal connections within geometry domain

Vertices and Shapes

The basic geometric concept is a shape. A shape is an ordered list of vertices that are connected together. The ordering is very important, as it defines the path of traversal for the shape, enabling both convex and concave shapes. The vertices usually lie in a flat 2D plane. They can either be a loop (closed) or have start and end points (open). The shape concept is also called a path, poly line, or contour in other software (analogous concepts can be found in IFC, EnergyPlus, AutoCAD, SVG, and others). Note that shapes are similar to polygons, but are not necessarily composed entirely of straight line connections. There may be a curve connecting two vertices instead of a straight line.

image goes here

The key advantage of this structure is that it conveys adjacency information and in the closed case has an inside/outside. We know which segments are connected together. We can query whether points are in the shape. Shapes are used in a variety of ways throughout Quantum; a few examples include: 1) defining floor plans, 2) defining custom shaped apertures, 3) defining sub-surface geometry.

Floor Plan Shapes

The primary use of shapes for us is to describe the floor plan of a space. In this case each vertex represents the beginning of a wall around the loop. The length of the wall is determined by the distance to the next vertex. The loop encloses the boundary of the space, and is often referred to as the boundary shape. The boundary shape determines the floor plan of any particular zone. The floor plan is then extruded by a height to get the shape of the room. The exact shape of each wall, as well as the floor and ceiling is implicit in this model. You must refer to the context of the wall in the shape to understand its length and height.

image goes here

A surface is a logical piece of construction in a space such as a wall, door, or window. Whereas shapes are very concrete in the sense that they exist as they are being defined, surfaces are more conceptual because they are really a consequence of the geometry definition, meaning, they only exist after the geometry is defined. Even within the realm of surfaces, there are certain surface types that are more conceptual than others. For example, the only purpose of a boundary surface is to capture the shape of the space, whereas other surface types are intended to convey thermal characteristics of the surface (layers, and others). The surface type is the mechanism used to convey the purpose of a surface. There currently exist 11 different surface types:

Primary Surface Types
Wall, Floor, Ceiling, Roof, BasementWall, Slab
Fenestration Surface Types
Door, Glazing, GlassDoor
Conceptual Surface Types
Boundary, SubSurface

Surfaces are related to one another via two primary mechanisms:

3d building with arrows pointing to boundries, glazing, walls

Surfaces can be adjacent to other surfaces, but adjacencies are a more generic tool for relating things to surfaces. For example, they enable us to relate an equipment or component to a surface. More details on how the exact location of an arbitrary thing is specified in relation to a surface will come later.

3d building with arrows pointing to walls and ceiling
Multiple Spaces and the Role of SubSurfaces

So far, we have mostly focused on how surfaces and shapes relate to a building composed of a single space, but this is not a very realistic picture of a building. When we begin looking at buildings having multiple zones, intersections between surfaces become very important.

A few crucial points to reiterate before diving into this topic:

This is what enables us to move spaces around in 3D very freely. The wall surfaces of a space are really just a consequence of the boundary shape definition—they do not depend on how two spaces are situated in relation to one another. That said, certain information only becomes known when spaces are placed in 3D space relative to one another. This is the case for surface intersections, as demonstrated below.

diagram displaying two rooms with connecting walls

This is the primary role that subsurface surface types play—they are surfaces that are derived based on intersections of other surfaces. This occurs with:

Some important characteristics of subsurfaces.

3d model exploring subsurface materials
  1. Sometimes also referred to as entities.
  2. https://www.linkedin.com/pulse/state-graph-merger-property-graphs-semantic-kurt-cagle/
  3. https://www.nrel.gov/docs/fy08osti/43156.pdf