building energy management system (bems) definition€¦ · building energy management system...

[Digitare il testo] [Digitare il testo]

This project has received funding from the European Union’s Horizon 2020researchand innovation programme under grant agreement N° 637186.

Building Energy Management System (BEMS) definition 31 January 2016 – 01/16 (M12)

D5.1: Building Energy Management System (BEMS) definition WP 5, T5.1 Authors: Francisco J. Miguel, Roberto Sanz, Álvaro Corredera, Víctor Serna, José L. Hernández (CAR), Jesús García, Vicente Madero, Ricardo Palomar (ACC), Daniel Martín (ASC), Gulfem Inaner, Zeynep Ozdogru (EKO), Yildirim Ozkaya (NME), Emilio Vega (SOL), Borja Tellado (TEC)

BREakthrough Solutions for Adaptable Envelopes in building Refurbishment EeB-02-2014 RIA Technical References

D5.1 Building Energy Management System (BEMS) definition 2

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement N° 637186.

1

PU = Public PP = Restricted to other programme participants (including the Commission Services) RE = Restricted to a group specified by the consortium (including the Commission Services) CO = Confidential, only for members of the consortium (including the Commission Services)

Project Acronym BRESAER

Project Title BREakthrough Solutions for Adaptable Envelopes in building Refurbishment

Project Coordinator

Isabel Lacave Azpeitia

ACCIONA INFRAESTRUCTURAS

mailto:[email protected]

Project Duration February 2015 – July 2019 (54 months)

Deliverable No. D5.1

Dissemination level1 PU

Work Package WP 5 – Integrated Building Energy Management System

Task T 5.1 – Definition of the Building Energy Management System (BEMS) to implement control strategies

Lead beneficiary CAR

Contributing beneficiary(ies)

ACC, ASC, EKO, NME, SOL, TEC

Due date of deliverable

31 January 2016

Actual submission date

31 January 2016

mailto:[email protected]



Document history

V Date Beneficiary Author

0.1 30/09/2015 CARTIF Víctor Serna, Francisco Miguel, José Hernández

0.2 02/10/2015 CARTIF Roberto Sanz, Álvaro Corredera, José Hernández

0.3 07/10/2015 CARTIF Francisco Miguel, Víctor Serna, José Hernández

0.4 14/10/2015 TECNALIA Borja Tellado

0.5 16/10/2015 ASCAMM, SOLARWALL Daniel Martín, Emilio Vega

0.6 20/10/2015 CARTIF Víctor Serna, Francisco Miguel, José Hernández

0.7 10/11/2015 ACCIONA, EKODENGE Ricardo Palomar, Vicente Madero, Zeynep Ozdogru

0.8 23/12/2015 EKODENGE Zeynep Ozdogru, Gulfem Inaner

0.9 13/01/2016 CARTIF Roberto Sanz, Álvaro Corredera, José Hernández

0.10 15/01/2016 CARTIF Francisco Miguel, José Hernández

0.11 19/01/2016 CARTIF Francisco Miguel, José Hernández

0.12 22/01/2016 ACCIONA Ricardo Palomar, Vicente Madero

1.0 25/01/2016 CARTIF José Hernández



0 Summary

The present document contains the collection of all the developments carried out in Task 5.1. It contains the definition of the BEMS as an ICT solution for managing energy sources by means of integration of the energy systems and monitoring networks. Then, the objective is to design a cost-effective computer-based control system installed in buildings that monitors and controls the building's mechanical and electrical equipment. In this way, the document describes the end-user requirements, use cases, control scenarios and the software modelling. Moreover, a data model is envisaged with the aim of gathering and storing persistent data useful for the assessment. Finally, a test suite is defined for the validation process.



Table of content

0 SUMMARY _________________________________________________________________________ 4

1 INTRODUCTION ____________________________________________________________________ 10

1.1 PURPOSE AND OBJECTIVE ______________________________________________________________ 10

1.2 RELATIONSHIP WITH OTHER TASKS ________________________________________________________ 12

1.3 CONTRIBUTION FROM PARTNERS _________________________________________________________ 12

2 BEMS CONCEPT ____________________________________________________________________ 13

3 DEFINITION OF REQUIREMENTS _______________________________________________________ 15

3.1 LIST OF REQUIREMENTS _______________________________________________________________ 15

3.2 FUNCTIONAL REQUIREMENTS ___________________________________________________________ 16

3.2.1 FUNCTIONAL REQUIREMENTS __________________________________________________________ 17

3.2.2 NON-FUNCTIONAL REQUIREMENTS ______________________________________________________ 27

4 USE CASES ________________________________________________________________________ 31

4.1 SOFTWARE USE CASES ________________________________________________________________ 31

4.2 CONTROL SCENARIOS _________________________________________________________________ 32

4.2.1 SOLAR PRE-HEATED AIR SYSTEM _________________________________________________________ 33

4.2.2 DYNAMIC WINDOWS ________________________________________________________________ 36

5 BEMS DESIGN ______________________________________________________________________ 39

5.1 SYSTEM ARCHITECTURE _______________________________________________________________ 39

5.2 COMPONENTS DESIGN ________________________________________________________________ 40

5.2.1 ENTITIES DIAGRAM _________________________________________________________________ 40

5.2.2 INTERFACES DEFINITION ______________________________________________________________ 43

5.2.2.1 Internal interfaces ______________________________________________________________ 43

5.2.2.2 External interfaces ______________________________________________________________ 44

5.2.3 CLASS DIAGRAMS __________________________________________________________________ 47

5.2.4 SEQUENCE DIAGRAMS _______________________________________________________________ 47

5.2.5 GRAPHICAL USER INTERFACE___________________________________________________________ 48

6 DATA MODEL ______________________________________________________________________ 52

6.1 DATA CATEGORIZATION _______________________________________________________________ 54

6.1.1 ENVIRONMENTAL MODEL _____________________________________________________________ 54

6.1.2 BIM MODEL ______________________________________________________________________ 55

6.1.3 USER PREFERENCES MODEL ____________________________________________________________ 55

6.1.4 RESOURCES SCHEDULING MODEL ________________________________________________________ 55

6.1.5 ADVICES MODEL ___________________________________________________________________ 56

6.1.6 ENERGY PERFORMANCE MODEL _________________________________________________________ 56

7 TECHNOLOGIES ENVISAGED __________________________________________________________ 57

8 TEST ENVIRONMENT ________________________________________________________________ 59



8.1 UNITARY TESTS _____________________________________________________________________ 59

8.2 INTEGRATION TESTS __________________________________________________________________ 59

8.3 PERFORMANCE TESTS _________________________________________________________________ 60

9 CONCLUSIONS _____________________________________________________________________ 61

10 REFERENCES ______________________________________________________________________ 62

APPENDIX I. USE CASES DETAILS __________________________________________________________ 63

APPENDIX II. EVENT DEFINITION __________________________________________________________ 77

APPENDIX III. CLASS DIAGRAMS __________________________________________________________ 83

APPENDIX IV. SEQUENCE DIAGRAMS ______________________________________________________ 91

APPENDIX V. DATA MODEL TABLES _______________________________________________________ 93



List of Tables Table 1 – Relations with different tasks .......................................................................................................... 12

Table 2 – Contribution from partners ............................................................................................................. 12

Table 3 – List of end-user requirements.......................................................................................................... 15

Table 4 – Data communication functional requirement ................................................................................. 17

Table 5 – Data model functional requirement ................................................................................................ 18

Table 6 – Data storage functional requirement .............................................................................................. 18

Table 7 – Monthly reports functional requirement ........................................................................................ 19

Table 8 – Prediction tools functional requirement ......................................................................................... 19

Table 9 – Optimal calculation functional requirement ................................................................................... 20

Table 10 – Load balancing functional requirement ......................................................................................... 21

Table 11 – Blind controller functional requirement ........................................................................................ 21

Table 12 – Corrective actions functional requirement .................................................................................... 23

Table 13 – Alarm management functional requirement ................................................................................. 23

Table 14 – Actuation checking functional requirement .................................................................................. 24

Table 15 – Manual mode functional requirement .......................................................................................... 24

Table 16 – Data mining functional requirement ............................................................................................. 25

Table 17 – Real-time data functional requirement ......................................................................................... 26

Table 18 – Recommendations functional requirement .................................................................................. 26

Table 19 – Time response non-functional requirement .................................................................................. 27

Table 20 – Availability non-functional requirement ........................................................................................ 27

Table 21 – Fail-recovery non-functional requirement .................................................................................... 28

Table 22 – Extensibility non-functional requirement ...................................................................................... 28

Table 23 – Replicability non-functional requirement ...................................................................................... 28

Table 24 – Openness non-functional requirement ......................................................................................... 29

Table 25 – Occupants disturbance non-functional requirement .................................................................... 29

Table 26 – Access rights non-functional requirement .................................................................................... 30

Table 27 – Mapping between use cases and requirements ............................................................................ 31

Table 28 – Solar pre-heated air system control scenario 1 ............................................................................. 33

Table 29 – Solar pre-heated air system control scenario 2 ............................................................................. 34

Table 30 – Dynamic window control scenario 1 .............................................................................................. 37

Table 31 – Dynamic window control scenario 2 .............................................................................................. 38

Table 32 – Mapping use cases and components ............................................................................................. 42

Table 33 – LonWorks interface ........................................................................................................................ 44

Table 34 – Database connection properties .................................................................................................... 46

Table 35 – Data model categories ................................................................................................................... 54

Table 36 – Example of unitary test .................................................................................................................. 59

Table 37 – Example of integration test ........................................................................................................... 60

Table 38 – Performance tests .......................................................................................................................... 60

Table 39 – Operation mode use case .............................................................................................................. 63

Table 40 – Prediction tools use case ............................................................................................................... 63

Table 41 – Load balancing use case ................................................................................................................. 64

Table 42 – Calculation use case ....................................................................................................................... 65

Table 43 – Actuation use case ......................................................................................................................... 66

Table 44 – Actuation checker use case............................................................................................................ 66

Table 45 – Corrective action use case ............................................................................................................. 67

Table 46 – User recommendations use case ................................................................................................... 67

Table 47 – Data gathering use case ................................................................................................................. 68



Table 48 – Weather forecast data gathering use case .................................................................................... 69

Table 49 – BMS data gathering use case ......................................................................................................... 69

Table 50 – External data gathering use case ................................................................................................... 70

Table 51 – Data model use case ...................................................................................................................... 71

Table 52 – Data storage use case .................................................................................................................... 71

Table 53 – Mode switch use case .................................................................................................................... 72

Table 54 – Visualization use case .................................................................................................................... 72

Table 55 – Reports use case ............................................................................................................................ 73

Table 56 – Alarms use case .............................................................................................................................. 74

Table 57 – Self-train use case .......................................................................................................................... 75



List of Figures Figure 1 – Work Package structure ................................................................................................................. 10

Figure 2 – Conceptual diagram ........................................................................................................................ 13

Figure 3 – Interaction of the BEMS with building facilities ............................................................................. 14

Figure 4 – Use cases diagram .......................................................................................................................... 32

Figure 5 – Operation scheme for the heating system ..................................................................................... 36

Figure 6 – High level architecture .................................................................................................................... 39

Figure 7 – Components diagram ..................................................................................................................... 41

Figure 8 – OSGi event mechanism ................................................................................................................... 43

Figure 9 – TRNSYS communication procedure ................................................................................................ 47

Figure 10 – Navigation flow ............................................................................................................................. 48

Figure 11 – Monitoring screens for the (a) admin, (b) technical, (c) owner and (d) external users ............... 49

Figure 12 – Alarms screen ............................................................................................................................... 49

Figure 13 – Configuration screen for the administrator ................................................................................. 50

Figure 14 – Configuration screens for the technical user ............................................................................... 51

Figure 15 – KPIs screen .................................................................................................................................... 51

Figure 16 – Data model schema ...................................................................................................................... 53

Figure 17 – AlarmManager class diagram ....................................................................................................... 83

Figure 18 – Calculator class diagram ............................................................................................................... 83

Figure 19 – Communicator class diagram ....................................................................................................... 84

Figure 20 – ControlModule class diagram ....................................................................................................... 84

Figure 21 – DatabaseCommunicator class diagram ........................................................................................ 85

Figure 22 – DataModel class diagram ............................................................................................................. 85

Figure 23 – ForecastDriver class diagram ........................................................................................................ 86

Figure 24 – GUI class diagram ......................................................................................................................... 86

Figure 25 – Integrator class diagram ............................................................................................................... 87

Figure 26 – LonDriver class diagram ................................................................................................................ 87

Figure 27 – Predictor class diagram................................................................................................................. 88

Figure 28 – Reports class diagram ................................................................................................................... 88

Figure 29 – Translator class diagram ............................................................................................................... 88

Figure 30 – Schedulers class diagram .............................................................................................................. 89

Figure 31 – Self-Trainer class diagram ............................................................................................................. 89

Figure 32 – SignalManager class diagram ....................................................................................................... 90

Figure 33 – Supervisor class diagram .............................................................................................................. 90

Figure 34 – Switch class diagram ..................................................................................................................... 90

Figure 35 – Sequence diagram for gathering data .......................................................................................... 91

Figure 36 – Sequence diagram for control operation ..................................................................................... 91

Figure 37 – Sequence diagram for GUI ............................................................................................................ 92

Figure 38 – Sequence diagram for mode switch ............................................................................................. 92

Figure 39 – Sequence diagram for alarm logging ............................................................................................ 92



1 Introduction

1.1 Purpose and objective

The present document is the deliverable that comprises the starting activities from Work Package 5. This work package is dedicated to the concept, presentation design, development, testing and putting into service of the Building Energy Management System (BEMS from now on). Along with the WP3 works that include the design and development of new envelopment components, the efforts in WP5 run towards the development of the BEMS, as it has been foretold, and they comprise together the whole innovation efforts for the project, as it is shown in Figure 1.

Figure 1 – Work Package structure

Concerning the development of the BEMS, the procedure to follow goes in the same way as the present document, considering the steps:

Definition of the requirements to fulfil with the BEMS. This includes what can and should

be done, limitations and goals. This is included into chapter 3.

The use cases are defined to cover the usefulness of the BEMS. This is covered in chapter 4,

and the work is developed in parallel with the previous point.

With the previous results, it is time to translate the concepts into the logic structure that

the software must follow in order to achieve what is expected from the real BEMS to be

implemented. This is covered in chapter 5.



Along with the software structural design, the data model has to be defined in order to

handle the information gathered, generated, transmitted and stored in the whole system.

The data model is defined in chapter 6.

Before the developers start working to create the BEMS, the tools to perform the activity

have to be selected to cover the needs of the project. These are identified in chapter 7.

Once the three previous steps have been completed, the process of software design can

start, as long as all necessary elements have been defined.

The testing features have to be indicated in order to optimize the trial-fail-develop

procedures in the real system. These testing elements are included in chapter 8.

First, these tests are done in simulation environments, and then tested in real locations

that could include the demo sites. When some changes are made in the demo, the BEMS

should be tested and reshaped to comply with the new situation, until the definitive

settlement of devices in the demos has been installed and successfully

About the scientific objectives, the contribution of the deliverable covers the following:

“A. Design criteria for the integrated system” a) “To define the system context and limits of use”

Boundaries for the BEMS are defined explicitly b) “To develop a design guide and computer tool for aiding design”

The design for the software elements are mainly defined into this document, so they will be directly used in subsequent guides.

“B. New envelope components”

a) “To test and validate the BRESAER system according to EU standards and regulations“

The testing features in terms of software elements and related to BEMS system are also defined here.

“C. Integration of the active envelope components with existing installation”

a) “To develop guides for installation, commissioning and maintenance” Maintenance also includes the software, the computing equipment,

database and sensors, and these are considered in this category. b) “To develop a software tool for supporting the envelope components installation”

This tool will be in line with the BEMS development if not being an integral part of it.

“D. Building Energy Management System (BEMS)” a) The whole points and goals are completed in this document, as previously

indicated.

“E. Demonstration and evaluation” a) Under this paragraph the testing procedures have to consider the BEMS as another

component to be tested inside the whole system. The BEMS will affect the performance of the current development, has to be commissioned and installed and has some economic impact in the final result.



1.2 Relationship with other tasks

This deliverable contains the info to develop the BEMS that is one half of the framework for future works. Consequently the content is mainly used as a guide to perform other future tasks related to the measurement, the process and validation of data, the analysis of the gathered data, monitoring of variables and final management and testing of the BEMS. The next table shows the relationship with the other tasks:

Table 1 – Relations with different tasks

Deliverable Task Relation

D3.2 T3.4 & T3.5 The monitoring of values will take advantage of some of the BEMS features designed here

D5.2 & D5.3 T5.2 & T5.3 The complete works and activities from T5.1 will be followed by the ones in T5.2 and T5.3

D6.2 & D6.6 T6.2 & T6.7 Monitoring data are gathered through the BEMS.

D6.7 & D6.9 T6.7 The results of the analysis and evaluation of the solution and the improving regarding the initial situation will need the implementation and adjustment of the BEMS

This table will help to make some adjustments in the start and ending of the related tasks in order to avoid delays and to comply with the deadlines. The content and conclusions from this document will be part of milestone MS2 along with the Simulation and validation to achieve an advanced design (WP3) led by Mondragón.

1.3 Contribution from partners

Table 2 – Contribution from partners

Partner Effort (PM)

Responsibility

ACCIONA 3 Definition of requirements, Control Scenarios, Communication interfaces, Tests

ASCAMM 1 Definition of requirements, Control Scenarios, Tests

CARTIF 14 Task leader, Definition of requirements, Use cases, Control scenarios, Data model, Architecture, Components, Class/Sequence diagrams, Communication interfaces, Tests

EKO DENGE 2 Definition of requirements, Control scenarios, Graphical User Interface, Tests

NME 1 Definition of requirements, Definition of regulations to be fulfilled in the BEMS

SOLARWALL 1 Definition of requirements, Control Scenarios, Tests

TECNALIA 3 Definition of requirements, Data model, Tests



2 BEMS concept

“A Building Management System (BMS) is a cost-effective computer-based control system installed in buildings that monitors and controls the building's mechanical and electrical equipment such as ventilation, lighting, power systems, fire systems, and security systems” [1]. “A BMS is a complex, multi-level, multi-objective, integrated, interrelated and complete intelligent design management information system” [2], which combines software and hardware for managing the behaviour of the facilities of any building [3]. Hardware system is set up by the sensor network (see D6.1 [4]), meanwhile software integrates the communication driver and business logic (control algorithms, database connection) establishing an "all in one solution". The BMS is centred in four basic functions [1][2][3]:

Monitoring: Continuous monitoring of the sensors measurements.

Controlling: Control algorithms for the facilities behaviour in the building.

Optimizing: Working out the best performance of the system.

Reporting: Documentation of the intermediate and final results.

Figure 2 draws a conceptual model about what would stand for the global platform. From bottom, the physical environment is connected through communication drivers that speak the same language than the field protocols. However, it is common to have several protocols or languages, which are harmonized by means of the integration layer (or, namely, data model). The advantage of this approach lies in the capability of homogenising the signals from the upper layers perspective, reducing the complexity in the intermediate translations. Next, it is required a business core in charge of the communication, dispatching signals and being aware of what is internally happening in the platform (i.e. schedulers, alarms…). Moreover, conceptually, it is necessary to connect a database and show the information in a graphical interface to the end-user. Finally, the high-level services concept is remarking the intelligence of the system and all the high-level algorithms are included within this concept that, sometimes, could require the connectivity with external tools.

Figure 2 – Conceptual diagram



With this approach, the four basic functions are completely covered. Firstly, monitoring is ensured by the sensor network designed in D6.1 [4] whose values are gathered by the proper driver and, thus, stored in the database. Secondly, the control is available by means of the drivers as well, which execute commands when the control algorithms determine a new actuation. Third, optimizing is rendered through the high-level services that implement advanced strategies in order to increase the energy performance, as well as assuring comfort. Finally, reporting is also integrated in the high-level services by a component in charge of generate these reports. As stated by [1], BEMSs are commonly implemented in buildings for the management of the energy facilities and, as pointed in some studies, they could represent up to 40% of the energy savings. With this aim, within the project, a BEMS is designed to govern the active envelope components, as well as the existing energy facilities. In that sense, within the BRESAER context, the BEMS will be able to manage the dynamic windows, ventilated façade, boiler, lighting systems, sensor network and the benefits of thermal insulation, as highlighted in Figure 3 (a more detailed description of this concept may be extracted from [5]).

Figure 3 – Interaction of the BEMS with building facilities



3 Definition of requirements

The first step in any object-oriented modelling is the definition of the requirements from the end-user point of view. This requirement model aims at defining and limiting the software functionality and it can be viewed as the contract with the client [6]. Then, it is usually gathered through surveys and interviews with the end-user (in BRESAER project it has been a collaborative work among all the partners) in order to reflect the desired functionalities. In a first iteration, the communication language is not technical, whereas in the following iterations these requirements are translated into technical language as input for the next steps in the software modelling. The followed procedure in BRESAER is not an exception at all, and the end-user requirements are to be described to be completed with the technical (or namely functional) ones.

3.1 List of requirements

As stated, first step is the collection of the requirements from the end-user. Thus, Table 3 gathers the requirements numbered by FR-# and NFR-# whose meaning will be explained in the next section, as well as the type (functional and non-functional). It is also important to remark that every requirement starts with “The BEMS should…”.

Table 3 – List of end-user requirements

Number Type Description

FR-1 Functional …gather information from multiple “physical” environments/protocols such as existing sensor networks, new ones, available data sources (e.g. weather forecast), WP3 solutions, among others, through open/standard protocols.

FR-2 Functional …integrate the information in a common data model based on standards with the aim of the representation of the information in the same vocabulary, increasing the scalability.

FR-3 Functional …store the data into a persistent resource (i.e. database) compliant with the data model so as to keep an historical record of the monitoring system for further evaluation.

FR-4 Functional …generate monthly reports which should present the information and graphs according to the useful variables for the Measurement and Verification plan and the evaluation of the KPIs.

FR-5 Functional …make use of external tools for predictions, such as TRNSYS [8] or Energy+, based on well-known interfaces (i.e. Java based, Matlab [7] type 155…).

FR-6 Functional …calculate through advanced control algorithms the best performance actuation into the building facilities by minimizing the energy consumption and assuring the comfort values (double objective: internal comfort and reduction of energy bills).

FR-7 Functional …balance out the load between the energy sources (current building generation and distribution systems, as well as envelope solutions (i.e. SolarWall solution as heat source)) with the aim of decreasing the energy consumption and prioritizing renewable energy.

FR-8 Functional …determine and communicate the set-point of the blind so as to enable the blind controller to perform the proper behaviour of the blinds.

FR-9 Functional …check the status and perform corrective actions by means of real-time data when the actuation has been carried out with the aim of detecting a failed prediction.



FR-10 Functional …generate and collect external alarms previously configured and to report about them.

FR-11 Functional …check that the actuation has carried out in a right way (signal feedback).

FR-12 Functional …switch between automatic and manual control in order to allow external users to manage the system elements.

FR-13 Functional …contain a function for control strategies self-learning (data mining) in order to perform an energy and economic monitoring along the building's history and propose control strategies based on the historic data (this function would be operative after a reasonable period of time).

FR-14 Functional …show in real-time, through a user-friendly interface, different information: the data collected by the monitoring system, the evolution of different parameters during a period of time (for example by charts), the strategy is being followed at any time and others, by means of a simple navigation flow.

FR-15 Functional …determine recommendation to the end-users when the building facilities are used in a bad way from the energy/comfort point of view (e.g. natural ventilation when air-conditioning is running).

NFR-1 Non-Functional

…respond in a limited time (time response).


…provide service near 100% of time.


…implement a fail-recovery mechanism for lost data, communication failures and so on.


…extend its functionality and integrate other buildings.


…replicate its functionality in other buildings.


…make use of free-license software whenever possible.

NFR-7 Non-functional

…generate only very limited disturbance to occupants during operation

NFR-8 Non-functional

…contain different levels of permissions, depending on different user (end-user, building owner, administrator, etc.), giving different privileges to perform specific actions within the system by a user.

3.2 Functional requirements

The second step is to translate the aforementioned requirements into a technical language. Moreover, the details of these requirements are established. Apart from that, it is important to mention that the requirements are divided into functional (FR) and non-functional (NFR). The first group points the requirements which are related to a desired functionality of the platform, whereas non-functional ones determined performance/configuration parameters. Then, next sections depict the functional and non-functional requirements in table format. Every table has been defined in order to capture the requirements related to a specific aspect of the BRESAER system, for example data management, APO modules, and so on. So as to measure the relevance of the requirements for the behaviour of the system, an “Importance” field has been defined with three levels of importance: critical, high, and standard:



Critical – These requirements are indispensable for the operation of the BRESAER system.

High – Without these requirements, only limited functionality can be achieved.

Standard – These requirements have an impact on the quality of service but are not crucial for the operation of the BRESAER system itself, i.e. they add value to the overall system.

3.2.1 Functional requirements

Table 4 – Data communication functional requirement

Name FR-01: Data layer connection

WPs affected WP3 & WP5 & WP6

Description The BRESAER BEMS should be able to gather information from multiple “physical” environments/protocols such as existing sensor networks, new ones, available data sources (e.g. weather forecast), WP3 solutions, among others, through open/standard protocols.

In this way, the BEMS will gather the information from the following sources.

Building Management System (BMS): This is the main resource for the building data. The BMS is usually represented by the monitoring sensor networks, weather station and the Building Automation Control Systems (BACS) which provide the interface to gather the data measurements and the possibility to actuate into the controllers. These BMSs can be composed by different networks implemented in different protocols (existing and new sensor networks). Therefore, the BEMS should implement the specific communication driver to communicate high-level services and the physical network through open and standard protocols (LonWorks, BACnet, OPC…) and the monitoring network should run by means of these open and standard protocols. Then, the BEMS will include as many drivers as available protocols.

WP3 solutions: When retrofitting, additional solutions to the existing building facilities are integrated with the goal of improving the thermal performance. These solutions should include sensors and actuators for exchanging information between the BEMS and such solutions. Then, the BEMS should implement additional drivers for the communication with these solutions in case the aforementioned protocols are not covered. The communication should be based on open and standard protocols. Additionally, the monitoring network should integrate this information whenever possible.

Weather Forecast: Prediction tasks require the interaction with forecasting. In the case of energy systems, the weather forecast is a very important service because, depending on the weather conditions, the energy systems should behave in the proper way to efficiently manage the building facilities. Then, the BEMS should be able to connect these services by means of Web Services (SOAP, RESTful) so as to insert this information into the control algorithms.

External sources: Normally, in this kind of solutions, external sources are required, for example, external tools or data as calendar. In the case of the BEMS, these data need to be collected and interfaced by means of Java APIs or free license software. Even static data could be used (for instance, standard occupancy profile) by statically inserting this information into the database with the objective of allowing the use of the data for control purposes.



All these data sources should be periodically compiled each 10-15 minutes according to the Measurement and Verification plan from the T6.1.

Importance Critical

Rationale Periodically log the information from the data sources in order to set up an historical record for evaluation proposes.

Table 5 – Data model functional requirement

Name FR-02: Organize the information in a complete data model

WPs affected WP5 & WP6

Description The BRESAER BEMS should be able to integrate the information in a common data model based on standards with the aim of the representation of the information in the same vocabulary, increasing the scalability. The essential information that the data model must represent would be:

Building information. The static data that describes the building: description, metadata, information about the systems…

Devices. Not only the static information about the devices (localization, description, model, vendor…) but also the dynamic information (variables, values, states…)

BEMS decision

Aggregated data: KPIs, other processed information…

Alarms

The objective is the execution of a mapping between the data model and the data base.

Importance Critical

Rationale The data model is a necessary standard to ensure exact communication between systems.

Table 6 – Data storage functional requirement

Name FR-03: Store data into a persistent resource


Description The BRESAER BEMS should be able to store the data into a persistent resource (i.e. database) compliant with the data model so as to keep an historical record of the monitoring system for further evaluation.

The collected information from the Building Management System (BMS), WP3 solutions, weather forecast and external sources will be stored in a database which follows the defined data model.

The information stored in the database will be available for the BEMS, and for any service of the BEMS (if needed and if there is authorization).

The design of the database should be performed under big-data concepts with the aim of improving the performance of the system.

The system should be able to securely backup data and restore it if needed. Multi-level incremental backups are preferred.

The system should be able to keep historical logs of access, modification and deletion of data.

Importance Critical

Rationale The data must to be correctly stored for the analysis of the BEMS performance and also the whole BRESAER System.



Table 7 – Monthly reports functional requirement

Name FR-04: Monthly reports


Description The BRESAER BEMS should be able to generate monthly reports which should present the information and graphs according to the useful variables for the Measurement and Verification plan and the evaluation of the KPIs.

The report will have the following features:

Header, containing a correlative Id number and date.

Variables and KPIs will be presented with graphics showing the evolution of the values, during the latest month, along with max and min values and any required data mining technique according to the Measurement and Verification procedure in T6.1.

Alerts and warnings will be also included, indicating the date and time of the event, level of importance and a brief message with the actuation associated to the event.

There will be information paying attention to the events of “manual mode”, including date, location and length (if the event lasted longer than a few minutes).

End of the document, with recommendations associated with the eventual alerts and warnings generated, contact persons for maintenance purposes, and the legal disclaimer.

These reports will be automatically generated first day of the next month. In case, the report generation process fails, it will be manually generated.

Importance Standard

Rationale Obtain info about the behaviour of the system in a constant basis.

Table 8 – Prediction tools functional requirement

Name FR-05: Interface with external tools for predictions

WPs affected WP5

Description The BRESAER BEMS should be able to make use of external tools for predictions, such as TRNSYS [8] or Energy+, based on well-known interfaces (i.e. Java based, Matlab [7] type 155…).

Simulation software tools will be necessary for predicting how the building is going to behave and which will be the optimal strategy to follow in order to fulfil the requirements with the best operation. TRNSYS [8] or Energy+ are examples of those suitable tools. The interface between the simulation software and the BRESAER BEMS must be solved in the easiest way. Different options could be used:

Type 155 from Trnsys library [8]: This TRNSYS Type implements a link with Matlab [7]. The connection uses the Matlab [7] engine, which is launched as a separate process. The Fortran routine communicates with the Matlab [7] engine through a Component Object Model (COM) interface. Type 155 can have different calling modes (e.g. iterative component or real-time controller). It is necessary to have Matlab (6.5 or later) [7] although this component must be recompiled specific to a particular version of Matlab [7]. As constraint, the current version of the element only works with 32-bit version.

Type 9 from Standard Trnsys library [8]: This component serves the purpose of



reading data at regular time intervals from a data file, converting it to a desired system of units, and making it available to other TRNSYS components as time-varying forcing functions. This component is generic in nature and can read many different types of files. The data from line to line must be at constant time intervals.

New Trnsys element: It is possible to create a new element using FORTRAN code in order to make the interaction between Trnsys model and BEMS.

Java based: This last possibility is based on Java process management. The idea behind is that Java reads and writes the input file for TRNSYS (.dck) [8] and, then, launched the TRNExe.exe process by indicating the input file. Once the simulation is finished, Java reads the output file (.out or .txt) with the results of the simulation. In contrast to the aforementioned methods, this parametrizes files to run independent simulations.

Importance Critical

Rationale To establish a safe communication between simulation tool for prediction and BEMS

Table 9 – Optimal calculation functional requirement

Name FR-06: Calculate through advanced control algorithms the best performance actuation

WPs affected WP5

Description The BRESAER BEMS should be able to calculate through advanced control algorithms the best performance actuation into the building facilities by minimizing the energy consumption and assuring the comfort values (double objective: internal comfort and reduction of energy bills).

The system could act as an intelligent control software, based on monitoring data, a history of past actions, weather forecast, a set of operating strategies and simulation software that will reproduce the behaviour of the whole system (building + HVAC systems).

This tool should be able to recommend the best sequence of strategies to apply during a period of time to maintain the energy production over the demand applying the strategy with the minimum cost, therefore two different objective would be satisfied:

the energy requirements of the buildings would be met (by selecting energy production curve over energy demand curve)

reduction of costs (by selecting the minimum cost curve among all the curves with energy production over energy demand and taking into account a maximum deviation between production and demand).

Importance High

Rationale To have a tool to meet the energy needs at minimum cost.



Table 10 – Load balancing functional requirement

Name FR-07: Load balancing


Description The BRESAER BEMS should be able to balance out the load between the energy sources (current building generation and distribution systems, as well as envelope solutions (i.e. SolarWall solution as heat source)) with the aim of decreasing the energy consumption and prioritizing renewable energy.

The BEMS should take into account all the generation sources to balance the load in the most suitable way to save as much energy as possible by ensuring the comfort levels. Within these generation systems are:

Heating/cooling sources, such as gas/gas-oil/biomass boilers already available in the system. That includes the distribution systems (i.e. pumps, valves, etc.) and storage systems (i.e. DHW tanks). In this way, the SolarWall solution is considered

Electricity: Photovoltaic.

External gains/losses: Thermal inputs from the external radiation and capable of being controlled through the smart windows.

With regard to the end uses, there are several possibilities:

Air Handling Units (AHUs)

Radiators

Air-conditioning systems

The final list of generation/distribution systems and end loads will be determined within the T6.1 and the building description. Moreover, the decision making process will be selected according these inputs/output and the methodology will be decided within several possibilities, such as Fuzzy algorithms, neural networks or adaptation of existing algorithms in routing methodologies (Energy-Aware Adaptive Solutions).

Importance Critical

Rationale The ability of reducing the energy consumption is remarked by the proper balance of the generation sources and the loads.

Table 11 – Blind controller functional requirement

Name FR-8: Blind controller


Description The BRESAER BEMS should be able to determine and communicate the set-point of the blind so as to enable the blind controller to perform the proper behaviour of the blinds.

The BREASER Blind is a controllable blind which can perform any of the actions depicted in Fig. 1. Basically, it is capable of going up/down the blind, turning the blind to avoid the entrance of sun and locking the blind to avoid thermal losses.



(a) up-down

(b) Sun shading

(c) Lock + Air-tightness

a) move up and down the blind slats b) rotate the slats to give them different inclination angles c) lock blind in closed position tightening junctions in order to ensure total air

sealing and guaranteeing security from intrusion Fig. 1 – Blind functions

This blind will have its own embedded control which will be in charge to perform the previous actions. The controller will be also in charge of monitoring the blind status. Blind status will be shared in order to provide some inputs to the BEMS. The blind control will be designed in order to operate in two modes. In both cases, the BEMS will collect the status of the blind continuously.

MANUAL, where the blind is controlled directly by the final user. REMOTE, where the blind is be controlled by the BEMS.

Regarding the final user control, the selection between both modes will be done by means of different buttons on nearest BEMS Control Cabinet. Depending on the operating mode, the system will allow the final user to:

MANUAL Control Manually the blind position (up-down, slats angle, etc.), or Select an AUTOMATIC mode. In this mode, the blind controller will set the blind position according to the information received from the dedicated sensor and some embedded algorithms.

REMOTE In this mode, the blind position will be determined by the BEMS and the final user will not have any control. In this mode, the BEMS will be in charge of sending the Set-Point (SP) values to the blind, and the blind controller will move the blind to the set position.

SP parameters

Up-down The BEMS will send the Set-Point to move up and down the blind slats.

Analog value

Angles The BEMS will control the inclination angle of the slats

Analog value

Lock The BEMS will send true or false to lock the blind

Binary value



If there is any failure in the blind, its controller will send an alarm signal to the BEMS. Next, there is placed a summary of the BEMS requirements described previously:

The BEMS will be able to communicate with the blind controller by means of an open protocol, such LonWorks, Modbus, or similar.

The BEMS will receive information about the status (mode of operation, slats position, slats angle, sensors…) of the blind in either mode operation mode: MANUAL/REMOTE. The user will be able to change the mode of operation at any time, by means of a button available in the nearest BEMS Control Cabinet.

The BEMS will send the Set-Point values to the blind controller, in REMOTE mode, in order to move up and down the blind, modify the inclination angle of the slats, or lock the blind.

The BEMS will receive an alarm signal if there's some failure in the blind.

The BEMS will receive a busy signal if controller is still performing some control action that has not been finished yet.

Importance High

Rationale The BRESAER blind is one of the BRESAER active solutions that have to be controlled by the BEMS.

Table 12 – Corrective actions functional requirement

Name FR-09: Correction of strategies based on failed predictions

WPs affected WP5

Description The BRESAER BEMS should be able to check the status and perform corrective actions by means of real-time data when the actuation has been carried out with the aim of detecting a failed prediction.

Predictions are susceptible to fail because the simulation models are usually simplified with the aim of improving the system performance. Besides that, the weather forecast is not an exact science and the provided values could be wrong. In these cases, some actions should be taken in order to execute the corrective measures:

Generate the “failed prediction” warning that will go to the reports. As well, an alarm should be thrown.

The BEMS should be re-calibrated with the new real-time values and, then, balance the loads in consequence to assure the users’ comfort and the minimization of the energy use.

While the BEMS is being adjusted to the new data (new inputs, new simulations), an alternative operation should be ready as back-up (for instance, the latest known actuation).

Importance High

Rationale One of the advantages of the smart adaptable management is the possibility to correct strategies automatically and in real time.

Table 13 – Alarm management functional requirement

Name FR-10: Collecting, Prioritizing and Reporting Alarms

WPs affected WP 3 & WP 5 & WP 6

Description The BRESAER BEMS should be able to generate and collect external alarms previously configured and to report about them. Collecting and prioritizing the alarms / notifications



is one of the critical requirements in a management system. An existing system can generate hundreds of alarms on a day. Alarms rank from important issues, like power failure, to inconsiderable messages like a notification that a self-test has started and faults may lead to issues being missed the poor prioritization of interference. For this reason BEMS must be managing the alarms as follows:

Defining rules well for prioritizing alarms based on algorithms previously identified.

Collecting and recognizing the importance and category (occupant comfort or energy consumption etc.) of a generated alarm.

Reporting systematically to reconsider the notifications and to intervene in case of a need.

Importance High

Rationale Alarms and notifications have high importance for maintaining and operating whole building energy systems.

Table 14 – Actuation checking functional requirement

Name FR-11: Checking actuation

WPs affected WP 3 & WP 5

Description The BRESAER BEMS should be able to check that the actuation has carried out in a right way (signal feedback).

Once the BEMS send an actuation signal to a device it needs to know if the signal was correctly understood. In this case, two different situations could take place:

If the actuator device offers feedback about its state after the actuation the BEMS had only to receive this feedback

If the actuator device does not offer feedback about its state after the actuation (or usually offers feedback but in the case that the feedback is not received for the BEMS) the BEMS had to ask the actuator for the new state.

In both cases the BEMS check if the value of the variable of actuation accords with the value expected.

Importance High

Rationale It is necessary to ensure that the commands of BEMS have been received and processed properly because if the actuation is not the desired one, the BEMS strategy will not work.

Table 15 – Manual mode functional requirement

Name FR-12: Switch between manual and automated mode


Description The BRESAER BEMS should be able to switch between automatic and manual control in order to allow external users to manage the system elements.

Some of the WP3 solution can be manually or remotely (i.e. through the BEMS) managed. When switched, the behaviour of the system is as follows:

The WP3 solutions should send an alarm message to the BEMS which catches it.

The BEMS should continue the normal operation with the provided measurements from the solution (that, is such case, will be the values which the user sets in the physical environment).



After emitting the signal, the BEMS should check the status and if the device is being manually controlled, then, it would not receive control impulses until the mode will not change to automated.

The system will keep on obtaining values from the device being controlled independently from the current mode.

Depending on the device, the user could change again to automated mode, and/or the system could recover the control of the device after a determined lapse of time.

The event to change to manual mode should be recorded, including time, location and duration of the event.

All users would be allowed to handle the manual mode of a device, in case they had previously authorized access to the device. The system will not perform any security check, save for the ones integrated into the device to be controlled.

Importance High

Rationale The communication amongst all the components is necessary for the properly behaviour of the whole system.

Table 16 – Data mining functional requirement

Name FR-13: Control strategies self-learning

WPs affected WP5

Description The BRESAER BEMS should be able to contain a function for control strategies self-learning (data mining) in order to perform an energy and economic monitoring along the building's history and propose control strategies based on the historic data and suitable strategies chosen.

Generally, data mining is the process of analyzing data from different perspectives and summarizing it into useful information. It is a computational process of discovering patterns in large data sets involving methods at the intersection of artificial intelligence, machine learning, statistics, and database systems. At the end, the overall goal of the data mining process is to extract information from a data set and transform it into an understandable structure for further use.

After a reasonable period of time, the BREASER BEMS could work taking into account the data mining process and avoiding, in this way, the use of simulation tool as main information provider for the selection of the optimal strategy, what would reduce those risks associated to predictions based on simulations.

There are two critical technological drivers:

Size of the database: the more data being processed and maintained, the more powerful the system required.

Query complexity: the more complex the queries and the greater the number of queries being processed, the more powerful the system required.

Importance Standard

Rationale To have an advanced BEMS system able to provide the optimal strategy based on historic behaviour and relationships among different parameters (data mining).



Table 17 – Real-time data functional requirement

Name FR-14: Access to real-time data

WPs affected WP 3 & WP 5 & WP 6

Description The BRESAER BEMS should be able to show different information consist of the data collected by the monitoring system, the evolution of different parameters during a period of time (for example by charts), and the strategy is being followed at any time and others, in real-time, through a user-friendly interface by means of a simple navigation flow. The system should allow users to see changes in energy supply or demand caused by building occupants and if the display is provided by a navigation flow (as a proxy, or setting a VPN or the other applications), it will present accessibility for users. Time interval of these data is important for making energy management decisions in real time.

In this way, the BEMS can collect the data, illustrate in charts and figures and show as following;

The sub meters and sensors* collect real time energy usage data from building

equipment and zones.

The collected interval data is put in charts trough basic instructions in interface

(Charts/dashboards should be customized based on users’ requests.)

An access is generated with navigation flow, which gives the users the ability of

following the changes from laptops or mobile phones. (For example, the increased

or decreased conditioning requirements)

*Additional occupancy information can be identified with sensors and it makes possible to detail the analyses of energy efficiency.

Importance High

Rationale The real time data access provides flexibility, easy management and real time analysis to the user

Table 18 – Recommendations functional requirement

Name FR-15: Determining Recommendations

WPs affected WP 3 & WP 5

Description The BRESAER BEMS should be able to determine recommendation to the end-users when the building facilities are used in a bad way from the energy / comfort point of views (e.g. not using natural ventilation when air-conditioning is running). Moreover, statistical analysis, simulation and predictive modelling can be applied to determine such as how many chillers need to be turned on, based on forecast occupancy levels and outside weather conditions. (Optimizing algorithms over time, realizing even greater energy savings also.) In this case, the system should use data presented in

Table 17 and present recommendations to users. This step also can be adjustable set up automatically in need.(or remote control) These recommendations can be about;

Lightning,

Operating isolation,

HVAC,

Overloading on the grid



Daily energy cost limit (if it was set up before)

Fire,

Security etc.

Importance Standard

Rationale The impact of end-users on energy efficiency of buildings has high importance in order to achieve the targets of BRESAER project and recommendations provided from BEMS will reduce this risk.

3.2.2 Non-functional requirements

Table 19 – Time response non-functional requirement

Name NFR-1: Time response

WPs affected WP5

Description The BRESAER system should be able to respond in a limited time (time response).

The operative procedures should have an adequate response time. Consequently, if this time is surpassed, the original diagnosis for the system should be a crash failure or similar (power failure, etc.).

The final value could be assigned as a variable by the system manager.

Importance Standard

Rationale It is necessary to show distinctive behaviour when the system has crashed, it is switched off, or the response is suffering a long delay.

Table 20 – Availability non-functional requirement

Name NFR-2: Time of service

WPs affected WP5

Description The BRESAER system should be able to provide service near 100% of time.

The actuation should go in two complementary directions:

Minimize the time for certain operations that leave the system offline, like maintenance tasks, software and hardware reboots, updates, reparations, etc. In order to achieve this, it is necessary to plan these actions carefully and perform them when the users would be less likely to interact with the system (night time).

Provide with mechanisms to early detect possible failures that could crash the system, and even procedures to foresee problems at hardware and software level (predictive maintenance).

Importance Standard

Rationale A system with a low time of service becomes useless quickly.



Table 21 – Fail-recovery non-functional requirement

Name NFR-3: Fail-recovery mechanism

WPs affected WP5

Description The BRESAER system should be able to implement a fail-recovery mechanism for lost data, communication failures and so on.

Every module will contain the proper procedures to recover from a failure:

Backup service for the database.

Remote reset for electronic devices.

The status of the system would be saved periodically in a location independent from the one used for data storage.

Usage of a UPS to save the system variables, status and data in case of power failure.

Importance Standard

Rationale This is perceived as an automated self-reparation procedure, reducing the dependence from the human factor.

Table 22 – Extensibility non-functional requirement

Name NFR-4: Extension of the functionality


Description The BRESAER BEMS should be able to extend its functionality and integrate other buildings.

The creation of new solutions, functionalities or services should be an allowed process by the BEMS, without a lot of efforts. Besides, including new functionalities should not affect the right operation of the system. For such purpose, the BEMS should be designed according scalability patterns and follow a clear and open methodology, as well as the documentation of code interfaces between the BEMS and other modules should be provided, as for example:

BMS

DBs

third-party web services

external tools,

external ICT systems/devices

new modules: Nonetheless, this does not imply full compatibility with

equipment installed in other buildings with different features. The BEMS will be

portable just to a reasonable degree.

Importance Standard

Rationale The scalability of the system is appreciated for the objectives of this project

Table 23 – Replicability non-functional requirement

Name NFR-5: Replication in other buildings

WPs affected WP5

Description The BRESAER BEMS should be able to replicate its functionality in other buildings.



The system should be open enough to run its operation in any building where BRESEAR solutions were installed, independently of the building configuration. Therefore, during design and development stage of the BEMS, it will be emphasized the independence of the building and the BEMS.

Importance Standard

Rationale The project aims the replicability of the solution.

Table 24 – Openness non-functional requirement

Name NFR-6: Free-license software use


Description The BRESAER BEMS should be able to make use of free-license software whenever possible.

The solution should be based on free/libre open source software whenever possible.

In the communication with the BMS and the WP3 solutions, the system should be implement open or standard protocols. If it is not possible, it should be looked for a commercial solution that maps the proprietary protocol to an open or standard protocol. If it is not possible, the proprietary protocol should be implemented in one driver into the BEMS.

In the communication with external sources, the BRESAER BEMS also should implement open or standardized protocols (SOAP, RESTful, Java APIs…).

The communication with the database should be based on SQL queries or other open database standards.

Importance Standard

Rationale BRESAER BEMS should adopt open software and the use of open standards

Table 25 – Occupants disturbance non-functional requirement

Name NFR-7: Disturbance


Description The BRESAER system should be able to generate only very limited disturbance to occupants during operation.

The envelope solutions are usually composed by mechanical elements which could cause disturbance to the users, such as noise. Therefore, the WP3 solutions should be designed to avoid noise, flickering light or any other inconvenience caused to the end users of the building.

In the case of the BEMS, the actuation over the envelope elements should not provoke malfunctioning into the building with the aim of avoiding any disturbance to the users. That means the thermal, acoustic, visual and air quality comfort should be ensured. Thus, the control should be verified and issued without intermittent signals in order to complete the actuation in the less time possible.

Importance Standard

Rationale The solutions should minimise the disturbance of the occupants.



Table 26 – Access rights non-functional requirement

Name NFR-8: Users’ privileges

WPs affected WP5

Description The BRESAER system should be able to contain different levels of permissions, depending on different user (end-user, building owner, administrator, etc.), giving different privileges to perform specific actions within the system by a user.

The access to the information is commonly a concern, even increased when graphical interfaces are available to end users. With the aim of creating multiple access levels, a set of privileges are defined to provide specific info. At the moment, four privileges are detected:

Administrator: This user can access to the gathered information from the sensor network. Moreover, it is able to configure the BEMS parameters, such as users’ administration and alarms handling.

Technical: This user is the designated one to the configuration of the BEMS technical issues, as for example, internal set-points, KPI’s parameters/constants for their calculation or any other technical parameter for the control algorithms to be determined. As well, it is able to configure internal scheduled tasks into the BEMS (i.e. data collection) and visualize alarms. Apart from that, the monitoring values are completely accessible.

Owner: The owner is mostly interested in the behaviour and performance of the building. Hence, this user accesses to the monitored data and KPIs information. Additionally, it can visualize alarms and configure a restrict set of parameters (mainly those related to the country or specific regulations).

External: This user is the most restrictive one and it can only access to a set of filtered data with no additional functionality.

Importance Standard

Rationale The access to the information should be filtered dependent on the users’ privileges.



4 Use cases

Next step in the software design is the analysis model which treats to develop a system architecture that is able to solve the initial problem under ideal conditions [6]. This analysis is focused on the functionality, the interactions and how to deal with the problem. Then, two approaches are followed: use cases and control scenarios. The first one describes how an entity (namely actor) is capable of executing a functionality of the platform. Normally, the use case is a sequence of actions to carry out a specific task. This type of diagrams specifies the communication and behaviour of the system according to the requirements before detailed. In contrast to the use cases, the control scenarios remark the problem to be solved. In the specific case of BRESAER, as it is a BEMS to control a set of building facilities, these are focused on how to deal with the needs.

4.1 Software use cases

As stated, the first step is the use cases definition which is composed by a diagram where the actors, the use case and their relationship are drawn. Figure 4 represents them for the BRESAER system. The actors are the “time” (used for periodic tasks that are executed over the time), “BEMS” itself (for these operations automatically run by the BEMS) and external “users” (for accessing the platform). Regarding the use cases, they cover the requirements as mapped in Table 27. Note that the non-functional requirements are not mapped because they do not represent any functionality as happens with the use cases.

Table 27 – Mapping between use cases and requirements

Use case Requirement

Gather data FR-1

Gather BMS data FR-1

Gather external data FR-1

Gather weather forecast FR-1

Represent info in a common data model FR-2

Store data FR-3

Generate monthly reports FR-4

Make use of prediction tools FR-5

Calculate the operation mode FR-6/8

Obtain minimum consumption with comfort assurance FR-6

Balance loads out FR-7

Actuate FR-8

Check the actuation FR-9/11

Perform corrective actions FR-9

Collect alarms FR-10

Switch manual/automatic modes FR-12

Self-train with previous data FR-13

Visualize data FR-14

Send user recommendations FR-15



Figure 4 – Use cases diagram

On the other hand, the sequence of actions for each use case needs to be explained. Appendix I collects several tables where each use case and sub-case is detailed. These tables describe the use case, the steps to perform the actions (usually there are multiple steps which are necessary), pre and post-conditions, exceptions that can occur during the procedure, frequency of execution and importance from the system point of view.

4.2 Control scenarios

In contrast to the software use cases, the control scenarios are high-level use cases which remark the control strategies to be followed. With them, the objectives of the actuation are established by means of a cost function that specifies the energy term to be maximized or minimized. Then, the BEMS has to implement some functionality that assures obtaining the result of such equation which is translated in components. Apart from that, the definition of control scenarios helps to follow a black-box approach because the controllers may be designed with the set-up inputs/outputs and the formula to be resolved. Additionally, some constraints must be taken into account. In the BRESAER project, the control will be rendered in the pre-heated air system and dynamic windows. Hence, there are two sub-chapters that gather the control scenarios for each solution, although, during task 5.2, these will be merged to overcome with a holistic solution.



4.2.1 Solar pre-heated air system

The first solution whose control scenarios are being detailed is the solar pre-heated air system which is used for heating purposes. This system will stand in for the boiler whenever possible, therefore, it will be the main one within the load balancing tool, only supported by the boiler when the heat is not enough for ensuring the end-user comfort. This control scenario is depicted in Table 28. Nevertheless, there exists a second functionality about the night cooling with the external air, which is described in Table 29.

Table 28 – Solar pre-heated air system control scenario 1

CONTROL SCENARIO 1

Name Winter thermal production

Description Thanks to the installation of SolarWall®, hot air can be generated. This pre-heated air can have different destinations and/or utilities: heat pumps, AHU, direct ventilation system, drying, water heating by exchanger, generate cold by adsorption and so on.

Operation: A few centimetres away from the southern wall (or walls facing southeast, southwest, east and west), the perforated collector panels are installed especially for creating an air cavity. Solar radiation heats the metal coating, while a fan creates a negative pressure in the air cavity, allowing heating air to take advantage of the solar energy through the perforations of the panels.

Existing system’s fans (e.g. air conditioners) are in charge of creating the required depression for correct operation. If the flow calculation is not available due to the pressure drop in pipe, then it is necessary to insert a compensation fan.

Typically, air is extracted from the top of the wall (since hot air rises), thereby ensuring that the entire generated solar heat is collected. Then, the hot air is conducted into the building through a socket connection with heating, ventilation, air conditioning facilities. The air entering the air conditioner has been heated in advance several degrees above room temperature. This value can vary between 16°C and 45°C, depending on configuration, design flows, radiation, etc.



Cost function

Objective Reducing consumption of energy from conventional energy sources and maximizing savings by producing thermal energy from the sun.

Cost function min (CostSolarThermal * UsesSolarThermal + Costboiler*Usesboiler)

Inputs and outputs

Inputs Inputs necessary for the proper management of the system:

Room temperature.

SolarWall® duct temperature probe.

SolarWall® duct flow.

Set-point temperature sensor system where hot air enters.

Entries not necessary but desirable:

Global radiation sensor.

Control opening bypass (on-off) or (% open) probe.

Outputs The system must perform control over:

Fan load compensator (optional).

By-pass damper (this flap can be all or nothing, while desirable proportional opening). The trapdoor will warm external air, similar or upper than the value of the set-point, which might be set up to the system security value.

Other parameters (to be set according to the final system installation).

Control variables

Control variable 1 On/off fan (optional).

Control variable 2 On/off by-pass damper.

Control variable # Possible new control variables depending on the final installation.

Constraints

Constraint 1 Maximum temperature: If the duct temperature is higher than the one reported by the conventional generator of the AHU values, then cooling is required or free-ventilation with external air.

Constraint 2 Minimum temperature: It is possible that sometimes the duct air is even lower than the environment (cooling effect). This case should be avoided when heating.

Table 29 – Solar pre-heated air system control scenario 2

CONTROL SCENARIO 2

Name Passive cooling air SOLARNIGHT

Description Thanks to the installation of SolarWall®, passive cooling might be used on a clear night. NightSolar® system provides use throughout the year with winter heating and summer cooling. NightSolar® uses most efficient and proven solar technology in order to take advantage of the night radiation to cool the rooms. During the day, the panel acts as spare on the building surface, reducing the heat load. Additionally, during the night, the celestial phenomenon of black body cooling might be used to cool with the aim of creating an air stream to be introduced into the building. This can reduce the size of cooling equipment and associated energy costs. Night radiation cools ceilings up to 10°C below ambient temperature on clear nights. It also has the ability to reduce or even displace conventional air conditioning from dusk until dawn. As the warm night air touches the cooler surface of the collector, which transfers its heat to the surface, the cooled air is then drawn through the perforated surface.



Cost function

Objective Reducing consumption of energy from conventional energy sources for cooling the building.

Cost function Min (CostSolarThermal * UsesSolarThermal + Costrefrigernate * Usesrefrigerante)

Inputs and outputs

Inputs Inputs necessary for the proper management of the system:

Room temperature probe.

SolarWall® duct temperature probe.

SolarWall® duct flow.

Set-point temperature sensor system where hot air enters.

Entries not necessary but desirable:

Global radiation sensor.

Control opening bypass (on-off) or (% open) probe.

Temperature probe inside the building.

Outputs The system must perform control over:

Load compensator fan.

By-pass damper (flap for building cooling pipe, see diagram above).

Other parameters (to be set according to the final installation).

Control variables

Control variable 1 On/off fan (optional).

Control variable 2 On/off by-pass damper.

Control variable # Possible new control variables depending on the final installation.

Constraints

Constraint 1 Maximum temperature: If the temperature of the air to be introduced is greater than the inner function, the mode is summer and air must not be injected.

Constraint 2 Minimum temperature: Set-point over which the cooling mode should be stopped.

In order to explain better the aforementioned control scenarios, Figure 5 represents the SolarWall® system.



Figure 5 – Operation scheme for the heating system

Two operational cases are distinguished:

Heating mode: If the duct temperature is upper than the external temperature, the by-pass should be closed so as to only allow the SolarWall® system that is the normal operational mode. In the case of the duct temperature is lower than external temperature, then, the by-pass is open, injecting external air instead of pre-heated air. Finally, if the indoor temperature exceeds a threshold (e.g. 2°C more than the set-point required by the user), then, the by-pass is open, without SolarWall® system for security issues (i.e. avoid heating in spring and/or summer).

Cooling mode: If the duct temperature is upper than external temperature, the by-pass is open so as to allow injecting external air. In the case of duct temperature is lower than external temperature, the by-pass is closed and the SolarWall® system is working. Last but not least, similar to before, if indoor temperature is below an established set-point, the by-pass is open for security reasons.

4.2.2 Dynamic windows

Second active solution is the dynamic windows whose goal is to design and install an active system which allows the entrance of sunlight to heat the rooms thanks to the solar gains. It is part of the balancing tools because the gains must be taken into account in order to balance the loads between this system, the pre-heated air one and, finally, the boiler of the building. Apart from that, the windows might be used for lighting, hence, the objective is twofold: heating/cooling and/or lighting. Then, similar to before, two control scenarios are required that is expressed in Table 30 and Table 31, including the inputs and outputs, as well as the constraints of the system and operation modes. This table is a valuable input for T5.2 where the control algorithms will be designed and developed.



Table 30 – Dynamic window control scenario 1

CONTROL SCENARIO 1

Name Blind control in REMOTE mode (temperature control)

Description The aim of the intelligent blind is to support the building for temperature control inside room.

minimizing/maximizing solar incident radiation performing the complete blind air sealing (at night)

Operating in REMOTE mode, the blind will be controlled by the BEMS. In this mode, the BEMS will be in charge of sending the Set-Point (SP) values to the blind, and the blind controller will move the blind to the set position. The Set-Points to be controlled will be:

Blind up-down position. The BEMS will send the Set-Point to move up and down the blind slats.

Slats angle. The BEMS will control the inclination angle of the slats Blind Lock (total air sealing). The BEMS will send true or false to lock the

blind so as to avoid thermal losses.

Cost function

Objective Minimize the energy needs for increasing/decreasing/maintaining the room temperature.

Cost function Min (Costroom heating or Costroom cooling)

Inputs and Output

Inputs From blind controller: CV (Current Value) of blind up-down position CV of blind slats angle.

From monitoring system: Room Luminosity (inside room) Room Temperature (inside room) Room Occupancy (inside room) Outdoor luminosity (roof sensor)

Output Blind optimal configuration (LonWorks signal)

Control variables

Control variable 1 Blind up-down position

Control variable 2 Blind slats angle

Control variable 3 On/Off lock blind (total air sealing at night)

Constraints

Constraint 1 During the day, when there is natural light outside, a minimum of external light have to enter to the room, even if this is not optimal for temperature maintenance. The reason for this constraint is the comfort sensation produced when user can see outside the room. In this case, the blind slats could neither be completely closed or air sealed. This minimum light level has to be determined.

Constraint 2 When the blind is in lock mode (air sealed) it is not possible to actuate.

Constraint 3 The blind position has to avoid dazzle effect on people.

Constraint 4 The temperature control by means of the smart blind has to be done according to its operation for lighting control. BEMS must decide whether lightning or temperature action has priority over each other and/or to weigh its action control



Table 31 – Dynamic window control scenario 2

CONTROL SCENARIO 2

Name Blind control in REMOTE mode for lighting control.

Description The aim of the intelligent blind is to support the building for light level control inside rooms. The blind will help to modify/keep room light level by:

minimizing/maximizing exterior light penetration Operating in REMOTE mode, the blind will be controlled by the BEMS. In this mode, the BEMS will be in charge of sending the Set-Point (SP) values to the blind, and the blind controller will move the blind to the set position. The Set-Points to be controlled will be:

Blind up-down position. The BEMS will send the Set-Point to move up and down the blind slats.

Slats angle. The BEMS will control the inclination angle of the slats

Cost function

Objective Minimize the energy needs for increasing/decreasing/maintain the room illumination level minimizing the energy needs for artificial lighting.

Cost function Min (Costroom lighting)

Inputs and Output

Inputs From blind controller: CV (Current Value) of blind up-down position CV of blind slats angle.

From monitoring system: Room Luminosity (inside room) Room Temperature (inside room) Room Occupancy (inside room) Outdoor luminosity (roof sensor)

Output Blind optimal configuration (LonWorks signal)

Control variables

Control variable 1 Blind up-down position set-point

Control variable 2 Blind slats angle

Control variable 3 On/Off lock blind (total air sealing at night)

Constraints

Constraint 1 When the blind is in locking mode (air sealed) it is not possible to actuate over any other Set-Point.

Constraint 2 The blind position has to avoid dazzle effect on people.

Constraint 3 The light level control, by means of the smart blind, has to be done according to its operation for room temperature control. BEMS must decide whether lightning or temperature action has priority over each other and/or to weigh its action control.



5 BEMS design

After the requirements and analysis, taking the results as input, the design takes over and extends the analysis to determine the system architecture and the communication details [6]. This is the last step just before the code implementation. Hence, being an object-oriented development, the architecture, components, class and sequence diagrams ought to be expressed so as to fulfill the requirements, both functional and non-functional. This design considers an ideal model and environment [6]. That is why updates from the design could come during the implementation which will be documented in the proper deliverable, if any.

5.1 System architecture

The high-level architecture represents the multiple layers which are composed any software application. It is common to represent the levels according to the abstraction level. Hence, low layers are related to the physical environment, being the upper levers the ones that depict the intelligence of the system. The, Figure 6 illustrates this architecture which is pretty much similar to the concept diagram with the difference that all the previous ideas are organized into a multi-layer system that covers the specifications.

Figure 6 – High level architecture

Firstly, from bottom, the data acquisition layer represents the physical concept where the Building Monitoring System (BMS or sensor network), WP3 active solutions (i.e. pre-heated air and dynamic windows), weather forecast services for prediction and there exist the open possibility to integrate other external sources (e.g. access control systems). However, all these data sources do not speak the same language at all, but they are compliant with different protocols, whose communication is set up by the drivers. Hence, the integration layer (IL) appears so as to gather the information from the data acquisition layer and homogenize all the data samples in the same data model. As already stated, the advantage is that eases the communication in the high-level services without the need of adding a level of complexity to interpret data. Next, business layer



(BL) is the responsible for the management of the BEMS itself. That is to say, it is in charge of the engine of the BEMS (i.e. dispatch of signals, scheduled tasks, communicate the entities for the proper behavior of the system…). Upper level represents the service layer (SL) which, as the name indicates, contains the high-level services where the intelligence and control algorithms are developed, as well as the graphical user interface (GUI). Last but not least, there is an additional parallel layer, named Data Access Object (DAO) that renders the communication between the platform and database. It is, in fact, a sub-layer to map the objects world and the relational databases, which benefits programmers when convert both environments.

5.2 Components design

Once the architecture is designed, one step forward is the detail of the components which will implement the functionalities within each layer and their communication procedure (i.e. interfaces). Thus, next section will go through these details.

5.2.1 Entities diagram

Usually, each layer in the high-level architecture needs to be split into several components which, by means

by means of the interaction among them, perform the use cases’ functionalities. This modular design helps

design helps developers to reduce the complexity of the entities and increases the scalability/extensibility

scalability/extensibility because each component is highlighted to cover specific and simpler functions. Thus,

functions. Thus, Figure 7 divides the layers in components to carry out particular functionalities which are

part of more sophisticated use cases, but they are necessary to ensure the proper completion of the

operation. In this way, Figure 7 prints the high-level architecture, but each layer already contains the

components. The implementation of these entities assures to cover the expected functionalities from the

definition of the requirements. To double check it,

Table 32 maps the components with the use cases. As observed, the mapping is one-to-one in some cases (i.e. one component implements one use case), one-to-many (i.e. one component takes part in different use cases as, for instance, the scheduler) in other and, finally, many-to-one (i.e. several components are needed to fulfil a single use case due to its complexity).



Basically, the designed components cover simpler functionalities. In the IL, the main entities cover the drivers, for the communication with the sensor network, active solutions (which are compliant with LonWorks too) and the forecast services, integrator and translator with the aim of merging signals in an unique one compliant with the data model and, finally, the supervisor to check the actuations. Regarding BL, there is a calculator to obtain aggregated data (e.g. KPIs), a signal manager to dispatch communication signals, communicator to connect external tools, alarm manager which handles internal alarms, data model that contains the classes representing this data model and the schedulers which is able to run periodic tasks. Last but not least, the SL integrates the GUI (Graphical User Interface), the control module which executes the control algorithms, switch to detect manual or automatic modes, self-trainer that learns from previous data and experiences, predictor to get predicted values as input of the control module and the reports which automatically generate the monthly reports.



Figure 7 – Components diagram



Table 32 – Mapping use cases and components

Component Use case Description

LONDriver Gather data Gather BMS data Gather external data Actuate

Driver for communicating every LonWorks systems (i.e. sensor network and active solutions), both for reading and writing signals in the physical environment.

ForecastDriver Gather weather forecast This driver collects information from HTTP services.

Integrator Gather data Represent info in a common data model

Integrator merges signals from different sources in a single one and harmonized in the data model.

Translator Represent info in a common data model

It is the responsible for translating the physical signals into the data model.

Supervisor Check the actuation Perform corrective actions

This component checks that the actuation has been properly carried out. If not, the supervisor comes back to the previous status.

Calculator Obtain minimum consumption with comfort assurance

It calculates aggregated data and KPIs, including comfort and energy consumption.

SignalManager All It is the engine of the platform in order to handle and dispatch all the internal signals.

Communicator Make use of prediction tools This communicator is in charge of connecting external tools such as prediction tools.

DataModel Represent info in a common data model

This component contains the classes that represent the data model.

Schedulers Gather data Generate monthly reports Calculate the operation mode

The scheduler affects multiple use cases because the idea is to periodically launch some operations or tasks.

DatabaseCommunicator Store data All the communication with the database is made by means of this component.

GUI Visualize data Graphical User Interface itself.

ControlModule Balance loads out Calculate the operation mode

This module is the biggest one because it contains the control algorithms and calculates the best operation mode.

Switch Switch manual / automatic modes

It enables/disables the operation modes.

Self-trainer Self-train with previous data Send user recommendations

One of the functionalities is to learn from the past, then, this component self-trains from previous data. As well, it sends recommendations according to the acquired knowledge from these data.

Predictor Make use of prediction tools Predictor is the entity that collects results from the prediction tools, as well as forecast to obtain the predicted value.

Reports Generate monthly reports As the name says, it generates reports from stored data and user information.

AlarmManager Collect alarms Alarms indicate wrong behaviour of the system and this manager handles these alarms.



5.2.2 Interfaces definition

Once the architecture and the components which make up the global system are explained, it is time to communicate one to each other. Then, how to perform this connectivity is the question to be answered and that is named interface. In short, the interface is the boundary between components which allow each other to access a set of resources. In the BRESAER approach, there exist a couple of interface types: internal and external. The first group are those used for the inter-relationship of the BEMS components. On the other hand, external interfaces are those connecting the BEMS and external tools, such as happens with the predictions tools.

5.2.2.1 Internal interfaces

As described above, the internal interfaces are those used for the internal communication of the components. These are deployed in the form of the so-called bundles which need to exchange information in order to complete any operation. As the BEMS will be deployed under the OSGi umbrella, the already-established mechanisms [11] are made use of. Basically, these share events where the sender is called “Event Publisher”, meanwhile the listener or receiver is the “Subscriber”, such as drawn in Figure 8.

Figure 8 – OSGi event mechanism

The essence of this procedure is based on the issue of events with a set of internal properties which might include request parameters or the result itself. Then, the Publisher is able to send or post (the difference between them is the synchronization) a message, which is caught by the internal Event Admin object of the OSGi container and this dispatches the event to the Subscriber that listens to such event. As said, the events can be synchronous (sendEvent method) or asynchronous (postEvent method). The main difference is how the Admin manages them. In the first case, EventAdmin service looks for all the handlers subscribed to the topic and notifies each one in turn. In contrast to this process, when posting, all the subscribers are notified at the same time without mattering when the handlers will receive and process the event [11]. It is important to remark the handlers that have been mentioned. Each component must implement the interface EventHandler provided by the OSGi environment. The implementation class is thus responsible to register and manage the event in the proper way, executing the actions according to the topic and properties. These two last characteristics define the event (i.e. topic and properties). The first one determines the name, whereas, the properties can vary in number, but they always follow the pair key-value concept where the key is the name of the property and



the value is the assigned value for it (for example, a number, a string, etc.) [9]. Nevertheless, there is no standard topology to name the event topics. Hence, BRESAER will determine its own language or “ontology” so as to facilitate the handling of events. In this case, next bullet gives the convention for the topics. First of all, any event starts with the “bresaer” keyword that indicates the events associated to the project, therefore, any other event is directly discarded. Secondly, the name of the receiver component is set. Third part is the operation which could be request, response, error, etc. Finally, the function, which is related to the use case or functionality to be performed, is needed. For instance, a request of BMS data would follow an event as “bresaer/LONDriver/request/gatherBMSData”. The complete event list is included in Appendix II.

bresaer/receiver_component/operation/function

5.2.2.2 External interfaces

Regarding external interfaces, these represent the communication with external entities, such as weather forecast services that are available on Web Services. The challenge in this case is the variability in the types of connectivity. However, in the BRESAER project, these difficulties are reduced because the number of external data sources is limited. In particular, the external sources in the current BEMS are the next ones:

BMS network that is LonWorks compliant. It is important to mention here that the existing facilities (i.e. boiler) are adapted to this protocol by means of input/output modules.

WP3 active solutions which are also LonWorks compliant.

Weather forecast whose communication is available through Web services, concretely HTTP request/response mechanism based on XML format.

External tools like simulation tools (TRNSYS [8] or E+) or Matlab [7] are connected to the BEMS making use of Java remote procedure calls.

Database system which is SQL-based and the Hibernate framework will be used to translate the object world into relational one.

Starting with the BMS network and WP3 active solutions communication, as stated, both cases are LonWorks compliant. Nevertheless, they are independent and should be merged in a single network, as well as the existing facilities as, for instance, the boiler. All the related variables to these systems must be read and, in some cases, even written for applying the proper control commands. Then, the already-LonWorks-compliant devices are connected to the backbone of the monitoring network (see D6.1 [4]), meanwhile the universal signals are connected through input/output modules that allow gathering the signals from conventional sensors. As before, these modules are connected to the backbone too. Thus, the network interface, namely iLON in D6.1 [4], is able to read and write all these signals. Furthermore, iLON offers a Web Service interface, based on SOAP, in order to remotely exchange information with the network. Apart from that, there exists a FTP (File Transfer Protocol) interface so as to collect backup files. Both communication procedures will be locally managed because the data collector and the iLON will be in the same IP segment, therefore, using internal IP addresses. In summary, Table 33 reflects this information.

Table 33 – LonWorks interface

Service Protocol Message format IP address Port

Main collector SOAP XML-based 88.247.28.90 5274

Backup service FTP CSV files 88.247.28.90 21



Next, weather forecast is a Web Service available on Internet free accessible. These weather forecast services are required in order to perform prediction tasks. There exist several services over the Internet, but Weather Underground [16] has been selected due to its characteristics. First of all, it offers a free interface (or API), although the number of calls is limited for every day. However, this amount is not exceeded under the normal operation of the BEMS. Moreover, it provides all the main weather data points like temperature, relative humidity or dew point, sea level pressure, visibility, wind direction and velocity, precipitations, etc. Moreover, Weather Underground provides several plans, depending on the level of data. For the BRESAER project, the most detailed plan (‘Anvil’ for developers) has been chosen, that permits 500 calls per day and 10 per minute and the included features are [16]:

Geolookup

Autocomplete

Current conditions

3-day forecast summary

Astronomy

Almanac for today

10-day forecast summary

Hourly 36-hours forecast

Satellite thumbnail

Dynamic Radar image

Severe alerts

Tides and Currents

Tides and Currents Raw

Hourly 10-day forecast

Yesterday's weather summary

Travel Planner

Webcams thumbnails

Dynamic animated Radar image

Dynamic animated Satellite image

Current Tropical Storms

All of these characteristics are not going to be used in the BRESAER project, but the connector is able to boil down the proper ones and this more advanced plan allows testing the different collection data streams. Besides that, a couple of formats are available (i.e. JSON and XML), although the envisaged one is XML because the easiest management of data through Java libraries. Then, with the suitable HTTP calls and the XML responses, the weather forecast may be handled in the BEMS. Of course, the BEMS also translated the XML data into the data model to make use of generic data structures. Finally, the link to access weather underground is:

38.102.136.138/api/589b8db8e353dea3/hourly/q/Turkey/Ankara.xml

Apart from these data sources, there is an additional one and, perhaps, the most important one that is the database. In this case, the database is PostgreSQL-based and it will follow the same structure than the data model which is explained below. The idea behind is to directly map the Java objects into tables of the database which eases the development of the communication. In



this regard, the mapping will be rendered through the Hibernate [13] framework that is an environment which automatically translates the object world into the relational world. Therefore, a developer does not need to take care of SQL (Structured Query Language) because Hibernate makes it by itself. Thus, by using the Hibernate libraries and the suitable methods, the framework converts the Java function into the SQL query in order to get or set data. Furthermore, Hibernate is database engine independent. That means Hibernate is able to work with several database vendors such as PostsgreSQL, Oracle or MySQL, among others. The environment is configured in an XML file where the properties of the connection are marked, as well as the dialect of the database. Thus, Table 34 summarises the properties which should be included in such configuration file. It is important to remark the database will be deployed in the same computer than the BEMS and that is why the IP address to be used is localhost. On the other hand, for security issues, the password of the database is not determined so as to avoid external accesses.

Table 34 – Database connection properties

IP address Port DB Name User Dialect Driver

localhost 5432 bresaer bresaer org.hibernate.dialect.PostgreSQLDialect org.postgresql.Driver

Last but not least, there exist external tools that need to be interconnected with the BEMS in order to perform the control strategies and prediction tasks. In the first case, it is still not decided whether Matlab [7] will be used as external tool or Java libraries would be enough. During T5.2, when designing the control algorithms, the final decision will be made, therefore, if necessary, the interface will be detailed in deliverable D5.2. However, as first approach, communication between Java and Matlab [7] is easily implemented by means of remote calls, although the parametrization has to be included too. Secondly, prediction tools are required because they, together weather forecast, allow to estimate the energy demand in the future. With this aim, TRNSYS [8] is foreseen to contain the building model and energy facilities so as to run a simulation under certain conditions. Similar to Matlab case, the communication will be rendered by a remote call to the TRNSYS engine from Java code [8]. Nevertheless, it is necessary to provide parameters for the simulation, as well as collect the results. The schema for this communication is highlighted in Figure 9. With this aim, a set of TRNSYS types [8] will be used as follows:

Data readers TXT-based files input separated in columns whose values will be defined within the task T5.2 where the control algorithms and simulation strategies will be developed.

Data outputs TRNSYS offers some types to write the outputs in a well-defined format which may be read by the software tool to get the specific values.



Figure 9 – TRNSYS communication procedure

5.2.3 Class diagrams

Any software engineering requires a structure or skeleton of the future code, which is known as class diagram. It represents a static structure of the component by showing a set of classes, the attributes of the class, its operations and relationship among objects [6]. Then, the diagram is a conceptual model which is translated into code. In the representation, one class maps a physical or abstract object with the associated attributes that qualify the object and the methods which are the operations that the object can perform. Furthermore, the relationships between objects are drawn in these diagrams which indicate some type of interaction among them. There are multiple possibilities, but they are out of the scope of the deliverable. These may be looked up in any UML (methodology used in BRESAER) reference, such as [6]. Within the design, the class diagram for each one of the components has been realized. Nevertheless, as there are many pictures, they have been moved to the Appendix III. One last comment is the possibility of updates in the upcoming tasks when the control algorithms would be designed, as well as the development. Any modification with regard to this deliverable will be documented in the deliverables of these tasks. The reason of the updates is because the design has followed an iterative-incremental methodology, such as CMMI [17] establishes. CMMI is a quality procedure for software engineering followed around the world and gives guidelines to software analysts about how to proceed to ensure high-quality designs. Thus, in spite of having rendered several iterations, additional ones should be done when developing code so as to receive the feedback from developers and keep the design up-to-date.

5.2.4 Sequence diagrams

Finally, the last step in the components design is the realization of the sequence diagrams which are also named interaction diagrams because they represent the communication flow between objects to obtain a result [6]. Commonly, they are used in big class diagrams with several objects interacting among them. However, in the BRESAER case, as the design is modular, the complexity of the components is reduced. Therefore, instead of representing the interaction among objects, in this case, it is printed the communication between components to cover the use cases. Each interaction is performed with a message that, in BRESAER, is an event. In summary, the picture shows how to achieve a single use case or a combination of them by means of exchanging events among the components. The sequence diagrams for the use cases are included in the Appendix IV. As stated before, the sequence diagrams could be modified during the WP5 duration when implementing or designing the control operation.



5.2.5 Graphical User Interface

The Graphical User Interface (GUI) is an added value feature of any BEMS and, although, it is not critical, it involves the end-user in the energy savings procedure. Yet, GUI does not only provide more awareness to the end-user, but it also integrates the monitoring and reporting issues that any BEMS should cover. Apart from this basic information, additional data are managed within the GUI from the configuration and maintenance point of view, such as alarms or Energy Performance Indicators (EPI). That is why the access needs to be protected and, as remarked in the requirements, four levels have been defined:

Administrator: It basically accesses to the monitoring screen, alarms and configuration screens where this last one is focused on the management of users.

Technical user: It is envisaged that this role comes from the project and knows the technical issues. Then, it is additionally able to access the EPI results and download data. Moreover, about the configuration, this user manages the scheduled tasks of the system and energy prices for the evaluation of KPIs.

Owner: This user is the most interested in the energy results, therefore, its main outcome is the visualization of the results and alarms about what was wrong in the building.

External user: Last but not least, the BEMS allows the access to external users whose privileges are reduced to the monitoring screen.

In summary, the different levels of accessibility to the GUI are drawn in the navigation flow in Figure 10, which represents how the different screens are communication among them.

Figure 10 – Navigation flow

As it is observed in the navigation flow, after the user login, different level of users are envisaged, depending on the privileges. However, all of them enter into the monitoring screen which is similar as highlighted in Figure 11. The difference lies in the additional services accessibility that is available in the tabs. The content is based on graphical trends which represent the variables associated to the devices selected in the menu.



(a)

(b)

(c)

(d)

Figure 11 – Monitoring screens for the (a) admin, (b) technical, (c) owner and (d) external users

First of all, between the administrator and the technical user, there is a common screen, namely “Alarms” and illustrated in Figure 12. The visualization basically consists on a list of the launched alarms that are classified in different topics: Indoor Environmental Quality (IEQ), energy, costs and security. In the right part of the figure, there is an example of the alarms generated by low temperature comfort values and whether the alarm has been repaired.

Figure 12 – Alarms screen

Secondly, there is an additional common service between these users, the configuration. However, in this case, the properties to be established differ from the administrator to the



technical user. In the first case, the administrator is able to list, add and remove users with one of the aforementioned four roles, as shown in Figure 13. In contrast, the technical user is responsible for the schedulers (i.e. periodic operations of the BEMS), prices of the energy sources and the devices deployed in the monitoring platform because additional monitoring sensors could be added, as in the example of Figure 14.

Figure 13 – Configuration screen for the administrator



Figure 14 – Configuration screens for the technical user

Last but not least, the technical user and owner dispose another service related to the Key Performance Indicators (KPIs) calculated in the system to evaluate the energy performance. On one hand, the technical user is the one who interprets the results in order to determine whether the system behavior is being as expected. On the other hand, the owner is the user most interested in the performance of the building. Therefore, accessing this service as depicted in Figure 15, the performance of the building may be displayed in a single view. In that sense, despite being a “passive” involvement, the end-user enters into the loop of the renovation project from the BEMS point of view.

Figure 15 – KPIs screen



6 Data model

As it has been pointed out, the BRESAER BEMS is based on a common data model which represents the information from the different data sources. In this way, all the components may communicate each other in the same language that avoids intermediate translations in order to fulfil the expected message in a different entity. Additionally, making use of a data model homogenizes information signals and that is why an integration layer. Besides these advantages, the data model is also helpful for databases. In this topic, the database is deployed according to the data model. That is to say, the database tables are represented, one-to-one, by the data model objects. The benefit of this approach is the handling of persistent storage system and the BEMS itself. By using frameworks such as Hibernate, the relational database can be managed as Java objects increasing the abstraction level. Then, it is not required to know the relationships between tables, but only creating mapping between tables and classes, which is already performed through the data model. The elaboration of a data model is often a complex task, not only when data are numerous and varied, but also because of the different views that can be chosen to analyse the role played by these data in the related business processes, and to structure them accordingly. The methodology chosen by the BRESAER consortium to elaborate the so-called BRESAER Data Model followed a bottom-up approach, starting from the description of specific parts (sub-models) and merging the produced sub-models into a holistic and consistent model. This allowed every partner to contribute to the elaboration of the Data Model, by assigning them the responsibility of one or several sub-models corresponding to their area(s) of expertise. More precisely, the methodology comprised 4 four steps:

Categorization of data: several categories of data have been identified, by referring to the corresponding more or less to a specific functional view of the system.

Modelling of data in each category: this was achieved by following the UML entity diagram approach, complemented by a description of entities and relationships following a common template in a tabular form.

Analysis of the state-of-the-art, including: o Review of ongoing R&D projects on ICT4EE in Buildings with a focus on data

modelling: this was achieved by filling a template that makes easier the comparison between the different approaches chosen by the projects.

o Analysis of relevant standards in the Building domain: especially the IAI/IFC [7] and gbXML [10] standards.

Merging produced sub-models in a global BRESAER Data Model, which implies identification of common concepts and possible inconsistencies.

The result of this process is depicted in Figure 16 where the data model is printed. It is also important to note that these objects are mapped into Java classes which compose the “DataModel” component.



Figure 16 – Data model schema



As it is observed, the data model is comprised in several entities divided into categories (explained below) and related to each other to fulfil with the relationships (i.e. foreign keys in database terminology). The details of each table are contained in Appendix V.

6.1 Data categorization

This section describes the different kinds of data to be stored in the BRESAER database, 6 main data categories have been identified as shown in Table 35, each one corresponding to a specific functional view of the system.

Table 35 – Data model categories

Abbr. Data Category Content

ENV Environmental and contextual data

• Location, climate zone, shadowing, building orientation, etc. • Weather data, energy prices, etc.

BIM Energy-focused BIM (Building Information Model)

• Space organisation / Envelope & partition (characteristics) • Home equipment (appliances, generators, storages…) (location,

type, characteristics…)

USR User preferences • Usage profile, definition of scenes, including comfort set-points and

use of appliances • Control rules and energy strategy

SCH Resources scheduling • Scheduling of resources

ADV Advices • Orders, and associated advices, created as a result of an event,

usually associated to an action of the user and some other actions suggested by the system

EPI Energy performance indicators

• Log of consumptions • Performance indicators

It should be noted that the above-defined categories do not constitute disjointed sub-sets of data. Indeed the same data can belong to more than one functional view. Nevertheless, this bottom-up approach allows dividing the complex modelling work into more elementary tasks. In the following sections the details of each category are described.

6.1.1 Environmental model

The Environment diagram describes the data model used to represent the environment of the building, which includes its physical environment and its relation with this environment (location, orientation, shades…), the local climate and, the economic environment (energy prices). For this latter information, the model focuses on forecast data (for weather or energy price). The model also includes the main characteristics of the external online resources able to provide the requested information. The main entities described in the diagram are:

WeatherForecast: This entity acts as a container that collects the hourly evolution of weather parameters during a certain period of time.

DayAheadPrices: This entity is similar to the previous one, but for energy prices. Different types of energy may be considered in the PrimaryEnergySource entity. Prices also depend on the type of contract concluded with the energy supplier. In a multi-dwelling building, it



is assumed that a specific contract (per each used energy type) may be concluded for each dwelling, as well as for the common building areas.

6.1.2 BIM model

The BIM model describes the data model used to represent the building physics (building spaces, building structure….) and the equipment deployed in the building. BIM model is an implementation of the IFC4 reference accommodated to BRESAER project requirements. To facilitate the reading, this part has been decomposed in different entity diagrams:

Building: The first one is related to the building spaces organisation, including the definition of homogeneous thermal zones.

BuildingElements: BuildingElements model describes the façade and other enclosure elements that contribute to give from to different building partitions.

BuildingEquipment: BuildingEquipent model describes all the equipment type that may be found at building level including from simple sensors to complex HVAC devices.

6.1.3 User preferences model

The User Preferences diagram explains the data model used to represent the daily planning of the building usage by the end-users. It comprises the definition of daily usage profiles at level of building zones, each profile describing the sequence of scenes (e.g. dinner), the loads involved, and the comfort set-points (temperature, luminosity…). In addition, the model also includes the user choice of the energy strategy (possibly for each day), and of the control rules associated to devices. The main entities described in the diagram are:

BuildingPlanning: This entity allows defining different profiles for the daily usage of a zone (in case of a multi-dwelling building this is either a dwelling or a common building area).

Scene: This entity allows defining usage scenarios, i.e. specific usages of the building, in terms of comfort set-points and appliances usage.

6.1.4 Resources scheduling model

The Scheduling diagram points the data model used by the system to represent the daily planning of the usage of the resources of the building. Then it includes in detail the overall building energy usage planning, as well as the individual use of each resource. The main entities described in this diagram are:

ProgrammedSchedule: This entity represents the daily schedule of resources usage within a building. It includes a set of resource schedules.

ResourceSchedule: This entity allows the representation of the power consumption/generation of the devices that exist within the building. The specialization of the entity into load, generation and storage is also described, as well as a more detailed specialization for devices that have to be scheduled in switching actions or certain property evolution values. This schedule holds a link with a corresponding device and the operating details of it.



6.1.5 Advices model

The Advices diagram contains the data model used by the system to represent the advices given to the user about ways to improve the energy efficiency of the building. The main entities described in the diagram are:

Order: This entity allows the representation of the advice into orders that should be executed by the actuators if the users are willing to follow the advice.

Advice: This entity stores a notification delivered to UI interfaces displayed to the User.

6.1.6 Energy performance model

The performance diagram describes the data model to represent the control devices together with their link with the equipment they operate upon, as well as details of the operation of the control devices, represented by logged data about their operation. The daily measurements to be displayed to the user are also described in this diagram. The main entities in this diagram are:

DataLog: This entity stores the details of the operation of sensors and actuators. MeasurementLog: This entity holds the daily detailed energy consumption/generation of a

specific meter. This log of measurements can belong to the physical building or to a reference one that is used for comparison purposes.



7 Technologies envisaged

This section summarises the technologies to be used in the development of the BEMS which are integrated to each other and benefit the proper behaviour and performance of the final platform. First of all, it is important to note that the fundamental technology is Java that is an object-oriented programming language widely used in the software world. Nevertheless, it does not make sense to extend the Java description because the documentation is wide on Internet. What is really important is to remark that the development is a Service-Oriented Architecture (SOA). That means the functionalities are implemented through simple services which talk to each other so as to complete a more complex function. Within this context, OSGi [11] is a framework which enables modular assembly under the Java umbrella. Some of the greatest advantages of OSGi are summarised in the next bullets, although more features are available on [11].

Interoperability: The framework allows communication among a broad variety of devices, application and devices.

Remote management: The OSGi distributed services offer the possibility to deploy services in different locations, as well as the access remotely to these services.

Reduced complexity: Thanks to the modularity, the complexity of the development of each component is reduced because they code simple functionality and the complex one is achieved by means of the communication among them.

Reuse: Any module can be reused in another OSGi environment.

A complementary framework of OSGi is Spring Dynamic Modules [12] which is a wide framework with a lot of characteristics (full-stack Java application framework). This offers a dynamic application execution environment in which modules (bundles) can be installed, updated, or removed on the fly. Apart from that, the great advantage of Spring Dynamic Modules that is being exploited in the BRESAER context is the service abstraction though the dependency injection. This feature allows setting the reference to other beans (Java objects) without the need of creating the new object in the software module. Instead, Spring makes this reference transparent to the developer with a single XML file and, then, the environment is able to get the object and inject the dependency. That is very useful to ensure that all the components use the same Event Admin interface from the OSGi framework.

Therefore, all the components will run in the OSGi environment under Spring Dynamic Modules. However, external sources need to be connected too. One of them is the database, whose communication will be rendered with the aid of Hibernate [13]. That is an implementation of the Java Persistence API (JPA) or the so-called DAO in BRESAER. Then, it is easily integrated into the OSGi environment. The great benefit (and the reason why Hibernate is used) is the capability of mapping the relational and object worlds. Through the use of simple Plain Old Java Objects (POJO), Hibernate is able to transfer information in a bidirectional manner. Moreover, Hibernate is in charge of maintaining the JBDC sessions and transforming the persistent objects into SQL queries. Finally, it also increases the abstraction level because, with the help of configuration files, various database providers and languages might be used without modifying the code. There are other advantages why Hibernate is helpful in BRESAER, but the main ones have been summarised. To go more in detail, the documentation is available on [13].



Additional data sources ought to be connected with the BEMS, although all of them do not require any external framework, but they are Java-based. The most important is the BMS which is LonWorks compliant [4]. However, the network interface provides the Java libraries to access the information through Web Services (SOAP - Simple Object Access Protocol). Thus, the functionalities for reading and writing values are available. Secondly, the weather forecast requests are performed via HTTP, whose communication is also offered by the exiting Java libraries in the default installation. As well, the response is XML format, but Java provides the XML parser libraries too. Finally, the external tools, such as TRNSYS [8] and/or Matlab [7], can be executed with remote procedure calls where Java gives the control to any of these tools which return the control to Java when finish, including the execution results.

An added value of the BRESAER BEMS is the Graphical User Interface (GUI) that will be developed with the GWT (Google Web Toolkit) libraries [14]. GWT is a development toolkit to simplify the complex browser applications. It is open-source software that allows developing Java code which is translated into Ajax, JavaScript and XML code running in the browser. It is important to mention here that GWT follows the client-server approach where the client code is only downloaded first time in the browser, whereas the server contains the intelligence of the Web site. Therefore, the client is softer than other Web-based applications. In fact, GWT does not allow the use of all the default Java packages.

Finally, the technologies, bundles and components must be integrated. With this aim, Equinox [15] has been selected as server container. Equinox is, in fact, an OSGi core framework specification that already includes a set of core bundles with the main OSGi functionalities. Besides, Equinox offers Web server libraries (e.g. jetty), as well as the possibility of integrating it into the Eclipse environment which is used at implementation phase. Hence, debugging applications is easier.



8 Test environment

In any software development, one of the most important parts is the test phase where the functionalities need to be validated. There are several steps in the tests: unitary, integration and performance [6] which are more detailed below.

8.1 Unitary tests

First of all, the unitary test refers the checking of code modules. In particular, within the BRESAER project, unitary tests cover each individual component. In that sense, the objective of these tests is to validate the developed code by the developer. The advantages of this phase of testing are:

Changes on-the-fly: Unitary tests allow the developer to modify the code quickly when an error or exception is found. This fixes some bugs in an easy manner.

Simplify the integration: The correction of the first bugs in the code eases the integration of the modules because the number of errors has already been reduced.

Documentation: During tests, it is common to document the code so as to detect which errors appeared and how they were solved, then, the documentation is improved.

Modularity: This test phase promotes the modification of parts of the code in order to split the interface and the functionality itself.

This document does not present a test plan as usual, but the unitary tests will be basically to run each of the components individually by means of dummy modules that simulate the behaviour of another element. In this way, the dummy component is in charge of sending the inputs to the component, as well as simulating the delivery of the event (note that the communication is based on OSGi events). Then, the unit test plan will be the development of a dummy element and one test will be run for each one of the functionalities of the specific component. In this way, once implemented, i.e. output of the T5.3, one table similar to Table 36 should be filled where each test contains a number, name, description, the sent inputs for running the test, the received outputs from the component and the success criteria, which is assessed true whether the output is the expected one or false otherwise.

Table 36 – Example of unitary test

Test # Name Description Input Output Success

#1 Data reading

The test runs the reading of data from the monitoring network.

-- List with the values

True

8.2 Integration tests

Second step is the integration tests. Once the components are individually working and running without errors, they should be combined to perform any of the BEMS functionalities. The intention of the integration tests is to verify the functional requirements that usually require the interaction among multiple elements of the platform. Normally, the integration tests are based on “test cases”, but, in our approach, these are exactly the same than the use cases described above. Therefore, the test plan at this level lies in deploying the component in a common container,



listing the use cases and running a dummy “starter” whose function is to begin a transaction from the end-user point of view or executing a timer for periodic operations. Then, the total amount of integration test is the same than the defined use cases. Similar to the unitary test, the success of the integration test will be documented in T5.3 and the way to do so is following the example in Table 37 where the success criteria is the well-established in the use case tables (see Appendix I).

Table 37 – Example of integration test

Use case # Description Input Output Success

#1 The test runs the reading of data from the monitoring network until the storage into the system.

-- Data in the database

True

There are several approaches in these tests, such as bottom-up or top-down. However, the set-up in BRESAER is the named “sandwich” approach which is a combination of the aforementioned methodologies [6]. It basically runs end-to-end operations where all the modules have the same weight, meanwhile the other two approaches consider low or high level components first. It is important to highlight that the failed tests require a re-code of the instructions in order to solve the issues. In these cases, the document must contain a log record indicating how the exceptions were resolved and when. That is also applicable in the unitary tests.

8.3 Performance tests

Last but not least, the last step in the test procedure is to determine the performance of the system. Until now, the components have been individually verified and improved, as well as the interaction among them to cover the functionalities. In contrast, performance does not mean functionality, but responsiveness and stability under a particular workload. The result is the quality of the platform such as scalability, reliability and resource usage [6]. Within BRESAER, the tests to be rendered are remarked in

Table 38 – Performance tests

Test # Type Description Parameters Success criteria

#1 Load The test will run under concurrent request of data from different sources.

10 requests per minute

No block

#2 Stress The test will run under high payloads to measure the capacity of the system to give a response.

Max payload No block

#3 Spike The test increases the payload under multiple requests measuring the response time.

Payload < 5 sec

#4 Availability This test tries to keep the BEMS running without locks during one week.

Normal operation

24/7

#5 Response time

The tests will run several requests with different payloads and the measure is the time to get the info ready from

the end-user perspective.

Normal operation

< 2 sec



9 Conclusions

This document has served to initialize the works to develop the BEMS, from the conceptual elements to the final guidelines to develop the software that composes the BEMS system. The coverage of info has included:

The definition of the BEMS in the BRESAER project, the constraints, goals and requirements

of the upcoming element. From the initial definition, the basic functionalities have been

extracted and described, and used afterwards in combination with the project features to

select the requirements to fulfil.

The environment and the cases to be covered by the BEMS. The functionalities necessary

to implement the BEMS inside the BRESAER should fit into these environments and cases.

The definition of the software structure. This way, the document works as a guide for

programming the different elements composing the BEMS system.

The data structures and types to interchange information. Combining the needs and

requirements from the designers of the different devices inside BRESAER solution, the data

formats have been defined to facilitate the communication between the different

elements of the solution.

The tools needed to program the BEMS and its components, and for the comprehensive

and ordered definition of the architecture.

The testing environments and variables that will be considered in such tests.

After following the previous steps, the next move is the real execution of the BEMS programing under the conditions explained inside this document.



10 References

[1] J. Cser, R. Beheshti, P. van der Veer, “Towards the development of an integrated building management system”, in: Innovation in Technology Management - The Key to Global Leadership, PICMET '97: Portland International Conference on Management and Technology, 1997, pp. 27-31.

[2] D. Abdulmohsen, Al-Hammad, “Building management system (BMS)”, http://faculty.kfupm.edu.sa/ARE/amhammad/ARE-457-course-web/Building-anagement-System.pdf, college of environmental design (2013).

[3] J. L. Hernandez, S. Reeb, G. Paci, H. Garrecht, D. Garcia, “A novel monitoring and control system for historical buildings”, in: 3rd European Workshop on Cultural Heritage Preservation, no. ISBN 978-88-88307-26-8, 2013, pp. 251-257.

[4] BRESAER consortium, “D6.1: Monitoring and evaluation plan for the real demonstration”, Tehcnical report, BRESAER project, July 2015.

[5] BRESAER consortium, “D2.2: BRESAER system conceptual design and methodology for a systemic building refurbishment”, Tehcnical report, BRESAER project, July 2015.

[6] Alfredo Weitzenfeld, 2000, “Ingeniería del Software orientada a objectos con UML. Java e Internet”, 1st edition, Mexico, Thomson ed., ISBN 970-686-190-4.

[7] MathWorks, “Matlab: The language of technical computing”, http://es.mathworks.com/products/matlab/, last visited January 2016.

[8] TRNSYS, “Transient System Simulation Tool”, http://www.trnsys.com/, last visited January 2016.

[9] Building Smart, “IFC4 Documentation”, Industry Foundation Classes v4 (IFC4), http://www.buildingsmart-tech.org/ifc/IFC4/final/html/, last visited October 2015.

[10] Green Building Open Schema (gbXML), http://www.gbxml.org/, last visited October 2015. [11] OSGi Alliance, “OSGi framework and Internet of Things (IoT)”.

http://www.osgi.org/Main/HomePage, last visited October 2015. [12] Spring framework: SpringSource, “Spring Dynamic Modules Reference Guide”,

http://docs.spring.io/spring-osgi/docs/1.2.0-m2/reference/html/index.html, last visited October 2015.

[13] Hibernate community, “Hibernate ORM (Object/Relational Mapping) framework”, http://hibernate.org/, last visited October 2015.

[14] GWT: Google Web Toolkit, “GWT developers guide”, http://www.gwtproject.org/, last visited October 2015.

[15] Eclipse team, “Equinox OSGi”, http://www.eclipse.org/equinox/, last visited October 2015. [16] Weather Underground, “Weather Forecast & Reports”, Weather Underground Service,

http://www.wunderground.com/, last visited October 2015. [17] Software Engineering Institute, “Capability Maturity Model Integration”,

https://www.sei.cmu.edu/cmmi/, las visited January 2016.

http://es.mathworks.com/products/matlab/

http://www.trnsys.com/

http://www.buildingsmart-tech.org/ifc/IFC4/final/html/

http://www.gbxml.org/

http://www.osgi.org/Main/HomePage

http://docs.spring.io/spring-osgi/docs/1.2.0-m2/reference/html/index.html

http://hibernate.org/

http://www.gwtproject.org/

http://www.eclipse.org/equinox/

https://www.sei.cmu.edu/cmmi/



Appendix I. Use cases details

Table 39 – Operation mode use case

1 Calculate the operation mode

Description The system should automatically calculate the operation mode based on a well-established time period and data inputs though advanced control algorithms to reduce energy consumption by assuring comfort conditions.

Pre-condition Data are available in databases, external tools and other sources Normal sequence Step Action

1 Read data from the different sources: Historical data from database, weather forecast, BMS live data and external tools, if needed. 2 Run the simulation with the aforementioned information to determine the prediction results. 3 Make use of the advanced control algorithms based on neuro-fuzzy network to determine the best actuation parameters over the building.

4 Send the actuation signal. Post-condition Actuation over the facilities to balance loads out.

Exceptions Related step Action

1 In case no data are available on the different sources, interpolation will be used whenever possible. Moreover, an alarm will be generated and reported.

2 If the simulation tool is not reachable, the previous actuation will be kept and an alarm will be generated and reported.

Performance There is no performance issues with regard to this use case because the algorithm will run in advance to take advantage of its results.

Frequency At design stage, it is estimated to be run every hour.

Importance Vital

Urgency Immediately

Comments Step 1 is not aggregated in the use case diagram because the retrieval of data is represented by the use cases 3, 4 and 5.

Table 40 – Prediction tools use case

1.1 Make use of prediction tools

Description This is a sub-case of the mainly one (in concrete from the step 2) and it highlights management of the prediction tools.

Pre-condition Data availability and well-established interface Normal sequence Step Action

1 Data request from the different sources. 2 Connect to the prediction tool through one of the available interfaces 3 Injection of the information through the interfaces to the tool variables (i.e. input variable in TRNSYS type 155 [8], modification of input files, etc.).



4 Run the simulation 5 Collect the simulation results 5a If TRNSYS type 155 [8] is used, the information is collected by

output variables. 5b If it is Java-based, the output files are read.

6 Send the parameters back to the neuro-fuzzy algorithm

Post-condition Predictive results are available in the neuro-fuzzy algorithm. Exceptions Related step Action

1 In case the information is not available, a new iteration will not run, keeping the previous control in the building facilities.

2 If the interface is not available, the simulation will not be run and the alarms will be accordingly generated/reported.

Performance The simulation model should be detailed and, at the same time, simplified enough to allow running iterative simulations in a short period of time.


Importance Vital

Urgency Immediately

Comments No additional comments

Table 41 – Load balancing use case

1.2 Balance loads out

Description This is a sub-case of the mainly one (in concrete from the step 3) and it highlights the control algorithm to balance the different heating sources in the building.

Pre-condition Data available and prediction results Normal sequence Step Action

1 Receive the information from the data sources and the results from the prediction tools.

2 Inject the input variables to the control model

3 Run the neuro-fuzzy algorithm to obtain the results based on historical, predictive and live data.

4 Compare the results with the costs produced by the actuation, comfort and energy savings in order to achieve a commitment between them to satisfy the conditions.

4a If the costs and energy consumption are upper the envisaged ones or the comfort conditions are not satisfied, the previous control is maintained.

4b If it is producing energy savings but the costs are increased or vice versa, then, the previous control is maintained.

4c If, and only if, one of these variables is maintained at the same time the second one is reduced or both are improved in terms of energy and cost savings, then, the new values for control are set up.

5 Determine the control parameters taken into account the available heating sources, electricity generation systems and the end-distribution systems.



Post-condition Control values as result of the algorithm Exceptions Related step Action

1 In case the information is not available, a new iteration will not run, keeping the previous control in the building facilities.

3 If the neuro-fuzzy algorithm does not converge, the incidence will be reported to improve the algorithm.

Performance Regarding performance, the only constraint is the convergence time which should be limited by a maximum of 20 iterations.


Importance Vital

Urgency Immediately


Table 42 – Calculation use case

1.3 Obtain minimum energy consumption and comfort assurance

Description This is a sub-case of the mainly one (in concrete from the step 3) and related to the sub-case 1.2. It is in charge of checking the energy savings and comfort assurance after determining the values for actuation. This use case is in charge of calculating a set of KPIs to obtain the energy consumption and comfort.

Pre-condition Control algorithm completely run Normal sequence Step Action

1 Get the actuation parameters and control algorithm results.

2 Calculate the energy consumption and associated costs. 3 Determine the comfort values with the aforementioned variables.

4 Check the results. 4a If comfort is ensured while energy or costs are saved, success.

4b Otherwise, the actuation is not applied. 5 Send the parameters back to the neuro-fuzzy algorithm

Post-condition Validation of the control signals. Exceptions Related step Action

Performance There are not performance restriction for this use case


Importance Vital

Urgency Immediately




Table 43 – Actuation use case

1.4 Actuate

Description This is a sub-case of the mainly one (in concrete from the step 4 and it remarks sending the actuation signals to the building facilities.

Pre-condition Control algorithms and checkers completed Normal sequence Step Action

1 Get the actuation parameters after checking.

2 Represent the information in the network interface format. 3 Send the signals.

Post-condition Actuation performed. Exceptions Related step Action

3 If the BMS is not reachable, an alarm is generated/reported and no actuation is completed.



Importance Vital

Urgency Immediately


Table 44 – Actuation checker use case

2 Check the actuation

Description The system should check the status that the actuation has carried out in a right way.

Pre-condition An actuation has been performed in the building facilities Normal sequence Step Action

1 Read on-line the new values of the variables over actuated.

2 Get the local values of the latest actuation. 3 Compare both actuation signals.

3a If both cases are the same, no action is required. 3b Otherwise, the actuation was not correctly applied and an

alarm should be generated/reported 4b Perform a corrective action.

5 If applicable, calculate recommendations for the end users behaviour.

Post-condition Validation of the control signals. Exceptions Related step Action

1/4b BMS is not available, therefore, an alarm will be generated and the checking will be called off until BMS is again reachable.


Frequency It will perform each time a new actuation is carried out.



Importance Very important

Urgency Immediately


Table 45 – Corrective action use case

2.1 Perform corrective actions

Description The system must work properly, but if the actuation was not applied in a right way the system should be able to correct the action.

Pre-condition An actuation has been sent to an actuator but the actuation was not correctly applied both on/off signals and set-point values.

Normal sequence Step Action 1 The BEMS try another time send the actuation (the actuation signal could

have been lost) and another time the local values of the actuation and the new values of the variables are compared.

1a If both cases are the same, no action is required. 1b Otherwise, the actuation was not correctly applied

2b Check if the actuator is in REMOTE mode,

2a If it is in REMOTE mode the BEMS desist of sending the actuation signal. No more actions are required

2b Otherwise the system should perform another corrective actions 3b The system should recalculate the operation mode taking into account

that this actuation is not possible because it is out of actuation range.

4 Send the control signal again or the new one.

Post-condition The corrective action has been applied if necessary. Exceptions Related step Action


Frequency It will perform each time an actuation has not been performed correctly.


Urgency Immediately


Table 46 – User recommendations use case

2.2 Send user recommendations

Description The system should send recommendation to the end-users when the building facilities are not used in a good way from the energy or comfort point of view

Pre-condition The actuation decided for the user in MANUAL mode is different to the action calculated by the BEMS

Normal sequence Step Action 1 In MANUAL mode, the BEMS calculate the actuation expected



2 Compare the value calculated for the BEMS and the action selected by the user.

2a If both cases are the same, no action is required. 2b Otherwise, the actuation was not the most optimal

3b The BEMS generate a recommendation taking into account the actuation expected and the actuation selected by the user.

4 The recommendation is stored for the generation of the monthly report.

5 If possible, the recommendation is presented to the user through a GUI Post-condition Recommendation generated

Exceptions Related step Action All BMS is not available, therefore, an alarm will be generated and the

checking will be called off until BMS is again reachable.


Frequency It will perform each time a new actuation is carried out in MANUAL mode.

Importance Important

Urgency It can wait


Table 47 – Data gathering use case

3 Gather data

Description The system obtains the data from various origins in a fixed time basis Pre-condition n.a.

Normal sequence Step Action

1 The clock activates the signal to acquire global data. The data request is built and sent to the drivers. 2 The working procedure of the drivers depend on the data source: 2a If the source is the weather forecast service, see Gather weather

forecast. 2b If the source is the BEMS itself, see Gather BEMS data.

2c If the source is located outside the BEMS, see Gather external data.

Post-condition The Data is in the BEMS in Java format Exceptions Related step Action

Performance The system should perform this task at least before the next data request would be

launched, but a maximum time of acknowledge could be set. Frequency Measure done once every time interval scheduled (e.g., one hour)


Urgency Immediately

Comments The sequence elements 2a, 2b and 2c are not exclusive amongst themselves. In fact, during normal performance of the complete system, they would probably happen at the same time.



Table 48 – Weather forecast data gathering use case

3.1 Gather weather forecast

Description This is a sub-case of the mainly one (in concrete from the step 2a). The system should be able to read data in fixed temporal steps, recovering the measures from the weather forecast service in a way described in this document. This is a procedure inside the global task of acquiring the whole data set of the system.

Pre-condition Measures requested by the clock. Normal sequence Step Action

1 Request for data to the weather forecast service (website). 2 Reception of measurement using a Web Service (through http), getting

an xml file.

3 The data from the driver is parsed into data that can be internally managed by the BEMS

Post-condition Data available in the BEMS. Exceptions Related Step Action

1 Website not reachable. Generation of alarm (website unavailable) and report.

2 Data from Web Service corrupted or not recognized. Warning generation (data corrupted), followed by report.

2 No answer detected in time. Generation of TimeOut alarm (timeout).

Performance The system works within the scheduled timing intervals for data gathering. The absence of single sets of data is considered of least importance.

Frequency Measure done once every time interval scheduled (e.g., one hour)


Urgency Immediately


Table 49 – BMS data gathering use case

3.2 Gather BMS data

Description This is a sub-case of the mainly one (in concrete from the step 2b). The system should be able to read data in fixed temporal steps, recovering the measures from the sensors. This is a procedure inside the global task of acquiring the whole data set of the system, along with the data from the weather forecast service and the external data.

Pre-condition Measures requested by the clock. Normal sequence Step Action

1 Request for measurement sent to the corresponding driver. 2 The measures are received and it is checked if they are corrupted.

3 The data from the driver is parsed into data that can be internally managed by the core application.

Post-condition Data available in the BEMS.



Exceptions Related Step Action 1 Driver not reachable. Generation of alarm (driver unavailable) and report.

2 Data corrupted or not recognized. Warning generation (data corrupted), followed by report.

2 No answer detected in time. Generation of TimeOut alarm (timeout).

Performance The system should perform this task at least before the next data request would be launched, but a maximum time of acknowledge could be set.



Urgency Immediately


Table 50 – External data gathering use case

3.3 Gather external data

Description This is a sub-case of the mainly one (in concrete from the step 2c). The system should be able to read data in fixed temporal steps, obtaining data from various external sources. This is a procedure inside the global task of acquiring the whole data set of the system, along with the data from the weather forecast service and the BEMS data.

Pre-condition Measures requested by the clock signal. Normal sequence Step Action

1 Request for measurement sent to the corresponding service. 2 The data are collected through the means of Java APIs.

3 The data from the APIs are parsed into data that can be internally managed by the core application.

Post-condition Data available in the BEMS. Exceptions Related Step Action

1 Service not available (inactive, disconnected, unable to perform connection…).More than one try can be performed. Once reached, set alarm (service unavailable) and report.

2 Data format not recognized or corrupted. Another try (or more than one). After a couple of failed trials, disconnect and set alarm (data corrupted) and report.

Performance The system should perform this task at least before the next data request would be launched, but a maximum time of acknowledge could be set.



Urgency Immediately




Table 51 – Data model use case

4 Represent information in a common data model

Description The system should integrate the information in a common data model based on standards

Pre-condition The system have gathered the data and it has the information in the Java format Normal sequence Step Action

1 The data is translated to the appropriated format taking into account ifc4 (or the format selected)

Post-condition The information has the ifc4 format and can be saved in the database Exceptions Related step Action


Frequency It will perform each time new data are gathered


Urgency Immediately


Table 52 – Data storage use case

5 Store data

Description The system should integrate the information in a common data model based on standards

Pre-condition The system has new data in the data model format Normal sequence Step Action

1 The data is formatted in the database format

2 The data is saved in the database

Post-condition The information has been stored in the database and can be accessed by other service from BEMS

Exceptions Related step Action 1 Database is not available, therefore, an alarm will be generated and the

checking will be called off until database is again reachable.


Frequency It will perform each time new data are represented in a common format


Urgency Immediately




Table 53 – Mode switch use case

6 Switch manual/automatic modes

Description The system changes the status of a single device that can be handled locally (by a user) or remote (by the BEMS). This case is for local activation by the user.

Pre-condition The user requests the manual use of a certain device. Normal sequence Step Action

1 The device sends an alarm message (switch mode) through the device driver. 2 The BEMS performs a procedure to gather de status of the device (see Gather BMS data) 3 The BEMS check if the device is turning into manual mode, or into automated mode.

3a If it goes into manual mode, the BEMS activates a flag to avoid the actuation on the device, until certain conditions: it became into automated mode again, the system or device had a reboot, or a fixed lapse of time has passed.

3b If it goes into automated mode, the BEMS activates a flag to indicate that it can use the device to perform the management duties.

4 The event is recorded (switch user mode), including time, location and duration.

Post-condition The mode has been switched. Exceptions Related step Action

2 The device does not respond to the status request. An alarm (missing device communication) is created, and the report too.

2 The device has no reference in the database. Set an alarm (unknown device) and report.

3a The device remains in manual mode for too long. Set the device back to automated mode through the steps 3b and 4. Create a report (automated change) to indicate that the device goes back to automatic.

Performance The switch has to be done almost immediately.

Frequency It is a single-shot event

Importance Vital

Urgency Immediately


Table 54 – Visualization use case

7 Visualize data

Description The user request data visualization and the system offers a set of info depending on the user security level and data selection.

Pre-condition The system GUI is ready to receive requests from the user Normal sequence Step Action



1 Reception of data request from the user. The request contain: type of data (temperature, status of device…), date (from X to Y) and the security level of the user.

2 The access request is registered (time and user, mainly)

3 The user security level is extracted in order to prepare the database request.

4 The request for the database is prepared to get the request data, and considering the user security level. Then, the result depends on this user level.

4a User administrator and technical user: access to all data.

4b User owner: access to monitored data and KPIs info. Configuration data restricted to country or specific regulations.

4c User external: only a filtered set of data available.

5 The database is accessed, and the data extracted.

6 The data are adapted to be displayed into the GUI

7 The data are shown to the user. Post-condition GUI is shown with data.

Exceptions Related step Action 3 The database is not available or reports failure. Generate an alarm

(database error) and report.

3 The request parameters make no sense, or give an invalid database access. Generate warning (request error) and report.

3 The user tries to access to data without complying with the security level. Generate alarm (insufficient security level) and report.

5 & 6 The GUI does not accept the data, or they cannot be displayed. Generate error (data format) and report.

Performance The response should be processed and shown in a reasonable lapse of time (e.g. around 30 seconds).

Frequency Triggered event by the user.


Urgency Can wait


Table 55 – Reports use case

8 Generate monthly reports

Description The system should generate monthly reports which should present the information and graphs according to the useful variables for the Measurement and Verification plan and the evaluation of the KPIs

Pre-condition The system has collected the variables and KPIs and then it has stored these in the database. Also, there is a preconfigured list of variables, KPIs and alarms that should be shown in the report.



Normal sequence Step Action

1 Read historical data from database: KPIs, variables, alarms and events in manual mode

2 If there is KPIs that they are not calculated yet, these KPIs are calculated 3 The system generates a set of recommendation based in the data obtained

4 A report is generated with all the information is generated

5 The report is saved in the corresponding directory

Post-condition The report is available for the allowed users Exceptions Related step Action

1 Database is not available, therefore, an alarm will be generated and the checking will be called off until database is again reachable.


Frequency Monthly


Urgency Immediately


Table 56 – Alarms use case

9 Collect alarms

Description The system should generate and collect external alarms previously configured and to report about them. This case includes two sequential groups of actions to perform. The first one is the acquisition and storage system for the alarm signals created through the whole system. The second one is reporting the alarm to the corresponding agent, based on a relational table (“in case of” alarm x “report to” user y).

Pre-condition Generation of an alarm located anywhere in the system. Normal sequence Step Action

1 The alarm message is received through different means (generated by the BEMS directly, drivers, web services…)

2 The alarm message is stored in the database. The database is checked to prevent failures during the writing process. This check has to be done at least twice, for the case of finding the database already busy with other tasks.

3 The message is inserted to the internal database (update)

4 The message emergency level is checked and compared with the alarm relational table, in order to get the agent that has to be informed about it.

5 The alarm message is sent through the corresponding channel.

5a If the destination is one user “on location”, the message is sent to the interface located there (e.g. application in computer).

5b If the destination is a device, the signals to inform about the alarm are sent to the device driver.



5c If the destination is an internet site, the alarm is sent through a Web Service.

5d If the alarm is “internal”, this step is empty. This is created for alarms with not user assigned.

Post-condition Alarm being stored in the database. Exceptions Related Step Action

2 Database failure. Try to rewrite once again, after a reasonable lapse of time.

3 Database writing error. Try to rewrite once again, after a reasonable lapse of time.

4 The alarm has no correspondence in the table. Generate a new alarm message (alarm undefined) and end procedure.

5 Cannot reach destination. Generate a new alarm (destination missing failure) and end procedure.

Performance n.a.

Frequency This has to be performed with any single alarm generated, due to the fact that some of them could be of maximum urgency.


Urgency Immediately


Table 57 – Self-train use case

10 Self-train with previous data

Description The system should use the data collected from the different sources in order to adjust its behaviour, so the expenses and energy consumption would be optimized.

Pre-condition A large quantity of data gathered after the last self-train procedure, so the results for the calculations would be remarkably different.

Normal sequence Step Action 1 Evaluate if there are enough new data since the last training procedure,

consulting the database.

2 The process load of the system is evaluated. If the load is high, the training does not start and this process is halted for a reasonable lapse of time. Otherwise, the training starts.

3 The older values are stored in the database, in order to have the chance to reset the system to these older variables if the new ones are not satisfying. 4 The training is performed through the usage of the proper tool. The new values for the system are calculated.

5 The new values are updated. To achieve this, the system should be halted to avoid inconsistencies (some values are updated earlier, so during the update procedure the system has wrong values).

Post-condition New iteration in the self-learning process. Exceptions Related Step Action

2 System with high load processes working, devices in user-mode or failures and/or alarms not yet attended. The training should be delayed until the abnormal situations would be corrected.



3 The database is not ready (busy or faulty). Repeat the request and in case or persistent fail, create alarm message (database error) and end procedure.

5 The system cannot be halted for the new upgrade.

Performance The system should perform this task once every set up lapse of time (typically between 1 day and 1 week), to show some degree of evolution and smart behaviour.

Frequency The system variables should be updated every few days.

Importance Not very important

Urgency It can wait

Comments As it has been implied in the comments, this procedure has to be done during low working loads because: a) the calculations can be very CPU-consuming and b) the update of the variables has to be done at the same time in the whole system to avoid inconsistencies.



Appendix II. Event definition

This appendix contains the definition of the events classified by component where the events inside each subsection are those to which the component is subscribed.

AlarmManager

Event topic Properties Type Description

bresaer/AlarmManager/Alarm/logAlarm

process_id String Identifier for the operation

component String Component which launched the event

error_code Int Code of error

error_msg String Error message from the origin

type String Application field of the alarm useful for visualization

Calculator


bresaer/Calculator/CalculationRequest/Request



operation_code Int Code for the operation to be rendered which identifies the KPI to be calculated

data Map<String, Map>

Map whose key is the device and the value is another Map with the timestamp and value.

Communicator


bresaer/Communicator/ControlCalculation/PredictionRequest



objects List List of object whose prediction has to be determined.


bresaer/Communicator/ControlCalculation/PredictionResponse



data Map Map with the pair element-prediction that contains the forecasted values for rendering control operation

ControlModule


bresaer/ControlModule/ControlStatus/SetStatus



status Int 1 or 0 depending on manual or auto


bresaer/ControlModule/ControlCalculation/Iterate






bresaer/ControlModule/ControlCalculation/PredictionResponse



data Map Map with the pair element-prediction that contains the forecasted values for rendering control operation


bresaer/ControlModule/ControlCalculation/KPIResponse



data Map Map with the pair KPI-result in order to make a control decision.


bresaer/ControlModule/ControlRequest/DataResponse





DatabaseCommunicator


bresaer/DatabaseCommunicator/DataRequest/HistData



operation int Type of operation

start_date Timestamp Low limit for the date of the request

end_date Timestamp Upper limit for the date of the request

objects List List of objects to be retrieved, 0 for all


bresaer/DatabaseCommunicator/DataRequest/Insert



operation int Type of operation

objects Map<String, Map>

Map whose key is the device and the value is another Map with the timestamp and value of the objects to be stored in the database

DataModel


bresaer/DataModel/DataModel/ModelRequest


component String Component that launched the event


bresaer/DataModel /DataModel/ModelResponse





data_model List<Object> List of objects which comprises the data model in which data must be represented.

ForecastDriver


bresaer/ForecastDriver/WeatherForecastRequest/DataRequest



http String Http where to retrieve the information

GUI


Bresaer/GUI/VisualizeData/DataResponse




Map whose key is the device and the value is another Map with the timestamp and value of the objects to be shown in the GUI.


Bresaer/GUI/GenerateReport/ReportResponse



uri String Path where the report is


Bresaer/GUI/ConfigureSystem/Confirm



object_id String Identifier for the object that has been configured, i.e. scheduler, user…

status Int Status of the object in case any error was found


Bresaer/GUI/VisualizeData/DataResponse




Map whose key is the device and the value is another Map with the timestamp and value of the objects to be shown in the GUI.

Integrator


bresaer/Integrator/DataSetIntegration/DataInfo



sensor_data HashMap Hashmap with the readings from the monitoring network

timestamp_sensors

Timestamp Time when the monitoring values were received.



weather_data Hashmap Data from the weather forecast

Timestamp_forecast

Timestamp Time when the forecast was received

LONDriver


bresaer/LONDriver/SensorDiscovery/SensorDiscovery




bresaer/LONDriver/SensorDataRequest/DataRequest


component String Component which launched the event to the LONDriver

query_type Int 0 for temporized data requests 1 for asynchronous data requests

devices List List of sensors to be retrieved in case of asynchronous request of data, otherwise empty list for all.


bresaer/LONDriver/Actuation/Update


component String Component which launched the event to the LONDriver

actuation HashMap HashMap whose key is the device_id to be updated and the value, the actuation parameter

Predictor


bresaer/Predictor/SystemForesee/Prediction



forecast_data Map Weather forecast data

prediction_data Map Energy demand prediction

target_timestamp Timestamp Goal time for prediction

Reports


bresaer/Reports/CreateReport/Report process_id String Identifier for the operation



bresaer/Reports/CreateReport/DataResponse







Schedulers


bresaer/Scheduler/ScheduledTask/Create



scheduler_id String Identifier of the scheduler to be removed

event String Event to be launched

start_time Timestamp Date when the scheduler starts

end_time Timestamp Data when the scheduler expires

timer Int Timer of the periodic task in seconds

props HashMap Map with the properties of the event


bresaer/Scheduler/ScheduledTask/Remove



scheduler String Identifier of the scheduler to be removed

Self-trainer


bresaer/SelfTrainer/Training/DataInput



actuation HashMap HashMap whose key is the device_id to be updated and the value, the actuation parameter in order to train the module with the updates

SignalManager


bresaer/SignalManager/Signal/dispatch



event String Event to be forwarded

props HashMap HashMap with the properties to be dispatched in the new event

Supervisor


bresaer/Supervisor/CorrectActuation/Perform



actuation HashMap HashMap whose key is the device_id to be updated and the value, the actuation parameter

Switch


bresaer/Switch/ControlStatus/SetStatus process_id String Identifier for the operation


status Int 1 or 0 depending on manual or auto



Translator


bresaer/Translator/DataTranslation/Merge



data HashMap Hashmap with the readings integrated in a single object

timestamp Timestamp Time when the monitoring values were received.


bresaer/Translator/DataModel/ModelResponse



data_model List<Object> List of objects which comprises the data model in which data must be represented.



Appendix III. Class diagrams

Figure 17 – AlarmManager class diagram

Figure 18 – Calculator class diagram



Figure 19 – Communicator class diagram

Figure 20 – ControlModule class diagram



Figure 21 – DatabaseCommunicator class diagram

Figure 22 – DataModel class diagram



Figure 23 – ForecastDriver class diagram

Figure 24 – GUI class diagram



Figure 25 – Integrator class diagram

Figure 26 – LonDriver class diagram



Figure 27 – Predictor class diagram

Figure 28 – Reports class diagram

Figure 29 – Translator class diagram



Figure 30 – Schedulers class diagram

Figure 31 – Self-Trainer class diagram



Figure 32 – SignalManager class diagram

Figure 33 – Supervisor class diagram

Figure 34 – Switch class diagram



Appendix IV. Sequence diagrams

Figure 35 – Sequence diagram for gathering data

Figure 36 – Sequence diagram for control operation



Figure 37 – Sequence diagram for GUI

Figure 38 – Sequence diagram for mode switch

Figure 39 – Sequence diagram for alarm logging



Appendix V. Data model tables

Actuator : Actuator is a component of a Control Element. Control elements are composed by actuators OR/AND sensors

ColumnName DataType PrimaryKey NotNull Flags Default Value Comment AutoInc

id INTEGER PK NN UNSIGNED Auto increment id for the register

AI

ActuatorType_id INTEGER NN UNSIGNED Foreign key to the actuator type table

ControlElement_id INTEGER NN UNSIGNED Foreign key to the Control Element table.

maxValue INTEGER UNSIGNED Maximum value that the actuator can have

dimmable BIT Boolean to determine if it is dimmable

minValue INTEGER UNSIGNED Minimum value that the actuator can have

alarmValue INTEGER UNSIGNED Value to trigger the alarm state

name VARCHAR(20) Unique identification for the actuator

IndexName IndexType Columns

PRIMARY PRIMARY id

Actuator_FKIndex1 Index ControlElement_id

Actuator_FKIndex2 Index ActuatorType_id

ActuatorHistDataLog : Stores historical values for Actuators



AI

Actuator_id INTEGER NN UNSIGNED Foreign key to the Actuator table

ControlElement_id INTEGER NN UNSIGNED Foreign key to the ControlElement table

logDate DATETIME Timestamp in which value has been stored

valueDate DATETIME Timestamp in which value has been read from the actuator

value FLOAT Value for the actuator


PRIMARY PRIMARY Id

ActuatorHistDataLog_FKIndex1 Index ControlElement_id

ActuatorHistDataLog_FKIndex2 Index Actuator_id

ActuatorLastDataLog : Stores last values read for Actuators


Id INTEGER PK NN UNSIGNED Auto increment id for the register

AI

Actuator_id INTEGER NN UNSIGNED Foreign key to the Actuator table



ControlElement_id INTEGER NN UNSIGNED Foreign key to the ControlElement table

logDate DATETIME Timestamp in which value has been stored

valueDate DATETIME Timestamp in which value has been read from the actuator

Value FLOAT Value for the actuator


PRIMARY PRIMARY Id

ControlElemDataLog_FKIndex1 Index ControlElement_id

ActuatorLastDataLog_FKIndex2 Index Actuator_id

ActuatorType : Stores the different type of actuators available


id INTEGER PK NN UNSIGNED Auto incremente id of the register

AI

acType VARCHAR(20) Actuator type description


PRIMARY PRIMARY Id

BldSpace : Stores the building space description. Building Spaces are related to existing building partitions (rooms, corridors,….)



AI

Storey_id INTEGER NN UNSIGNED Foreign key to the Storey to which the building space belongs

BldZone_id INTEGER NN UNSIGNED Foreign key to zone id

name VARCHAR(20) Unique identification for the building space

spType INTEGER UNSIGNED Foreign key to the building space type


PRIMARY PRIMARY Id

BldSpace_FKIndex1 Index Storey_id

BldZone : Building Zone is the logic aggregation of building spaces



AI

name VARCHAR Unique identification for the building zone

area INTEGER UNSIGNED Area that the building zone covers


PRIMARY PRIMARY Id

BldZone_FKIndex1 Index BldSpace_id



Building : Modeling unit. Building is an aggregation of storey.



AI

BuildingType_id INTEGER NN UNSIGNED Foreign key to the building type

Owner_id INTEGER NN UNSIGNED Foreign key to the building owner.

Site_id INTEGER NN UNSIGNED Foreign key to the site/location of the building

owner INTEGER UNSIGNED

name VARCHAR(20) Unique identification for the building.


PRIMARY PRIMARY id

Building_FKIndex1 Index Site_id

Building_FKIndex2 Index Owner_id

Building_FKIndex3 Index BuildingType_id

BuildingType : Stores the different type of buildings available (schools, apartment buildings, sport facilities,….)



AI

bldType VARCHAR(20) Description of the building type.


PRIMARY PRIMARY id

CommType : Stores the different communication types that building systems may have (RS232, TCP/IP, ….)



AI

comType VARCHAR(20) Description of the communication type


PRIMARY PRIMARY Id

ControlElement : Control element is the aggregation of sensors or actuators that perform control or metering operations


id INTEGER PK NN UNSIGNED Auto increment id for the registers

AI

SystemObject_id INTEGER NN UNSIGNED

Foreign key to reference entity SystemObject. System object is implemented to keep compatibility with IFC4

model VARCHAR(20) Model of the control element

manufacturer VARCHAR(20) Manufacturer name of the control element



controlRoutine INTEGER UNSIGNED Control routine definition ID linked to the control element

name VARCHAR(20) Unique control element description


PRIMARY PRIMARY Id

ControlElement_FKIndex1 Index SystemObject_id

ControlRoutine : Control routines describe sequence of actions related certain actuator and/or sensor values


id INTEGER PK NN UNSIGNED Auto increment for the register.

AI

Sensor_id INTEGER NN UNSIGNED Foreign key to the sensor related to the control routine

Actuator_id INTEGER NN UNSIGNED Foreign key to the actuator related to the control routine

ControlElement_id INTEGER NN UNSIGNED Foreign key to the control element related to the control routine

definition VARCHAR(255) Description of the control routine


PRIMARY PRIMARY id

ControlRoutine_FKIndex1 Index ControlElement_id

ControlRoutine_FKIndex2 Index Actuator_id

ControlRoutine_FKIndex3 Index Sensor_id

FlowControlElement : Stores the system objects focused on smart metering



AI

SystemObject_id INTEGER NN UNSIGNED Foreign key referencing the system object

address VARCHAR(20) Communication address for the element

model VARCHAR(20) Model name

manufacturer VARCHAR(20) Manufacturer


PRIMARY PRIMARY id

FlowControlElement_FKIndex1 Index SystemObject_id

FlowMeter : Stores the flow (liquid, gas) meters deployed



AI

FlowControlElement_id INTEGER NN UNSIGNED Foreign key referencing the flow control element

scale VARCHAR(20) Scale of the metering




PRIMARY PRIMARY id

FlowMeter_FKIndex1 Index FlowControlElement_id

Owner : Stores the list of building owners.



AI

name VARCHAR(20) Name of the owner

address VARCHAR(20) Address of the owner

phone VARCHAR(20) Phone number of the owner


PRIMARY PRIMARY id

PowerMeter : Stores the list of smart power meters deployed



AI

FlowControlElement_id INTEGER NN UNSIGNED Foreign key to the flow control element

phases INTEGER UNSIGNED Number of electrical phases that the meter handles

maxValue VARCHAR(20) Value to reset the counter to 0


PRIMARY PRIMARY id

PowerMeter_FKIndex1 Index FlowControlElement_id

Sensor : Stores the list of sensors deployed. Sensors are linked to control element.



AI

SensorType_id INTEGER NN UNSIGNED Foreign key to the sensor type id

ControlElement_id INTEGER NN UNSIGNED Foreign key to the control element id

units INTEGER UNSIGNED Units for the sensor reading

maxValue INTEGER UNSIGNED Maximum value for the sensor

minValue INTEGER UNSIGNED Minimum value for the sensor

alarmValue INTEGER UNSIGNED Alarm value for the sensor

name VARCHAR(20) Unique name for the sensor

aggregationPeriod INTEGER UNSIGNED Aggregation period for the sensor


PRIMARY PRIMARY id

Sensor_FKIndex1 Index ControlElement_id

Sensor_FKIndex2 Index SensorType_id



SensorHistDataLog : Stores historical values for sensor values



AI

Sensor_id INTEGER NN UNSIGNED Foreign key to sensor id

ControlElement_id INTEGER NN UNSIGNED Foreign key to Control Element id

logDate DATETIME Timestamp for storing

valueDate DATETIME Timestamp coming from the sensor reading

value FLOAT Value


PRIMARY PRIMARY id

SensorHistDataLog_FKIndex1 Index ControlElement_id

SensorHistDataLog_FKIndex2 Index Sensor_id

SensorLastDataLog : Stores last read sensor values



AI

Sensor_id INTEGER NN UNSIGNED Foreign key to sensor id

ControlElement_id INTEGER NN UNSIGNED Foreign key to Control Element id

logDate DATETIME Timestamp for storing

valueDate DATETIME Timestamp coming from the sensor reading

value FLOAT Value


PRIMARY PRIMARY Id

SensorLastDataLog_FKIndex1 Index ControlElement_id

SensorLastDataLog_FKIndex2 Index Sensor_id

SensorType : Stores the different type of sensors available


id INTEGER PK NN UNSIGNED Foreign key for the register AI

sensorType VARCHAR(20) Description of sensor type


PRIMARY PRIMARY id

Site : Stores the description of sites. Buildings are related to sites



AI

latitude INTEGER UNSIGNED Latitude value for the site

longitude INTEGER UNSIGNED Longitude value for the site

altitude INTEGER UNSIGNED Altitude value for the site

address VARCHAR(20) Selected location address

country VARCHAR(20) Selected location country

city VARCHAR(20) Selected location city




PRIMARY PRIMARY id

Storey : Stores the description of the building storey. Buildings are considered as aggregation of storey.


id INTEGER PK NN UNSIGNED Auto increment id for the register.

AI

Building_id INTEGER NN UNSIGNED Foreign key referencing the building

area INTEGER UNSIGNED Area of the selected storey

elevation INTEGER UNSIGNED Elevation of the selected storey


PRIMARY PRIMARY id

Storey_FKIndex1 Index Building_id

System : Stores the basic information for any building equipment, instantiated as control element, flow meter….



AI

sysType INTEGER UNSIGNED Reference to system type

address VARCHAR(20) Communication address for the system

comType INTEGER UNSIGNED Reference to communication type

owner INTEGER UNSIGNED Reference to the owner, it can be the system supplier.


PRIMARY PRIMARY id

BsrSystem_FKIndex1 Index comType

SystemObject



AI

BldZone_id INTEGER NN UNSIGNED Foreign key reference to zone

System_id INTEGER NN UNSIGNED Foreign key reference to system

address VARCHAR(20) Auxiliary address for communication

sysObjType INTEGER UNSIGNED

pollPeriod INTEGER UNSIGNED


PRIMARY PRIMARY id

BsrSystemObject_FKIndex1 Index sysObjType

BsrSystemObject_FKIndex2 Index System_id

SystemObject_FKIndex3 Index BldZone_id



SystemObjetType



AI

sysObjType VARCHAR(20) Description of the object type


PRIMARY PRIMARY id

building energy management system (bems) definition€¦ · building energy management system...

Documents