A Fault Handling Process for Faults in District Heating Customer Installations

Abstract

Faults in district heating (DH) customer installations cause high return temperatures, which have a negative impact on both current and future district heating systems. Thus, there is a need to detect and correct these faults soon after they occur to minimize their impact on the system. This paper, therefore, suggests a fault handling process for the detection and elimination of faults in DH customer installations. The fault handling process is based on customer data analysis since many faults manifest in customer data. The fault handling process was based on an analysis of the results from the previous fault handling studies, as well as conducting a workshop with experts from the DH industry. During the workshop, different organizational and technical challenges related to fault handling were discussed. The results include a presentation of how the utilities are currently working with fault handling. The results also present an analysis of different organizational aspects that would have to be improved to succeed in fault handling. The paper also includes a suggestion for how a fault handling process based on fault detection using data analysis may be designed. This process may be implemented by utilities in both current and future DH systems that interested in working more actively with faults in their customer installations.

1. Introduction

District heating (DH) systems have been identified to play a key role in the decarbonization of the heating sector [1] since they provide a cost-efficient way to provide energy-efficient heating based on renewable and surplus heat sources [2]. However, the DH technology must develop to reach its full potential in the energy systems. This development includes a reduction of the distribution temperatures in the systems [3], which would make it possible to integrate more low-temperature heat sources such as heat from renewable heat sources [4]. It would also be possible to introduce more excess heat from processes in industrial and commercial buildings [5], and other processes where excess heat is created, such as sewage treatment plants [6]. Reduced temperatures would also decrease the heat losses from the systems [7] and increase the power-to-heat ratio in combined heat and power (CHP) plants [3].

One way to obtain lower system temperatures is to eliminate faults in the systems causing high distribution temperatures [7]. One of the main categories of such faults is faults located in the customer installation, i.e., faults located in the customer substation or the customer’s internal heating system [8]. The internal heating system and the substation consist of several components that may break, malfunction, or perform sub-optimally in different ways. In other words, a fault is not only broken components, but could, for example, also be a change of the settings in the controller of the substation, or poor balancing of the customer’s internal heating system. The common denominator for the issues referred to as faults is that they usually cause high return temperatures from the customer installations, which results in overall high distribution temperatures in the DH systems [7]. Faults in the customer installations must thus be eliminated if a utility wants to reduce the system temperatures. However, few DH utilities are currently working to eliminate these faults in a structured and organised way.

This study aims to investigate how a utility may work to obtain successful fault handling in their customer installations and suggest a fault handling process where fault detection using data analysis is one of the main components. The reason for including data analysis in the fault handling process is that many of the faults that may occur in a customer installation manifest themselves in customer data, where they appear as deviations from the normal behaviour of the substation [8,9].

Successful fault handling processes are not only an essential aspect of the current DH systems; they will be even more important in future systems. The DH industry is currently transitioning towards the fourth generation of district heating (4GDH). 4GDH is characterized by low distribution temperatures, low heat losses, ability to integrate renewable and surplus heat, and provides synergy effects that will be important in the future, smart energy systems [3]. These systems have been suggested to operate with supply temperatures of around 50 °C and return temperatures of around 20 °C [3]. The conventional DH temperatures are significantly higher than this—for example, the average supply/return temperatures in Sweden and Denmark are 86/47 °C and 77.6/43.1 °C, respectively [8]. The low temperature levels of the 4GDH system cause the system to be sensitive to temperatures changes and will thus be negatively affected by high return temperatures from the customer installations. In [10], Averfalk and Werner also show that the future heat supply methods are more cost-sensitive to temperature changes, which means that there is an economic incentive to maintain the system temperatures at a low level in the 4GDH systems.

This implies that detecting and correcting faults in buildings connected to DH systems is a problem that should be handled with high priority in both current and future systems. However, a large share of the buildings in the current DH systems contain faults that affect the return temperatures. Studies have shown that as many as 74 % of the buildings in a DH system may contain faults [8]. There is thus a need to improve the current fault handling processes at the utilities. Current utilities mainly base their fault handling processes on so-called corrective or preventive maintenance schemes. Corrective maintenance is an unplanned maintenance task performed when a fault has already occurred and caused a failure or malfunction in a system. Preventive maintenance is performed regularly with a predetermined interval of time between the maintenance occassions [11]. These type of maintenance schemes are, in general, costly in terms of person-hours and costs of spare parts [12]. One way to improve the fault handling capacity at the utilities is to transition towards predictive or condition-based maintenance. Both methods rely on the analysis of data from the customer installations. In condition-based maintenance, the analysis methods consist of algorithms monitoring the state of a system, and predetermined thresholds or conditions in the algorithms determine when maintenance has to be performed [13]. Predictive maintenance relies on methods capable of predicting the next state of the customer installation as faulty or healthy, making it possible to detect imminent faults and remediate them before an actual malfunction or failure in the customer installation appears [14].

The development of new maintenance schemes based on data analysis goes with the current development of new information and communication technologies (ICT) within the energy industry. ICT in the energy sector include among else, sensors, smart meters, and different software tools [15]. In future energy systems, ICT is seen as a facilitator in the integration of the different energy sectors and within the different sectors themselves [16]. Different ICT solutions provide a possibility to perform demand-side management, provide advanced control strategies for the energy system, and perform fault detection and diagnosis in, e.g., HVAC (Heating, Ventilation, and Air Conditioning) systems [17]. The DH industry’s interest in ICT solutions has increased as the technology has improved and as more data from the system have become available [7]. Customer data were available to the European DH utilities since they are obliged by the European Energy Efficiency Directive to bill their customers according to their actual heat consumption [18], thus having to collect data of their customers’ heat use. Previous studies have shown that this data may be successfully used for fault detection purposes, for example, in [8] where Gadd and Werner used the temperature difference signature to detect deviating behaviours in data from 140 different substations. A similar method was presented by Sandin et al. in [9], but the parameter investigated in this study was the heat load pattern instead of the temperature difference. Another approach presented by Xue et al. is to use data mining and association rules to devise a method for identifying deviating patterns in DH customer data [19]. Other studies have developed fault detection methods based on clustering, for example, [20], where Calikus et al. cluster heat load patterns into 15 different clusters and then investigate heat load patterns that deviate significantly from the identified clusters. The interest in developing automated fault detection tools in DH systems is further shown in Swedish industry collaboration Smart Energi. Smart Energi is a collaborative organization where 11 different Swedish DH utilities collaborate to develop digital solutions for the energy and DH industry [21].

There is thus a variety of different methods that may be implemented for fault detection of customer installations. However, the implementation of such methods comes with several challenges, including both organizational and technical aspects. The challenges include who should be in charge of the fault handling process, how to use the results from the fault detection method in the DH utility’s organization, and how to make the fault handling process as efficient and well-functioning as possible. While many different studies are currently looking into different fault detection methods, none have taken a holistic perspective of how a fault handling process using customer data could be implemented at an active DH utility. This study, therefore, suggests such a workflow for fault handling. The workflow is partly based on the results and conclusions from studies [22,23,24,25], and partly on the results from a workshop conducted with DH experts from several utilities. This methodology made it possible to complement the results from the research papers with expert knowledge from the industry. In this way, it was possible to obtain a fault handling process that would make sense to implement in the organization of a DH utility. The workflow includes several different steps, including data analysis, site visits to buildings, and a structured way to report faults. The workflow has also been developed with a future perspective in mind, where predictive maintenance could be the basic approach to fault handling.

The study has been conducted in Sweden, and therefore, representatives from Swedish utilities participated in the workshop. This means that the results described in this paper are presented from a Swedish context. However, both current and future aspects of the DH technology are very similar in other countries, especially technological aspects related to fault handling and decreased return temperatures. There may be some organizational aspects that differ, e.g., the ownership structures of the DH customer substations. However, these aspects may be transferred into the fault handling process suggested in this paper. Further, the aim of the suggested fault handling process is primarily to provide a template and guideline that may be used by DH utilities when implementing fault detection tools in their fault handling processes. This includes describing the main features of the process, as well as describing both technical and organizational key aspects of successful fault handling processes. Thus, the fault handling process is not outlined in detail, but rather provides the main outline for such a process. Therefore, the results in this paper may be transferred to the contexts of both other countries, and other DH utilities.

2. Methodology

The suggestion for a workflow was developed in three steps. The first step was to develop an initial suggestion for the workflow. This was done by studying the results in research papers [22,23,24,25] to identify relevant aspects of successful fault handling processes. One key aspect investigated in studies [22,23] is to use fault detection methods based on analysis of customer data capable of detecting faults in customer installations rapidly and with high accuracy. The results from [24] further showed that the DH utilities are interested in using such methods. Therefore, one of the key components in the fault handling process suggested in this study is automated fault detection based on customer data analysis.

The next important aspect is that the fault detection methods can identify installations with an actual fault. This problem was partly investigated in [22,23], where it was concluded that labelled data were needed to improve the accuracy of the fault detection methods. Labelled data may, in this case, be described as data where a specific fault is known to have occurred, in a specific installation, at a specific point in time. A suggestion for how to solve this problem was presented in [25], where a taxonomy for labelling customer data sets containing deviations caused by faults in the DH systems was introduced. The taxonomy is also identified as an essential component in the fault handling process suggested in this paper. Implementing the taxonomy in the process would make it possible to obtain labelled data sets as the fault handling process is carried out.

The study conducted in [24] presented several organizational aspects of successful fault handling. These aspects include clear incentives to why fault handling is important to a utility and how to involve the customers in the fault handling process. These aspects have also been taken into consideration when developing the fault handling process in the current study.

Additionally, all previous studies have been conducted in close collaboration with active DH utilities. During this process, several discussions and meetings regarding fault handling have taken place. The discussions have provided an in-depth insight into the technical, analytical, and organizational challenges that may arise when conducting fault detection using customer data analysis. The authors have thus been able to identify the steps, tools, workforce, and other solutions needed in a successful workflow for fault handling. The fault handling process suggested in this study was developed based on these results.

The second step was to evaluate the fault handling process together with eight Swedish district heating utilities. The evaluation was done during an online workshop, where the workflow was presented, evaluated and improved. The participating utilities’ previous experiences of fault handling were also discussed. Before the workshop, a survey consisting of three questions regarding the utilities’ previous experiences of fault handling were distributed to the participants:

1.

What methods are you currently using to detect faults in your customer installations?

2.

What roles within your organization are currently involved in your fault handling processes? What role has the main responsibility?

3.

Are you using any digital tools to facilitate your fault handling process? If so, what tools?

The results from the short survey were then presented during the workshop and served as a basis for the discussions regarding the utilities’ previous experiences of fault handling. The workshop was conducted as a qualitative, semi-structured group interview. The qualitative format was chosen since the purpose of the workshop was to gather more knowledge about different aspects of the fault handling processes and the implementation of a new fault handling process. The semi-structured interview format was chosen due to the possibility to ask follow-up questions to understand further the in-depth aspects of the answers being given. The group interview method is a way to provide a stimulating environment where the group setting allows the interviewees to interact with each other and gain new insights and ideas during the interview by continuing the argumentation of the other participants. This way of conducting an interview makes it possible to obtain collective views of a topic. However, the personal views of a topic may be more challenging to obtain [26]. The topics discussed during the workshop included technical and organizational aspects of the utilities’ previous experiences of working with fault handling, as well as their opinions of future, successful fault handling processes based on analysis of customer data.

The workshop was conducted with DH experts from eight different DH utilities of varying sizes, and the participating utilities had DH systems in many different parts of the country. The eight participating utilities were elected to participate in the study since they had all shown a previous interest in improving their fault handling processes, either in the previous studies about fault handling conducted by the authors or in connection with the activities conducted in Smart Energi. They had thus already, to some extent, considered different issues related to automated fault handling processes. This provided a possibility to obtain more in-depth answers from utilities that were already familiar with the problem of fault handling.

The DH experts from the different utilities had somewhat different roles within their respective organizations, but they were all somehow involved in the fault handling processes at their respective utility. The group included technical service personnel working actively with the customer installations, personnel responsible for the organization of the fault handling processes, and personnel working actively to develop and improve different energy services that aim to help improve the fault handling at the utility.

By having several different utilities represented in the workshop, it was possible to obtain opinions and information from several different utilities based on their organizational structure and specific challenges related to the implementation of automated fault handling processes. By having several different roles represented, it was also possible to investigate how different parts of a DH organization may be affected by implementing an automated fault handling process. It was also possible to investigate the specific challenges to that part of a DH organization.

The workshop was conducted online and took 2.5 h to complete. Two researchers conducted the interview. One of the researchers acted as moderator and asked the questions which had been prepared before the interview. The second researcher acted as an observer and helped the moderator taking notes. In this way, it was possible to observe the group interactions while also obtaining notes of the discussion conducted during the workshop. The workshop was also recorded in the online platform where it took place, which made it possible for the researchers to revisit the material when compiling the results from the workshop. After the workshop, the material obtained was analyzed and divided thematically into three main categories: (i) Previous experiences of fault handling at the utilities, (ii) Aspects of future fault handling processes, and (iii) Input for the suggested fault handling process based on data analysis. All three categories contained information about both technical and organizational aspects of fault handling processes.

In the third step of developing the fault handling process, the process was improved and clarified using inputs from the workshop. This material was collected from the third category of workshop material, (iii) Input for the suggested fault handling process based on data analysis. When analyzing the material, it was clear that additional steps had to be added to the process, as well as displaying a clearer division of responsibility between different roles involved in the process.

3. Results and Analysis

In this Section, the results from the workshop regarding the utilities’ previous experiences of fault handling will be presented first. After this, some essential organizational aspects of future fault handling processes are analyzed based on the information and opinions gathered during the workshop. The last part of this Section presents the suggested fault handling process, and each part of the developed process is described.

3.1. Previous Experiences of Fault Handling at the Utilities

The results related to the utilities’ previous experiences of fault handling are based on the answers in the short survey the utilities answered before the workshop and the discussions during the workshop. The results are presented in a synthesized way, which means that the answers from the survey and the workshop are presented side by side based on interesting themes identified during the material analysis.

3.1.1. Current Fault Detection Methods

The answers to question 1 in the survey, “What methods are you currently using to detect faults in your customer installations?” showed that all participating utilities currently detected most of the faults in their customer installations due to their maintenance agreements. This interesting aspect raised several questions regarding how the maintenance agreements were currently designed to facilitate fault handling. Therefore, the maintenance agreements were further discussed during the workshop. The utilities had different types of maintenance agreements, but they all included service visits to the customer installations performed regularly. A common solution was that the single-family houses had one type of service agreement, while companies and multi-family houses had a different type of agreement. Another common solution was that the maintenance agreement was included in the DH agreement for some customer groups, e.g., single-family houses. Other customer groups would have to sign a separate maintenance agreement with the utility if they wanted the utility to perform service visits to their installations. The time between the service visits varied between the DH utilities. Some performed service visits every year, while others visited their customer installations every other year. An interesting solution was that one of the utilities recently had changed their maintenance agreement so that they visited their customers every other year instead of every year. The utility offered their customers a discount on repairs needed to be done in the installation to compensate for the skipped visit. This solution made it possible to keep the customers interested in the maintenance agreements.

As previously mentioned, the utilities primarily detected faults when performing their regular service visits. However, the utilities stated that their primary purpose of the service visits was not to detect faults. Instead, the primary purpose of visiting the customers was to maintain a good relationship with their customers. The utilities experienced that this was obtained during the service visits since they could meet the customers and discuss the performance of the customer installations. They were also able to improve the customers’ confidence in district heating, thereby decreasing the probability of customers converting from district heating to other heating alternatives. If needed, the utilities also helped the customers to improve the performance of the installation. On such occasions, the utilities did detect faults that affected the performance. However, since this was not the primary purpose of the visit, the utilities did not experience the service visits as a systematic way to detect faults in their customer installations. Instead, they experienced that detecting faults during service visits was a bonus to the other benefits of having maintenance agreements. This aspect shows a discrepancy in the fact that the maintenance agreements were the primary way for the utilities to detect faults in customer installations and what kind of faults were detected during the service visits. The way the current service visits were performed resulted in the utilities mainly identifying faults that the customer experienced had a negative impact on their heat comfort. However, such faults do not always cause high return temperatures. This meant that the utilities, to a large extent, did not identify the faults that actually affected the DH system during the service visits.

The customer relationship aspect of the service visits was clearly important to the utilities. This aspect was apparent when discussing the effects of the COVID-19 virus, concerning the possibility of still performing the service visits (the study was conducted during April 2021). Many of the utilities stated that several of their customers were either seniors or part of risk groups. Therefore, it was not possible to visit the customer installations to the same extent as is being done during a typical year. Thus, the utilities had to find other ways to maintain their customer relationships, and one of the utilities had started performing online service visits. During these visits, technical service personnel made a video call to the customer, and the customer brought a phone or tablet with a camera to their substation. The technical service personnel then instructed the customer on how to perform a simplified operational control of the substation. In this way, the utility could still provide the customers with the service they paid for while still respecting the COVID-19 guidelines. The utility stated that this solution had become very popular among the customers who appreciated the utility’s effort to find a solution that works even when a physical site visit could not take place.

Despite the maintenance agreements being the primary way for fault detection, the utilities also stated that they performed fault detection using some other methods. Many of the utilities performed regular monitoring of their customer data. The monitoring included analyzing the return temperature performance, cooling performance, and overflows of their customer installations, where top-ten-lists of customers with poor cooling or overflow performance were produced. By analyzing the overflow, it was possible to create a list where the customers with the most considerable impact on the DH system were placed in the top ten. The list gave a priority order for what customer installations to visit first. The lists were mainly generated by analyzing meter values collected from the meter data collection system, either directly in the program or by analyzing the meter readings in Excel lists. The top-ten customers were then contacted and visited, depending on whether they had maintenance agreements or not. A customer without maintenance agreement was contacted to notify them of their installation’s poor performance and asked whether they wanted to sign a maintenance agreement to help remediate the problem. It was then up to the customer whether they wanted to fix the fault or not. A customer with a maintenance agreement was first contacted, and then a service visit was performed. The utilities performed the analysis on different time intervals—some utilities performed this type of analysis every month, while some utilities did the analysis once a year. Other utilities performed this type of analysis when they felt that they had some time to spare but stated that they were interested in improving the temperature performance of the customer installations in their DH systems.

Some of the utilities had also implemented more advanced tools for analysis in their fault handling processes, as was seen in the answers to question 3 in the survey, “Are you using any digital tools to facilitate the fault handling process? If so, what tools?”. Some utilities used tools developed by external actors, e.g., the data analysis tool K2 [27], while others had developed their own analysis tools. The tools were developed to indicate deviating behaviours in, e.g., the energy consumption profiles of the customer installations. Most utilities were currently using these tools on a sporadic basis. Many utilities had also recently started using their tools and had not yet integrated them into their fault handling processes to their full extent. One utility used their analysis tool as an added service towards the customers that had a service agreement. This solution meant that they analyzed their customers’ energy consumptions regularly. If a customer with a service agreement showed up in the list of customers displaying a deviating behaviour; the utility performed a service visit to that customer. The utilities participating in the workshop had thus shown an interest in the digitalization of their fault handling processes. They had, however, not come far in the process of implementing these tools on a larger scale. This implies that it is not sufficient to have digital tools available—they have to be implemented into the organization of the utility, and someone has to work actively with the tool to detect faults.

Other ways to detect faults in the customer installation included the customer contacting the utility after experiencing an issue with the heat comfort in their building or a leakage in their customer substation. Despite the utilities discovering faults in this matter, the utilities experienced that the customers were not a very reliable type of fault detection if wanting to detect faults that affect the system temperature levels. The customer will only contact the utility if a problem with heat comfort occurs. However, many faults affect the system negatively but do not affect the customer heat comfort [7]. Thus, the customer may not detect many of these faults. Such faults have to be detected by the utilities instead. There were also examples of utilities that only detected faults through their maintenance agreements and customers contacting the utility. Thus, if the customer did not have a maintenance agreement; no other work was being conducted to detect faults in the customer installations. The latter also relates to who is responsible for correcting faults that do not affect the customer heat comfort but negatively impact the DH system. In Sweden, most customers own their substations, which means that they, on paper, are responsible for ensuring that the substation works as it should. However, the utilities experienced that the customers were less likely to correct faults that only affect the DH system and not the heat comfort in their installation. The utilities, therefore, expressed an opinion that they should be the ones responsible for correcting these faults. However, this was hard to do when they did not own the customer substations. Some utilities, therefore, believed that a solution to this problem would be that the utilities owned the substations in future DH systems.

The utilities further stated that their main problem is not to detect the customer installations that are deviating significantly from the rest of the installations. These installations are quite easily found using analysis methods that they have already implemented in their fault handling schemes, e.g., the overflow method. However, the utilities struggled to detect the installations that continuously have a negative effect on the system without having a clear profile of poor performance when conducting service visits or manual analysis of customer data. Such faults could, e.g., include a problem with the control of a control valve, causing the control valve to open and close at unwanted instances. These faults must be identified and corrected if wanting to reach lower system temperatures. Therefore, the utilities stated that these faults should be prioritized when developing automated fault handling processes, especially when developing automated fault detection methods. They also stated that these types of fault detection methods would be of great interest to them to improve their fault detection schemes.

3.1.2. Organizational Aspects of Current Fault Handling Processes

As may be deducted from the answers related to the fault detection methods used by the utilities, there were many different ways to perform fault handling in a DH utility. The differences in work procedures were also apparent when asking the utilities about the organizational aspects of their fault handling schemes. In the survey, the utilities were asked what roles in their organization are involved in their fault handling processes and what role has the primary responsibility of fault handling. The main common feature of the utilities’ fault handling processes was that some technical service personnel was involved. The rest of the organizational structure of the fault handling processes differed between the different utilities depending on how the utility was organized and what part of the organization was responsible for customer installations. In some of the utilities, the fault handling processes were controlled by the division of distribution. The reason for this was that they were also responsible for the operation of the customer installations. Other utilities had a division dedicated to operation and maintenance, whose primary purpose was to ensure that all parts of the DH system work as they should. This work included properly functioning customer installations.

However, the utilities lacked someone in charge of the fault handling processes of the customer installations. The lack of this person resulted in a lack of follow-up in the fault handling processes, which the utilities experienced was a big problem. During the workshop, they stated that it would be advantageous to perform follow-ups on the work that was to be done and had been done in a structured way to investigate the value of an effort to eliminate faults in customer installations. Thus, there should be a clear stakeholder, with a clear set of requirements for what was to be achieved in the fault handling processes. The lack of a stakeholder made it hard to create clear incentives within the utility to work with fault handling. To create clear incentives was a problem since the part of the organization that has the most to benefit from successful fault handling, i.e., (usually) the production, does not work actively with the customer installations. They were thus not a natural part of the current fault handling processes and did, in most cases, not take an active role as a stakeholder either. There were thus no clear incentives to work actively with fault handling for the rest of the organization. This aspect shows that fault handling may easily fall between the cracks in the work procedures conducted by the DH utilities without a clear stakeholder in the process.

The results from the workshop also showed that there are some different organizational aspects to consider regarding the technical service personnel. From an organizational point of view, a DH utility usually considers a customer installation to consist of three main parts: the heat meter, the customer substation, and the internal heating system of the customer. The last of the three is usually the customer’s responsibility to maintain, while the utility may help the customer with problems in the heat meter and substation. These two parts are usually the responsibility of two different parts of the organization of a DH utility. Thus, faults in the heat meter should be handled by the meter division. In contrast, faults in the substation should be handled by the division in charge of issues related to the substation (as previously mentioned, the division in charge of this differed between different utilities). There may thus be two separate divisions involved in the fault corrective part of the fault handling process. Thus, the work order must be assigned to the correct division depending on the nature of the fault. The utilities further stated that some customers used other companies to carry out maintenance of the customer installations. This situation meant that the utilities were not responsible for the maintenance of these installations but instead had to depend on the external service technicians to maintain the performance of the customer installations. An aspect of this, which the utilities experienced to be a problem, was that they did not receive any information about faults in these customer installations.

3.2. Aspects of Future Fault Handling Processes

During the workshop, several different aspects of future fault handling processes were discussed. This Section presents some aspects that a DH utility has to consider when implementing data analysis methods for fault detection in the fault handling process.

3.2.1. Future Fault Detection Methods

When introducing data analysis into the fault handling workflow at a utility, it is essential to identify the purpose of the data analysis. The results from the workshop show that the utilities are primarily interested in analysis tools capable of automatically detecting indications of faults, i.e., fault detection. Several utilities stated that such a tool should detect and indicate deviations independently without involving a human in the process. Using this kind of tool would make it possible for the utility to instead focus on and allocate person-hours to the rest of the fault handling process where human involvement is needed. These situations include, e.g., the correction of faults in the customer installations where technical service personnel is needed.

The results from the workshop show that the utilities’ main interest is in fault detection methods that immediately flag deviations that occur suddenly in the data—i.e., deviations in data that occur suddenly and may be complex for the human eye to detect. Some faults are not clearly visible in data at all instances, e.g., faults in the space heating system that are only visible in customer data when there is no domestic hot water load. Such faults may be hard to identify when performing manual data analysis since such analysis is usually performed on the current measurements and not historical data. It is thus possible to overlook the symptoms of these faults. By having an analysis tool capable of detecting deviations in data at all instances, it would be possible for the utility to act quickly and perform an action to correct the fault. The utilities compared this to the current situation. They primarily performed different types of data analysis on a monthly, yearly, or sporadic basis and primarily worked with top-ten-lists. This work procedure made it hard for them to detect sudden deviations in data, and they only investigated the top ten worst performers. Therefore, they may overlook many other installations that are not performing as they should. These problems would be remediated if using automated data analysis tools ready to perform fault detection at all instances.

The utilities also experienced that automated fault detection tools would make it possible to create new energy services and business models. One solution mentioned was that the utilities would be able to offer the customers a new type of maintenance agreement based on data analysis. The utilities would then use data analysis to detect faults in the installations and reach out to the customers directly to help them correct the fault. There is an added value in this—by reaching out to the customers about faults in their customer installations, the customers would be made aware that something is wrong in their installations. Thus, there would be an incentive for the customer to correct the fault, and it would also be easy for the customer to do so—all they would have to do is say yes to a service visit. By working in this way, the utilities would be able to detect and correct more faults than they are currently capable of doing. The utilities also saw an opportunity to further improve the customer relationship by working in this way. These kinds of digital tools would also help the utilities to work more proactively with fault handling. A proactive fault handling work would make it possible for the utilities to contact the customer about a fault instead of relying on the customer contacting the utility when experiencing a problem with heat comfort in the installation. This would reduce the dependence on the customer acting as a fault detector in the current fault handling processes.

The utilities also stated that they would be interested in data analysis tools capable of performing predictive fault detection. Predictive fault detection methods involve different types of algorithms capable of predicting the next state of the system being investigated, in this case, a DH customer installation. These methods make it possible to detect imminent faults before they have had an impact on the system. By detecting faults at this early stage, it would be possible to correct the faults before they actually affect the return temperatures. These types of fault detection methods also align with the predictive maintenance schemes described in Section 1.

3.2.2. Organizational Aspects of Future Fault Handling Processes

When analyzing the results from the workshop, it was clear that the utilities considered the organizational structure of the fault handling processes to be an essential aspect of successful fault handling. However, some organizational aspects had to be improved if they were to conduct more structured fault handling schemes. The most important aspect was to, as previously mentioned, identify a clear stakeholder in the fault handling process. A clear stakeholder would improve the follow-up and monitoring of the fault handling process and make it easier to allocate resources to the fault handling processes. They stated that even though they would be interested in working more actively with fault handling, the lack of allocated resources impeded their work. The lack of resources made it hard to assign someone the task of fault handling, and they were not able to spend money to, e.g., procure digital tools needed for fault detection. Therefore, an important aspect of future fault handling is identifying a clear stakeholder and allocating resources to the process.

The lack of a stakeholder may be related to the utilities not having identified the added value of detecting and eliminating faults in their customer installations. As previously mentioned many of the utilities participating in the workshop experienced that there were possibilities for improving the customer relationships if working actively with the customer installations. However, there are also economic values related to the elimination of faults in the customer installations. In many cases, faults in customer installations cause high return temperatures, and the elimination of faults is thus a possibility to reduce the return temperatures. Previous studies have shown that the economic value of reduced return temperatures may amount to 0.5 €/(MWh, °C) [7]. Thus, DH utilities have an economic incentive to work with the elimination of faults in their systems. However, the economic value of reductions of the return temperatures should be evaluated for each DH system. Few of the DH experts participating in the workshop were aware of whether this kind of value had been calculated for their respective systems. The DH utilities should therefore calculate and make their employees aware of such values. Doing this work would make it possible to create more clear incentives for a utility to work with fault handling. It would also clarify the need to have a stakeholder in charge of the process to obtain the economic value of reduced return temperatures. Thus, a DH utility needs to identify a clear goal of what they are to achieve when performing fault handling and, perhaps most importantly, what the value of eliminating faults in their system is.

3.3. A Suggestion for a Fault Handling Process Using Data Analysis

The following Section will present the suggested workflow. The initial version of the workflow has been improved using the results from the workshop. An illustration of the suggested fault handling process may be seen in Figure 1. Each step in the process is important to the fault handling process and should not be excluded. The workflow takes the form of a closed cycle, which signifies the importance of using the information obtained in the “real world” to improve the different steps of the fault handling process, such as the data analysis step. Each step of the workflow will be described in detail in Section 3.3.1, Section 3.3.2, Section 3.3.3, Section 3.3.4, Section 3.3.5, Section 3.3.6, Section 3.3.7, Section 3.3.8 and Section 3.3.9.

3.3.1. Collecting Customer Data and Information

In a fault handling process based on customer data analysis, the customer data itself is critical. Thus, the first step of the fault handling process is to collect data from the customers’ heat meters. It is also important to obtain other information about the customers, such as customer ID numbers and where they are located in the DH system. The data used as input for the analysis tool should be of high quality and preprocessed so that the data format is suitable for the fault detection algorithms in the analysis tool.

3.3.2. Analysis of Customer Data

The next step of the fault handling process is to analyze the customer data to detect deviating behaviours in the data that may indicate a fault. The analysis requires an automated data analysis tool capable of handling a large amount of customer data. Initially, the data analysis step should primarily include fault detection since this is the one most important task at the moment—to obtain faster fault detection. In the longer term, the data analysis step may also include fault diagnosis, i.e., detecting faults and indicating what fault is present in a customer installation. Once the fault detection algorithm has detected a deviating data pattern, the data analysis tool should indicate that a suspected fault is present in the installation. Even though the data analysis should be performed automatically, it is important to have a person in the organization that is responsible for the analysis being carried out. There should thus be a data analyst involved in this step.

3.3.3. Other Indications of Faults

The workflow presented in this study mainly focuses on fault handling using analysis of data to detect faults. However, as stated in Section 3.1.1, there are several ways that a fault may be indicated, e.g., if a customer contacts the utility when experiencing issues with heat comfort in their installation. These indications of faults also need to be included in the workflow. Therefore, they have been added to Figure 1 either as inputs to the data analysis tool or as an immediate indication of a fault in the third step of the fault handling workflow. Using the indications as an input for the data analysis tool makes it possible to further investigate the performance of the customer installation before deciding to visit the installation. However, some faults may be more urgent and should thus not have to pass through the entire fault handling process before being treated. These fault indications could instead enter the fault handling process in the third step of the process.

3.3.4. Decides on Continued Fault Handling

The next step in the fault handling process is to decide if and how an indication of a fault should be further investigated in the process. This step requires a person that is capable of processing the fault indications and making such a decision. This person should have good knowledge of the characteristics of the local DH system and the customer installations located in the system. This knowledge makes it possible for the utility to prioritize between different fault indications, based on, e.g., the size of the customer and where it is located in the system. It would thus be possible to prioritize the faults that have the most significant impact on the function of the DH system or is present in the most fault-sensitive customers. It is also important that this person is aware that some deviations that occur in the data may not be a fault that has to be corrected. As mentioned in the introduction, many different kinds of issues may cause a deviation in data. Thus, it is possible that a change in how heat is being used in a building, e.g., if a new family moves into a single-family house, may occur as a deviation in the customer data. Other examples are that a customer performs energy efficiency measures in the house, installs an alternative heat source such as a heat pump, or that the customer is, in fact, a prosumer (i.e., both produces and consumes heat in the DH system). These examples are not faults per se but will generate a deviating pattern in the customer data. Therefore, the person in charge of deciding whether a deviation should be treated further must be aware that such changes may occur and that he or she is capable of making decisions based on this information.

In this workflow, the person in charge of deciding on further fault handling is called a service admin (short for service administrator). To decide whether an installation should be visited or not, the service admin may have to gather more information about the installation by, e.g., contacting the customer to ask about the performance of the installation or collecting more information from service records and earlier indications of faults. This information will make it possible for the service admin to perform an educated decision about if the fault should be further handled in the fault handling process or not. By involving a service admin in this step, it will also be possible to decide what part of the organization should be further responsible for the fault handling. As discussed in Section 3.1.2, two different parts of the organization may be involved in the fault handling process, depending on if the fault is located in the heat meter or the customer substation. Thus, the service admin should allocate faults to the correct part of the organization. However, this task may be challenging, especially if the analysis tool only performs fault detection and not fault diagnosis. Thus, the “wrong” part of the organization may be allocated a case of fault handling. However, by having a close collaboration within the utility, it should be possible to resolve such issues and help each other in the fault handling process.

3.3.5. Documents Decision

If the service admin decides that a fault should not be further investigated, it is essential to document this decision. A reason for not visiting an installation could be, e.g., that it is not prioritized in the current fault handling process since its system impact is small compared to other installations. However, the installation could still be interesting to visit in the future and should still be monitored. By documenting this decision, the information will be available in future cycles of the fault handling process. Suppose an installation has several of these reports. In that case, it may indicate that the installation should be visited even though it has not been the highest priority in previous fault handling cycles.

3.3.6. Creates Work Order

After the service admin has identified a fault indication that should be further handled, a work order must be created. This work order specifies what part of the organization should handle the fault and which installation should be visited. The work order should also contain information about the equipment installed in the customer installation and if other faults have occurred in the installation previously. It may also be that some faults cannot be identified during a site visit due to the nature of a fault. For example, some faults may only cause deviations in customer data when the outdoor temperature is above or below a specific outdoor temperature. Thus, these faults may be hard to detect if the service visit is not performed when these circumstances are in place. Therefore, it may be valuable to include information regarding this in the work order, e.g., by instructing the technical service personnel to look at historical data before visiting the installation to retrieve as much information as possible about the nature of the fault. In this workflow, it is the service admin that is responsible for creating the work order. The information included in the work order should be in a format that is easily understandable and relatable to the people who perform work based on it. In this case, this means that the information written as the specifics of a work order has to be easily understood by technical service personnel. Therefore, the service admin who writes the report must be well familiar with the service technicians’ work. Thus, there are significant advantages in using a person in this fault handling step instead of a computer.

3.3.7. Performs Site Visit

After the work order has been created, a site visit is performed. This site visit involves a service technician going out to the installation of interest and investigating the customer installation for any possible faults. Before performing the visit, the service technician may have to visualize some customer data from the installation to achieve a basic understanding of the fault in the building. During the visit, the technician fills in a service protocol. The protocol should indicate the date of the service visit, if the installation contained a fault or not, what the fault was and its location in the building, and if anything has been done to correct the fault. It is important to have this information in a standardized format since this makes it possible to use the information to, among else, improve the accuracy of the fault detection algorithm in the analysis tool. A service application should be used to receiving everything in a standardized format. The service application should contain all the information that the service technician may need during the site visit. The way that faults are reported in the application should be based on a structured way to label different faults, for example, the taxonomy developed in [25]. By using such a structure, the utility would obtain structured information about faults in their customer installations that would be possible to use in several different parts of the organization, see Section 3.3.9.

3.3.8. Creates Report from Site Visit

After performing the site visit, it is important to create a report of the site visit. This report may be used for several purposes, including reporting what was done during the visit to the customer and reporting to different systems at the DH utility. The report should be based on the service protocol that is filled in during the site visit.

3.3.9. Reports Back to Different Systems

The last step of the fault handling process is to report back to different systems at the utility after the site visit report has been created. The systems include business systems, service records, and the data analysis tool that performs fault detection. Reporting back to these systems makes it possible to bill the customer for the cost of correcting a fault, to maintain an updated record of different faults that have occurred in the DH system, and to improve the performance of the fault detection algorithm. The latter advantage arises if using the information in the service report (i.e., was a fault present, and if so, what fault) to label the deviating patterns in the customer data. Labelling deviations in data results in data sets where a specific fault is known to have occurred at a specific time. If using this data to update the algorithm’s performance, the algorithm will be more accurate in its detection. Updating the algorithm will also reduce the number of false alarms obtained from the algorithm, making it easier for the service admin to prioritize the different faults. The information reported back to the data analysis tool may also be used to close the current fault handling case for that specific customer installation.

3.3.10. A Note on When a Fault Handling Case Has Been Completed

Another critical aspect of a fault handling process is to decide when a fault handling case has been completed, i.e., when has a fault been wholly treated in the fault handling process, and who decides this? There has to be a clear role responsible for this decision, who is responsible for closing fault handling cases and recording that this has been done. In this workflow, it is suggested that the data analyst takes this role. He or she will collect information from the data analysis tool and the information reported back from the service visit to decide on the specific case. It may be that the fault handling process has to be iterated several times before actually finding the root cause of the deviation in data. The need for several iterations arises because some deviations in data may have several different root causes, which means that one fault may be identified in the installation, which is not the only fault. A second visit to the customer installation may thus be needed if the performance of the installation does not improve after correcting a fault.

4. Concluding Discussion

This paper describes a fault handling process for handling faults in DH customer installations, where fault detection based on data analysis is one of the most important components. The results further show that several organizational aspects are important to consider when implementing this type of fault handling process and identify some of the key components to succeeding with the fault handling processes. In addition, the results include information about how utilities are currently working with fault handling and identify some areas where there is a need for improvement.

When considering the results related to current fault handling processes, it is clear that the utilities are not working with faults in their customer installations in a structured way. The most common way to detect faults is when performing service visits that are a part of the customers’ maintenance agreements. However, the utilities mainly saw the service visits as a possibility to improve customer relationships. Faults detected during such visits were primarily seen as a bonus. Some utilities also used digital tools to detect faults. This was primarily done on a sporadic basis, and there was no clear structure in how to work with the results from such tools. It was not clear who should correct the faults and what resources should be used to do so. The utilities participating in the workshop all experienced that this may be since the importance of fault handling was not clear in their respective utilities. Few utilities had calculated the economic value of eliminating faults causing high return temperatures in their systems. Thus, there were no clear incentives for working with, and what part of the organization had the most to benefit from, fault handling. Because of this, there were no clear stakeholders in the utilities’ current fault handling processes. These results indicate that if the utilities want to detect and eliminate faults on a larger scale, there is a need to implement more structured fault handling processes with clear stakeholders. They also need a clear division of responsibility within the fault handling organization and accurate fault detection methods specified on detecting faults in customer installations. These aspects are important in the current DH systems but will be even more critical in the future 4GDH systems to avoid unwanted increases in the temperature levels.

There is also a need to change the utilities’ perceptions of fault handling in their systems. Today, the utilities mainly handle faults if they have time to spare. The problem of faults in the customer installations is thus not highly prioritized within the DH industry. However, the utilities participating in the workshop did express an interest in working more actively with fault handling. They were also interested in more advanced tools for fault detection. By investigating the value of fault elimination and assigning a clear stakeholder in the fault handling process, it would be possible to improve the situation. A stakeholder will demand that the faults are handled and make sure that resources are allocated to the fault handling process. Having a stakeholder in the process would make it possible to, among else, allocate person-hours to detect and eliminate faults and procure more advanced data analysis tools. These key factors will make it possible to eliminate more faults in the customer installations, improving the possibilities to obtain more resource-efficient DH systems with low environmental impact.

The fault handling process suggested in this paper gives an outline for how fault handling based on data analysis may be implemented in a DH utility. The process contains the main features and describes the importance of feedback within such a process. Some organizational aspects that are important to consider when implementing the process have also been provided, such as the importance of clear stakeholders and different roles involved in the fault handling process. It is important to keep in mind that each DH utility faces its individual challenges when changing how they work with different issues. An example is that all utilities have different systems that they use in their work, such as different business and customer systems. Thus, it would not make much sense to provide a list of different systems that have to be integrated into the process. Neither would it make sense to suggest a more complex and complicated process since the goal is to provide a process that many different utilities may implement. Therefore, the suggested fault handling process does not detail the specifics of the different stages in the process. Instead, the fault handling process provides a general layout for fault handling, where key steps and roles are outlined. A utility interested in implementing data analysis in their fault handling process could use this suggestion as a template and then identify their specifics in each step of the process to make it fit their organization.

An aspect that affects the generality of the results is that the utilities participating in the workshop had somehow already considered implementing fault detection based on data analysis in their fault handling processes. Thus, they were already familiar with the different aspects and challenges of implementing such methods. This was an essential aspect of the workshop since the goal was to evaluate a fault handling process using data analysis. If including utilities without any experience of fault handling using data analysis, it might have been challenging for these utilities to provide adequate answers to the questions being asked during the workshop. It is, however, possible that utilities that have never considered implementation of such methods would have contributed with different thoughts and aspects than the more experienced utilities. However, the utilities participating in the workshop were all at different stages of the development of successful fault handling processes. Some had just started considering an implementation, while others had come further in the process and were now using automated fault detection on a more or less regular basis. Therefore, the material obtained during the workshop contained answers from utilities with several different levels of experience of fault handling.

Further, a difference between the district heating business and other businesses where fault handling is being conducted is that other business (such as industries) own their equipment and have a large share of the equipment "in-house". In district heating, the customers usually own their customer installations, both the internal heating system and the customer substation. This means that the DH utilities do not have the same authority to fix faults in the customer installations as when conducting fault detection in other businesses. In DH, you need the customer to approve such measures. Therefore, fault handling is not as straightforward for a DH utility as it is for other, similar organizations. Therefore, the suggested fault handling process suggests solutions for involving both the customer and the DH utility in the fault handling process, therefore improving the possibilities to obtain successful elimination of faults.

The fault handling process further requires some digital tools to be available. These tools include a data analysis tool for fault detection and a service application that provide a structured way to report the identified faults. Such tools are currently under development and will be available in the near future. Once these are in place, it would be interesting to implement the suggested fault handling process in practice at a DH utility and investigate the outcome of this work. Then it would also be possible to evaluate the economic value of systematic elimination of faults in DH customer installations.