WP3: Middleware Platform

Objectives

This work package aim to develop the definition and implementation of the middleware platform. The middleware will be an effective, holistic service and provide integrated communication. It will take into account existing open standards frameworks, SOA architecture and security and privacy needs.

WP3 will define and implement the detailed middleware platform addressing essentials for data description (integrating the data modeling results from WP2), defining functional architecture and the integration components for control strategy and real-time building performance as well as the detailed interface specifications. Additionally, this WP will provide a service platform prototype where the WP5 APO services (Assess, Predict, Optimize) can be implemented upon. The aim is to provide a robust and flexible service middleware platform architecture and model that allow applicability to the theoretical use cases defined in WP1.

Approach

The schematic below is presenting the envisioned operation of the BaaS System in a real building. During normal operation the middleware platform will abstract building devices. The data warehouse will be the central data repository and the APO services will provided the much needed operational intelligence.

In the schematics information and communication paths are shown. Upon identification of an anomaly, say the failure of the HVAC system or other atypical scenarios. The BIM information will be updated and this will trigger a regeneration/update of all BaaScomponents.

Task 3.1: Data Modelling Harmonization

  • Extend established data models (BIM, IFC) with special emphasis on building dynamics and respective real-time monitoring and actuation,
  • classify data models regarding privacy/security issues and derive security and privacy concept,
  • distribute functions / data according to case studies from WP1,
  • apply standards and interoperability as defined in WP2 where appropriate solutions are defined to fill gaps.

Task 3.2: Functional Architecture

  • Collection of functional requirements (incl. study of external services that could be used to provide generic services inside the platform).
  • Definition of functional components and interaction schemes in different trust model.
  • Definition of the specifics for dynamic complex systems and realization of an appropriate system architecture enforcing the evolutionary strategies developed in WP5.
  • Distribution and interconnection of functions (Buildings, internal and external ICT systems, core service platform functions) realizing effective cloud-interacting middleware enabling flexible cloud deployments.
  • Definition of the control container for the interaction with service logic defined in WP 5.
  • Define security / privacy / trust / fail-over requirements and procedures.

Task 3.3: Overall System Design

In this former stage, four components are envisioned, a Logic Layer will standardize the access to the information managed in the Data Management Layer, a Process Layer will include and centralize every control process, the APO Services used to provide generic services inside the platform are the Core Services, and the Dashboard related to the Graphical User Interface.

Task 3.4: Prototype Implementation

  • To evaluate platform for implementation (SW framework).
  • Prototyping.
  • Proof of concept / evaluation of prototype.

Contact

Work package leader: Dr. Mischa Schmidt < This email address is being protected from spambots. You need JavaScript enabled to view it. >. NEC Laboratories Europe. Heidelberg (Germany)

Participants:

  • Fundación CARTIF
  • Honeywell Prague Laboratory.
  • University Colleage of Cork-Iruse