Synthetics
Overview
Synthetics are modeled with the synthetic
tag. Synthetic refers to any data that does not come from a physical sensor or device. Instead, any synthetic data, and associated subtypes, are generated by some methodology; e.g., energy simulation, machine learning, etc.
The tag synthetic
extends from pointFunction
. This means that any synthetic
, or child of that type, is not also a sensor
, sp
, or cmd
. Conceptually, the data modeled by synthetics is introduced via some external source other than the local entities within a physical space, e.g., an energy model or machine learning algorithm.
Tags
Synthetic is an abstract pointFunction
for any synthetic data. In practice, any synthetic-point
should be specifically defined based on the methodology used to generate its data. Current subtypes include:
A point
leveraging this ontology would be tagged as a sim-point
, ml-point
, or computed-point
.
Each synthetic type can further prescribe necessary tags based on use case and that methodology's requirements to model other parameters.
Structure
Any synthetic-point
should define a pointRef
tag identifying the sensor
it models. The default structure is assumed to be an equip
containing both sensor
and synthetic
points. This structure is not explicitly prescribed, should the need or use case arise to separate related sensor
s and synthetic
s into different equip
s.
An example structure is provided below:
//example, ahu with a discharge air temp sensor & synthetic point in the same equip id: @site site dis: "Acme Co" -- id: @space space dis:"Space" siteRef: @site -- id: @ahu01 equip ahu dis:"AHU 01" spaceRef: @space siteRef: @site -- id: @dat point discharge air temp sensor -- id: @synthDat point discharge air temp //sim, ml, and computed all valid here sim pointRef: @dat equipRef: @ahu01 siteRef: @site
Synthetic Models
The concept of a syntheticModel
is also introduced with this ontology. The syntheticModel
is a first-class entity to identify the collection of algorithm, application, parameters, and other settings used to generate a set of data for one or more synthetic-point
s.
The term syntheticModel
is used instead of the more generic term model to avoid confusion or overlap with other concepts. Synthetic model is then extended to different types of fooModel for each kind of synthetic subtytpe. For all models, syntheticModelRef
is used as to point a synthetic-point
(of any subtype) back to its respective model.
A synthetic-point
should only ever have one syntheticModelRef
target.
Synthetic Models are a container for relevant information that generated any synthetic-point
related to it. This relevant information will differ greatly depending on the sub-type of model, the application, and even practitioner's preferences or tookits. As such, there are no generic tags that apply across each model type.
Current syntheticModel
subtypes incldue:
Simulation Overview
Simulation points are generated from a physics based model, typically some form of black or gray box energy model.
Sample sim
implementation including a simModel
:
id: @simModel dis: "Operational Sim Model" simOperation //see below for simScenario detail simModel --- id: @vav navName: VAV vav equip --- id:@point navName: DAT-Sensor equipRef: @vav point his discharge air temp sensor --- id:@simPoint navName: Sim-Point equipRef: @vav pointRef: @point syntheticModelRef: @simModel point his discharge air temp sim
In this example, both the sim-point
and the point
are nested under the same equip
. This is not necessary, but is suggested as a convention. This documentation may be updated in the future to reflect the community's adoption/implementation of this schema.
simScenario
simScenario
is used as a choice to identify different simulation options, tagged on the simModel
.
For example, a physics-based whole-building sustainability modeling can create numerous decarbonization scenarios of energy conservation measures and bundles of measures for consideration.
Right now, simScenario
is the only introduced tag for simModel
s. This is provided as a useful example for how practitioners can add other defs as the need arises.
This proposal introduces three (3) base simScenario
s, but practitioners may add further ad hoc cases by using 'is: simScenario' for their own custom definitions. Current simScenario
s include:
Computed
Computed is a stub out for simple computational data (be it curVal
or his
data).
Machine Learning Overview
A machine learning model (ML) is a synthetic construct whose parameters are derived from historical data. Machine learning, a branch of artificial intelligence, offers a wide range of algorithms to choose from. This ontology specifically addresses supervised learning and models with multiple inputs and a single output (MISO models).
Key details, such as the specific type of machine learning algorithm or its hyperparameters, are deliberately left out to allow for user-specific customization. This ontology captures only the essential and most general characteristics.
mlModel
The mlModel
entity represents a machine learning model and encapsulates all relevant information, including:
mlIdentificationPeriod
: Time span defining the training period.mlModelParameters
: Result of model identification.mlModelMetrics
: Goodness-of-fit metrics provided in the form of a simple dictionary.
Additionally, mlModel
includes references to both input and output variables through mlInputVarRefs
and mlOutputVarRef
, respectively. These utilize mlVar
tag.
The mlVar
entity serves as a reference for the model's input variables (also known as independent variables) and the model's output variable (also known as the dependent variable or target). Each mlVar
is linked to a specific point via mlVarPoint
tag. Alternatively mlVarFilter
can be used for referencing a point.