Technology Stack

• Linux - While most of of its dependencies are platform independent, the GreenBus distribution targets the Linux platform. Red Hat and Debian are supported, with GreenBus components running on machines as small as Raspberry Pis.
• Java Virtual Machine - While the messaging underlying the GreenBus services is platform-independent, the core services and components run on the JVM. Both Java and Scala client interfaces are supported directly.
• AMQP - The transport protocol for the GreenBus services is AMQP, which enables both the abstraction of service endpoints and event-driven asynchronous notifications of updates to data and configuration.
• Google Protocol Buffers - The primary wire protocol and data definition language for the GreenBus services is Google Protocol Buffers, which is designed for compactness on the wire with an emphasis on extensibility.

The GreenBus service bindings run purely in the Java Virtual Machine, making Windows or any other non-Linux platform running Java a full participant in a GreenBus deployment.

Devices / Data Sources

GreenBus front ends are a system component which establish connections to devices or external services using their communications protocols (i.e. DNP3, Modbus, or web services), convert the data to a protocol-independent format, and associate it with inputs in the GreenBus configuration model. Conversely, command requests from GreenBus clients flow in the opposite direction after having been translated to the external communications protocol.

In addition to normalizing data and control formats, converting the protocol transport to AMQP may aid with crossing network boundaries between sources and the system securely.

Clients

Applications and user interfaces use the GreenBus service APIs to inspect the model, monitor system state and issue controls. Services generally follow RESTful conventions for querying, creating, updating, and deleting objects.

Service request and response data are defined in a protocol neutral format and idiomatic code bindings are generated for particular platforms (such as Java).

In addition to reading the current state of the system, service requests may also negotiate a subscription to asynchronous delivery of updates in the future.

Configuration updates to the GreenBus system model are made through service calls, and updates to the model are subscribable.

Model

The GreenBus system model applies context and structure to the data input and control outputs in a GreenBus system. The model has two main divisions: the communications model, organizing communications sources, and the equipment model, which builds a hierarchical logical organization on top of the inputs and outputs regardless of their source.

Objects in the GreenBus model may have types which attach queryable metadata. Types can be used to provide semantic meaning to inputs and outputs, promoting a common understanding of the model regardless of equipment hierarchy and naming conventions.

Every object may also store configuration data in its own set of key-value pairs. Values may be simple data types or arbitrary opaque data. Examples of data stored in key values could be protocol configuration, schematics, or nameplate parameters for devices.

Databases

The GreenBus services provide a common, database-neutral interface to the underlying persistence stores. The two major logical data stores are the model and the measurement databases, with service implementations mapping requests to queries to the actual databases. (In simple deployments, PostgreSQL by default.)

The measurement services are further broken into two logical stores: the current value key store and the measurement history store that provides real-time queries for historical values. The GreenBus measurement services can adapted to utilize stores that optimize for the requirements for throughput, latency, and space.

Security

Security in the transport layer is provided by AMQP through the combination of TLS for encryption and SASL for authorization to be a participant on the bus.

GreenBus then layers a user authorization system which provides access control at the level of individual services. User agents have permission sets granted to them, which are system-configurable collections of access entries (allow or deny) for create/read/update/delete actions on service resources.