Due date: 13/04/2021 - Task leader: CERTH
This report presents the results of Task 1.4 – Architectural Design, Functional & Technical Specification describing the D^2EPC system architecture. The overal goal of this report is to provide a holistic view on the D^2EPC system architecture, its building blocks, components, interdependencies among
components and related constraints such as development methodology. Starting with the methodology, a brief overview of most commonly identified processes and standards are covered in order to understand and present the steps and the information that need to be covered towards presenting a system architecture that completely covers the needs of the D^2EPC framework. Following a four step methodology, the user and market requirerements extracted through previous WP1 activities are translated to business scenarions and technical users cases, along with functional and non-functional requirements. These are then used to update the overall concept and high-level conceptual architecture, which then guides the more careful and accurate definition of each individual component as a module and as part of the overall system.
Out of the examined approaches, four initial viewpoints have been selected to be adopted from presenting the details of the D^2EPC architecture: i) Functional, ii) Deployment, iii) Information, and iv) Dynamic views.
Throught the T1.4 activities 4 business groups have been identified, including in total six (6) business scenarios, further divided into 19 Technical Use Cases. At the same time, a more elaborate iterative approach, usinγ the JIRA framework revealed a first set of 44 requirements (34 functional and 10 nonfuctional), which are documented following the Volere Template. Both the Business Scenarios and the System Requirements, introduced technical aspects that led to the re-design of the D^2EPC architecture. Following a layered approach, the D^2EPC architecture has been divided into 4 layers, each hosting different D^2EPC components, as follows:
- The Infrastructure or Physical Layer consists of one of the core layers for dynamic EPC, especially for the operational rating. Within this layer, all devices, sensors, actuators, and in general Internet of Things, and systems (i.e. Building Management System – BMS, Energy Management System – EMS, or even Supervisory control and data acquisition - SCADA) are included for collecting the necessary building information for all upper layers. As weather data are also required, in the absence of accessible weather stations on site, external weather APIs will be used to retrieve the necessary information.
- The Interoperabity Layer consists of one main D^2EPC component, i.e., Information Mangement Layer. This component is responsible for communicating with the building assets from the physical layer, retrieving the necessary information, translating it to a commonly accepted format and streaming it to the D^2EPC repository to be further utilised in other D^2EPC layers.
- The Service/Processing Layer consists of most D^2EPC components and sub-components responsible for delivering all the main functionalities envisioned:
◦ BIM-based Digital Twin,
◦ D^2EPC Calculation Engine
▪ Building Performance Module,
▪ Asset Rating Module, and
▪ Operation Rating module,
◦ Added-value Service Suite for D^2EPC
▪ Roadmapping Tool for Performance Upgrade
▪ Building Energy Performance Benchmarking
▪ Performance Alerts & Notifications
◦ Extended dEPCsApplications Toolkit
▪ Energy Performance and Credibility
▪ AI-driven Performance Forecasts
- The Representation Layer constitutesthe layer that is offered for interaction with the endusers (engineers, building owners, registries, etc.) or third party platforms / tools (i.e. blogbooks, BIM desing tools, etc.). Within this layer, three D^2EPC components are included, namely:
◦ D^2EPC Web Platform
◦ D^EPC Web GIS, and
◦ Credibility UI.
Based on this layered architecture, functional, deployment and information viewpoints have been provided, presenting for a more detailed analysis of each individual component, along their inbetween interactions.
Finally, the dynamic view, covers several use cases per business scenario, each instantiated through specific requirements and sequence diagrams. The purpose of these sequence diagrams is to clarify how the D^2EPC platform will work and which components are relevant to achieve different tasks.
As the project continues and the activities within technical workpackages progress, the technical aspects of the D^2EPC framework will become clearer and more specific. Hence, more elaborate details are expected to be delivered in the next versions of this report, with certain aspects to be reevaluated and refined.