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 sensors and synthetics into different equips.
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-points.
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 simModels. This is provided as a useful example for how practitioners can add other defs as the need arises.
This proposal introduces three (3) base simScenarios, but practitioners may add further ad hoc cases by using 'is: simScenario' for their own custom definitions. Current simScenarios 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.