Application server as the BMS core

The application server handles all operations between the building resources users (occupants, algorithms) and the backend components (databases, SB middleware, etc.). It hosts the RDBMS for the building models, provides the RESTful API and the minimal building management and data aggregation functionality together with the simple frontend configuration and monitoring dashboard, Fig. 2.5. More sophisticated, management algorithms and frontend interfaces leveraging the exposed SB resources can be implemented using the API.

The web application is based on the well know, feature-rich web framework named Django. It is based on Python and follows the model-view-template architectural pattern. Its rich toolset and the Python programming language has enabled the rapid development of the designed system architecture within a research project time-budget. Moreover, Django is the framework of choice not only for prototyping but also for thousands of production environments in a critical system and web application.

Figure 2.5 – An example frontend as a minimal BMS dashboard

Besides the rapid prototyping and development, Django also has several other advantages that were leveraged for the efficient BMS implementation:

• integrated object-relational mapping (ORM);

• content caching functionality for significant performance gains; • extensible authentication system;

• built-in template language;

• middleware hooks to alter request or response objects after creation (not to be confused with the proposed SB middleware of Chapter 3).

Architecture

Fig. 2.6 illustrates the core architecture of the application server. The operation is similar to any large scale application server. On an incoming request, the URL dispatcher, depending on the URL, invokes the proper View function. Depending on the nature of the request, the View either renders a frontend template with the dynamic content or JSON-serializes data from the

TSDB or models. The former process is used, for example, when a user requests a frontend view while the latter in the case of an API request. In both cases, the Caching framework ensures that identical requests and dynamic data would be fetched from memory rather than rendered or serialized once again.

Concerning the dynamic data, the application server supports multiple sources and external services due to the nature of the BMS. The Model corresponds to the semantic abstractions and the ORM through which any data stored in the RDBMS and characterizes the building

and its ICT devices is retrieved. Examples of such data as combinations of models are:Loads

perRoom,SensorsperRoom, all the temperatureSensorsinUnit, installedGenerationin

Unit, all theRoomsin theUnit, etc. Those can be used either for creating dynamic frontend

depending of the installed service in the SB or for replying to specific API requests.

Furthermore, the TSDatamanager is responsible for storing and retrieving the real-time sampling data (sensors, actions, occupant locations, etc.) that are placed into the TSDB. It is invoked by the View after the Model invocation that returns the proper IDs from the RDBMS. Using those IDs the TSDatamanager retrieves and stores the data samples on the correct timeseries streams. This step in crucial as the TSDB does not store any relational data or unstructured data that characterize the semantic meaning of the stored streams.

Finally, when it comes to interacting with the physical environment through the ICT devices, or for any other reason requiring to communicate with the distributed middleware, the View invokes the ModeltoBackend. This process takes place again after the the Model invocation in order to retrieve from the RDBMS the internal IDs of the devices, their functionality as well as the middleware node that they belong. The ModeltoBackend connects with the middleware using the ZeroMQ protocol and a request(REQ)-reply(REP) socket pair. The algorithmic request of the View instance is converted to the proper middleware-compatible message. Last but not least, theModeltoBackend and the Model act as the middleware directory service required for the self-discovery functionality discussed in Chapter 3.

URL dispatcher View Model _RDBMS TSDB TSDataManager ModeltoBackend Distributed middleware Caching framework Template Serializer request reply

Web application External services

Object-relational mapping

The integrated ORM is a considerable advantage of Django framework as indicated before. It automates the conversion of data stored in relational databases into software objects for use in application code. This high-level of abstraction to any supported RDBMS allows the interfacing with scalar data using only Python code instead of merging SQL within. This not only speeds up the development facilitating the management of complex data structures but also permits the switching between various RDBMS without modifying the application code. Hence, the ORM was used for both implementing and interfacing the data of the SB models studied in Section 2.4. The implementation corresponds to class definitions in Python that follow a relational data model; the committing of the object-oriented models to the relational database tables and relationships is performed with a process called Migration. The interfacing of the data corresponds on any use of the ORM in the Python code for combining, filtering, sorting, and any other data operations for retrieving the correct information from the RDBMS. Django follows a lazy evaluation strategy for improving the database performance. Using the ORM for a database query, the object query is created, passed around, modified, and extended without incurring any database activity. It is only when the query gets evaluated that the final database query is formulated and send to the RDBMS for retrieving the data. Therefore, in the BMS all the database related requests are performed through the ORM which improves the performance overall and mitigates potential poor programming overheads.

API

The holistic API is crucial for exposing to external entities and stakeholders the full length of interaction services of the SB in a trivial and standardize manner. A good API should remain functional, structured, granular yet minimal, and self-explanatory for anyone outside the BMS designers team. Concerning the particular implementation in the proposed system, the API covers all information that can be extracted from the BMS. The implemented list of API resources is reaching 100. All the URLs are well documented with the Swagger library and can be tested directly within a dedicated application web page.

An API can be designed by following various paradigms and implementation schemes. A modern approach for APIs is a REST based API. REST stands for representational state transfer web services and the concept was first introduced in the Ph.D. thesis of Fielding [87]. The REST as a paradigm of web design and not a standard can not be directly compared with established web services standards. Nevertheless, Pautasso et al. [88] illustrated the conceptual and technical differences between the RESTful and the alternative SOAP protocol.

External applications and algorithms have already used the API successfully for many cases such as energy management and optimization, occupant activities and their optimal comfort learning, thermal simulations, mobile applications, and user engaging HID for improved energy awareness.

Security

Django integrates an extensible authentication system. While it is designed for ensuring the

access rights to the web application, in the proposed model, the (occupant) is uniquely

associated with the internal models of the authentication system. Thus, physical (building) and digital (web application) access rights are unified and co-managed, which enhances the security and transparency. Finally, Django framework has built-in mitigation techniques for cross-site request forgery, cross-site scripting, SQL injection, password cracking and other typical web attacks.