|
|
|
|
|
The primary objective of EEBUS is to define a universal, machine-readable and interoperable standard. For this reason, EEBUS technology is designed to harmonize with various protocols and transmission channels. Only through this consistent approach can different technologies merge to form a customer solution.
For more information on system architecture and other resources, please refer to EEbus.org
EEBus SPINE Device Model
A device model helps to find appropriate devices for communication as well as clustering information in a logical manner.
The EEBUS SPINE device model consists of three levels: device, entity and feature. Each level holds a type: deviceType, entityType and featureType.
EEBus SPINE Data Model
EEBUS SPINE itself does not define any layers below ISO-OSI layer 7. So, the EEBUS SPINE data model and protocol specifications can be used with every technology that supports bi-directional communication with any payload.
The EEBUS SPINE communication uses its own header and payload definitions within a EEBUS SPINE message (hence within layer 7).
Messages can be transferred with different classifiers (e.g. read/reply/write), enabling polling-based communication as well as trigger or event based notifications.
The data model is very modular. For different use cases, the EEBUS SPINE functions can be combined and used in different ways. This may seem more complex than just modelling each needed data as a separate element like it is common practice in most technologies. But in fact the modularity enhances reusability and recognition of well-known definitions. Especially as the list of requirements grows, and so the list of different data points, the modular concept of EEBUS SPINE shows its strength.
The EEBUS SPINE device model helps finding appropriate communication partners. It consists of three layers: physical device, logical device (entity), functionality (feature).
The modularity requires the combination of "modules" into a single message for a specific purpose. A concept for combining several information in one atomic message is realised with the EEBUS SPINE complex classes.
Each feature has a role: client or server (and, in some cases, special). The server provides information that may be read or (if allowed) written. The client requests information from a server or changes it.
Whether a message could be transmitted / evaluated or not can be communicated with acknowledge and error messages.
Binding and subscription mechanisms enable an easy way to connect matching devices. The usage of binding is feature type specific (it may be used to determine which communication partner is permitted to change something on the device or where to send commands). Subscription is used wherever a client wants to receive updates from some server functionality automatically.
To be able to communicate with another device, one needs to know what functionality is implemented there. The device discovery concept delivers the relevant information about a device (including hierarchy levels device, entity and feature).
For every communication, it is essential to have some kind of address where the message shall be sent to. EEBUS SPINE has its own addressing schema that has representatives for all three hierarchy levels.
To communicate with devices that are not connected directly, the destination list of another device may be requested. Devices included in this list may be used as partner in the further communication.
In some cases, not the complete data of a resource is of interest. A filter may then be applied together with a read command, to cut down the payload to transmit. This concept is also used when a notification only includes changed data or together with a write command.
EEBus SPINE Classes, Functions and Elements
The EEBUS SPINE data model is divided into classes. For each functional domain supported by EEBUS SPINE, a related standard class is defined. For example Measurement, Sensing, TimeInformation, etc. Class names are capitalised. Additionally, complex classes exist that allow the combination of functionality defined by standard classes.
EEBUS SPINE classes have a collection of functions that can be used for communication. Function names are lowercased.
The following is an example from the Measurement class:
There is always either one ...Data function OR one ...ListDat_a function (also called the "resource"). In case of a ..._ListData function, a ...ListDataSelectors is defined, used for filtering desired information.
As an example, in the ActuatorLevel class the actuatorLevel function and the actuatorLevelDescription function are the only defined information. In contrast, the information specified within the Measurement class covers the above mentioned functions together with the selectors (as all functions are of type ...ListData):
In the second example, the ...ListData function is denoted, not the ...Data function, because the Measurement class supports lists and does not allow to send the single ...Data function as so-called "cmd" payload (but the ...Data function is a sub-element of ...ListData).
For each class there is a dedicated section ("ActuatorLevel" to "Version") with its possible functions. Functions contain elements. Each element represents a single information. E.g. a timestamp, a value, a unit, etc. In the data model, elements are initially marked as optional. This is due to reuse-considerations, particularly for the complex class concept. Of course, some values need to be mandatory, to fulfill a meaningful and interoperable context. Such restrictions are entailed with the use of the so-called feature types.
The XSDs and some further documents describe how an XML must be structured and filled in order to be "valid" within the EEBUS SPINE specification. That does not mean that only XML can be used for communication. In SHIP, e.g., JSON is used. Other formats are possible, too.