CORDIS

Executive Summary:
The ECODISTR-ICT project has developed an Integrated Decision Support System (IDSS) that facilitates decision making on the retrofitting and renewal of existing districts and their composing buildings. It connects the main decision makers in urban district transformation programs, acting from different perspectives, with different time scales, to reach a coordinated approach that joins building retrofitting with district renovation. The tool provides trustworthy insights on retrofitting and renewal projects, the associated costs and benefits during the life cycle of the buildings and the impacts of these on resource efficiency, social aspects, and environmental concerns.
The work method for the project consisted of four constructive pillars of software development towards the IDSS, complemented by testing the IDSS in five case studies. Two work packages destined to coordination, communication, dissemination, and exploitation completed the set up.
The four software development pillars consisted of (1) assessing stakeholder needs and context factors for the selected decision environment, (2) securing appropriate methods for the necessary data collection, (3) selecting a set of calculation and evaluation modules that fulfil the assessment requirements, and (4) creating a user-friendly interface that navigates stakeholders and decision makers through the ICT-supported evaluation process. This interface has resultantly been shaped as a web-based dashboard linked up to a series of key performance indicator (KPI) calculation modules, and includes a design and visualisation module, a KPI scoring dashboard and a crowd-sourcing tool for high-end user convenience.
The IDSS was developed iteratively and tested in five case studies related to urban districts in need of renewal, situated in Rotterdam (NL), Valencia (ES), Stockholm (SE), Warsaw (PL) and Antwerp (BE). The geographical distribution of the case studies revealed contextual differences regarding culture, climate and policies in relation with energy-use and energy efficiency as well as with other retrofit issues. These differences were incorporated in the development of the tool, which should enhance the wide applicability of the tool.
The work packages developed their activities in a parallel rather than sequential way, and the first case studies started already from the outset of the project. ECODISTR-ICT hereby gathered continuous feedback and developed the IDSS in an iterative way, in close collaboration with actual users and stakeholders. One important insight gained from this work method was the firm need for assessing social and qualitative aspects of urban renewal, besides quantitative and technical indicators. As a result qualitative KPIs using normative scoring have been brought in. Secondly a major focus was put on assisting stakeholder interaction troughout the whole decision process.
Resultingly ECODISTR-ICT not only links a set of calculation modules, but has become a hybrid, quantitative-qualitative instrument with a powerful user-interface, designed for accommodating the complexity and the variety of real world urban decision contexts. As the five case studies have confirmed, contextual differences amongst European districts raise the need for setting specific KPIs and targets for individual districts, as opposed to a one-size-fits-all scheme. ECODISTR-ICT delivers an open source instrument with a modular structure that is fit for addressing these multi-aspectual urban questions, and has a high degree of flexibility to be further expanded and tailored to specific needs in real world applications.
The ECODISTR-ICT IDSS is delivered as an open source software platform. Extensive documentation inclucing deliverables, user wiki’s, developer notes and the open software repository are publicly available at http://ecodistr-ict.eu/.
Project Context and Objectives:
1.2.1 Project context
1.2.1.1 An urgent need for energy efficiency in buildings and urban districts
Energy efficiency has become a major issue for the society in order to combat climate change and to ensure energy security and economic prosperity. Amongst many current initiatives from the very local to the global level, the EU has defined a 2030 Energy Strategy in order to realise
▪ ‘a 40% cut in greenhouse gas emissions compared to 1990 levels
▪ at least a 27% share of renewable energy consumption
▪ at least 27% energy savings compared with the business-as-usual scenario’ for Europe.
Being the largest consumer of energy and the largest CO2 emitter, addressing the building sector is crucial for meeting the ambitious energy and climate objectives.
The 2002 ‘Energy Performance of Buildings Directive’ (EPBD) required all EU countries to enhance their building regulations and to introduce energy certification schemes for buildings. The EPBD recast of 2010 has further strengthened the requirements for new buildings: by 2021 all new buildings in Europe need to be nearly zero energy. The energy performance of the existing building stock however remains poor compared to current and future new construction. The annual growth rate of new buildings added to the housing stock is currently estimated at around 1-1.5% per year. The number of buildings removed from the stock is about 0.2-0.5% per year. It is expected that, by 2050, about half of the existing building stock as of 2012 will be still operational. In order to reach a substantial reduction in energy demand and CO2 emissions, tackling the energy performance of existing buildings becomes a top priority.
The EeB PPP roadmap proposes a combination of four implementation options to comply with the challenges ahead, inevitably mixing rehabilitations and construction of new buildings:
1. Increase significantly the rate of high performance, deep rehabilitation of commercial and residential buildings, while lowering the costs of rehabilitation,
2. Increase the overall depth of rehabilitation by favouring district rehabilitation in priority,
3. Valorise energy production and use within new districts to make these districts “energy positive”,
4. Scrap all poorly insulated buildings and replace them by high performance buildings (energy neutral and, when possible, energy positive).
The four inter-connected options raise one need; up-scaling by moving the individual efforts to be accomplished at building level to a district level in order to achieve a wider environmental and energy efficiency impact. In certain cases, the increased energy performance cannot be achieved by solely retrofitting. Renewal might point to a better impact looking at both energy use and district quality levels, and particularly when considering district energy production investments.
1.2.1.2 The district scale as the new level for integrated intervention
As the EeB PPP roadmap points out, up-scaling the effort of energy renovations from the level of individual buildings to whole districts has several significant benefits. Besides technical opportunities (see below), the foremost reason to tackle energy renovation on a district level is the opportunity to integrate a multi-disciplinary approach. Buildings do not operate on their own, but are part of an intricate network of other buildings, public services, transport networks, social interactions of people living, working, and recreating in their environment, etc. Coordinated retrofitting or renewal of districts does not only guarantee energy savings, but above all makes the districts more attractive and sustainable. Consequently, a coordinated approach that joins building retrofitting with district renovation scenarios can be a catalyst to empower districts and turn them into improved livelihoods, resulting in increased market values, less environmental impact, social upgrade and reducing the risk of fuel poverty. It can also generate better living conditions, e.g. by creating healthy indoor and outdoor environments. Energetic district retrofits can thus be a way out of the vicious circle downwards many decrepit districts are in, with people willing to invest in their neighborhood, rather than leaving it behind when they have the chance.
A coordinated approach of tackling the much needed retrofitting demands on a district level adds several advantages to current practice where refurbishment tends to take place as isolated projects, focusing on upgrading individual buildings:
▪ Economy of scale: shared cost for social acceptance, PR and research; possible discount due to larger renovation works; shared energy production facilities are more efficient
▪ The district dimension provides new energy optimization possibilities; for instance through the connection to heat and cooling networks, balancing electricity production and needs, locating energy production facilities at the most effective position in the district, etc.
▪ A coordinated approach gives the opportunity to align the goals of individual owners and occupants with the ambitions of the policy makers on district level investigating qualities such as improved greenery, outdoor health and safety, social cohesion, common places, utilities such as schools and healthcare services.
▪ A coordinated approach gives the opportunity to focus on a sufficiently large amount of buildings and larger time frames and consider the future development and spatial planning of a district. Depending on the actual morphology of the district and the needs of local inhabitants, one can conclude that some of the buildings should not be renovated, but for example rather be demolished and transformed into a local green area, or change function, etc. Because of the long service life of buildings, an individual decision e.g. to do a partial renovation of a building, can have a reverse impact on the district for several decades to come, if the social, economic, physical and environmental values of the districts are not considered.
▪ For some buildings a deep retrofit is not possible or even desirable, because of poor structural quality, considerations of monumental and historical values, excessive costs, etc. By analyzing a larger amount of buildings, the energy reduction efforts can be optimized. Some buildings can be demolished and renewed instead of being renovated; others should not be touched, but can for example be privileged recipients if there is any excess heat available in the district.
▪ Combining decisions on all buildings in a district allows for optimizing the efforts over a longer period of time, instead of just sub-optimizing individual buildings. The measures can be prioritized and other important social, economic, and environmental considerations can be integrated in the decision process.
1.2.1.3 The need for decision support tools
The above-mentioned opportunities in district retrofitting are seldom exploited to their full potential. A coordinated approach towards design, planning and implementation of retrofitting and renewal projects in districts is needed, as it has multiple benefits for all stakeholders (planning officials, inhabitants, SMEs, ...) regarding cost effectiveness, environmental and social impact. The main barrier towards this integrated approach is the lack of information and coordination between the stakeholders.
▪ The different stakeholders are often uninformed of the goals and strategies of other actors. For example, the architects, engineers and contractors are often unaware of opportunities to reach cost-effective energy and resource savings by looking beyond the level of single buildings. District decisions influence decisions on the life cycle strategy decision for buildings and vice versa. The optimum is only reached when decisions on all levels are made in close interaction.
▪ The interactions of buildings, infrastructure grids, inhabitant behavior and social aspects and the vast array of renovation options make the decision making process particularly complex. The decisions are often supported by simulation tools that exist on both building level and urban area level today. However, these tools differentiate largely, both in the required input, as well as in the results, and are often only applicable in one specific country and focus on one specific theme of scale. The complex interactions of building and district level are not fully understood by current state of the art tools, and social, economic and environmental dimensions are often lacking in the evaluation.
In conclusion, the complex interactions of many stakeholders and visions on a district level and the technical complexity of the interplay of buildings, districts, and retrofit scenarios urges the need for information that can support the decision making process. The ECODISTR-ICT project has developed a toolbox that can support the value chain actors with the information necessary to develop and implement suitable options for district retrofitting/renewal projects. By creating this tool, we provide support in different phases of decision making in order to understand the district dynamics and potentials and assess the expected impacts of energy reduction measures and related actions.
1.2.2 Objectives of the project
The ECODISTR-ICT project aims at developing an Integrated Decision Support System (IDSS) that facilitates decision making on the retrofitting and renewal of existing districts and its composing buildings. It connects the main decision makers in urban district transformation programs, acting from different perspectives, with different time scales, to reach a coordinated approach that joins building retrofitting with district renovation. The tool provides trustworthy insights on retrofitting and renewal projects, the associated costs and benefits during the life cycle of the buildings and the impacts of these on resource efficiency, social aspects, indoor and outdoor quality of buildings and districts, and environmental concerns.
In order to reach this key objective, following four sub-objectives have been pursued:
1. To integrate goals and stakes of different stakeholders in a single software environment: When renovating districts, a broad range of professionals has to work along to reach their unified goal. Up till now, those professionals each have their own specific working environment, with few consultations between different specialties. By creating one software environment, we enable bigger coherence between the project partners, creating true interdisciplinarity. The lead users will be urban planners, local authorities as well as housing corporations and engineering companies. By working on a unique platform, they can join their capabilities in striving towards the same goal. This does not imply a loss of functionality for the users, as the tool can differentiate between the different user needs thanks to its modular structure.
2. To enable analysis of different scales and different time frames: A district consists of complex interactions of buildings, networks, social aspects ... The selection of adequate energy reduction measures as well as the verification of the actual energy reduction and quality improvement can only be done at building level. But to achieve impact and optimize interventions over a larger area, urban aspects and the up-scaling to districts is crucial. Our approach is to link existing tools and indicators on the level of individual buildings to frameworks for urban simulation. This tiered approach closes the gap between the current building performance simulation tools used for the design and renovation of single buildings, and the simulation tools which focus on the level of a district or city. The tool also enables decision making on different solutions for renewal and retrofitting throughout the different stages of urban planning and building stock management. The tool equally provides the opportunity to monitor the actual progress of the district.
3. To create a versatile tool with an open structure: The IDSS has a modular structure and results in an open access software tool. The interaction of different modules enables true interdisciplinary assessments of district retrofitting. Many modules can be attached to the framework tool, so the retrofitting project can be accessed from different angles. Energy calculation models are complemented with modules regarding local green space and ecologic values, life cycle impact assessment to quantify resource efficiency, quality assessment, and modules on life cycle costing. The IDSS becomes open source after the duration of the project. By ensuring free access to the tool, interested parties can use it and even modify it to their specific needs, by adding new modules to the framework.
4. To facilitate day to day work of future users: The IDSS fits the actual needs of its future users and clients. The tool integrates multiple disciplines and scales, thus enabling a comprehensive overview of the impacts of district retrofitting in one single software package. Gathering reliable data on building geometry, thermal properties, information on occupants etc. requires a lot of effort and often forms a major barrier towards actual implementation of tools on district levels. To facilitate the required user input, methods to ease the data collection are developed. To increase user friendliness to the maximum, much attention is directed toward the user interface of the tool. The tool provides comprehensible visualizations to assist in understanding the effects of different alternative futures for the district.
Project Results:
ECODISTR-ICT adopts a holistic approach, considering environmental, technological aspects, technology integration (targeting both the buildings and the broader urban environment), as well as extensive stakeholder collobaration as the key for successful district (re)developments. Therefore, it has developed an Integrated Decision Support System (IDSS), an open-source web platform that enables to reach a common understanding in a data driven decision making process to upgrade the sustainability of existing districts and their composing buildings.
This chapter first addresses the technical part of the project. It briefly describes the general architecture of the IDSS and its main components such as data gathering facilities, calculation modules and visual representations. The IDSS itself and additional information can be found in the Wiki-sections of ECODISTR-ICT’s website and the GitHub-page.
Second, the use of the IDSS in practice is illustrated with the iterative development process of the IDSS itself, more in particular the testing and application of the IDSS in five case studies.
Finally, we reflect on the future of urban renewal and the potential role of the IDSS in it.
1.3.1 Integrated Decision Support System (IDSS)
Under this section the main components of the Integrated Decision Support System (IDSS) are briefly described. More in-depth descriptions of its technical features are documented in the deliverable report D4.9 “Concise report on performance prototype”.
1.3.1.1 IDSS functional design
The decision-making process for district retrofitting involves multiple stakeholders who have a wide range of stakes, objectives, priorities and expectations from the decisions made. At the start of the project, the specifications for the ECODISTR-ICT IDSS were further refined from the perspective of stakeholders. This included literature review on the context of urban retrofitting and the processes taking place there, and an analysis of stakeholders’ roles and preferences by means of role-playing sessions, interviews, etc. In the deliverable report D1.1 ‘List of specifications for the decision tool in function of stakeholder’s input’ forty-three distinct stakeholder profiles were identified, which were grouped into ten categories. In the first year of the project the WP5-partners prepared the test locations, reached out to possible stakeholders and took initiative in connecting to local decision-making processes. The aim was to set up the first contacts, to get a view on the data availability, and to prepare for the testing periods.
The deliverable report D1.2 listed the stakeholders’ objectives and decision-making criteria and mutual interdependencies. These were mainly based upon an actor-institutional analysis of the five ECODISTR-ICT case studies and the ongoing processes of sustainable renewal taking place there. As such, a number of requirements for a truly interactive and integrated decision-support system were formulated, including:
▪ the need to be able to go back and forth between calculated results and Key Performance Indicator (KPI) input, enabling different rounds of KPI input and of software mobilisation and thus of a collective definition of the KPIs that matter
▪ the need to include a broad range of KPIs, move (far) beyond energy related issues, and combine complex issues like energy poverty, mobility, green spaces, public spaces, home ownership, affordability, etc.
▪ the need to support the definition and the inclusion of KPIs, and to make explicit both quantitative and qualitative KPIs in the IDSS, even though there may not be an automated calculation module (yet)
Since the aim of ECODISTR-ICT is to support professional stakeholders in complex decision-making processes, the IDSS was developed interactively, using the seven steps of basic decision-making as building blocks. To cater for the complexity of decision-making, the IDSS was therefore developed as a flexible and modular structure, allowing users to repeat the basic steps as often and in whatever sequence as deemed necessary, to work on different levels, to address a wide range of KPIs, etc. Most of these requirements were addressed during the IDSS development process. Based on these analyses and direct feedback from the projects case study reference groups, it was also decided not to focus the IDSS on some specific target groups, but keep the flexibility of addressing a large set of stakeholders, and a flexible set of KPIs and goals.
Other features were firmly expanded compared to the initial development plan. Most notable is the fact that almost all parts of the IDSS are now operating in a webbased environment (also
referred to as ‘the cloud’). This required significant IT development efforts, but greatly expanded the usability since users only need an up to date browser for working with the IDSS instead of installing software on their computer. Furthermore this greatly increases the possibility to work with different people on the same district project (even remotely) and reduces the calculation time for some of the KPIs significantly.
Another noteworthy scope change was based on case study feedback highlighting the need for tools that can assist in the collection of data. Therefore the ‘monitoring’ tool developed as part of deliverable D1.5 was created in a flexible way, so it can also support other forms of data collection. The facilitator can edit the questionnaires, in order to gather the missing data. The tool can be set up for a specific district, so the answers gathered are geotagged and can be imported directly into the system’s database
Jointly the work packages identified four groups of requirements: the requirements from the user perspective by describing the decision making process; requirements from the decision support modules; the data requirements; and the requirements from the perspective of integrating the modules and the data.
These requirements lead to the functional design of the two main components of the IDSS: the Framework, connecting all components into one integrated environment, and the IDSS dashboard, the front-end for the user to embrace the functionality of IDSS and follow the decision process.
The requirements for the other components followed from indepth discussion with future users and developers.
1.3.1.2 IDSS technical design
The functional design of the IDSS evolved into the technical design, including a further elaboration of the way KPIs are dealt with in the IDSS, and the Graphical User Interface for the dashboard (Deliverable 4.234).
In the course of the development of version 1.0 and version 2.0 of the IDSS the system architecture evolved to the architecture shown in Figure 4 (see pdf attachment).
Based on this architecture of the IDSS, the following components have been developed:
1. Dashboard
2. Framework
3. Data
4. Support Modules
5. Calculation Modules
1.3.1.3 Dashboard
Introduction
The Dashboard is a web application for the user to manage the flow of the decision process. The different steps of the workflow are represented, such as creating a case, defining KPIs and work with the ‘As is’ situation, ‘To be’ situation and the different pages to develop, assess and compare alternatives. Several modules, such as the data module, the design module and the upload module have been connected to the dashboard together with calculation modules to enrich the functionality of the system.
The main usage and roles of the dashboard
Two types of accounts have been created to access the Dashboard. The main role is the Facilitator, who has access to all functionality in the decision process, called a Case. From the Dashboard the Facilitator can manage cases, KPIs and access and interact with the different IDSS modules. The Facilitator can also add Stakeholder Accounts to give people affected by the case the possibility to access the dashboard and define their ambitions.
The workflow and functionality of the dashboard
Seven steps are defined as the basis of the decision process and these steps are used to navigate and work in the dashboard, in which each step has its own web-page:
1. Analyse the problem. Setup the case, connect stakeholders and setup the KPIs.
2. Collect data. Use the link to the data upload module to gather district data in a centralised database. The data can then be validated through the dashboard.
3. As is situation. This step calculates the current situation and shows the KPI values.
4. To be situation. The facilitator can set the ambition for the stakeholders. It is also possible for the stakeholders to log in by using their credentials and set the ambition themselves.
5. Develop alternatives. In this step alternatives to the ‘as is’ situation can be created. Also together with contexts different variants can be created, e.g. one alternative combined with a context easily creates a new combination of the designed input and the input that can not be affected by design.
6. Assess alternatives. Every alternative has a link to the design module which makes it possible to configure the district in detail. This affects the input that is sent to the calculation modules. In this step new calculations can be done after changing the design of the district for the alternatives. This is similar to processing the ‘as is’ situation; every alternative has a list of KPIs that can be calculated and the mean values are shown.
7. Compare alternatives. The final step in the dashboard is to assess all the collected results at the same time. The raw data can be examined by using filters on this page of the dashboard. The final assessment is done in the Multi-Criteria, Multi-Stakeholder, Multi-alternatives module (KPI-scoring dashboard,see section 2.1.6.2) which can be accessed through a link.
Module connections
Many connections are made from the dashboard to the rest of the system. The main data traffic is realized through the connector to the Inter-Model Broker (IMB hub). The following list gives examples of the message procedure:
▪ When the dashboard starts up, it will send a message to ask which modules are available.
▪ When a new case is created, a message is sent to prepare the data module for storing new input and output from the modules. The same procedure is done when an alternative is created.
▪ On the collect data page, a message is sent to the modules to validate the current state of the input.
▪ To calculate a KPI, a message is sent to trigger a calculation. Any progress messages during the calculation can be shown directly in the dashboard user interface.
▪ To view the data in the MCMSMA module a message is sent with all the data necessary to update the interface of that module. This makes it possible to perform quick iterations.
The dashboard messaging also enables requests from other modules to obtain case data. The case details, KPIs used, and which alternatives exist, can be returned from the dashboard to other modules on request.
The other type of connection is realized through HTML links, and sends a session ID with the command to open a new tab in the web browser. In this way the separate web application will pick up the user details, case and alternative that should be used for the work session.
System design
The dashboard is a web based responsive application that follows the web standard specifications from W3C and HTML5. This makes it platform independent and accessible from different devices such as computers, tablets and mobile phones. Among the functional requirements are the possibilities to create powerful visualizations, work with large data sets and push message traffic from the rest of the IDSS to the user interface. An Application Programming Interface (API) is also necessary for the other subsystems to get data from the dashboard.
The dashboard consists of four main system parts:
1. Server,
2. Client,
3. Database, and
4. Connector to the framework (IMB hub)
Dashboard server
The dashboard is a web application that depends on an application server, a server API, and a dedicated database. Furthermore the server API is divided into several clustered processes to be able to scale when the load from multiple clients increases and the demand of handling large amount of data is becoming more critical. The ability to scale efficient on a server machine makes it necessary to use a high-performance storage between processes to keep track on user sessions and state.
The load of the server depends of several factors such as how many concurrent users are using the dashboard and the type of processing functionality that is needed. Heavy processing responsibility is not to be delegated to the Dashboard server. The major processing functionality is the one related to reading and writing files, parsing and preparing data for visualization, and querying the database.
Since the dashboard should be flexible to handle future needs of processing and the major bottlenecks of the server cannot be predicted in advance, a modular approach of the server architecture is used. In that way the processing needs and functionality can be isolated and increased on demand. To facilitate these needs a cloud platform provider is used which makes it easy to scale the system without providing the hardware upfront.
To be able to manage modularity and control extensive data flows, real time streaming and large quantities of concurrent requests, a natural choice for the server platform is Node.js. The convenient fact that the server programming language is the same as the one on the client makes the development more efficient. This is due to the fact that in some cases it is hard to determine in advance if processing functionality should be on the server or on the client with the classic consideration whether to make the client ‘thin’ or ‘thick’. The best approach is to be very flexible and thus to be able to move functionality between the client and the server, and if the same functionality is needed on both places, use exactly the same code. A common problem is that when developing on a computer with first class hardware and later testing the application on a mobile device, the application will perform with a poor result. The major approach for the dashboard development is therefore to try, as far as possible, to perform the processing on the client, with the fall back solution of putting the processing behind the server API.
Dashboard client
The client application is a self-contained web application that is distributed from the server. The application is executed in a web browser after being downloaded completely. This is also referred to as a Single Page Application and means that even though the Dashboard contains several pages during usage, the server does not necessarily return any other mark-up, style sheets or logic than during the initialising phase. After initialising the communication with the server the client and server internally will have full-duplex communication using WebSocket, thus making it possible to send and receive data continuously. The data to be sent includes
▪ Request and response traffic to the IMB connector
▪ Managing versions or other project specific data that is saved in the Dashboard database
▪ File uploads and file export
The dashboard uses modern open source libraries for visualisation and makes it possible to show KPI values, present data analysis and map data efficiently.
Setup and installation
The source code of the dashboard is available on Github with instructions on how to install and run the software. The guidelines for users can be found in the wiki.
Summary
The dashboard has evolved to fully embrace the decision process as it has been defined throughout the project. In a similar way the navigation and workflow have been refined step by step. As of an example a separate KPI page has been created to view all the details about the KPI, what modules are connected to it, and the current value in the active case. The connection to the IMB message hub has proven to be a flexible solution as adding new kinds of messages has been done smoothly through the development process. Also connecting other application and modules through normal HTML links has proven to make the system very flexible when it comes to the decoupled architecture and separating the concerns of the developers. With this future proof setup of the dashboard new developments can easily be added.
1.3.1.4 Framework
The components of the IDSS communicate both with each other and with the Dashboard through a Framework using the IMB Communication Hub. This Framework forms the backbone of the IDSS.
The IMB or Inter-Model Broker is a so-called message broker. It serves as an intermediary with a client and a server side, enabling communication between two or more applications without the need for the latter to run on the same physical machine. It parses messages from application A to B and back. All the applications communicating through the IMB Hub should apply the same protocol.
IMB makes use of a so-called Publish-Subscribe mechanism. This resembles radio communication (the type that needs a transceiver device, which both transmits and receives), where the listener can only receive radio messages when tuned in on a specific frequency or channel on which someone is broadcasting. Similarly, all applications that need to talk to each other through the IMB should use the same channel. Only in this case, the ‘channel’ is called a federation.
This federation is managed on a server, where a service is running that handles all the messages: the IMB Communication Hub. This hub can handle multiple federations at the same time. A component (e.g. a Calculation Module) that publishes to a certain federation, is basically sending messages to the Hub. Any other application, maybe on another physical machine, can now subscribe to the same federation and will thus be able to receive the messages that the other application sent through the IMB Hub.
Again, like in radio communication, the IMB Hub broadcasts its messages whether someone is listening or not. The Hub also works independently of how many subscribers are listening to the messages. Moreover, communication through the IMB is bidirectional: subscribed applications can also publish at the same time.
The main advantage of such a system is its scalability and flexibility. The system can run a simple simulation with only two Modules or a full-blown simulation with, e.g. fifty Modules. If the Hub becomes too slow, it is possible to set up more Hubs which are able to communicate with each other. Another advantage is that a Module developer does not need to be informed upfront on how the messages from his/her Module will be received by another Module. A Module only needs to interpret the specific messages it requires and it will have to send out messages that other Modules might require, but not necessarily need to pick up if they are not running.
In general the implementation of the IMB enables the following possibilities:
▪ Interactivity between users on different locations
▪ Interactivity between a user and one or more Modules (responding to a user action)
▪ Interactivity between Modules (responding to another Module)
▪ Real-time input of sensor data
▪ Data exchange in standardized formats between Modules, allowing more Modules to be hooked up to the framework relatively easy
▪ Data exchange between Modules and data stores in standardized formats, disabling the need for Modules to write and read to a data store themselves, thus making the Modules more manageable for developers
▪ Flexibility in terms of where Modules, user interfaces and data stores can reside within the framework (e.g. on a local machine or on different locations)
▪ Long term expansibility: framework capacity can be enlarged
The source for the IDSS Framework is available on Github with instructions of how to install and run the software.
1.3.1.5 Data
The rationale behind current developments is that the ECODISTR-ICT project will rely on databases (cloud based) that will be fed with data coming from various sources: web services, open data, stakeholders, crowd sourcing, etc. Thus, a ‘Geo-database’ is instantiated for each case study, aggregating the data collected.
The ECODISTR-ICT templates
In order to enable the proper use of the different Modules it is mandatory that the input information uploaded on the database (DB) is well formed. For this specific reason, three different templates have been developed to support different usages of the platform. In the wiki, there is an explicit description of the dependencies between the input data (and which template to use) and the other Modules.
The preparation of the information relies on the use of 3 kinds of spreadsheet templates corresponding to the different situations we faced for the project pilots:
▪ a District Template aims at covering the needs at the district level
▪ a Space Template aims at covering the needs at the ‘Space’ level (the notion of ‘Space’ is corresponding to a subset of the notion of District. For instance, it is well suited for the description of green areas in a district)
▪ a Building Template aims at covering the needs at the building level
These templates are containing several columns starting with headers. All of these headers are corresponding to district/space/building information that needs to be entered into the system before making use of dedicated Modules to perform calculations over these data. A specific document describing these templates and detailing the meaning of each of the selected variables has also been developed in parallel. This document is available on the wiki.
The information listed in these templates needs to be combined (or joined) with geographic information (location, building footprint, orientation, etc.). Most of the time in such project acting at the district scale, there are existing GIS files containing (at least) the geographic information mentioned above. Facilitators will consequently enrich this geographic basic information with extra information according to the fields which are predefined in the templates, and upload the resulting file to the database.
The Data Module
The Upload Module consists of a simple web service capable to convert ‘Comma-Separated-Values’ (CSV) data (defined by templates as described above) and to store them into the remote ECODISTR-ICT database.
The database chosen is a spatial database (posgres/posgis) which is used to store and retrieve attribute/geometry data. The standard geometry format used is the ‘Well-Known-Text’ (WKT) format (Level Of Detail -LOD- 0 only). The various attributes that can be used to describe the characteristics of the considered District / Space / Building are defined into the different upload templates of the project.
Each Alternative has its own data stored in a separate district database. This implies that for each case there are multiple district databases: one for the As-Is situation, and one for each Alternative. When a new Alternative is created, it always starts with a copy of the As-Is district database.
The Data Module binds the database to the other Modules over the IMB Hub.
The Data Module is currently built for two database structures. The original structure was based on city GML. This has been extended with a flat Data Module where objects with their properties are stored in tables.
For more details on these tables see the wiki of the Design Module.
The ‘crowdsourcing’ tool
A specific way to gather data is using the ‘crowdsourcing’ tool (see Deliverable 1.5). A dashboard enables the facilitator to create a questionnaire and gather data from local inhabitants or other stakeholders. The data is geo-referenced: the user can click on a building or other component in the district, and connect the questionnaire results to such an object. The data can be exported to a CSV, and after quality checking by the facilitator it can be added to the district database using the Data Upload Module. See the ECODISTR-ICT wiki for the end-user guidelines and GitHub for the source code and the developers’ instructions.
The upload process
A specific document describing the whole process needed to upload GIS data has been established. As explained above, before proceeding to the upload, there is a prerequisite to prepare these data and combine together, in a structured manner, the various informations needed by these other modules (see the Figure in PDF attached).
The guidelines are based on a simple example working with resources that are freely available (open street map web site and open & free software).
They describe step by step how to gather geographic information (terrain description, building geometry) and how to mix this information with the specific data needed by the various calculation modules. This document is availalble on the wiki.
1.3.1.6 Support Modules
The following supporting modules are presented in this chapter:
▪ Design & Visualisation Module
▪ KPI Scoring Dashboard
The detailed guidelines for the supporting modules can be accessed in wiki format at: http://ecodistr-ict.eu/supporting-modules/.
Design & Visualisation Module
The goal of the Design & Visualisation Module is to visualize map based data of the district and its Alternatives, and to manipulate the data by applying measures on objects within the district.
Data are visualized by coloured objects like buildings based on properties of those buildings. Colouring is done through the use of a legend defined per visualized property or based on the definition of KPIs. KPIs are defined within the dashboard, not in the Design Module. All defined and processed KPIs are automatically available as a ‘Detail’ item in the Design Module.
In the Design Module, objects like buildings or spaces can be selected. Per project, measures are defined that can be applied on specific objects or on the district as a whole as part of a specific Alternative. When applied on a set of selected objects, these measures change values of properties of the selected objects. Calculation Modules can read these changed values and calculate new KPIs based on those values. The KPIs that are related to objects can in turn be visualized by the Design Module. This chain of Module applications is controlled by the ECODISTR-ICT dashboard.
The source code, the documentation, the developer instructions and the end-user guidelines for the Design Module are in the ECODISTR-ICT repository on GitHub, and are open source. All source code is available except for some third party tools.
Figure 9 shows the main parts of the Design Module (see PDF attached).
The Web Client is the user interface of the Design Module, with its functionality as described above. The user can filter the information displayed by switching domains on or off to make the selection of layers and graphs easier.
From the IDSS dashboard, the user opens the menu item ‘As-Is’ or ‘Develop Alternatives’. In those screens there is a button ‘open Design Module’. This starts the Design Module Web Client for the selected case and Alternatives. There is a user manual for the Web Client in the ECODISTR-ICT wiki.
KPI scoring dashboard
Decision making on district renovation involves multiple KPIs and multiple stakeholders. In order to create a comprehensive and transparent overview of all the KPIs a separate dashboard has been developed: The Multi-Criteria, Multi-Stakeholder, Multi-Alternative module (abbreviated as MCMSMA or triple M or 3M). The purpose is to help the planning process, where many stakeholders are involved with different interests, by creating transparency and facilitating the comparison of different alternatives.
Three dimensions – three Ms
An alternative is a proposed retrofitting approach for a district - this is one of dimensions of the 3M module. There can be many different alternatives. The current situation ‘As-Is’ and the desired situation ‘To-Be’ are special alternatives. Other Alternatives are developed by applying groups of measures, leading to a situation somewhere between ‘As-Is’ and the ideal ‘To-Be’. An alternative is subsequently rated by means of key performance indicators, representing the performance on a given set of criteria, for example regarding the energy demand for space heating in buildings or the available green spaces in the neighbourhood. The scores on the KPIs are normalized resulting in a report mark (scale 1 to 10).
In a district there are many stakeholders; this is the second dimension of the 3M module. Each stakeholder can have a different rating for a KPI (applying different benchmark values, for example). Examples of stakeholders are housing associations, municipalities, energy companies etc.
The last dimension is the multi-criteria aspect. In order to compare different retrofitting alternatives a rating system is required. The 3M module rates the alternatives by calculating a score based on weighted averaging of the individual KPI scores, thus creating a multi-criteria assessment. The weighting factors are determined by the individual stakeholders and are displayed together with the scores; this creates transparency because it indicates which KPIs are important for a given stakeholder.
The screenshot on the left (see PDF attached) shows how a renovation alternative is differently appreciated by the stakeholders. The screenshot on the right shows an overview of how different alternatives compare to each other. The dashboard has a filter mechanism in order to be able to focus on the most promising renovation alternatives or on differences between stakeholders.
1.3.1.7 Calculation Modules
On the basis of an extensive review of stakeholder needs, a survey of existing tools, and a subsequent selection process (described in deliverables 1.1 1.2 3.1 and 3.2) tools for coupling to the IDSS have been identified and tailored to the specific needs of ECODISTR-ICT (described in deliverable 3.3).
Calculation modules relate to the KPIs that are handled in the IDSS.
The ability to link simplified excel sheets to the IDSS was identified as an important feature of the IDSS. In order to make the process of attaching new modules simpler a generic Excel module has been developed. It contains the fundamental structure needed to connect to the IMB Hub, respond to the Dashboard/Module messaging protocol (using the .Net messaging dll discussed above) as well as set and get values from an Excel module. This generic Excel module has been used to couple the following Excel modules: LCC Module, Affordability Module, Green Berlin Module, Green Stockholm Module, Renobuild Module (LCA) and the Mobility Module. In addition to these excel modules, a district energy simulation software was fully integrated in the IDSS: BIM Energy Map, developed by StruSoft.
The calculation modules are briefly described in the following sections. The code and the developer instructions for these modules can be found on GitHub (https://github.com/ecodistrict/excelmodule).
The end-user guidelines can be found on the ECODISTR-ICT wiki (http://ecodistr-ict.eu/calculation-modules/).
LIFE CYCLE COST (LCC) MODULE
The Life Cycle Cost (LCC) module is an open source calculation tool developed by SP Technical Research Institute of Sweden.
(See PDF attached)
LCC analysis to compare different investment alternatives
Life cycle cost analysis is a tool to determine the most long-term cost-effective options among different competing investment alternatives. This means that both the initial investment and installation costs are taken into account as well as the yearly costs such as energy costs, costs for maintenance work etc. In this way a more fair comparison can be made between an option with high initial investment cost and low annual cost versus an option with lower investment cost but higher annual running cost. The LCC analysis will determine whether an investment is profitable and hence guide future investment decisions for housing owners.
LIFE CYCLE ASSESSMENT (LCA) MODULE
The SP LCA module is based on an existing open source tool, developed in a Swedish project, Renobuild (www.sp.se/sv/index/research/renobuild) suitable for Swedish conditions. Within Ecodistr-ICT, the Renobuild environmental calculation tool has been modified, primarily by adding some new renovation options, by extending the usability for more countries and by integrating it into the ECODISTR-ICT IDSS platform. Before using the SP LCA module, the user has to contact and sign an agreement with the LCA-data provider Ecoinvent (www.ecoinvent.org) in order to get a sub-licensing right for access to a certain number of datasets from the Ecoinvent database.
(See PDF attached)
Find out global warming potential and primary energy demand of renovation alternatives
The SP LCA module calculates and evaluates renovation measures from a global warming potential and primary energy demand perspective, using a life cycle approach. The results are provided as changes in global warming potential (CO2-equivalents) and use of primary energy compared to a reference case (current situation, no renovation made). The module is mainly intended for estimating environmental impact of different renovation alternatives during the planning phase.
Based on life cycle assessment (LCA) on both building and district levels
The LCA module calculates the change in global warming potential (tonnes CO2eq/m2, year) and primary energy demand (MWh/ m2, year) from a lifecycle perspective. The module includes data and calculation models for a number of predefined renovation measures in the heating system, building envelope, ventilation, piping and possible installation of local energy production. The life cycle includes materials for renovation, changes in yearly energy consumption, changes in how the heating is produced and finally the end of life treatment of the building materials used in renovation. The module calculates the changes in global warming potential (tonnes CO2eq/m2, year) and primary energy demand (MWh/ m2, year) that follow from a renovation scenario including one or several renovation measures for individual buildings or a number of buildings for a district.
BERLIN GREEN MODULE (BAF)
Berlin Green is an open source calculation module used for calculating the biotope area factor according to the Berlin methodology (BAF). The calculation module was developed within the ECODISTR-ICT project and was programmed by SP Technical Research Institute of Sweden.
(See PDF attached)
The BAF methodology and what it does
The biotope area factor (BAF) was developed in the 1990s in Berlin, Germany to support the increase of green spaces in the city. This module calculates the biotope area factor of a district, i.e. the area portion of a plot of land that serves as a location for plants or assumes other functions for the ecosystem, in relation to the total area of the plot, in accordance with the model adopted in Berlin, Germany. The methodology, however, can be used in other cities as it is not dependent on site specific conditions related to the origin city. The BAF thereby contributes to standardizing and putting into concrete terms the following environmental quality goals:
▪ Safeguarding and improving the microclimate and atmospheric hygiene,
▪ Safeguarding and developing soil function and water balance,
▪ Creating and enhancing the quality of the plant and animal habitat,
▪ Improving the residential environment.
STOCKHOLM GREEN MODULE (GYF)
Stockholm Green is an open source calculation module used for calculating the biotope area factor according to the Stockholm methodology (Grönytefaktor, GYF). It also calculates subcategories relevant for the biotope area factor. The calculation module was developed within the ECODISTR-ICT project and was programmed by SP Technical Research Institute of Sweden.
(See PDF attached)
The GYF methodology and what it does
The original Berlin biotope area factor (BAF) has been further developed at other locations including the city of Stockholm (here referred to as GYF, Grönytefaktor). This module calculates the biotope area factor of a district, i.e. the area portion of a plot of land that serves as a location for plants or assumes other functions for the ecosystem, in relation to the total area of the plot, now in accordance with the model developed in Stockholm, Sweden. The methodology, however, can again be used in other cities as it is not dependent on site specific conditions related to the origin city. It was developed to illustrate ecosystem services and to encourage the strengthening of local ecosystems and the creation of climate-adapted courtyards with high social values. Planners, architects and developers received a concrete planning tool adapted to their way of working, which facilitated and inspired planning and design with ecosystem services.
The Stockholm GYF methodology is a more advanced tool compared to the Berlin BAF tool. It includes many more input parameters and investigates multiple aspects of urban green. The input required is more detailed and will take some time to investigate and collect whereas for the Berlin BAF this is a more simple procedure. Stockholm GYF will, however, provide the user with much more information on urban green and ecosystems in the district.
AFFORDABILITY MODULE
The Affordability module is an open source calculation tool developed by SP Technical Institute of Sweden.
(See PDF attached)
Affordability for residents
When a renovation of a district is planned it is of importance to consider its effects on the housing costs for the people living in the affected houses, i.e. how does it affect the affordability for the residents. In essence the Affordability module is used to elaborate on what is the threshold for the residents when it comes to housing costs, including costs for energy use. The outcome of the module is the minimum disposable income that a typical household needs to have in order to be able to afford a certain rent or housing costs. The calculated minimum disposable income can then be compared to benchmarks of the district, city or country.
BIM ENERGY MAP MODULE
BIM Energy Map is an application and module from the StruSoft commercial energy simulation platform BIM Energy. More information on the license can be found at bimenergy.com. The module returns results of the simulated building energy use.
(See PDF attached)
BIM Energy Map simulates building energy use
The BIM Energy Map module takes as input a building footprint together with some simple parameters such as building height, amount of glazing, typology (description of the building construction), activity template (description of the building usage). A building is generated from this input and a dynamic simulation is performed hour by hour. During the simulation every aspect of the building is taken into account for calculating the use of the energy in terms of gained and emitted values for different properties in the energy balance.
MOBILITY MODULE
The Mobility module is an open source calculation tool developed by Arup.
(See PDF attached)
Purpose of the Mobility module
The objective of the Mobility module is to determine the impact on the modal split for different renewal solutions with regard to transportation in a city district. Modal split is commonly defined as the percentage of travellers using a particular type (mode) of transportation, for example private vehicles, trams, busses, or bikes. Mobility has a significant impact on the energy consumption of an urban area; by reducing traffic demand, promoting slow modes (walking and cycling) and using more collective forms of transport the energy consumption can be reduced. The table below lists renewal solutions that are taken into account in the Mobility module. Two types of modal split are the outputs (KPIs) of the module, the modal split for origin and for destination. The origin modal split is applicable to the traffic that departs from the case study area and the destination modal split is applicable to the traffic that goes to the case study area.
(See table PDF attached)
1.3.2 Guidelines to use the IDSS in urban renewal processes
The retrofitting of an urban district is by nature a complex process in a complex system. In his keynote speech at the ECODISTR-ICT final conference, Adriaan Slob of TNO pointed out that this kind of process should not only be tackled from a technical perspective, but also from a social perspective (“it is not a technical thing, it is a social thing”), referring to the relevance of social sciences in this regard. The social dimension should be taken into account or in other words: regarding urban retrofitting processes, it is not only about the project (or the tool, taking the IDSS as an example), the process itself is as valuable.
Deliverable report D5.4 “Conclusion report on the governance of retrofitting and the use of the ECODISTR-ICT tool” is intended as a manual for the use of the IDSS in practice. It reflects on the role of the IDSS in urban renewal processes and explains how the case studies and stakeholder interactions influenced the development of the IDSS. Furthermore, recommendations are provided for future users of the IDSS. The activities and interactions that took place also provide valuable lessons and recommendation for the future development and use of the IDSS.
This chapter briefly highlights key topics of the report. The report itself is publicly available at ECODISTR-ICT’s website.
1.3.2.1 The iterative development process
In order to meet the challenges related to urban renewal projects and to enhance the potentials and usability of the ECODISTR-ICT tool, the ECODISTR-ICT software development process was designed as an interdisciplinary (integrating various disciplines) and a transdisciplinary (involving real users) process. Concomitant to the previous, from its start, the ECODISTR-ICT project adopted an agile product development approach. This concept is often used in software development in which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams. During the development of the ECODISTR-ICT IDSS, the project members did not only apply these principles to the development of the software code itself, but also to the definition of the functional needs and the preparation and testing in the five case study project areas. In a truly iterative process, IT developers, case study partners and external stakeholders were mutually involved in shaping the ECODISTR-ICT IDSS ‘along the way’. This is opposed to a more traditional approach in which the software would have been developed completely before using it in practice. As such, during the project incremental updates were developed and tested, including short feedback loops and multiple testings, thus reducing the risk, and enabling to adapt to changing requests and user needs.
Three parallel interactive processes can be distinguished:
1. creating the IDSS, using a scrum-like development process, in the ICT domain;
2. developing a multi-stakeholder interaction process for retrofitting districts, based on using the new IDSS, in the domain of the (urban retrofitting) process facilitation domain;
3. developing a new retrofitted district, using an interactive process and the new IDSS, in the district retrofitting domain.
Choosing for an interactive approach in the ECODISTR-ICT development process thus entailed organizing the alignment and the interaction between the people, methodologies and theoretical backgrounds of the three domains.
1.3.2.2 The case studies
The ECODISTR-ICT IDSS was tested in five real-life case studies in Rotterdam (NL), Valencia (ES), Stockholm (SE), Warsaw (PL) and Antwerp (BE), in a specific work package WP5. A geographical distribution of the case studies revealed contextual differences regarding culture, climate and policies in relation with energy-use and energy efficiency as well as with other retrofit issues. These differences were incorporated in the development of the tool, which should enhance the wide applicability of the tool.
WP5 thus primarily aimed to:
▪ test and demonstrate the scenarios developed in WP1, the data upload and reading of data in WP2, the software modules developed in WP3, and the integrated tool developed in WP4, through real life case studies
▪ discuss and test the ECODISTR-ICT software through design, planning and implementation of case studies
▪ establish a strong interaction with the other work packages through case studies and to provide continuous feedback of real-life cases allowing for an iterative development of the tool in close collaboration with actual users and stakeholders.
1.3.2.3 Role of the facilitator
The IDSS was tested in five different case studies by the practitioners (architects, urban designers and engineers) in the consortium. They took up the role of the ‘facilitator’ that operates the IDSS and manages the interactions with the stakeholders. Gradually it became clear that two different skills can be distinguished for the facilitator.
On the one hand, the facilitator has to have organizational and social skills to guide the stakeholders through the process. He or she will identify the ambition and concerns of the stakeholders and the district and translate these into the IDSS. Furthermore, he or she is responsible for setting up efficient and stimulating workshops, communicates with the stakeholders and tries to keep them motivated during the process.
On the other hand, the facilitator needs technical skills to manage the IDSS. He or she will take care of the configuration of the IDSS, operate the calculation modules and manage the data flow. This means that the required input data have to be uploaded by the technical facilitator, the KPIs are defined, the modules are connected and ready and the alternatives are generated. This also includes the validation of the results.
The combination of these two very different competences can be quite challenging. This was illustrated in the case studies, as each case study preferred to distribute these tasks among two parties: a ‘process’ facilitator and a ‘technical’ facilitator. This is certainly a valid possibility, under the condition that there is a close collaboration between the two facilitators.
1.3.2.4 Overview of the cases
The case studies were implemented by the partners TNO and VABI (Rotterdam), Bipolaire (Valencia), White Architects and SP (Stockholm), ARUP (Warsaw), and OMGEVING and VITO (Antwerp), who all have extensive experience in the local context and everyday practice. In the case studies, these partners developed a close cooperation with the software developers and research institutes on the one hand and a broad range of local stakeholders on the other hand. Since the software was tested in parallel with the actual development of the IDSS, the case studies had to deal with the different temporalities of software development and the availability of prototypes and (connected) modules.
- IDSS version 1.0 First version of the Prototype IDSS [Del. 4.7 month 18]
· Rotterdam Case study 1 [Month 18-22], using IDSS version 1.0
· Valencia Case study 2 [Month 21-24], using IDSS version 1.1
· Stockholm Case study 3 [Month 20-29], using IDSS version 1.2
· Warsaw Case study 4 [Month 28-36], using IDSS version 1.3
- IDSS version 2.0 Second version of the Prototype IDSS [Del. 4.8 month 30]
· Antwerp Case study 5 [Month 31-36], using IDSS version 2.0
Case study Rotterdam
(See table PDF attached)
Case study Valencia
(See table PDF attached)
Case study Stockholm
(See table PDF attached)
Case study Warsaw
(See table PDF attached)
Case study Antwerp
(See table PDF attached)
Lessons learnt
It can be seen that all case studies had a quite different approach. This can be related to cultural differences, different backgrounds of the facilitators and the stage of the IDSS at that time.
The first differences are related to the stage of development of the IDSS. The first test cases - Rotterdam and Valencia- had to work with a very basic IDSS that did not have a central database, nor a lot of calculation and/or supporting modules whether or not linked to the dashboard. These case studies focused mainly on participation and interaction with stakeholders. They calculated many KPIs manually and inserted a substantial amount of qualitative KPIs that stakeholders considered to be important. The alternatives were often presented by own visualisations in order to have a good communication with the stakeholders. The following case studies tried to implement new calculation modules and/or existing ones that were not integrated yet into the IDSS. Many supporting modules were developed during the process. According to the speed of developing the modules, the different case studies tested the newest modules and tried to make them suitable for their own case study.
Another difference between the case studies relates to their focus themes. Energy was always considered to be important. Warsaw implemented a mobility module, which added infrastructure as an issue. Rotterdam paid much attention to gas and water, Valencia to green and the proximity to services. Antwerp set out to focus on energy and feasibility (related to costs - affordability). The Antwerp case also tried to relate social aspects such as ownership and cultural differences within the district with different alternatives in order to apply diverse measures depending on the sector within the district. These foci are evidently related to the specificities of the area, building typologies and densities, macro- and microclimate, important stakeholders and their interests, demographical factors, cultural aspects, etc.
In the course of the case study testings of the IDSS, priorities were gradually set regarding the structure of the IDSS, the calculation modules to be connected to it (energy, affordability, mobility, green, LCC), the nature of that connection, the development of supporting modules (design module, multicriteria module, crowd sourcing module), the improvement of ways to visualise data, the position of the data module in the IDSS, etc. As such, the case studies were instrumental in the development of the structure, form, appearance, improved user friendlyness and current content of the IDSS. They also contributed to the modular and flexible nature of the IDSS and to the ambition to connect a wide range of calculation modules able to support decision-making.
The case studies however also showed that many challenges still lay ahead. To fully mobilise the IDSS in a district retrofitting decision-making process, more calculation and evaluation modules need to be connected. Also, more testing is necessary, given the fact that the last versions of the IDSS could only be tested for a short period and that testing in long lasting processes was not feasible.
1.3.3 The future of urban renewal and the role of the IDSS in it
As stated in the introduction, the need for urban renewal developments will grow in the near future as a result from the increasing need for energy efficiency. Similarly, the demand for more efficient and effective processes increases, in which the interests of relevant stakeholder are protected in a transparent way. Currently, these multi-stakeholder urban renewal processes are typically innovative and challenging endeavours. In the future these processes will become more and more mainstream. Today, a city is proud if they have one or two of these innovative district processes within their city. In the future, as we are heading towards nearly energy neutral living for all buildings; as a consequence each city district should have a continuous multi-stakeholder renewal process. This implies that we need to learn better from earlier processes and retain the knowledge gained in systems. This counts both for the physical systems, leading to optimized and standardization energy solution on building and district scales, and process supporting systems. The Integrated Decision Support System, as developed in the ECODISTR-ICT project, could well be a valuable system for retaining, transfering and repeatedly applying the knowledge how to protect the interests of the many stakeholders in an urban renewal project, leading to efficient and effective transformation processes.
Potential Impact:
1.4.1 Potential impact and steps taken to bring about the impact
The potential impact brought about by the project, both during and after the project term, is discussed below. We distinguish the impacts of ECODISTR-ICT at three levels: the direct impact created through the cases studies, the forthcoming impact for project partners and stakeholders, and the wider societal impact of the ECODISTR-ICT IDSS.
1.4.1.1 Direct impacts through the case studies in 5 districts
ECODISTR-ICT has demonstrated a potential reduction in energy consumption and CO2 emissions while at the same time investigating affordability for households, outdoor conditions and urban ecosystem services, as it links energy-use reductions and greenhouse gas emission savings (which are rarely the main drivers for building or district retrofitting) to a range of aspects like the motivations of households or the advantages of nature-based solutions on a district level.
Actors active in the urban planning sector were part of the consortium, and external parties were able to join stakeholder discussions to assess the needs of users and stakeholders. This maximized the relevance of the use of the IDSS, in particular in the case studies.
The ECODISTR-ICT approach has thus been validated in 5 major districts throughout the EU. In line with the above mentioned, immediate (potential) impacts were identified for the selected case study districts on resource efficiency, energy efficiency, outdoor environment quality and investment decisions due to the improved and integrated planning decisions. The selected districts range from several hundreds to several thousands of buildings.
As a consequence of the iterative development of the IDSS, the testing in the project case studies was done with incomplete prototypes of the ECODISTR-ICT IDSS. Nevertheless, the application in the case studies brought about real impacts in the case study districts as further detailed.
Impact of the deployment of the ECODISTR-ICT IDSS illustrated in five districts in Europe
Rubroek area in Rotterdam
As a consequence of the testing of the early ECODISTR-ICT IDSS prototype, the stakeholders in Rubroek are still very well connected. Local authorities and housing associations continue to explore collaboration opportunities in the district for sustainability and energy efficiency.
The common ground for these meetings is the low local economic and social development in the area. The relationship with, and possibilities for energy efficiency, have meanwhile become more evidenced to all of the concerned stakeholders.
Based on the findings of the workshops and other experiences, the Distribution System Operator (DSO) has started to define a Network CO2 Footprint framework to be used in decisions for integral energy efficient systems in the built environment. The city of Rotterdam has set up an approach to link energy efficiency with different other local challenges, enabling the uptake of energy efficiency measures in districts where local residents are hardly or not able to invest. This approach is, among others, based on the workshop and testing approach of ECODISTR-ICT. The method has been called ‘social approach’ to underline the role of social innovation and related interventions.
Campanar neighbourhood in Valencia
During the case study in Valencia, the main impact of ECODISTR-ICT was realised when all stakeholders were together in one room discussing possible scenarios and the needed actions to realise these scenarios. The moment where conflict between different interests turns into a moment of understanding each other’s point of view, is probably the most powerful feature of ECODISTR-ICT in a real decision-making process. The development of ECODISTR-ICT throughout the “use” of case studies (and not using case studies to check a tool) implied that the City of Valencia was strongly involved in the process, and picked up valuable ideas for the further development of the Campanar neighbourhood, as well as other districts in the city of Valencia.
Hovsjö district in Stockholm
For the main stakeholder, housing company Telge Hovsjö, it was an eye-opener to see how badly the building stock performs on energy efficiency. This convinced Telge Hovsjö to rush further to kick-start the deployment of energy efficiency measures. In addition the ECODISTR-ICT software clearly showed that the building blocks, with large roof surfaces with optimal orientation, are most suitable for solar power production. The IDSS also showed very good statistics in terms of the green area factor, which was strongly appreciated by the social housing company and confirmed the potential of the ample green space available in the district.
Służewiec Przemysłowy in Warsaw
The Służewiec Przemysłowy district in Warsaw appeared to struggle most with the effects of unplanned development and traffic congestion, apart from the classical energy considerations. ARUP set out with a data-intensive methodology (geometrical information, mobility data, energy consumption data, building physics, façade images, etc.), but quickly came to realise that a lighter method would better fit for the purpose of the project.
Useful lessons learned concerned different ways data could be organised and stored; new insights in the role that mobility can play in relation to energy; better understanding of the complexity of the process of retrofitting; and identifying a systematic approach that can be applied and replicated to other projects.
As in the other case studies, stimulating stakeholders with very different agendas to think collectively rather than from their own perspective only, and in this way identifying new development possibilities, was an important outcome of the process.
Kiel West in Antwerp
During the testing in the Antwerp Kiel area a large range of stakeholders were brought together. For the first time data collected from different partners provided an overview of qualitative and quantitative aspects of the district. This improved the understanding of the problems of the neighbourhood, and can now form a basis of further development. In 2017, a new neighbourhood development project will be launched by the department of social planning of the city of Antwerp. The project aims to connect different stakeholders in the neighbourhood and work on a wide range of subjects. Thereby energy related issues (insulation, energy poverty etc.) have been put high on the agenda.
Furthermore, the student workshop organised in the framework of the case study had a positive impact on the neighbourhood. The presence of the students in the community centre led to inspiring and interesting interactions. Residents and local stakeholders were involved in the different work sessions and a presentation of outcomes was given to them. The uninhibited and direct approach of the students was very much appreciated. The ECODISTR-ICT project thus definitely contributed to rising awareness among stakeholders, and improved the interaction and mutual understanding between them.
Finally all stakeholders have now access to data and maps that quantify and visualise energy related issues in the Kiel area.
1.4.1.2 Forthcoming impact for project partners and stakeholders
Throughout the ECODISTR-ICT project, valuable insights have been gathered which directly impact the operations of the ECODISTR-ICT project partners, as well as the stakeholders connected to them, e.g. in city administrations. This way multi-faceted knowledge has been produced in ECODISTR-ICT and can be adopted for other contexts. This includes:
▪ Knowledge on stakeholder interactions in district (re)development processes, which was especially insightfull for the more technically oriented profiles, and which had a direct impact on the software development. Direct impact on social acceptance is part of the decision criteria of ECODISTR-ICT. The project has built further on criteria for the social dimension as e.g. mentioned in CONCERTO plus (affordability, active participation) and includes these in different modules;
▪ Novel insights on the data gathering for district information modelling purposes. In the beginning a data heavy approach was envisioned (geometrical information, energy consumption data, building physics, façade images, etc.), but during the process a more efficient method was discoved that was fine for the purpose of the project. The team learned about different ways that data could be organised and stored;
▪ Data management and data interoperability: different data types, formats and details were gathered and used simultaneously;
▪ Systematic approach: the complexity of urban retrofitting was unravelled and the systematic approach developed can be replicated in other projects;
▪ For the engineering and architectural offices partnering in the project, new insights were gathered on technical retrofit possibilities from a wide range of disciplines and support tools such as the modules for financial decision-making, calculation modules on Life Cycle Costing (LCC) and affordability. These will impact the day to day work of the SMEs involved beyond the scope of the project.
▪ One project partner envisages using the IDSS to support the development of an urban greenfield. If successful, this would prove the suitability of ECODISTR-ICT for new district planning as well.
ECODISTR-ICT’s collaborative approach has been presented in several bilateral and small meetings with stakeholders and possible clients by the ECODISTR-ICT partners. The reviews are positive, and stakeholders in the energy transition of the built environment like the approach of considering multiple values in one effort. This positive feedback and the sense of urgency due to the Paris COP 2015 agreements might open up chances to further implement the IDSS in district retrofit projects. This has led to some tangible leads for implementing the IDSS in real cases, including:
▪ Ongoing talks on the potential use of ECODISTR-ICT in a national innovation and transition program in the Netherlands;
▪ TNO will propose to its partners in the Ruggedized project to use the ECODISTR-ICT IDSS in the Lighthouse project of Zuidplein, Rotterdam (NL);
▪ VITO has met with the Flemish regional administration (BE) to discuss the possibilities of using ECODISTR-ICT in urban renewal efforts. The administration shows strong interest in the tool as part of a set of regional policy instruments;
▪ A major energy provider in Belgium has showed interest in investigating the business development opportunities related to the IDSS;
▪ After a successful collaboration in the ECODISTR-ICT test case, Bipolaire Arquitectos was invited by the City of Valencia to be part of a new H2020-consortium for a project on Nature Based Urban Retrofitting. In the proposal, ECODISTR-ICT will be used as the design tool for the cases (Valencia, Manchester and Wroclaw). The GrowGreen proposal for the H2020-SCC-2016-2017 (Smart and Sustainable Cities) call was awarded in December and will probably start in April 2017. ECODISTR-ICT will be used in three urban retrofit projects that will be executed before 2022.
1.4.1.3 Wider impacts resulting from the completion of the ECODISTR-ICT project
By delivering the ECODISTR-ICT IDSS as an open source software platform, future users (e.g. local community development agencies, local authorities) and knowledge developers can tap into the results and thus create a growing community of active users and developers with possibilities for replication in many other contexts. A support group is aimed to continue and to grow after the project end.
ECODISTR-ICT adopts a holistic approach, considering environmental, technological aspects, technology integration (targeting both the buildings and the broader urban environment), as well as extensive stakeholder collobaration as the key for successful district (re)developments. The IDSS supports this by means of data gathering facilities, calculation modules and visual representations, to reach a common understanding and data driven decicion making process to upgrade the sustainablility of a district.
The real strength of the ECODISTR-ICT IDSS lies in complex urban retrofit processes in which interdisciplinary issues arise, often requiring the connection of specific additional calculation modules tailored towards local needs.
The open source nature and modular structure of ECODISTR-ICT allow to create wider impacts for a multitude of domains and stakeholders in the field of urban retrofitting such as:
Benefit to the local stakeholders in districts beyond the ECODISTR-ICT case studies
The use of the ECODISTR-ICT IDSS will be directly beneficial to the district inhabitants and other stakeholders in the value chain. By including an interdisciplinary and flexible set of KPIs, the project contributes to the expansion of social value that comprises the quality of life of the inhabitants, comfort, mobility, and appreciation of the urban environment. The integrated decision making towards sustainable neighbourhoods can thus directly impact local inhabitants, SMEs, and other local stakeholders:
▪ By choosing appropriate retrofit measures, the energy efficiency of existing buildings can be improved, resulting in the reduction of energy use and CO2 emissions. Through coordinating retrofitting and renewal on district level, the number of energy-efficient buildings can be increased, and benefits of scale can be exploited, e.g. enabling large-scale uptake of renewable energy sources for heating and cooling systems;
▪ The use of resources in a district can be optimized, e.g. in relation to transportation, waste disposal, consumption of materials etc.;
▪ Social acceptance of interventions can be improved, by explicitly taking into account inhabitant’s preferences, affordability indicators and qualitative KPIs;
▪ Urban ecosystem services can be optimized, e.g. by integrating green roofs and façades, exploring the impact of retrofit measures on urban heat island effects, etc.
Impact by guidance to the Local Authorities and Community Development Agencies
In today’s practice, all too often expeters work in parallell and isolated from each other, which leads to suboptimal interventions in districts and might even lead to lock-ins, preventing future upgrades of a district. This was the reason to adopt a holistic approach in ECODISTR-ICT, considering technological aspects, technology inte¬gration (targeting both the buildings and the broader urban en¬vironment), multi-stakeholder involvement as well as the user as the key for successful impact. ECODISTR-ICT has thus exploited the potential of combined and coordinated retrofitting efforts. This provides insights and guidance to local authorities aiming to ameliorate district retrofitting processes through the introduction of incentives, codes, and obligations. ECODISTR-ICT has also demonstrated the changing requisites of society in terms of affordability and energy-requirements.
A wider impact on local communities and development agencies can further be gained through the open source character of the tool.
Since the developed tool and modules have been tested in real life case studies, ECODISTR-ICT has effectively connected communities, local authorities, building owners, developers, tool owners, software developers and knowledge institutes. The feedback of these case studies has been used to strengthen the methodological approach embedded in the IDSS.
Direct economic impact towards inhabitants and businesses
Since ECODISTR-ICT boosts the economic advantages of coordinated and combined efforts on retrofitting implementation, the resulting scenarios can stimulate larger scale renovation compared to the current situation where this takes place building by building.
The use of ECODISTR-ICT IDSS will improve coherent decision making by different stakeholders across the entire value chain, and so help to optimize it. They can collaborate through the tool and modules, and retrieve direct access to the information ranging from building to policy level. Trough the calculation modules different alternative district developments can be tested. The ECODISTR-ICT IDSS can therefore directly result in facilitation and support of dialogues between local, national and international urban stakeholders involved in decision-making. In this way beneficiaries of the tool and method are not only inhabitants and authorities but also providers of utilities, construction companies, investors and property developers, architects, urban planners etc.
If construction projects are realized, the urban renovation scenarios can increase economic activities and employment (particularly in the local context and for SMEs).
Direct impact on existing directives and governance methodologies
Transforming the existing districts into sustainable urban areas will require different solutions and scenarios due to national regulations, contexts, policies as well as different energy-consumption behaviours and energy-saving requirements of the local habitants. However, depending on local circumstances and priorities, methods and tools to facilitate innovative governance and knowledge generation can be very similar across Europe.
ECODISTR-ICT provides deepened insights, throughout Europe, to support multi-stakeholder involvement in sustainable district transformation. Besides, the district renovation scenarios supported by the ECODISTR-ICT platform result in an environment where the exchange of scientific knowledge with practice can take place and be bridged. Through connection to scientific progress and visualization in the ECODISTR-ICT project, the governance methodologies can be enhanced and be aligned with current scientific and technological innovations. Therefore, ECODISTR-ICT adds value both for a participatory approach of urban (re)development and for wider impact regarding the implementation of the directive on the Energy Performance of Buildings and the Roadmap to a Resource-Efficient Europe.
Wider impacts on society, including businesses and academia
By delivering the ECODISTR-ICT IDSS as an open source software repository, future users, businesses and academia can further built upon its results.
The ECODISTR-ICT IDSS contains specific features, which can enhance current practices as well as future software tools in many ways. A non-exclusive list of these features:
▪ It offers a broad, interdisciplinary approach of complex societal challenges which lacks in current methods and tools;
▪ It takes into account qualitative KPIs, and also has a broad view on some of the quantitative KPIs; e.g. by incorporating longer return-on-investment periods than prevailing in most current methods and tools. This is important for investments which have a high societal value but require a much longer return-on-investment time, like investments in energy savings and clean local energy production;
▪ It provides insight into the possibilities for the combination of multiple business cases of urban stakeholders. Not only does this facilitate the realization of plans and interventions, but it also makes the process of urban (re)development more efficient by saving on costs for these processes (‘transaction costs’);
▪ The modular setup, including a generic data format and the IMB hub, allow expanding the IDSS with future updates. Thanks to a generic connector, such a calculation engine can even consist of an Excel sheet. This allows interconnecting multiple non-purpose built tools for district evaluation into one single decision support system;
▪ A data crowd sourcing tool allows gathering data by individual inhabitants, and storing the data in a geo-referenced database, to be used as input for the calculation methods;
▪ The system operates fully web-based. By operating ‘in the cloud’, servers and data can be spread out over multiple locations. This allows to easily scale up the system in the future, and removes the need for installing and updating the software on local computers. An up to date browser is sufficient to access and use the IDSS.
1.4.1.4 Added value of the EU approach
This project envisions a new market area for software companies across EU that can benchmark the best available technologies to adopt in the national contexts, where data gathering from the households, stakeholders involved in districts and authorities involved in policy levels are not complete yet. In this way ECODISTR-ICT opens new business channels to gather, filter, and process the data from different levels.
The project has benefited from the EU level of co-operation in order to establish:
▪ The integration of EU wide available decision tools for buildings/districts as starting modules for the interactive platform;
▪ The validation of the innovative tool in varying environments of building typologies, end-use patterns, legislative frameworks, stakeholder positions.... This enhances the replication potential;
▪ The combined networking of the project partners in different strategic EU initiatives.
The potential follow-up in different countries after the project ends is crucial for establishing a critical user quantity for further deployment.
1.4.2 Dissemination and/or exploitation of project results
1.4.2.1 Dissemination of project results
Beyond the contribution the project has had towards the impacts addressed above, it is equally important that:
▪ Project outputs can be fully exploited and be the most usefully put to work;
▪ The knowledge gained through the project, and more generally the information generated by the project, can be made available to all interested organizations;
▪ Elements of excellence of the project can be reused and replicated in other projects.
To maximize the efficiency of the above-mentioned efforts, the project has ensured the engagement of key stakeholders, identified as potential beneficiaries of the project outcomes. In order to achieve this goal, consortium partners were selected with regard to their potential to interface with relevant initiatives and liaise with relevant stakeholders. Categories of involved key stakeholders for the ECODISTR-ICT project included:
▪ Software developers;
▪ Architects;
▪ Civil and environmental engineers;
▪ Urban planners;
▪ Design offices;
▪ Housing companies and building owners;
▪ Contractors;
▪ City governments;
▪ Utilities (energy, water, transport);
▪ Local/Regional/National governments;
▪ European Commission;
▪ Research institutes;
▪ Universities and schools of urban planning / architecture;
▪ Local community development agencies;
▪ EU-wide federations and associations of relevant organizations;
▪ Other EU and national programs and initiatives;
▪ General public.
The main dissemination channels that were used by the project include:
▪ EC Dissemination Mechanisms, including publication of project information on the EC’s official websites and networking with other ongoing related activities such as the parallel FP7 project Fasudir (Friendly and Affordable Sustainable Urban Districts Retrofitting, http://fasudir.eu/). ECODISTR-ICT and FASUDIR had a mutual assistance at project events in Valencia and Torino, in order to incorporate project’s efforts into a wider context of international cooperation;
▪ EC Conferences & Cluster Meetings: the project has participated to EC Conferences (see list of dissemination activities) and the clustering meetings organized per thematic area, particularly in what concerns the project’s technological/scientific dissemination to the annual events organized under the auspices of the EC;
▪ Publications, including selected journals (under review), newspapers, and scientific or targeted publications through e.g. conferences (see list of dissemination activities);
▪ Web presence, including:
o The creation and enlivenment of the project website (http://ecodistr-ict.eu/): a dynamic website was developed and continuously up-dated throughout the project duration. Project deliverables and publications were made available at the website and project events were promoted. It was possible for all website users to provide feedback on the project activities and publications. Visitors and community members were allowed and encouraged to independently contribute to the dissemination of project results, thanks to features allowing them to post contents and share contents through a variety of social networks (e.g. LinkedIn). The project’s website was the web contact point to the wider audience leading the interested party to information material, as well as contact details of the project partners. Each partner’s website was linked to and from the project website;
o Contribution to social media such as such as Sustainable Places LinkedIn (https://www.linkedin.com/groups/4713944/profile) and Twitter (https://twitter.com/sustainplaces) and other blogs/websites focusing on relevant topics, e.g. partner websites. Through the use of social networks, project results and events were disseminated and discussions on relevant topics were launched, contributing to building of a strong and committed community, thus increasing the project impact;
▪ External events, a list of target events and planned participations were drafted and agreed by project partners at an early stage and kept updated during the project lifetime. Participation to external events included the creation and dissemination of oral and visual presentations, video documentations, and the distribution of printed leaflets;
▪ Project events, independently organized by the project, contributed to disseminate knowledge and raise awareness of a targeted public, allowing to go into a detailed analysis of project objectives and activities and to establish personalized interactions. Specific efforts were dedicated to organize effective networking sessions enhancing opportunities for exploiting project results.
Dissemination through the above-mentioned channels was achieved thanks to several dissemination supports developed by the project, including:
▪ Professionally designed promotional materials, including a project fact-sheet and brochure. The project brochure introduced the project vision, key developments undertaken in the project and their strategic relevance. This brochure was a key document disseminated by the consortium as a whole and by each consortium partner;
▪ A reference PowerPoint presentation, customized by speakers for each presentation of the project they made;
▪ Press releases, announcing the launch of the project and its key milestones;
▪ Project newsletters and posts, on social media and relevant websites, contributing to raise awareness and to keep attention toward project activities and achievements high;
▪ Project documents, both internal and public. To increase the impact of the project and to efficiently spread excellence and disseminate knowledge, the greatest number of project deliverables was given a “public” level of dissemination (see also http://ecodistr-ict.eu);
▪ Online documentation towards the future use and development of the ECODISTR-ICT IDSS, including videos, a user wiki, and technical notes for developers.
A full list of dissemination activities is available on the ECAS portal.
1.4.2.2 Exploitation of project results
Already at the proposal stage, all partners defined preliminary exploitation plans, aligned to their product portfolio and business plans. The identification of a strategy for the exploitation of project results was critical in order to create a bridge between the results of the research and other potential developments that go beyond the scope of the R&D project itself, such as the definition and implementation of a successful business plan. To facilitate this task, inputs from project partners were summarized in an Exploitation Plan Matrix. Each partner positioned itself in one or more market sectors, detailing the reason of its choice, its level of interest in a specific market sector and, possibly, its potential business model. The resulting matrix, matching market segments and partners, shows in which market segment(s) a partnership among two or more consortium members, or even among all the members of the consortium, is a promising strategy. The matrix constituted an effective instrument to promote partnerships and define potential business models.
An external partner (IS-Practice) was contracted to support the development of potential business models for the consortium. IS-Practice conducted interviews with all partners and also participated at the consortium workshop in Warsaw where business models were further elaborated. A report was delivered by IS-Practice to VITO within the contract 'Request for proposals for potential business exploitation' of 5 April 2016 (tender reference OV-1604-ECODISTR-ICT). The report provides an overview of activities conducted by the ECODISTR-ICT partners and IS-practice in order to define the sustainability strategy for the results of the ECODISTR-ICT project. It analyses these sustainability-related activities, discusses appropriate business models and outlines several options for legal structures. Based on these findings, the report provides recommendations incorporated in an exploitation roadmap for the upcoming months.
A Lean Business Model Canvas for the product is presented in the exploitation roadmap together with suggestions on the pricing models (direct sales model in combination with the open source model and brokerage/marketplace model for the potential later phase). The roadmap also contains an inventory of the intellectual property for which access rights shall be agreed before bringing the product to the market, and template tables with expected costs and revenues to be used for drafting a financial plan.
Many partners shared similar goals in terms of exploitation plans, which promoted cooperation. Exploring in detail this potential for cooperation and complementarities is a result of task 6.3 which identified cooperative patterns between project partners for exploitation of ECODISTR-ICT results, as well as an overall common exploitation plan.
Three ECODISTR-ICT partners (VITO, TNO and STRUSOFT) are currently in the process of negotiating a memorandum of understanding for a joint effort to offer ECODISTR-ICT as a software service. Although the code is publicly available, the effort of setting up servers and databases could be an important bottleneck for future users. A commercial offering of hosting the tool – possibly expanded with a helpdesk or additional support – could be beneficial for future users. Furthermore, it could generate the necessary funds to keep the ECODISTR-ICT outcomes operational (marketing, security patching, possibly functional upgrades,...). As suggested by IS-Practice, a shift towards a non-profit legal entity or commercial legal entity may be considered in a later stage once the business model will have been established, e.g. on the basis of a brokerage-marketplace concept.
1.4.2.3 Open source software repository
In its present status, the ECODISTR-ICT IDSS is a working prototype which is ready for use by expert users. The developed foreground methods and tools are published as open source software in the public domain using the Github repository. The BSD open software licensing scheme applies, which is a software license imposing minimal restrictions on the redistribution of the software code to the users of the software on one hand, and disclaims any warranties or liabilities by the providers of the software on the other hand.
The ECODISTR-ICT IDSS has been envisioned as a modular framework. This implies it is not a one-size-fits-all solution, and it will never reach a state where it is completely ready. Rather it is a flexible solution which can be adapted and expanded towards project specific needs. This was proven by the ECODISTR-ICT case studies in which it became apparent that decision processes and needs for KPIs and related calculation modules differed greatly amongst the five locations. In order to ease the process of connecting location specific calculation modules, a generic connector for Excel sheets was developed and documented.
Through the GitHub software repository, the ECODISTR-ICT software routines, algorithms and instructions for developers are available to the outside world, not only for direct use in district renovation processes, but also for researchers and practitioners to further build upon. Future users and IT developers have free access to share their updates and expansions with the community of users. Great effort has been put into documenting the use and IT development of the IDSS, e.g. by means of extensive annotiations in the GitHub. This also accounts for the guidelines for end-users in the ECODISTR-ICT Wiki.
List of Websites:
Project website: http://ecodistr-ict.eu
Project coordinator:
Han Vandevyvere, dr. eng. arch.
Project manager / Senior researcher Energy District Design
Unit Sustainable Energy and Built Environment
HQ: VITO NV | Boeretang 200 | 2400 Mol | Belgium
Office: EnergyVille | Thor Park 8310 | 3600 Genk | Belgium
Phone +32 (0)14 33 58 68
han.vandevyvere@energyville.be
Technical coordinator:
Stijn Verbeke, eng.
Project manager Energy District Design
Unit Sustainable Energy and Built Environment
HQ: VITO NV | Boeretang 200 | 2400 Mol | Belgium
Office: EnergyVille | Thor Park 8310 | 3600 Genk | Belgium
Phone +32 (0)14 33 59 61
stijn.verbeke@energyville.be

Project partners:
www.vito.be
www.arup.com/global_locations/netherlands
www.bipolaire.net
www.cstb.fr
http://omgeving.be
www.sp.se
www.strusoft.com
www.tno.nl
www.vabi.nl
www.white.se