Vis enkel innførsel

dc.contributor.authorKrogstie, John
dc.contributor.authorPetersen, Sobah Abbas
dc.contributor.authorOksavik, Odne Andreas
dc.contributor.authorSkeie, Kristian
dc.date.accessioned2024-06-13T09:15:40Z
dc.date.available2024-06-13T09:15:40Z
dc.date.created2024-06-13T08:36:56Z
dc.date.issued2024
dc.identifier.urihttps://hdl.handle.net/11250/3133837
dc.description.abstractThis memo follows up earlier theoretical reports on a possible ICT architecture for a collection of zero emission neighbourhoods described in ZEN Report 34 – 2021 (ZEN Data Management and Monitoring – Requirements and Architecture). A case study has been performed, taking the data visualization need for following up the adherence of the building operations to selected ZEN KPI, as described in ZEN-report 44. The case used the ZEB laboratory, which is already heavily instrumented making it possible to capture live data related to a number of the dynamic KPIs on a building in operation. By developing dashboards for the different KPIs, we get insight into the needed underlying data pathways from building sensors to the web. The focus on the existing work was purely on technical aspects, and we have enhanced this by including all levels in an enterprise architecture, adopting the approach from the +CityxChange project. As expected, the original architecture was overly general, although the main technical levels (edge, fog, cloudlet, cloud) makes sense also in the case, even if there is no cloudlet-layer here since we have only data from one building and not a full-fledged neighbourhood. Data is captured, processed and made available at different levels, rather than all collected in a cloud to be made generally available for all, which is the general approach e.g. in EU data spaces and the smart building hub project.1 The case is driven by the need for access to data on the current state, and to some design targets, but not a combination of current data and simulated data of the future, which could be relevant for a building manager. We see in the ArchiMate enterprise architecture models how one can combine the technical levels and business levels (e.g., showing how some data can go straight from edge to cloud, other is going first to the fog). The movement of data (from real-time, to last recent, to historical must be looked into in more detail. As observed from the dashboards. the dividing line between last-recent and historical data is not clear-cut. One can also more clearly define boundaries of who owns / is responsible for the various parts of the infrastructure using e.g., ArchiMate for depicting the whole Enterprise Architecture, include the ICT architecture. It was also noted that the current solution did not support the management of meta-data, and there are plans to adopt a standardized meta data schema. Meta-data is both a traditional data-model and a data movement plan (what is done with the data from it is collected to it is used and visualized, and more subtle aspect on a different granularity level (e.g., that some apparatus is not working appropriately in a certain time-period) Given the large activity nationally and internationally on such ICT and data architecture, it is advised to coordinate further work on this with the SBHub-project, where both SINTEF and NTNU collaborate, which uses the ZEB lab as a case. The case is simple compared to the scope of ZEN since the focus has been on an individual building as part of a smart neighbourhood, and not a total neighbourhood. Given that, not all KPIs are relevant, thus the next step is to investigate this on an area level. Missing areas in the ZEN KPIs are also identified, e.g. on the quality of the working environment such as air quality that one should have ways of following up. Through energinet2 one can access additional buildings at Gløshaugen. Still, starting small has given a good testbed providing relevant results both for the ICT Architecture and for the development of the KPIs themselves. Next, we need additional feedback from those responsible for the different KPI-areas. • How is it best to represent the different KPIs in a dashboard? A work on representing emission and other data for a building manager will be done in spring 2024. • How should one investigate the interactions between KPIs? • How to capture missing KPI-areas • How to integrate illustrating design targets, historical data, and simulated future data? For those needing a more holistic view, e.g. from the different entrepreneurs and technology providers questions might be overlapping with the above. • How should one investigate and illustrate the interactions between KPIs? • How to capture missing KPI-areas (if any)? • How to integrate illustrating baselines/reference data, design targets, historical data, and simulated future data? Similarly, researchers on different areas might want to have tailored views on the overall dataset.en_US
dc.language.isoengen_US
dc.publisherSINTEF akademisk forlagen_US
dc.relation.ispartofZEN Memo
dc.relation.ispartofseriesZEN Memo;55
dc.titleICT-Architecture applied on pilot buildingen_US
dc.typeResearch reporten_US
dc.description.versionpublishedVersionen_US
dc.source.pagenumber52en_US
dc.identifier.cristin2275767
dc.relation.projectNorges forskningsråd: 257660en_US
cristin.ispublishedtrue
cristin.fulltextoriginal


Tilhørende fil(er)

Thumbnail

Denne innførselen finnes i følgende samling(er)

Vis enkel innførsel