Overview

The GreenBus system model is built around two core types of I/O objects:

• Points represent discrete data inputs that correlate a series of values, or in GreenBus, Measurements. A Point might represent a particular voltage phase on a meter, or a current temperature reading on a thermostat.
• Commands represent outputs. In GreenBus, Commands are further subdivided into controls and setpoints, with the latter containing values. A control Command might be used to trip a breaker, and a setpoint Command might be used to set the output of a battery.

The set of Points and Commands represent the flow of data and control from device communications or some other data source. Additional structure is built on top of these basic elements, divided into the communications model and the equipment model.

`The communications model, made up of Endpoint objects, organizes Points and Commands according to their data sources. Endpoints represent a coordination point for the external processes (or "front ends") that provide data access, defining the type of process (or protocol), providing storage for any configuration necessary to establish communications, and allowing operators to disable the data source.

The equipment model, made up of model Entity objects, organizes Points and Commands into a logical hierarchy of groupings which provide structure and context for consumers of the data. Entities are primarily defined by their position in this tree structure, but may also contain metadata and configuration for applications and displays.

Identification

Model objects (Points, Commands, Entities, and Endpoints) are all identified by two fields:

• UUID - An 128-bit value that is globally unique for all systems (unless duplicated as part of an import process). Once the object is created, the UUID may not be changed.
• Name - A string value that is unique for the system model. It may be modified, and the UUID can be used to correlate the previous object with the updated one.

Names are intended to provide human readable identifiers, while the immutability of UUIDs enables applications to reference objects correctly regardless of changes to their names.

Relationships

Associations between objects are defined by directed relationships between parents and children.

System modeling only manipulates direct relationships, but GreenBus enables querying derived relationships created when a parent object's children have their own children. Derived relationships must not lead back to a parent (a "cycle"), and there must be only one path between any two objects.

Examples of relationship types used in the core system model:

• owns - defines the structure of the equipment model.
• source - defines associations in the communications model between Endpoints and Points and Commands.
• feedback - defines associations between Points and Commands that logically act on the values it represents.

Note that while the naming convention for objects in equipment models may reflect the tree structure, there is no direct link between relationships and object names.

Types

Model objects each contain a set of types. Types are queryable metadata that enable marking objects as belonging to a logical or semantic group. Types may be any string, and an object can have as many types as needed.

Key Values

Model objects may also contain key values, which provide a means of storing and providing programmatic access to additional system configuration and/or metadata. Objects may have an arbitrary number of key values, and every combination of UUID and key is unique.

The data stored in key values may include boolean and numeric values, strings, and arbitrary arrays of bytes.