IoT Middleware Platforms for Smart Energy Systems: An Empirical Expert Survey

: Middleware platforms are key technology in any Internet of Things (IoT) system, considering their role in managing the intermediary communications between devices and applications. In the energy sector, it has been shown that IoT devices enable the integration of all network assets to one large distributed system. This comes with signiﬁcant beneﬁts, such as improving energy efﬁciency, boosting the generation of renewable energy, reducing maintenance costs and increasing comfort. Various existing IoT middlware solutions encounter several problems that limit their performance, such as vendor locks. Hence, this paper presents a literature review and an expert survey on IoT middleware platforms in energy systems, in order to provide a set of tools and functionalities to be supported by any future efﬁcient, ﬂexible and interoperable IoT middleware considering the market needs. The analysis of the results shows that experts currently use the IoT middleware mainly to deploy services such as visualization, monitoring and benchmarking of energy consumption, and energy optimization is considered as a future application to target. Likewise, non-functional requirements, such as security and privacy, play vital roles in the IoT platforms’ performances. of devices, data persistence and energy IoT middleware emerging a wide range of commercial and non-commercial alternatives. While the introduction of universal standards in IoT a pious hope for the future, there are recurrent building services, concepts, protocols and functionalities that are found in both commercial and non-commercial platforms. This paper presented an expert assessment of requirements, limitations and challenges for large-scale deployment of IoT middleware in smart energy systems. The results corroborate ﬁndings in the literature, such as the need to standardize semantic data models, data point labels and APIs to improve portability and interoperability between devices and services from different vendors, More than 50% of the participants considered uniﬁed data models important; at the same time, only 15% of the experts currently used a uniﬁed data model, marking this as an important area for future research. Results show that the application layer protocols used by most of the middleware platforms are MQTT and HTTP, whereas on the network communication level, LoRAWAN, WiFi and 4G/LTE are the prevalent technologies. In the literature, the most important non-functional requirements were identiﬁed as: interoperability, scalability, ﬂexibility and openness, energy efﬁciency, security and privacy. Results of the survey show that experts consider security a crucial feature in any middleware platform, in addition to showing a big interest in developing open solutions. The fact that about 30% of the survey participants were not willing to make their data models freely available shows that further research should be devoted to highlighting the importance and the commercial and non-commercial beneﬁts of using open-source solutions and contributing to open-source projects. Development of uniﬁed data models, data representations and naming schemes by


Introduction
The Internet of Things (IoT) is understood as a ubiquitous, complex network of networkable, heterogeneous entities or "things" [1]. It collects environmental data; interacts with the physical world; communicates through internet standards; and provides applications, data transfer and data analysis [2] with minimal human interaction [3]. Developments in web and communication technology and the wide availability of microchips have accelerated the integration of computing machinery into all aspects of day-to-day life.
The application of IoT technology to the urban and building sector provides opportunities, especially within the context of sustainability [4,5]. Socioeconomic changes, such as the trend towards larger homes, the automation of household chores and the advent of energy-consuming entertainment devices, have caused the buildings sector to become the largest contributor to global energy demand [6], accounting for 40% of the energy consumption in the European Union (EU) [7] and 78% of greenhouse gas emissions in the EU and Iceland [8]. The integration of renewable energy technologies into the existing energy systems and the resulting decentralization and introduction of environmentally-friendly

Main Contribution
The digitalization of the energy sector greatly contributes to the transition towards environmentally friendly, low emission energy systems [22]. Several initiatives, such as "Digitalising the energy sector" [23] and "GAIA-X" [24], aim to provide digital infrastructure and energy services by developing trustworthy intelligent solutions for power generation, energy storage, power transmission and consumption monitoring. The IoT is the backbone of such an intelligent system [25]. Since no standards for IoT middleware or IoT energy platforms exist [26], the requirements of such platforms are unknown, and providers will often start their business based on few available components which might not be sufficient for practitioners' needs. Hence, our study contributes to this digital transformation by gathering the opinions of experts on requirements, promising technologies, limitations, etc., of IoT middleware platforms for smart energy systems. Expert surveys are a powerful research method allowing the systematic study of hard-to-measure phenomena through the aggregation of specialized expert knowledge [27]. Based on expert interviews, we define requirements for IoT middleware platforms; these include topics such as vendor locks, security, data models and communication technologies. In addition, we analyze promising applications, such as control services and demand-side management. To the best of our knowledge, there are no expert surveys on IoT middleware platforms for smart energy systems. To assess the state-of-the-art and the requirements and challenges for IoT middleware in smart energy systems, we devised a two-stage research plan, comprising a literature review and a quantitative expert survey that included (i) city officials who were responsible for smart city projects, (ii) experts in energy and energy technology companies and (iii) experts who were planning and/or operating buildings and districts. The literature review stage included reviewing IoT platform architectures, functional and non-functional requirements and the most common technologies and protocols in order to formulate survey questions that represent the real market needs of the people who operate these services in the energy sector. During the survey process, the experts were asked to list the tools they use/plan to use as IoT platforms, and their current and future applications; and to assess the importance of certain technologies, protocols and features in the IoT middleware frameworks.
The rest of the paper is organized as follows: In Section 2, we discuss recurring building blocks, concepts, protocols and functionalities found throughout the catalog of IoT middleware solutions for smart energy systems and identify the requirements and challenges in the development and roll-out of middleware platforms. In Section 3, we identify and analyze a set of commercial and non-commercial IoT middleware solutions used in the context of smart energy systems in terms of their functionalities, their nonfunctional characteristics and their protocols. In the subsequent sections, we present and discuss the results of the survey among building and smart city experts.

Background
There is a myriad of IoT devices offered by a considerable number of vendors, many of which ship with their own firmware that employs proprietary semantic models and communication protocols. While the choice of communication protocols has converged to a select few de facto standard protocols, such as Message Queuing Telemetry Transport (MQTT), Hypertext Transfer Protocol (HTTP), LoRaWAN and Bluetooth Low Energy (BLE), the problem of incompatible semantic models remains largely unsolved [28]. Consequently, most devices are incompatible with any software stack other than the one distributed by the vendor of the device. Therefore, operators often prefer integrated, proprietary solutions, even when these solutions do not fully address all their requirements [3].
Semantic models associating unambiguous, universal meaning to metadata are a key research interest. Sections 2.1-2.3 provide a brief background on the semantic interoperability and data models, main IoT architectures and definitions and the non-functional requirements most commonly considered important in smart energy systems.

Semantic Interoperability and Data Models
Semantic interoperability problems typically arise from ambiguities caused by missing standardization in the metadata schemata employed by the components of a heterogeneous system. The schemata most commonly found in the context of building automation are: eXtensible Markup Language (XML) [29]: which is a hierarchically structured data model, where comparison with a XML Schema Definition (XSD) is used to verify its structure. Information about things (concepts) discussed by the data model is generally fully contained within a single XML document.
Semantic Web Technologies [28]: The Resource Description Framework (RDF) and RDF schema (RDFS) constitute a graph-structured data model that is designed as a distributed knowledge-based system. RDF uses shared resource identifiers, which allows for expanding knowledge by defining entities that are linked to each other. The Web Ontology Language (OWL) RDF extends the RDF capability to organize concepts in a more object-oriented fashion and a more formalized description logic (cardinality and allowable relationships-OWL).
JavaScript Object Notation (JSON) [30]: is a lightweight, data-interchange, language independent format which uses conventions that are familiar to programmers of the Cfamily of languages, including C, C++, C#, Java, JavaScript, Perl and Python. JSON is built on two structures: a collection of name/value pairs, such as objects, structs and associative arrays in usual programming languages; and an ordered list of values similar to arrays, vectors and lists.
Significant effort has been devoted to introducing universal standards for a metadata schema in building automation by several non-commercial initiatives, such as Project Haystack [31], the Brick Schema [32], the IPSO smart object data model [33], the oneM2M specifications [34] and the Smart Appliance REFerence ontology (SAREF) [35], developed by the European Telecommunications Standards Institute (ETSI). The three most popular projects are: Project Haystack is a suite of open-source technologies. The main concept in Haystack is the use of "tags," which are pieces of information that document the attributes of any entity. Haystack defines data types (an extended version of JSON, to facilitate data exchange), file types (text format definitions to exchange the Haystack data types), an HTTP API protocol (for data exchange between servers and devices), an ontology (with a specific focus on buildings and districts) and so called "Defs" that can be used to define an extend the Haystack's ontology. Practitioners can use each of these definitions on their own or as a complete stack. The technologies and semantic data models provided by Project Haystack can be used in a wide variety of applications, including automation and control in energy, HVAC and lighting systems.
The Brick Schema provides an extensible open-source dictionary with terms, concepts and relationships needed for modeling buildings and districts. Flexible data models are designed to seamlessly integrate with existing systems. Brick applies a tagging system similar to Project Haystack; However, Brick provides formal semantic rules to ensure consistency and modeling support for spacial information, control relationships and operational relationships [36].
The SAREF ontology explicitly specifies core concepts in the smart applications domain, the main relationships between these concepts and axioms to constrain the usage of these concepts and relationships. The basic concept in SAREF is a device, which is defined as any tangible object that provides functions in a building. Functions are associated with commands and devices can change states. Devices can offer their functions as services to other devices via network. SAREF provides building blocks for each of these concepts and allows practitioners to separate and recombine the ontology based on individual needs. SAREF models can be seamlessly integrated with the Brick Schema.
A related concept was developed by OMA SpecWorks [37] in the form of the Next Generation Service Interfaces (NGSI) information model [38,39]. NGSI consists of an information model and an API to publish, query and subscribe to context information through well-defined operations. NGSI has been extended into the NGSI Linked Data (NGSI-LD) meta model and defines fundamental concepts of linked data models: entities, properties, relationships and metadata concepts: values and types. The FIWARE foundation [40] has developed an HTTP-based RESTful API for the revised NGSIv2 [41] interface.

IoT Platform Definition and Architecture
In the community, there is an ongoing discussion about the fundamental building blocks, layers and concepts in architecture of the IoT [26]. For instance, Farahzadi et al. [42] and da Cruz et al. [3] identify the three most relevant layers in IoT architecture as: users or applications; IoT platform; and devices and infrastructure. Jia et al. [43] and Domingo [44] define them as: perception, network and service. Keyur K. Patel [45] presents the IoT as four layers: smart device/sensor, gateways and networks, management service and application. According to the International Telecommunication Union, each IoT architecture should be divided into five layers: sensing, accessing, networking, middleware and application [46]. Another five-layer model, proposed by Antão et al. [47] consists of business, application, middleware, network and perception layers. Figure 1 illustrates the three architectures (three-layer, four-layer and five-layer architectures), their layers and their services. More advanced models, such as cloud and fog-based architectures [48] or the communicationcentric IoT reference model [49], and various six-or seven-layer models, can also be found in the literature.

Service Layer
Data management, data analysis, etc.
In this paper, we use a five-layer approach, derived from the model in [47]. It proposes a simple separation of layers based on their functionalities and can be described as follows:

1.
Business Layer: It offers a management and control of the IoT platform functions, including data analysis, (e.g., using Apache Spark [50] in case of dealing with big data) to help in the process of the decision-making by the responsible people.

2.
User/Application Layer: It is responsible for delivering and presenting the applicationspecific service to the end user. It defines a wide range of applications where the IoT platforms can be used, such as smart services applications.

3.
Middleware Layer: The concept of linking billions of individual devices and getting them to communicate with each other means that IoT systems are already inherently characterized by a high degree of heterogeneity [3]. The large number of different communication protocols, interfaces and platforms lead to heterogeneous IoT networks, which complicate the interaction. The task of middleware here is to function as a mediator between the devices by integrating the received data from the physical environment to the IoT-connected devices, networks and servers. This integration process also includes all the necessary operations, such as storing, analyzing and processing the data, allowing the connectivity between different and complex programs, which were not originally designed to provide this feature. Various protocols are used to provide the communication and services to the application in this layer. These protocols correspond to the application layer protocols in OSI model [51], such as:  [56]: It is a service-oriented, technologyindependent and platform-independent approach. It has created new and easy possibilities for communicating with Linux/Unix systems or embedded controls on other platforms and for implementing OPC connections over the Internet supporting both TCP and UDP. The fundamental element in OPC UA is the use of information modeling framework that turns data into information based on rules and building blocks necessary to expose an information model, and this imposed the different data models, which are described in Section 2. : An open standard for passing business messages between applications or organizations using TCP. It connects systems, feeds business processes with the information they need and reliably transmits onward the instructions that achieve their goals using the point/point and publish/subscribe interaction modes [58]. It was designed to achieve main goals of: message orientation; queuing; routing; security; reliability; interoperability. • Data Distribution Service (DDS) [59]: A middleware, M2M, Object Management Group (OMG) protocol and API standard for data-centric connectivity. It integrates the components of a system, providing low-latency data connectivity, high reliability and high scalability in publish/subscribe and request/response patterns over TCP and UDP.

4.
Network Layer: It is also known as the transport layer; it is responsible for transporting the data provided by the perception layer to the application layer. It uses an enormous number of standards and protocols to enable this connection, such as: • IP version 6 (IPv6) [60]: This has been designed to be an evolutionary step from IP version 4 (IPv4). The changes from IPv4 to IPv6 fall into the these main categories: expanded addressing capabilities; header format simplification; improved support for extensions and options; flow labeling capability; authentication and privacy capabilities. • ZigBee [61]: A low data rate, low-power-consumption, low cost, wireless networking protocol, to target automation and remote control applications. ZigBee's best quality is its low-power-consumption that can allow batteries in devices using ZigBee to last for several years. The main advantages of ZigBee over Z-Wave are the higher data rate and the ability to connect an unlimited number of nodes together. • Z-Wave [62,63]: A wireless protocol evolved by Zensys and confirmed by the Z-Wave Alliance for automation devices for homes and commercial environments. It enables reliable transmission of short messages from the control unit to one or more devices in the network with the minimum noise, low-power-consumption (less than ZigBee) and long battery life. It also operates at a low frequency range (800-900 MHz), which means a less congested band and covers a larger range of data transmission. On the other hand, in comparison with ZigBee, Z-Wave allows connecting a limited number of nodes, with lower data rates. • Bluetooth [64]: A wireless technology standard that is used for exchanging data between fixed and mobile devices over short distances using Ultra High Frequency (UHF) radio waves and building personal area networks (PANs) instead of wire connections. In the most widely used mode, transmission power is limited to 2.5 milliwatts, giving it a very short range of up to 10 m (30 feet). • WiFi [65]: It (also called 802.11) was released in 1997. It is a wireless technology that transmits data using high frequencies over short ranges (

5.
Perception layer: Physical/device layer, which includes all the passive, semi-passive and active hardware needed for gathering information from the environment, or taking actions in the physical system, such as sensors, actuators and other physical devices.

Non-Functional Requirements and Challenges of IoT Platforms
Non-Functional Requirements (NFRs) can be defined as the system attributes, which are not directly related to the offered functionalities, but are related to the emerging properties of the system. The importance of NRFs of the IoT middleware platform changes based on the perspective, the system domain and the end-users, and they provide a number of restrictions and challenges that the platform needs to address. Hence, when considering the smart cities and smart buildings domain, NFRs define the following challenges: • Interoperability: Different components of the IoT system must be able to connect and contact to each other. Historically, the building automation domain has always had interoperability issues, especially due to the segmented building process, leading to contractors offering trade-specific devices which are often incapable of communicating with devices from other trades. According to the economic research, up to 60% of the value that IoT systems might reveal is now locked by a lack of interoperability. Considering this, the IoT offers a great chance to actually improve interoperability by integrating and standardizing different components within the IoT platform [71]. The interoperability challenge combines three elements: 1. Device and connectivity: the starting point of the IoT architecture, which includes device capabilities and protocols.

2.
Data: several problems may arise when trying to combine data from different sources for different needs.

3.
Services/applications: these problems occur in the case of using data generated by a specific IoT device, in another application.
• Scalability: Device scalability defines its ability to adapt to the new changes in the environment, which is an essential feature for the growing IoT systems. Reliable IoT middleware needs to provide similar functionalities and similar quality of service (QoS) in small-scale and in large-scale environments [72]. • Flexibility and Openness [73]: Any IoT system needs to be flexible enough to support future technologies. Manufacturers typically create specialized hardware which gives optimal performance, while on the other hand, limiting the hardware's ability to track new updates and features. This introduces one of the most challenging problems for the IoT frameworks: vendor locking. Hence, a balance between software features and specialized hardware capabilities is one approach that must be considered in order to achieve the necessary flexibility Security [73,75]: Since a large number of "things" are connected together in one heterogeneous system, the security feature is fundamental in any system and includes all the different components. Thus, the system must be robust enough to deal with any of the possible security attacks by: firstly being able to detect the attack; then diagnosing the attack; and eventually deploying countermeasures and repairs. Considering an open, flexible, low power, lightweight platform makes providing the needed heavyweight security computations critical for future researches. • Privacy [73]: Human interaction, data exchange and wireless communication through the middleware platforms provide good functionalities, but also create a high possibility of violating privacy. Privacy solutions have been addressed by many works, offering secured authorization and authentication mechanisms for the users to access the data sources, e.g., the sensors and the data, in addition to encrypting the transmitted data during the communication.

Literature Review
A comprehensive analysis of IoT middleware platforms can be found in [3,76,77]; an application-domain-specific survey of cloud-based IoT platforms can be found in [21], which shows that application development and monitoring management are the mostly served domains by the current IoT clouds. An extensive state of the art review of cloudbased IoT middleware is presented in [78]. da Cruz et al. [79] provides a performance evaluation of 11 open-source middleware solutions based on qualitative metrics, in addition to a quantitative assessment of five of them (InatelPlat, Konker, Linksmart, Orion + STH and Sitewhere). The study concludes that Sitewhere outperforms all the other studied tools for the considered scenario. Ngu et al. [80] identifies and compares middleware platforms of different architectural types. They derive four key challenges in developing IoT middleware: a light-weight middleware platform that operates on power-constrained devices; an application-independent composition engine; a security mechanism that works in all resource-constrained environments; a semantic-based IoT device/service. The architectural designs and features of 16 cloud-based IoT platforms are analyzed in [20] in order to identify the gaps in the state-of-art IoT platforms and the theoretical foundations and vision of IoT. It also provides a set of principles for developing a model-driven IoT platform based on survey results, including providing Applications As a Service, using Capabilities Ontology to define the device's capabilities to sense and/or actuate and using RDF as a transport protocol. Hossein Motlagh et al. [81] presents a literature review on the applications of IoT technology in the energy sector with a focus on smart grids. It provides a summary of the challenges of using IoT in smart energy services, such as providing a reliable end-to-end connection, the integration of IoT with subsystems, standardization, providing efficient energy consumption, security-related issues and maintaining user privacy, along with possible solutions. Bedi et al. [82] analyzes the roles and impacts of smart IoT technology in digitizing electric power and energy systems, concentrating on the role of IoT sensors by providing an assessment of sensors' technical parameters. Martín-Lopo et al. [83] presents a comparative analysis of energy platforms for end users; analyzes recurrent hierarchical building blocks, main design options and strategies; and provides a set of IoT levels to evaluate the implementations of IoT technologies. The green quadrant report published by Verdantix [84] and Gartner's 2021 MQ [85] provide detailed comparisons of the most recent Industrial IoT (IIoT) solutions. In the next Section 3, we exclusively review the IoT tools and platforms that have been mentioned by the experts who were involved in the survey.

Middleware Platforms in Smart Energy Systems
Apache Kafka [86] is an open-source, distributed publish-subscribe messaging system. It focuses on collecting data from high-throughput streams into persistent storage. Apache Kafka clients and clusters communicate via binary TCP connections. These connections are comparatively complex to establish and maintain. In a setting where large numbers of IoT devices communicate through unstable, unreliable networks, the overhead might be prohibitive. It is, however, possible to extend Apache Kafka with MQTT connectivity, circumventing this issue. On the other end of a stream, Kafka can interface with a number of platforms, such as Java, .NET, PHP, Ruby and Python; and visualization services such as Grafana.
Aidon Gateware [87] provides a service package for Advanced Metering Infrastructure (AMI) management and assessment, including Aidon Gateware Head-End System (HES) which manages the head-end systems communications. The IoT communication in Geteware is provided using three parts: Aidon Linkware for interfaces integration to the Distribution System Operators (DSO)'s information systems; Aidon Gateware for management and execution of various AMM tasks based on scheduling using a graphical user interface; and Aidon Meteringware for data collection and storage from the smart devices.
Amazon Web Services (AWS) [88] is a suite of commercial, cloud-based, on-demand computing platforms. AWS IoT is a middleware solution that connects IoT devices with each other and to cloud services offered by AWS. It supports four communication protocols: MQTT, MQTT over secure web sockets, HTTP and LoRaWAN. AWS SDKs provide language-specific wrappers for the HTTP/HTTPs API to connect with custom applications on various platforms and with various languages, including Android, iOS, Python, Java, JavaScript and C++. Amazon provides seamless integration between device software, connection and management software (control services) and data analysis services.
Cisco Kinetic [89] offers a wide portfolio of commercial end-to-end IoT solutions ranging from network connectivity to cyber security. The Cisco Kinetic IoT platform consists of three modules, gateway management, edge and fog computing and data control. IoT devices can be connected via AMQP or MQTT. Application can be developed from pre-built functions in a proprietary SDK. The platform components can be used on a subscriptionbased license with optional visualization service components.
CO4 Cloud [90] is an energy management tool which provides an overview of the important energy, room and system data to the user. The provided features include energy monitoring and data visualization, data aggregation from the individual room to the portfolio, energy management, optimization and automation functions, energy accounting and billing, meter integration, virtual meters and data points, reports and data export, notifications, alerts and a ticket system. EDP Remote Energy Dynamics (Re:dy) [91] is an IoT service developed by EDP commercial. Re:dy connects and integrates the energy sources at home to be managed by the user. This platform needs a set of hardware devices in order to operate, which includes: Re:dy Box, Re:dy Plug, Re:dy Meter, Re:dy Switch and Re:dy plug A/C-an application in the EDP servers where the service is configured and a set of mobile applications for remote access.
Element IoT [92] is an IoT platform developed by ZENNER IoT Solutions GmbH in Hamburg. Element IoT includes a LoRaWAN network server, device and gateway management, and a number of data management functions. It provides solutions to improve the flexibility, interoperability and security of the system by supporting various communication protocols, such as LoRaWAN, NB-IoT, MQTT, HTTP, Sigfox, MS Azure and AWS; and supporting different integration technologies, such as REST, Websockets, MS Azure and AWS.
Siemens [93,94] is a global leader in power and utilities management. One of the services Siemens provides is the EnergyIP meter data management (MDM) application, which is currently enabling more than 200 electricity, gas and water utility companies to manage more than 90 million meters. In 2020, a cloud-hosted MDM started to be used, with the support of Amazon Web Services (AWS). The IoT-platform EnergyIP offers a set of tools and features, which address traditional and emerging use cases, such as billing. Additionally, it uses a unified data model and unified information technology (IT) and operational technology (OT) integration, which allow connecting smart meters from different vendors, with secured connectivity via wireless, radio, LAN and power line communication.
Enerbrain S.R.L. [95] is a company that provides solutions for optimizing energy consumption for air conditioning, improving environmental comfort and reducing CO 2 emissions and one's carbon footprint. The Enerbrain IoT solution offers remote control of heating, ventilation and air conditioning (HVAC) systems by connecting them to the cloud. The provided solutions include a set of sensors, actuators, controllers, meters, etc., such as eSense, eNode, ePLC and eMeter. The main IoT solution is eGateway, which connects the Enerbrain devices to WiFi or Ethernet (ETH) supporting WiFi-GSM-ETH communications in three different operating modes (from GSM to WiFi, from GSM to ETH, from ETH to WiFi).
FIWARE [96] provides a curated framework of building blocks for IoT middleware solutions, building upon the standards, ontologies and reference models described by the SAREF ontology and the NGSI specifications suite. The Orion context broker acts as the central entity in the middleware platform and supports communication via HTTP. Microsoft Azure IoT Central [98] is a commercial cloud-based application platform specifically aimed at enterprise-grade IoT solutions. It provides a webUI to connect, manage and monitor devices and connect them to line-of-business applications. IoT devices' communications are possible via MQTT, MQTT over WebSockets, AMQP, AMQP over WebSockets and HTTPS. High-level services such as visualization, data analysis and data monitoring can be implemented by using pre-defined application templates [99], such as smart meter analytics and solar panel monitoring, or by building custom applications from scratch.
Niota Cross IoT Platform [100,101] is an IoT platform for developing and deploying vertical IoT solutions across multiple industries. It combines data from various sources, such as sigfox, NB-IoT, LoRaWAN, M2M and NFC. Niota's IoT platform allows one to integrate new and old features and business models of Industrial Internet of Things (IIoT), within the current IT ecosystem. Additionally, it offers number of advantages, such as supporting different communication technologies; inbound and outbound interfaces; providing a visual IoT service builder; focusing on the integration, interoperability, flexibility and the security of sensitive data.
OdinS [102] offers smart solutions for infrastructure management of different applications, including industry, agriculture, environmental projects, intelligent buildings, smart cities, mobility and transportation. In the field of intelligent buildings and smart cities, OdinS provides solutions for improving energy efficiency in buildings and living spaces according to the facilities that are included, in addition to the integrated management in building and infrastructure networks and the cloud-based solutions with simultaneous and multi-user management. For the application designing, OdinS platform uses smart cities platforms such as FIWARE.
Telegraf/Influx/Chronograf/Kapacitor (TICK-Stack) consists of a set of modular services built around the time-series database InfluxDB [103]. The database is offered as an opensource version to be run on the user's infrastructure, as a cloud service or as an enterprisegrade production-ready cluster. InfluxData Inc. (San Francisco, CA, USA) provides their time-series database as an application for cloud-based platforms AWS IoT and Microsoft Azure. InfluxDB handles data persistence only; data collection happens through the open-source server agent plug-in Telegraf [104]. Telegraf allows users to connect IoT devices, other systems and databases to the InfluxDB. It supports push and pull operations via MQTT, HTTP and third-party APIs; Apache Kafka services; AWS cloudwatch; Mon-goDB; or visualization services, such as Grafana or Influxdata's web-based dashboard and real-time visualization plugin Chronograf [105]. On top of collecting (Telegraf), storing (InfluxDB) and visualizing (Chronograf), TICK-Stack provides the processing framework Kapacitor [106], which can be used for data analysis purposes, such as anomaly detection.

Method
In order to analyze IoT middleware platforms in smart energy systems, we pursued a two-stage research plan, consisting of a literature review and a quantitative expert survey. First, we conducted literature analysis in order to identify technologies, requirements and challenges that are relevant in the development and roll-out of IoT middleware platforms and to form a set of survey questions that would assess the experts' needs. Based on the results, we developed an online questionnaire that was made accessible to 47 experts from Europe: (i) 13% were city officials responsible for smart city projects and smart platforms; (ii) 50% were experts in energy and energy technology companies, including data analysts, IoT experts and researchers; and (iii) 37% were experts who planned and/or operated buildings and districts, such as experts in electricity markets, flexibility management, digitalization of district heating and energy in buildings. The experts were selected based on their involvement and interest in the development and operation of middleware platforms. Out of the 47 experts, 28 provided us with a complete set of answers, which corresponds to a response rate of 60%. Qualitative statements about IoT platforms tools, technologies, requirements and business cases were the core of the survey. Experts were asked to report their agreement with certain statements through simple yes/no answers or Likert answers. The survey took place between September and December 2020. The questionnaire and expert responses are openly available at GitHub: https://github.com/tug-cps/iot-survey (accessed on 21 March 2021).

Presentation of the Results
Hallowell and Gambatese [107] argue that the median value is more appropriate for analyzing results of a survey than the mean, as it is less dependent on outliers and extreme values introduced by biased responses.
Sachs [108] argues that the interpolated median, as given by (1), is even more appropriate than the median, as it provides a metric within the lower and upper bounds of the median, in the direction that the data is more heavily weighted.
where M is the standard median of the responses, N is the number of answers to a specific question, n 1 is the number of answers strictly less than M and n 2 is the number of answers equal to M.
To maximize the transparency of the results, they are presented in bar charts, as means, medians and interpolated medians.

Threats to Validity and Limitations of the Study
There is no universal criterion that allows for an unbiased assessment of what it means to be an expert in a certain field. Academic experts are often identified based on their numbers of publications and citations. However, there is no general criterion that allows an unbiased comparison of the impact of a researcher's work. This applies, in particular, to the comparison between disciplines. For experts in industry, there is no metric such as number of citations that would allow classification as an expert, since most experts in industry do not publish their work in (peer-reviewed) journals. In this study, experts from industry were selected based on their involvement and interest in the development and operation of middleware platforms. We are aware that this is a threat to validity. However, we claim that this is the most transparent selection procedure.

Results
In this section, we present the results of the quantitative expert survey divided into the following categories: business layer and end-users; NFRs and challenges; applications; middleware communications protocols; network communications protocols. Figure 2 shows that while most practitioners consider the development of uniform semantic models important, only a minority already use unified models in their systems. It can be seen in Figure 3 that most experts would share data models and schemata freely, and a majority would be willing to sign a service contract for a IoT platform. Besides, responses show that about for half of the experts, IoT middleware platforms are a core aspect in their business model. Additionally, we asked the experts about whether they operate their current/future IoT solutions on private or public clouds, or they prefer cooperating with a service partner. The answers for this question indicate that 40% of the users prefer to host IoT solutions on their private systems, and similarly 40% reported that they choose collaborations with service partners. On the other hand, Only 20% of the experts were interested in using the public clouds for operating such services. Figure 4 shows how much each of the participants categories considers using IoT solutions for monitoring and operation of buildings/districts/cities as important. To assess how much is it important to have an open-source platform, participants were asked to answer some related questions as shown in Table 1.

NFRs and Challenges
The pie chart in Figure 5 shows that only 15.6% of the participants planned to use or used IoT platforms for one building, while the remaining answers were evenly distributed between considering a scope of multiple buildings, districts, entire cities or other larger scales.   This imposes crucial security and sacalability requirements on the middleware platform, as data exchange needs to be secure regardless of the scale. This observation is highlighted by the responses visualized in Figure 6, where more than 95% classified security as either extremely or very important. Furthermore, Figure 6 and Table 2 emphasize that other non-functional requirements, such as openness, availability, reliability and avoiding vendor locks need to be considered as well.

Applications
The main goal of the IoT is to connect sensors, devices and networks in one aggregated system, providing a basis for a wide range of applications, including data-analysis and visualization. Figure 7 shows a list of applications that the survey participants are either already using or planning to use IoT middleware for.

Middleware Communication Protocols
An IoT platform needs to support various communication protocols to be able to connect with a wide variety of devices, networks and external systems. Accordingly, in our survey we asked experts to identify the most important communication protocols for IoT technology. Figure 8 shows that MQTT and HTTP are considered fundamental protocols by the survey participants.

Network Communication Standards
Similarly to the protocol requirements, IoT middleware solutions have to be able to support communication through a variety of network communication standards in order to provide maximum flexibility. Figure 9 depicts how the survey participants rate the importance of the most common network protocols in IoT middleware. Results show that LoRaWAN and are considered the most important technologies by the experts.

Discussion
Monitoring and operation through IoT solutions is seen as a key interest for energy technology companies, building managers and end users. This highlights that scalability and modularity are key requirements for IoT solutions. IoT platforms have to support a wide range of functionalities, as the use cases for energy technology companies are fundamentally different from the use cases of the other end users. Based on the expert survey, around 70% of the respondents found that visualization of energy production and consumption remains the central use for IoT infrastructure, and the potential of data analysis services and control automation are not yet exploited. However, there seems to be rising interest in energy optimization, including benchmarking, automation and control, and demand side management. Many commercial platforms provide services, service templates and SDKs for seamless integration with their platforms.
Regarding the IoT architecture model, in our research, we found that a five-layer approach offers the most practical solution by distinguishing layers based on their functionalities, while keeping it as simple as possible. The most relevant application layer protocols used by most of the middleware platforms in research are HTTP, CoAP, MQTT, OPC UA, XMPP, AMPQ and DDS. On a network communication level, IPv6, ZigBee, Z-Wave, Bluetooth, 4G/LTE, 5G, LoRAWAN, 6LoWPAN, LTE-M and NB-IoT are the predominant technologies. The survey results highlight that MQTT is considered to be even more important than HTTP by the respondents of the survey; however, especially in the matter of scalability and real-time control, CoAP, XMPP or DDS might find more relevance in future applications. Regarding the communication technology, LoRaWAN got the spot of the most relevant technology in the survey at roughly 65%, followed by WiFi, at slightly more than 55%. Offering more technologies could also help in drawing the attention to some alternatives that solve the drawbacks of the used technologies, such as using HTTP instead of MQTT to improve the scalability. To improve the portability of energy services between different platforms and to avoid vendor locks, it will be necessary to be able to use uniform semantic data models and data point labels in the future (see Figure 3). In addition, to allow the integration of a wide variety of third-party services, devices and (legacy) systems, it is critical to standardize APIs.
Extending the scales in which the IoT middleware platforms are used imposes the need of sharing and handling large amounts of real-time data in a scalable, controlled and secured way. Indeed, at least 64% of the participants claimed to use IoT middleware for multiple buildings.
Security is particularly important considering the severity of security breaches in the context of privacy and confidentiality and the risks for the operation of buildings, districts and grids. Figure 6 demonstrates how important security is for the users, by being considered as the most important non-functional requirement with approximately 90% of the votes.
With more services and functionalities being automated, it is imperative to ensure the reliability of the middleware platform. Although openness is seen as the least important property provided by middleware platforms among the NFRs, Figure 3 shows that while there is a general willingness to participate in the development of open-source IoT platforms by practitioners in energy technology companies, building operators and municipality officials, many users would still prefer to outsource operation and maintenance of platforms to third-parties. The same opinion applies for the management of these platforms: the majority of users would prefer to pay for the administration of the middleware platforms, rather than administrating their own. At the same time, some users are still undecided and have a wait-and-see attitude. Hence, we promote extensive research in this area. IoT middleware platforms are a promising solution to mitigate these issues and provide integration of devices, data persistence and energy services. IoT middleware is an emerging market, with a wide range of commercial and non-commercial alternatives. While the introduction of universal standards in IoT remains a pious hope for the future, there are recurrent building services, concepts, protocols and functionalities that are found in both commercial and non-commercial platforms. This paper presented an expert assessment of requirements, limitations and challenges for large-scale deployment of IoT middleware in smart energy systems. The results corroborate findings in the literature, such as the need to standardize semantic data models, data point labels and APIs to improve portability and interoperability between devices and services from different vendors, More than 50% of the participants considered unified data models important; at the same time, only 15% of the experts currently used a unified data model, marking this as an important area for future research. Results show that the application layer protocols used by most of the middleware platforms are MQTT and HTTP, whereas on the network communication level, LoRAWAN, WiFi and 4G/LTE are the prevalent technologies. In the literature, the most important non-functional requirements were identified as: interoperability, scalability, flexibility and openness, energy efficiency, security and privacy. Results of the survey show that experts consider security a crucial feature in any middleware platform, in addition to showing a big interest in developing open solutions. The fact that about 30% of the survey participants were not willing to make their data models freely available shows that further research should be devoted to highlighting the importance and the commercial and non-commercial benefits of using open-source solutions and contributing to open-source projects. Development of unified data models, data representations and naming schemes by considering the collaborations between academic researchers and practitioners should also be considered; this data model's harmonization helps in enabling a seamless interaction between digital sub-systems. This is strongly required for any kind of smart energy system that relies on sector coupling or enforces any kind of demand-side management or continuous adaptation of simulation models, such as fault detection and predictive control. Moreover, in this paper we discussed different protocols and technologies, but more research is required on assessing the suitability of these technologies and protocols for certain applications under real conditions.