Name: XBOSDocs
Owner: Software Defined Buildings
Description: Documentation
Created: 2017-02-16 18:26:03.0
Updated: 2017-11-09 12:59:39.0
Pushed: 2018-02-16 08:00:10.0
Homepage: null
Size: 385
Language: Shell
GitHub Committers
| User | Most Recent Commit | # Commits |
|---|
Other Committers
| User | Most Recent Commit | # Commits |
|---|
XBOS (eXtensible Building Operating System) is an open-source large-scale distributed operating system for smart buildings. XBOS provides secure:
XBOS aims to push the state-of-the-art in the operation, management, analysis and control of a software-defined building. XBOS integrates traditional vertical silos of building mangement – lighting, HVAC, electrical – by combining abstractions of underlying hardware, sensors and actuators with rich metadata description of those components and the relationships between them.
XBOS is assembled from a family of open-source technologies, which can be found via the XBOS Github. The overall architecture of XBOS and a brief description of these technologies are presented below.
XBOS is composed of a set of logically and physically distributed services, which are connected by a secure message bus. These services are broadly categorized into three layers:
Syndication: All of the above services communicate with each other using a secure publish/subscribe message bus named BOSSWAVE. BOSSWAVE also provides and enforces authentication and authorization, for example, when reading/writing from/to a device interfaces or controlling access to building data.
There is some flexibility in how these services can be placed on available computing resources, but the most common division is that of cloud and edge/local.
Security and authentication is not an afterthought but rather a core design requirement in XBOS. Therefore, you should always start by getting familiar with the XBOS syndication mechanisms and the BOSSWAVE terminology. Once you are familiar with BOSSWAVE, there are many places where you can get started with XBOS depending on your goal/role. Below are some examples.
This section presents more information and references to all of the XBOS technologies presented in the Architecture section. Please refer to the Getting Started section for which components might make sense to you as a starting point once you are familiar with BOSSWAVE.
BOSSWAVE is a secure, distributed publish/subscribe message bus. Instead of messages being sent directly from data producers to data consumers, messages are sent to an intermediary called a designated router (sometimes called a broker). Publishers attach an identifying topic (called a URI) to each message sent to a broker. Subscribers tell the broker the topics they are interested in, and the broker forwards the relevant messages to the subscribers. We have chosen this architecture because the scaling load is placed on capable servers acting as brokers, rather than on the data producers, which are typically constrained and behind NATs (i.e., not publicly addressable).
All resources (e.g., drivers, services, etc.) are represented in BOSSWAVE as a collection of one or more URIs. A resource reports its status by publishing to its own URIs and receives commands by subscribing on its URIs. Resources implement control of other resources by publishing on the URIs of those resources.
BOSSWAVE enforces guarantees not offered by existing pub/sub systems, namely the ability to enforce fine-grained permissions on resources (logically represented by one or more topics) at a global scale without relying on centralized or trusted infrastructure. Each service/resource in BOSSWAVE has an entity represented by a public/private Ed25519 key pair. This key pair is used for granting and revoking permissions on resources.
BOSSWAVE uses a fork of the Ethereum blockchain as decentralized storage for all identities and permissions.
There are several components of BOSSWAVE relevant to XBOS:
Source code:
Docs:
Publications:
Drivers implement one or more standard BOSSWAVE *interfaces for hardware devices, building management systems, web services, and other resources. These drivers can report state by publishing on BOSSWAVE URIs called signals and receive commands by subscribing on BOSSWAVE URIs called slots. The format of the messages published on these URIs is also part of the interface definition. A driver can represent one or more devices (such as through a gateway) and expose one or more interfaces for each device. All interface implementations should behave identically, regardless of the underlying device or resource.
XBOS defines a set of standard interfaces, documented here.
Source code:
Docs:
Spawnpoint is a tool to deploy, run, and monitor services. It is primarily intended for services that communicate over BOSSWAVE, but it also has features for applications that wish to make use of native means of communication. A “Spawnpoint” is an individual machine that supports service execution by providing storage, a BOSSWAVE router for communication, and a pool of memory and compute resources. Individual services run in dedicated Docker containers that are instantiated and managed by a Spawnpoint.
Source code:
Docs:
Publications:
BTrDB (Berkeley Tree Database) provides very fast storage and retrieval of scalar time-series data. It supports nanosecond timestamps, versioning of time-series streams, and boasts 16.7 million writes per second and 19.8 million reads per second on a single Intel Xeon E5-2680v2 based cloud server with 60GB of RAM (EC2 c3.8xlarge). Additionally, BTrDB accelerates the computation of associative statistics over arbitrary time ranges, using precomputed statistics over power-of-two-aligned time ranges.
Source code:
Docs:
Publications:
Pundat (Punctuated data archiver) subscribes to data published on BOSSWAVE and saves it to BTrDB. Streams can be marked for archival using “archive requests” that describe to Pundat how to archive published data. Pundat can parse time-series data from arbitrary data structures.
Source code:
Docs:
MDAL retrieves, aggregates and formats time-series data from BTrDB using queries that reference a Brick model. Brick models contain UUIDs referring to specific streams of time-series data. MDAL data queries refer to time-series streams using metadata (via a query against a Brick model) rather than explicitly referring to the identifiers of those streams.
MDAL provides data cleaning, pre-caching, and unit conversion capabilities while maintaining fast response times.
Source code:
Docs:
In existing Building Management Systems (BMS), contextual information (metadata) of sensors, systems and building structures is either absent or not consistently structured. What metadata does exist fails to capture the information needed by modern building applications such as fault detection, energy analysis, and model predictive control. Brick is an open-source, BSD-licensed development effort to create a uniform schema for representing metadata in buildings.
Brick has two main components: a class hierarchy describing the family of building subsystems and the entities and equipment therein, and a minimal, principled set of relationships for describing the associations and connections between those entities. Brick uses these vocabularies to realize a building as a directed, labeled graph. The representation of this graph leverages the standard RDF data model, which means that Brick usage and development can use existing tooling.
Source code:
Docs:
Publications:
HodDB is a specialized RDF database and SPARQL query processor for Brick. It stores models of buildings and serves queries on those models. HodDB supports a limited subset of SPARQL, but can evaluate most queries in less than 100ms. It also provides HTTP and BOSSWAVE APIs, an HTTP UI for exploring Brick models and building queries.
Brick models, via HodDB, are the “single point of truth” for the configuration and operation for all data-oriented services in XBOS.
Source code:
Docs:
Publications:
XBOS makes it easy to develop data-oriented applications that leverage the hardware abstraction layer and core services. Some examples of applications written for XBOS are: