Intro to Quantum

Why a new Standard?

The majority of smart building applications (and standards) in the marketplace today are designed around characterizing the controls and sensors of a building according to existing paradigms. These existing paradigms include: reactive (PID) and thermostatic controls, static sequences of operation, manual system commissioning, and SaaS overlay analytics applications. Physics based modeling of systems has been an entirely different discipline in its own right (Modelica, EnergyPlus, and others), and has mostly been limited to usage for early stage analysis of designed building performance. It is rare for physics-based energy models to see any usage into the operational stage of a building. Building Information Modeling (BIM) has a typical life cycle similar to energy models—if it is used during the design phase, it is also rare for it to find any usage in the operational phase of a building.

This isn’t to say that these existing standards and data models don’t have their own place, but in our investigation of standards related to modeling buildings, sensors, controls, or the physics of components and systems, there wasn’t anything out there that was:
1) looking at it from the perspective of autonomous controls and systems engineering,
2) tying the necessary aspects together holistically.

For example, in Haystack or Brick, we might say a sensor is in a zone, but that doesn’t tell an installer (or a self-commissioning system) where specifically that sensor is intended to be in 3D space. A zone being on a floor doesn’t convey where it exists in 3D space, nor the adjacencies of the surfaces in that zone to other surfaces and the likely heat transfer interactions that would occur. Semantically labeling something as a “pump” provides no notion of the role of that thing in a system, nor of the energy flows into and out of that thing. Providing a Modbus map or a BACnet points list doesn’t tie the sensor or control interfaces of a controllable system back to the physical piece of equipment being controlled.

So we decided to create a new approach with key collaborators, with the intention of capturing the concepts necessary for autonomous control; it’s called Quantum.

Quantum Basics

Quantum is a physics-based description language for autonomous systems. It organizes the fundamental pieces of information regarding equipment, buildings, people, and more—into defined relationships across different domains. Quantum is often discussed in a few different contexts; these are expanded upon below.

The Quantum Ontology

The dictionary definition of ontology is “the branch of metaphysics dealing with the nature of being.” We can think of it simply as having to do with identity and purpose; and Quantum as an ontology is primarily focused on answering the questions of “what do I do?,” and “how do I do it?” for all the things that are used in and around systems. This gets us away from focusing our time and attention on “what is this thing called?,” to focusing on “how do things work quantitatively?.”

A Systems Perspective

It is critical to maintain a systems theory perspective when learning about Quantum. When engineers design and build systems, either for an HVAC application or another industrial process, things are always placed into a system with intent.

Let’s just take the simple hydronic loop shown below. It has a boiler, a pump, a radiator, and some pipes connecting them. Start off by answering the question of “what is this system designed to do?” and “what are each of the things in the system supposed to accomplish?.” This example is straight forward—the goal of the system is to maintain some thermal condition of the radiator; the boiler is designed to provide thermal energy to the radiator; the pump is designed to overcome pressure losses in the system in order to actually transport the thermal energy; and the pipes provide pathways for the media carrying the thermal energy. If any of those things were missing from the system, it would be incomplete and non-functional per its design intent.

Actors, Quanta, and Behaviors

Understanding the intended role of something in a system is what led us to the creation of actor types. The actor type characterizes the intended role of a thing in a system. Going back to the example above, we characterize the pump as a transport actor, since its intended role is to move liquid throughout the system. This leads us directly into the concept of quanta types. We think about quanta as packets of substance that are exchanged by systems. Quanta themselves are mostly a pairing of a specific quanta type and a media. In the example above, the media being circulated might be water, and the quanta type would be a liquid; we would refer to this as a liquid quanta with a water media. As the quanta marches around the system above, its stateful properties are manipulated (or transformed) by the different components. The transform that acts on the properties of a quanta is called a behavior.

Composable Components

Up until this point, we’ve been referring to the things in systems very generically; let’s clarify that. The fundamental building block of autonomous systems in Quantum is the equipment component (component). We frame the identity of a component based on: 1) actor type, 2) quanta type, 3) behaviors, 4) properties. We parameterize the physical attributes of a component via properties, which can be either literal values or computed via an equation. For example, we might define the diameter of a pump impeller as a property (d) with a literal value (for example, 4 inches), but define the circumference of the pump impeller as a property of the pump computed via an equation (π*d). Once the identity of the component is framed, incoming and outgoing connection nodes are added to the component, which define the required quanta types. Components are then wired together to create equipment and equipment is wired together to create systems. Closed loops between the connections of components are used to infer systems, subsystems, and overall topology. The requirements placed on component connectivity enables components to be reused across different equipment and system topologies.

Contrasting Quantum with Modelica

Modelica is a language specification for component oriented modeling of complex physical systems. One of the most powerful paradigms that Modelica makes use of is the concept of linear graph modeling¹, which utilizes lumped parameter models to generalize energy conservation in physical systems across different energy domains (mechanical, electrical, fluid, heat transfer). An important thing to understand about linear graph modeling is that for each energy domain, there exist “through” and “across” variables². Across variables represent the driving force in a system (effort) while through variables represent the flow of some conserved quantity. For example, in an electrical system, the flow variable is current and the across variable is voltage. A minor distinction we make to Modelica, however, is that we use a normalized formulation of flow and effort variables, such that the product of the two always dimensionally reduces to a power unit.

Another powerful feature of Modelica is the ability to define connectors of components, where the flow variable at the connector is defined along with other variables. These features enable a causal³ formulation of component equations that can compose nicely together using connections to produce systems of differential-algebraic equations (DAEs) conforming to conservation of energy laws. Solver tools (such as Dymola) are then required to consume models, formulate them for solving, and actually solve them⁴.

We use very similar concepts in Quantum. We rely heavily on linear graph modeling, through variables, and across variables. Components in Quantum also have input/output connection nodes with defined quanta (quanta type and media pairing), although we predefine the flow variables and other variables based on the quanta type at a connection node (referred to as quanta interface properties).

In Quantum, however, we are more opinionated about which specific behaviors (Modelica equations) and properties (Modelica parameters) we require users to implement, and we also require users to dictate the intended role of the component being created. The intention here is to guide users into making components that 1) conform to first principles, 2) provide information that is relevant for operation and optimization of autonomous systems. Additional information about implementing behaviors for components is forthcoming. Moreover, Quantum includes many concepts that are specifically necessary for autonomous control of industrial systems, such as first class types for buildings, organizations, and historical and predicted values. Additionally, Quantum is concerned with quanta types outside the scope of energy conservation and typical lumped parameter models. This includes controls, sensors, networking protocols, and other concepts necessary for exposing the controllable and sensible interfaces of industrial equipment in a machine discoverable manner. Finally, whereas BIM or CAD software is highly focused on representation of things in 3D space, Modelica doesn’t have any 3D geometry modeling capabilities. Since buildings and geometry are basically 3D containers for autonomous systems, they are critical to and highly integrated into Quantum.