The OAP is central to tagging and data modeling for Noda products. The public website is introduced in this article, and its uses and applications are described in this article. Here we will introduce the overarching OAP Philosophy, its guiding principles and a YAML editors guide.
OAP Philosophy: Guidelines for Creating Entities in OAP
OAP is made possible by a group of ontology-minded, data-obsessed people within Noda and is available for participation from the industry at large. Each system, equipment, point, relationship and aligned ontology is defined following these guiding principles.
Entities
Each entity needs to be defined by a unique tag set
Use as few tags as possible to define entity
Create as few entities/types/subtypes as possible for use case (i.e don't create unnecessary variants). Use type_optional where possible.
Points
Sensor is used for feedback/status type points like:
"Mode"
"State"
"Cmd"
"Sp"
My point is missing? What do I do?
Is it missing or is it named something else?
If you are certain the point you need is not defined in the OAP, submit a request to the team to review the new point via this form.
Naming conventions
Point Name Codes, for example DATSP, are limited to 13 characters.
There are a list of standard abbreviations to use here: https://appriver3651002181.sharepoint.com/:x:/s/BuildingsIOTRD/EcNQJXCtMMZFgYIBNvtR8wkBuiHLoFXLYCF5JLVfJbZ5Iw?e=0oHk35
YAML Guide
On the back-end, the OAP website is published from YAML files. The team working on the OAP updates these YAML files and submits merge requests through GitLab to push changes. For those working within YAML files, this is your quick-start guide.
Points
Each point in OAP is defined with a common name, a description and an OAP point code ex. "DATSP" - discharge air temperature setpoint
Each point should have a list of unique tags to differentiate it from other points in the OAP.
There is no limit to how many levels of inheritance is allowable for points
Ex. CMD -> SSCMD-> PSSCMD
Points defined in OAP are very similar to the concept of Protos in Haystack
Points must have a kind.
Numerical points should have a unit(?)
Functions
Functions house a collection of points (incl. Commands and sensors) that are used in a common control function.
Ex. DFVSC – Variable Speed Control for discharge fans contains all the points related to controlling the discharge fan. Such as DFSPCMD, DFCMD, DFST
Tags that are defined on functions are inherited by the equipment that uses the function as type_optional tags.
Equips
Equips are defined with a set of tags that include the equip tag as well as any other relevant marker tags.
Noda Web supports one level of inheritance for equip
ex. Type: AHU -> subtype: DOAS
Tags on Equips are from the following:
Base "parent" equip
Tag on equip itself (I.e. listed under Haystack -> type)
Extends
Equipment and points (but not functions) can extend other equipment or points. This allows the subequipment or subpoint to inherit tags from its parent type.
Contains
Contains is a useful way to indicate what equipment or sub equipment is typically found inside another equipment.
Type_Optional
Type Optional tags are a way to tag equipment with additional information without having to define a new variant. Type_optional tags provide information that is not used to determine a variant but may be useful for analysis.