The meeting included some technical sessions on a variety of topics, an update on progress on each of the work packages and some discussions were held concerning the approach to the 1st Review Meeting that will be held at the beginning of May.
An overview of the topics for the technical sessions is listed below:
Topic 1: Preparation and organisation of Task 5.2 [MOS/API]
Topic 2: BPS – agreement and decision on a common vision for the BPS module(s) [UOS]
Topic 3: Data collection from Pilot site – Demonstration required for Review Meeting [ABO DATA].
Topic 4: Core Platform and Integration [NBK]
Topic 5: Platform commercialisation vision [R2M]
Topic 6: Visualisation in HIT2GAP [FISE] / Parallel session Topic 7: 3D visualisation/BIM [ZUT/MOS]
Some information was also provided concerning the preparation of the 1st periodic reporting – due in mid-March 2017.
Key actions and outcomes from the technical sessions were:
Topic 1: Preparation and organisation of Task 5.2 [MOS/API]
This session aimed to elaborate the use cases associated with each pilot site and discuss the concrete actions to be conducted by the pilot sites managers in order to comply with the modules requirements in terms of measurements.
UDG has agreed to provide a description of the scenarios associated with the use of the forecasting module (DR management, baseline establishment (M&V), energy budget control) and FDD-PCA module.
FISE will check the systems and the list of data required for the FDD module and refine it. FISE will provide the list of sensors required for some of the systems.
The process associated with the use cases definition will be further developed, led by Mostostal in order to reach a common and agreed vision.
Led by Joe Clarke, this technical session was dedicated to the BPS activities.
Topic 3: Data collection from Pilot site – Demonstration required for Review Meeting [ABO DATA]
ABO DATA presented the Challenger case study and the associated interface allowing the visualisation of the data collected on the Challenger building.
Concerning the Polish pilot, a ModBus/IP connector has been selected and agreed. ABO will need interlocutor from the BMS provider to discuss the configuration and the registers to consider. The whole BMS evolution will be ready by the end of May/beginning of June.
The BMS for NANOGUNE was installed last summer. ABO will supply the list of information required to GIROA.
The connection to the other data sources is in progress. The connection has already been established for the MM-WSN sensor.
For the BuildAX sensor, communication will be made via the Rest protocol. 2 options are possible but the most secure one will be implemented. For the indoor positioning system, no connection has been established yet.
List of actions:
-Challenger: collect data from BuildAX sensor and add a page in the existing dashboard to check incoming data.
-NANOGUNE: define the data that will be collected and the protocol to be used.
-Wilanów: Activate a data connector using MODBUS/IP and build a dashboard to display and check the incoming data.
-MM-WSN: deploy a test sample of sensors.
-Indoor positioning system: receive sample data from rest call.
-BuildAX: complete tests on the agreed protocol, receive sample data.
Nobatek presented the core platform functionalities and the modules integration process. Also discussed were the security aspects and Cylon agreed to provide support on this.
Questions raised by the H2G partners – a sample of these is listed below:
-can a third party developer be considered as user? A. yes.
-what is the difference between occupants and users? A. Occupants can be users.
-question around taking care of privacy in relation to access control for occupants and access control risks. A. Data coming from the field level is secured through anonymisation. Access control is managed differently (access to the data and to the module are secured).
Cylon has experience in deploying CAS (Certified Access Security). A telconference will be organized between NBK and CYL in order to discuss how Cylon can provide support in this area.
-what different user types need to be considered? A. Some roles should be attributed to the different users and according to the module. For instance, a large screen displaying information will be considered as a guest user for the use of the visualisation module.
-what about the BPS module? A. Each module should define these roles.
-NBK reminded that the platform is not a storage space. It is a communication space, a tube of communication between the different modules. So it will not run simulations or undertake complex computations.
To achieve the goal of the project, it was agreed that NBK will handle the storage issue. But for a final product, another solution should be envisaged.
It is important that each module developer identifies which output coming from other modules they can use. The prediction delivered by the UDG module could be used by the EGE BM module. This should be considered as a second step in the HIT2GAP process.
R2M presented their assessment of the main end users of the H2G solution. Other end-users missing from this list were suggested: building owner, estate manager, educational sector, etc., BMS providers. Each customer segment should be interested in a specific service. There is a need to have an overview of the application cases - these will be identified through WP5.
The open source option was also discussed. There is an opportunity to use the HIT2GAP solution as a ’standard’ by adopting an open source approach. It is therefore necessary to explore the associated opportunities. As a first step, within WP4, partners should clearly define what is open source and what is not.
Four display modules have been developed through the project:
DM1: Energy Management (ENE)
DM2: FM Visualisation Module (FISE)
DM3: Building Occupants (INX)
DM4: 3D/BIM Visualisation Module (ZUT)
Many other GUIs (Behavioral Module [API], ESP-r service UI [UOS], FDD [UDG], REnSIM [CYR], ModsCO [GAL]). The functionalities of these tools should be integrated in the other DM (visualizing outputs).