Local energy markets - an IT-architecture design

In recent years, local energy markets have become an important concept in more decentralized energy systems. Implementations in pilot projects provide first insights into different hypotheses and approaches. From a technical perspective, the requirements for the IT infrastructure of a local energy market are diverse, and a holistic view of its architecture is therefore necessary. This article presents an IT-architecture, which enables all basic local energy market functionalities, processes and modules based on the available literature. The proposed IT-architecture can serve as a blueprint for future local market projects as it covers the basic processes and is at the same time extendable. Furthermore, we give a detailed description of a real-world implementation of a local energy market using the described IT-architecture and discuss the advantages and disadvantages of the utilized technologies along with this case study.


Introduction
The expansion of renewable generation capacity has led to a structural change in the energy sector. Instead of building large, centralized, conventional generation plants, mainly small, decentralized renewable plants are installed. Most of these plants are directly connected to the distribution grid (Green & Newman, 2017). This new situation implies that, unlike in the past, supply and demand can be locally balanced more often and a violation of system constraints can be resolved on a local level. Due to this changing situation, there has been increasing discussion in recent years about so-called local energy communities (LEC) and, in particular, local energy markets (LEM) (Teotia & Bhakar, 2016;Mengelkamp et al., 2018a;Mengelkamp et al., 2018b;Wörner et al., 2019a). The objectives of such communities are manifold, but a central aspect is that the locally generated electricity is distributed within the community and consumed locally. This supports local congestion management schemes and can reduce transmission grid congestion. Small local producers share energy with local customers in the immediate vicinity. These can be private households with photovoltaics (PV) systems (so-called prosumers), individual wind turbines or small combined heat and power (CHP) plants on the producer side and private households, or local businesses on the consumer side (Kamrat, 2001). Specifically, LEMs organize this power distribution and financial flows within the community through an allocation mechanism (e. g., an auction or peer-to-peer (P2P) mechanism (Liu et al., 2019)). It allows producers to directly sell their generated energy, avoiding intermediaries such as aggregators. This new possibility integrates both consumers and prosumers actively into the energy system (Sandoval & Grijalva, 2015;Hall & Roelich, 2016).
Energy markets can be categorized as electronic markets (Alt & Klein, 2011). An electronic market is not only understood as a coordination mechanism for matching supply and demand but as a construct that must adapt to the particular social, business, and technical requirements in order to be successful (Weinhardt & Gimpel, 2007). One of the sub-segments is the IT infrastructure, which consists of various technologies and systems that involve different stakeholders. These must be coordinated and brought together in the right manner, which is a complex task. Due to this complexity, the architecture of this IT infrastructure plays a central role. It divides the overall information system into various modules with specific tasks and defines the interaction and coordination between these (Ross, 2003). Each interaction is a process initiated by a module and transmits information to another module. To fulfill their tasks, the modules utilize different technologies. Furthermore, the modules have specific requirements and limitations that must be considered and taken into account to ensure the overall functionality. Looking at the literature of LEM concepts, the multitude of different approaches is striking, shown by the review of (Sousa et al., 2019). However, there is a lack of proposals for LEM IT-architectures. Therefore, it is crucial to discuss the necessary functionalities and structure of an LEM IT-architecture based on the present research on LEMs and discuss this architecture based on real-world implementations. From a research perspective, we state the following two research questions: RQ1: What are the fundamental modules and processes of an LEM IT-architecture to ensure its underlying functionality based on existing literature? RQ2: What are valuable experiences from a practical implementation of the proposed LEM IT-architecture?
The study is divided into two parts. First, we identify the individual modules and processes of an LEM IT-architecture based on the existing literature body. Second, building on this, we assess an existing real-world LEM project that implements this IT-architecture in a case study. We describe the architecture in detail and discuss the implemented technologies, including design choices and share our experiences from the case study. We also elaborate on the advantages and disadvantages of these technologies based on daily experience from the implementation process and assess the performance on day-to-day operations.

Related work
With the increase of decentralized electricity generation and the application of information and communication technologies, citizens are empowered to become 'energy citizens' and form local energy communities (Wuebben et al., 2020;Kunze & Becker, 2015;Hisschemöller & Sioziou, 2013). This concept has gained momentum in recent years in academia, industry, and political institutions (Kalkbrenner & Roosen, 2016;Gui & MacGill, 2018;Richter et al., n.d.). For example, the Directive on Common Rules for the Internal Market for Electricity introduced by the European Parliament in 2019 strengthens the role of local energy communities beyond the stage of being a niche phenomenon (European Parliament, 2019).
In addition to this development, the ongoing blockchain technology hype has led to the promotion of the LEM concept (Richter et al., 2019;Mengelkamp et al., 2018c). With more than 20 projects, central Europe is one of the hotspots for local energy initiatives . Most projects include consortia consisting of several organizations with academic and commercial backgrounds. An overview of existing peer-to-peer and community-based electricity markets worldwide can be found in (Sousa et al., 2019). An assessment of LEMs in Germany, Austria, Switzerland, and Denmark is given in . The academic community states several advantages of LEMs. The local price signals provide incentives for both supply and demand to balance generation and consumption locally, reducing the burden on the overall system (Bremdal et al., 2017;Koirala et al., 2016;Block et al., 2008). Also, it incentivizes investment in additional generation facilities and stimulates local value creation (Koirala et al., 2016;Morstyn et al., 2018). According to (Mengelkamp et al., 2019a;Sundt & Rehdanz, 2015), the increasing environmental awareness might lead to a greater willingness of consumers to pay for green and locally produced electricity, which opens up a new income stream for small and private producers.
LEMs can be associated with the research field of smart grids. In this research area, different IT-architectures and systematics are proposed. These studies focus either on the overall system or the energy management of smaller sub-areas of the grid (e. g. (Anthony Jnr et al., 2020;Khorasany et al., 2020;Gottschalk et al., 2017;Wu et al., 2015)). The transition to local systems such as LEMs is fluid in the literature, and there are already first architecture approaches to integrate LEMs into the overall system. Often, layer or level models are described, which show the different levels and stakeholder groups (Zhang et al., 2018;Andrade et al., 2020). Other approaches show the interaction between the individual stakeholders (Mazzola et al., 2020) or in the interaction with the overall system (Zia et al., 2020;Budiman, 2018). Yet, a specific and detailed LEM IT-architecture with its different modules and processes is missing.
In general, IT-architectures play an essential role for companies, organizations, or institutions (Ross, 2003;Alonso et al., 2010). Due to the ongoing digitization of many sectors, the structure and functionality of the implemented information systems become more complex and relevant. Thus, the architecture plays a significant role (Schmidt & Buxmann, 2011). There is no clear definition of the term IT-architecture, and the term is often used synonymously with the term IT infrastructure (Ross, 2003). According to (Ross, 2003), an IT-architecture is 'the organizing logic for applications, data and infrastructure technologies, [...]'. The authors of (Schütz et al., 2013a) subdivide the ITarchitecture into three areas (data and information architecture, application architecture, and infrastructure technology) to examine the respective level of complexity in more detail. In (Guillemette & Paré, 2012), the authors define an 'architectural builder', which builds and organizes the IT infrastructure in such a way that it can implement the required processes while reducing complexity. They describe the IT-architecture as individual modules which interact with one another. A defined process represents each interaction, and the modules utilize different technologies. The latter is partly independent of the architecture as it only determines the minimum requirements for the technology. Overall, there is a whole research field in the Information Systems domain that deals with the management and complexity of IT architectures (for an overview, see (Schütz et al., 2013b)). Accompanying this, the authors of (Beyer et al., 2004) state that the information system's architecture represents an integral part of the entire socio-technical system and includes the stakeholders' requirements. They present an IT-architecture for integrated healthcare networks. The authors use an extensive literature review and stakeholder interviews to identify the key challenges and problems of existing information systems for healthcare networks and derive the essential functionalities relevant to the architecture. Comparable to the first part of the approach from (Beyer et al., 2004), we conduct an extensive literature review for the following analysis and identifiy individual components of the IT-architecture. In addition to this, we interviewed stakeholders during the planning phase of the case study presented later.

Identifying the it-architecture structure
The development of LEMs is still in an early stage, and there are many different designs and proposed functionalities. There is already a large variety of literature on LEMs. An overview of this is given in (Mengelkamp et al., 2019b). Our analysis of the ITarchitecture focuses on local markets where only energy is traded, as these have been discussed and addressed most frequently in the literature. We analyze the existing literature for basic functionalities and processes of LEMs. Due to the complexity and an often lacking precise formulation of assumptions on the underlying functionality, we also evaluate information from existing LEM implementations to obtain further information on possible architectural building blocks. With both analyses, we determined the basic functionality and the resulting necessary processes. Based on these, we define and describe the required modules of the IT-architecture and describe their tasks and related processes. As a result, we have identified four key modules of the IT-architecture that are mentioned and frequently referred to in our literature and project analysis. These components are the 'Smart Meter Hardware', 'Market Implementation', 'User Interface', and 'Database'.

Smart meter hardware
The first module is the Smart Meter Hardware which many authors implicitly or explicitly mention. Energy trading on an LEM requires the load values of all participants in real-time. The authors of (Teotia & Bhakar, 2016;Ilic et al., 1998;Long et al., 2017) mention the necessity of metering infrastructure to capture load data and specify parts of its functionalities. In (Mengelkamp et al., 2018c), the authors state that each participant requires a smart meter to measure the required load data. Overall, the task of this module is to measure load data and transfer the data to the information system. These measurements take place at the participant's home, and the hardware transfers the information with specific communication technology. This module can come with various technology standards, but in the analyzed literature, no author precisely specifies their specific technical approach or mentions possible technical standards. In the related smart meter literature, different technologies are proposed. The most common ones are the data transmission over the mobile network, local area network (LAN/ WAN), or various radio standards like LoRaWAN (Long et al., 2017;Kabalci, 2016;Mlynek et al., 2015;Varsier & Schwoerer, 2017). In the case study, we will discuss the advantages and disadvantages of the LoRaWAN technology in more detail. Besides the communication technology, the measuring capability of the smart meter hardware is crucial for market mechanisms. A 15-min clearing interval requires measurement data in the appropriate resolution or higher (Block et al., 2008;Ilic et al., 1998). Therefore, the smart meter hardware technology's feasible measurement accuracy determines which market mechanisms can be implemented successfully. However, they all share the need for some form of smart metering technology.

User interface
The connection between the users and the information system plays a minor role in the current literature. Although the individual participant groups like prosumers or private households are described in almost all LEM-related publications, virtually no information is provided on how the participants interact with the information system. In (Wörner et al., 2019a;Mengelkamp et al., 2018c;Wörner et al., 2019b;Vasconcelos et al., 2019), the authors mention an application or user interface. However, it is not clear what functionalities this module includes. This is probably caused by the still early development stage of the LEMs. Since many LEM concepts are based on active trading and participation by the different stakeholders, the submission of preferences or bids and the reception of market and consumption data is necessary. According to (Mengelkamp et al., 2018b;Wörner et al., 2019a;LO3 Energy, 2018a;LO3 Energy, 2018b;Mannaro et al., 2017), each participant must be able to place bids on the market, and view and monitor transactions, market results, and consumption or generation data. Also, the 'User Interface' module requires a verification process. The authors of (Mengelkamp et al., 2018c) state that each participant's identity must be ensured via a verification process. This authentification is an important component, as individual load data is sensitive. Additionally, the information system must prevent the users from viewing each other's individual information or placing bids for someone else, which threats the integrity of the LEM. In the blockchain context, identity management is also mentioned in (Wörner et al., 2019b;Mengelkamp et al., 2018d). In these publications, different identities are assigned with the help of the blockchain technology.

Market implementation
The third module is the 'Market Implementation'. The vast majority of publications deal with different approaches and proposals about the allocation mechanism of the market. The literature does not explicitly mention the process needed to execute the market. Most authors do not specify the required data in concrete terms. However, these can usually be derived from the design of the mechanism. In (Mengelkamp et al., 2019b), the authors identified over 30 publications that describe a kind of market mechanism or 'trading design'. There are approaches like auctions (Teotia & Bhakar, 2016;Mengelkamp et al., 2018c;Lezama et al., 2019), P2P designs (Wörner et al., 2019a;Sousa et al., 2019) or mechanisms that rely on an optimization algorithm (Block et al., 2008;Torbaghan et al., 2016;Holtschulte et al., 2017). In most cases, the load data and user input (bids, preferences, willingness to pay) are necessary. Overall, the basic function of this architecture module is to request the required information and prepare it accordingly for the market mechanism. With this data, the implemented market mechanism software calculates the individual transactions. Then, the market mechanism module passes these transactions back into the information system. It becomes clear that the concrete design of the market mechanism is not relevant for the IT-architecture itself and can be substituted as needed. Only the capabilities of the smart meter technology need to be respected by the mechanism design.

Database
The 'Database' module is the last in the proposed architecture. This module, similar to the 'User Interface' or 'Smart Meter Hardware', is rarely specifically mentioned or specified in the existing literature even though it is clearly part of the architecture. There are often implicit assumptions since many authors promote the blockchain or distributed ledger technology in their approaches (Wörner et al., 2019a;Mengelkamp et al., 2018c;Wörner et al., 2019b;Mengelkamp et al., 2018d;Blom et al., n.d.). For instance, the 'Smart Meter Hardware' module generates data and stores it in the blockchain database for both the 'Market Implementation' and 'User Interface' modules. The blockchain is a special type of database which is selfmanaged locally by all participants. They agree on the current state of the database through a consensus mechanism (Mengelkamp et al., 2018d;Andoni et al., 2019). However, the usage of this technology is much broader than just storing information. For example, smart contracts execute the market mechanism on the blockchain automatically (Wörner et al., 2019b;Mengelkamp et al., 2018d). The great attention for blockchain technology indicates that data's consistency and assignability play an essential role.
In each of these descriptions, the blockchain is the central entity that stores, manages, and provides the data. Parts of the information are stored or retrieved regularly (load data, transactions), and some irregularly (bids), the 'Database' module must be available at all times. Therefore, the 'Database' module itself initiates no processes. However, this module is the central point in the architecture. Each of the other three modules communicates exclusively with the Database module.

Fundermental IT-architecture overview
The results of the literature and project analysis are displayed in Fig. 1 and further explained in Table 1. As mentioned above, we identify four modules and six processes between them. The modules of the architecture ensure the basic functionality of an LEM, and the database module is the central building block of the architecture. Here, all data is stored and distributed. As Fig. 1 shows, the other modules communicate exclusively with the database. Due to the centralized structure around it, the individual modules influence each other only through the database. This allows the implementation of different market mechanisms and technologies without having to change the underlying structure. Also, it can be extended easily. Different market mechanisms can be exchanged in the module, and other modules with additional functionalities can be added.
Yet, the technical requirements of these modules or mechanisms, like the resolution of the load data, have to be considered to avoid malfunctions.
The proposed modules and processes cover the basic functionality of LEMs. Further functionalities, such as billing or prediction of load values, are partly mentioned in the literature but represent a higher complexity of the LEM IT-architecture because regulation has to be considered much more closely. The presented modules with their functionalities should be present in every LEM to ensure its basic functionality. Nevertheless, the gap between academic research and real-world implementations still seems to be large. Different stakeholders and settings apply in real-world projects. Thus, the IT-architecture can differ from our proposed structure. Yet, it should inherit the proposed modules and processes that can be modified or extended.

Case study
The above presented IT-architecture does not describe the modules' internal processes to fulfill their tasks, possible technologies used within the modules and their communication with the database. Besides, it was noticed during the literature analysis that there are no examples of an IT-architecture described in detail that has actually been implemented. In the following, we describe in detail the technical structure of a real-world implemented LEM with the proposed IT-architecture. We elaborate on the necessary processes, used technologies, and discuss their advantages and disadvantages from the experience of a day-to-day operation over 2 years.

Project description
The LEM project considered in the case study is the Landau Microgrid Project. This project is a cooperation between the Karlsruher Institute of Technology, the software company Selfbits GmbH and the local utility EnergieSüdwest. Its objective is to investigate the different requirements and challenges of an implemented LEM. Throughout the project, data is gathered on the impact of the design, implementation, and operation of the market. The project is set up in a selected areal grid in the area of the involved utility. There are 118 connection points within the area network, the majority of which are private households. The project partner is the contracted supplier of all households. A local CHP plant with a capacity of 50 kW electrical (85 kW thermal) and a PV system with a capacity of 23.56kWp provide local energy. The CHP is heat-controlled and supplies the households with heat. Electricity is, therefore, a by-product. The CHP is heatcontrolled and supplies the households with heat. Electricity is, therefore, a by-product. The typical load of the CHP is based on the time of year. It is almost at full load in winter due to heat demand, while in summer, it is mostly off. In spring and fall, its operation depends on the weather. The project partner owns and operates both installations. The areal network is connected to the public grid via a single connection point. In case of an overproduction within the areal network, excess energy can be fed into the public distribution grid. Additional energy can also be obtained if the local generation is not sufficient. Initially, eight private households decided to participate in the LEM. The annual consumption of these participants corresponds to about 7% of the total consumption in the area network.

Modules and processes of the projects IT-architecture
The four distinct modules of the IT-architecture previously identified are implemented. Firstly, smart meters with LoRaWAN sensors record the load values of all participants and transfer them (Smart Meter Hardware). The local market participants have access to this load data and are able to submit bids to the system through a mobile user application (User Interface). The load and bidding data are processed into transactions with the help of a specific market mechanism (Market Implementation). A relational database stores all load and market data and manages the access of different users. A representation of the actual architecture with its modules is shown in Fig. 2. In the following, we describe and discuss each module, its processes and implemented technology in detail.

Smart meter hardware
In the LEM IT-architecture, a digital electricity meter records the load data. This meter has a communication module that allows the measured load values to be transmitted to an information system (process 1). It utilizes the LoRaWAN technology. LoRaWAN stands for 'Long-Range Wide-Area Network' and is a low-power wide area network. The latter describes a network protocol that enables communication over long distances (up to 2-5 km in inhabited areas) and consumes little energy. The architecture of the LoRaWAN networks is centralized and organized with one or more gateways as nodes. For a new area, at least one gateway is required in the direct neighborhood. The end devices (LoRa sensors) publish the measured data on the frequency band of 868 MHz in 15 min intervals. The gateway, which is connected to the internet via the mobile network, receives the signals. Then, it forwards the received data to a network server. Within the LoRaWAN, the network server checks and processes the received data (e.g., deletes duplicate entries) and sends it to an application server where the data is stored. The processing step between the network and application server is necessary because the gateways forward all received LoRa signals. Therefore, it also sends signals from devices that are not intended for the LEM. The network server ensures that only the transmitted load data of the electricity meters are stored. In the last step, the application server transmits the data to the Database module via a WebSocket connection. The transfer of load data to the database itself is a process between the 'Smart Meter Hardware' and 'Database' modules. The system is able to identify the incoming load data of each device. For every active device, the system administrator registers it with a SmartMeterID in the database (more details in the Database section).

Technology discussion
In the project, a digital meter of the brand 'EMH-metering', more precisely, the model LZQJ-XC is used. A LoRa Sensor is connected to the meter, reads the load data, and broadcasts it over the frequency band. In detail, a Class A 'LoRaWAN' sensor from the company 'nke-watteco' is used. For the project, a new gateway was installed in the direct neighborhood, as well as the required backend, namely the network and application server. The advantages of the LoRaWAN technology for this application are easy installation, scalability due to the cost per sensor, and signal strength. For some participants in the project, the grid connection point is in the basement from which no connection to a mobile network is possible. Therefore, the installation of a regular GSM modem was no option. The advantage of the LoRa technology is that a LoRa sensor has high sensitivity and can transmit much better from underground indoor locations (LoRaWAN and NB-IoT : competitors or complementary | LoRa Alliance®, n.d.). Since the sensor transmits only a meter reading to the LoRa, the data payload is not very large, and the low bandwidth of the technology is not an issue. A further advantage is a simple and inexpensive expansion with further end devices. In an approach based exclusively on the mobile phone network, these modules would have had to be equipped with prepaid mobile credit. Besides, the requirement of privacy and data security is an inbuilt standard by the design of this technology. Since the LoRaWAN technology is a network protocol designed for the Internet of Things, many different end devices located in the reception area of a gateway can be used. The network protocol uses end-to-end encryption to avoid direct access to data and to avoid alteration (man-in-the-middle-attack). The encryption is valid up to the application server and cannot be decrypted by the network server. The network protocol only performs an integrity check to identify transmission errors. A weak point of the LoRaWAN technology is the network architecture. The installation of a single gateway creates a single point of failure. If the gateway fails, there is no transmission of the measured values. This case has occurred during the active operation of the LEM. A storm damaged the gateway, which had to be replaced. However, this problem is overcome by installing a second gateway within the transmission range of the LoRa sensors. As the technology is used for different purposes by the energy provider in the LEM area of the use case, better coverage can be expected in the next years. Also, for a better connection between the gateway and the devices, the installation of the former must be at a certain height.
A web socket connection between the 'Database' and the 'Smart Meter Hardware' module is used in the project to transfer data from the application server to the database. The advantage over a conventional Hypertext Transfer Protocol (HTTP) connection is the web server, which is able to forward new information directly to the client without receiving an initial request. A small disadvantage of the web socket is that a faulty connection, where no data is transferred, can remain if data transmission from the web socket is not checked regularly. However, the risk can be limited by regularly checking the database and restarting the web socket.
During the project duration, technical problems occured repeatedly. Besides the LoRaWAN technology, there is no backup transmission technology in the project. Therefore, no data is transmitted in the event of a malfunction. As Fig. 3 shows, about 60% of all malfunctions are Fig. 3 Distribution of malfunction duration only one period (15 min) long. 85% of all occurring malfunctions are one hour or shorter. We track these malfunction problems back to transmission errors by the LoRa sensor. They are partly related to the distance of the sensor to the antenna. Two participants live near the transmission limit of the antenna and have a significant share of these short-term issues. However, the error also occurred with subscribers who live much closer to the antenna. These circumstances indicate that distance is not the only reason for these short interruptions. Since only the LoRa sensor transmitts absolute meter readings and not the difference between two readings, the missing load values from periods with malfunction are automatically captured in the next successful transmitting period. Additionally to the short-term issues, the installed LoRA sensors show issues in long-term usage and stop transmitting. These malfunctions periods are longer and occur randomly. We solved this problem by restarting the sensors manually. Nevertheless, these issues contributed to longer downtimes that lasted for several days for one participant. However, as Fig. 3 shows, the proportion of these failures is less than 1%. In addition to these smaller, individual disruptions, there are major technical failures (over several weeks) during the project caused by technical issues of the LoRaWAN antenna. For example, a storm damaged the antenna, which had to be repaired. Also, the web socket failed one time and caused a longer interruption. Both problems required repairing or restarting the system. It turns out that LoRa technology is vulnerable to transmission errors and is not a good technology choice for the smart meter hardware module. For future projects, we recommend using other smart meter technology (e.g. transmission over the mobile network) or relying on backup systems, like a second antenna, ensuring reliable and steady data transmission.

User Interface
In the derived IT-architecture, the module 'User Interface' is the connection point between the system and the user. In the case study, this interface is an application that the user can install on a computer or smartphone. Therefore, the application is accessible to all participating users. Mobile devices like smartphones and tablets are very popular, therefore a development for the largest platforms like Android and iOS was chosen. Also, an interface via a web application allows access via a browser, which gives access to the application over a desktop PC. The goal is that the LEM can be reached via a large number of different devices. This coverage allows participants to use their usual devices without requiring additional hardware. Addressing the functionality of the module 'User Interface', the architecture distinguishes between five different processes. Figure 2 displays all these processes with the number 2. Processes 2.1, 2.2, and 2.3 display the user's registration, identification and connection to the smart meter within the information system. All three processes can be assigned to the user verification process mentioned in the previous section. The application prevents users from viewing the data of other participants or issue bids in their name. For the user's identification, the information system has to be able to identify the user. This is ensured by the registration process (2.1). In order to enable the unique identification, each participant must register its login data (usually only a username and password). For this, the application has a registration menu that can be selected by a new user. The application sends the registration data to the account database over a secure representational state transfer application programming interface (REST-API). The account database first saves the username and password and then creates a new UserID linked to both. In the next step, this ID is also saved in the market database, which allows the market database to identify the user. The distinction between the two databases is discussed in the Database section. The registration process only needs to be carried out once by each participant in order to record themselves in the system. As a minor note to the login data: It is part of today's standard procedure that the username is an e-mail address of the user, whose possession he has to verify via a confirmation link. This process is not mapped in process 2.1, as this is part of the IT system's security architecture.
After successful registration, the system can authenticate the user through the login data. Figure 2 illustrates this authentication process in 2.2. The user enters the login data on the login screen when starting the app. In the authentication process, the application sends the credentials to the account database over the same REST-API mentioned in process 2.1. The account database compares the login data with the registration data. If both are the same, the authentication is successful, and the application receives a JSON Web Token (JWT) as an access token from the account database. The access token allows the GraphQL Server of the market database to identify a user and accept their requests. For security purposes, the access token is only valid for a certain time.
The corresponding device is linked to the UserID in the market database so that a user can view the consumption or generation data. The meter hardware is connected to the UserID. Process 2.3 establishes a connection between the SmartMeterID and UserID in the 'Database' module. The user enters the SmartMeterID in the application via a specific interface. The application then transmits this information to the GraphQL Server and connects the UserID to the SmartMeterID in the market database. The user only has to perform this process once for each meter.
The 'User Interface' module allows the user to view individual consumption and market data (transactions, market prices, and past bids) and to place bids. This functionality is illustrated in Figure Fig. 2 by processes 2.4 and 2.5. Process 2.4 describes the request for individual consumption and market data by the user. The application displays this data in different granularity, for example, daily or weekly consumption. After successful authentication by the user, the application has a valid access token. It sends the data request over the GraphQL API to the GraphQL Server. The server validates the token and accesses the requested data in the database. The database uses aggregates, which are defined as so-called views, and the API makes them available. These views contain the pure data of the daily aggregates and are then formatted in the app so that they can be presented in different forms. In the architecture, there is no data stored within the app, but it is provided through live queries against the server. Focusing on graphical display in the application, there is always the possibility for the user to see the data in a non-aggregated form like a table. These modules also request data from the database (2.4) an processes them internally. The last process, 2.5, is the submission of bids by the user. The application provides an interface where the user enters a new bid price to buy or sell energy on the energy market. The application transmits the bid via the same GraphQL API to the database. For identification purposes, the application also uses the before-mentioned token. The server checks the validity of the bid, stores the bid in the market database with the corresponding timestamp and UserID.

Technology discussion
In the project, the software partner provided a self-developed application for mobile devices like smartphones and tablets. The application was developed according to the described architecture and specifically tailored to this project. The cross-platform mobile app development framework 'Ionic' was used. This framework provides tools to develop apps on top of standard web technologies like CSS, HTML, and JavaScript, which allows a single codebase that can be distributed to the two largest mobile platforms, the Android and iOS operating systems. Also, it allows users to access the app via a web application. The advantages of this design approach are that the users in the project are independent of the operating system and can access the application from nearly any device. In addition, the framework prevents double development costs for both platforms. However, at the beginning of the project, it was not certain whether participants had the appropriate hardware or were willing to use it. For this reason, each participant was given an Android tablet for the sole purpose of participating in the LEM. It had the pre-configured application installed, which ensured access to the local market. The user also got a link to the web interface, and the participants had the possibility to use the application via their private devices.
Since the application is publicly available for download in the corresponding app stores, it has a start screen where a user has to register and later authenticate herself (process 2.1, 2.2) to prevent unauthorized access. Both processes are implemented in the project, as described above. The use of the JSON Web Token to authenticate the user against the market database is well suited, as a stateless session can be created. The token transfers all information required for the authentication with the database. Therefore, the database does not need to save the session with the user. This situation is advantageous because as long as the access token is valid, the user remains logged in and can request data without repeating the authentication process.
It should be noted that registration and authentication are possible without a smart meter. This design implies that even people who are not participating in the project can have access to LEM data. In the project, we allow access to the market prices and aggregated production quantities. The user gets access to the individual load data only after registering the smart meter (process 2.3). In the project, the process is similar to the process described above, with an additional security feature. The participants receive a pin and SmartMeterID from the system administrator The combination of both prevents an unauthorized person from gaining access to the individual data of a smart meter through trial and error or a brute force method. This design makes it easy to provide the data that is needed by the user, hiding the complexity and structure of the underlying database. By separating the registration process, smart meters can already create devices in the system before the serial number is known. This is relevant in the parallel development process of the LEM between the modules of the 'User Interface', the 'Database', and the 'Smart Meter Hardware'. If no final decision has yet been made on the model and modification of the metering equipment, it does not prevent the database structure from being set up. Another advantage is that replaced or new devices can be integrated into the application quickly.
The project application provides several interfaces where the user can retrieve load and market data. Figure 4 shows four screenshots of the implemented user application design. Since all participants are native German speakers, the language of the application is German. The first two screenshots from the left show individual load data ("Vebrauch") and its composition by local sources ("Einkauf"). The composition interface distinguishes between power from the CHP plant ("BHKW-Strom"), PV power plant ("Solarstrom"), and the backup grid option ("Netzstrom"). The application offers the data for different time resolutions (day ("Tag"), week ("Woche"), month ("Monat")). This can be adapted for other projects within the proposed IT-architecture. For each of these periods, the temporal resolution is adjusted accordingly (hours, days, weeks). The reason for the graphical representation is that people can grasp and understand them quicker. Additionally, the user can see all her transactions on the market and the according market prices. The two screenshots from the right in Fig. 4 displays this information. The left shows the market prices ("Übersicht Marktpreise") of the CHP ("BHKW-Strom") and PV ("Solarstrom"). As mentioned earlier, registered users without a smart meter can also see these interfaces. The right illustrates the transactions ("Transaktionsmengen") of the PV power plant. It distinguishes between local transaction ("Transactions") of the LEM and surplus sellings to the grid ("Produzierte Überschüsse"). At last, the user has access to her bid history.
The application uses the views to send predefined data queries from the app to the database. The usage of these views to represent the data has two advantages. First, mobile devices are not optimized for these calculations, so depending on the scaling of the chart, it is beneficial to calculate an aggregate form of the data in the database. Second, the user does not need access to all her time-series data at once. The last functionality is the submission of bids. The process of the submission and storage in the database proceeds, as explained above. The biggest challenges are potential wrong or illogical inputs of bid prices by the user. Also, the entry must be within the specified upper and lower limits of the bidding range, which a user might forget. A graphical feature solves these problems. The consumer can set her bid price for both power sources via a graphical controller. This ensures that the user does not place a bid outside the upper or lower limits. Logically incorrect entries are not possible. Again, these functionalities can be adapted as needed within the proposed IT-architecture. Within the User Interface, we implemented an automatic report system that sends weekly reports to each participant, including their aggregated individual load data. These reports are an additional source of information for the user to assess their consumption behavior and compare it to previous weeks to track increases or decreases in consumption and costs.

Market implementation
Based on the proposed IT-architecture, the 'Market Implementation' module is implemented using two components: The MarketWrapper and the market mechanism. The market mechanism ensures coordination of demand and supply and decides on the allocation of generation. The mechanism used in the project was specifically developed. It distinguishes between the two different types of generation that exist locally (PV and CHP). Each is cleared in a separate market with a uniform price auction. The market mechanism determines the clearing order of the markets based on the incoming bids from the users. The clearing interval is 15 min. A detailed description of the market mechanism implemented in the project is provided in (Richter et al., 2019). The task of the MarketWrapper is to process the raw data from the 'Database' module and to transmit the market results to the database. The input parameters are the bids of all participants, and the outputs are the transactions and market prices after a successful matching. For this purpose, the module requests the current bids of all participants of the local market. In the proposed architecture, the database stores no final bids, only its components. Therefore, the Market module creates the bids within its structure. The MarketWrapper then creates the bids from the load values of the electricity meters and bid prices of the producers and consumers. The MarketWrapper has fixed reading and writing permissions for certain tables of the database. It makes the requests for the relevant data for the bidding process via the GraphQL API. The GraphQL server then passes the data to the MarketWrapper in a JSON file. It receives a JSON file and processes the raw data into bids. The MarketWrapper then transmits these bids to the market mechanism. In Fig. 2, process 3.1 displays this procedure. The market mechanism then takes the bids and creates market transactions and market prices. After the market is cleared, the MarketWrapper transfers transactions and market prices via the GraphQL API. It writes each transaction individually to the database. To do this, the MarketWrapper passes each transaction to the GraphQL-Server in a single request to keep the complexity low.

Technology discussion
The project distinguishes between market execution and preparation. The advantage of this separation is the division of tasks between different programs. One program communicates with the 'Database' module, and one executes the actual market matching. This way, malfunctions that occur during communication with the 'Database' module do not lead to a crash of the market mechanism. Also, the preprocessing by the Mar-ketWrapper allows for an easy exchange and adjustment of market mechanisms. The separation allows changing the code in one of the two components without affecting the other. However, this separation is not absolutely necessary for a functioning module, but it has become an apparent advantage during the project's development process and operation.
Both programs are Java-based and run on a separate server than the database with an Ubuntu operating system. The server connects to the database over the internet using the GraphQL API. The server executes the market mechanism every 15 min. The market mechanism differentiates between local trading and the public grid and thus distinguishes between local and external network transactions. The recording of both is important to enable accounting and accurate allocation. The public grid serves as a backup option for unmatched bids (both generation and consumption) after the execution of the local market. Generation sold into the public grid is rewarded with the national feedin tariff for solar PV, consumption from the grid is charged based on the retailer rate.

Database
The architecture's 'Database' module consists of two separate databases: the account and the market database. The heart of the system is the market database. The task of the market database is to store all data arising within the LEM and to make it available to others. A server handles the management of the database and processes data requests in a specific programming language like GraphQL. Such a GraphQL server manages and monitors the writing and reading accesses of the other modules. It also manages the requests of the other modules and transmits or receives the data via a GraphQL API. An object-relational database organizes the data with different tables. Each data type has its own table. For instance, a table stores all information related to the user, another table stores all smart meter readings, and another table stores all market transactions. An object-relational database was implemented with the open-source database management system PostgreSQL. Figure 5 shows the Enhanced Entity-Relationship (EER) Model of the market database relations, including intra-and interrelation integrity constraints. The market database has six tables. These are divided into three groups (colors) in relation to the other three modules. This circumstance can easily be adjusted with other instantiations of the proposed IT-architecture. Each table consists of different attributes, which collect different kinds of additional data. For the 'Smart Meter Hardware' module, two tables exist. One for the management of the 'Smart Meter Hardware' (e.g., Hardware IDs) and one for the storage of transmitted meter readings ('EnergyTurnover'). The 'Energy-Turnover' table continuously records the meter readings of Process 1. Process 3.2 stores the transactions and market prices in the market database. Therefore, the 'Market Implementation' module requires two tables, one for the transactions and one for the market prices. Last, the User Interface also has two tables, one to store user information and one for the submitted bids. The latter table stores the bid prices submitted through the application (process 2.5). The account database takes over the process of user registration and authentication. The account database stores the login data and creates a UserID in the registration process. The account database also transfers the UserID to the market database 'User' table, which is described in processes 2.1. The task of the account database is then to compare the login data with the authentication requests of the users (process 2.2). An authenticated user receives a JSON token from the account database (see 'User Interface') and can use it to make valid queries to the market database (process 2.3, 2.4, 2.5). Process 2.3 connects the table 'SmartMeter' and 'User' table to map the corresponding load values. This connection allows the individual data request in process 2.4 and bid submission in process 2.5. As mentioned earlier, for users without a registered smart meter, process 2.4 only requests market prices and aggregated transactions of the production (PV and CHP power plant). The two right screenshots of Fig. 4 show the data which these users can access.

Technology discussion
At the beginning of the project, the implementation of a blockchain as the database was discussed but dismissed. In initial simulations on the Ethereum Blockchain, the implementation of the market mechanism in smart contracts proved to be a technical challenge (Heck et al., 2020). The proof-of-work algorithm, the resulting block creation time, energy consumption, and technical instability, involved too much risk. In addition, the use of LoRaWAN technology would not have been possible.
The separation of user authentication and market data has several advantages. First, the login data is stored separately from all other data. No module has access to this data, as it only communicates with the GraphQL server of the database. Also, the market database itself has no access to the account database. In case of errors in the access management or malfunctions, no access to the participants' login data is possible. The 'User Interface' module communicates directly with the account database, has no direct access to the stored data, and registers or authenticates the user. This design ensures a high level of protection of all participants' login data and their individual load data. One reason for choosing a PostgreSQL-based database over a relational database is the cross-table transactions referential integrity. For example, if an identification number of a smart meter in the table 'SmartMeter' is changed, an inter-relational constraint guarantees that the information is updated in all tables, which are related to this identification number. If a system administrator tries to create an already existing smart meter identification number in the table 'SmartMeter', an intra-relational constraint disables the multiple allocations of the same identification number. The lack of licensing costs, thanks to open-source deployment, is another reason. An alternative to a relational database would be a so-called NoSQL database system like MongoDB.

Conclusion
A functional and mature information system is essential for the operation of a local energy market and particularly to achieve high customer satisfaction. The architecture of an information system has a central influence on subsequent functionality and performance. We answer our first research question with the deduction and discussion of an LEM IT-architecture based on extant literature that enables the necessary functionality described in the literature on existing LEMs. The majority of the publications focus on market mechanisms and give only a partial picture of the LEM's core functionalities and architecture. Regarding the IT-architecture, numerous contributions only implicitly mention functionalities and modules. More technical contributions focus mainly on the usage of blockchain technology. The deduced IT-architecture has four central components: The 'Smart Meter Hardware', the 'User Interface', the 'Market Implementation', and the 'Database'. The first three modules generate and process the data of the LEM and enable the operation. The 'Smart Meter Hardware' module collects the load data of the participants and transfers them to the 'Database' module. The 'User Interface' module is the interface between the information system and the respective participant. It provides individual load data and market data to the user and records his bids. The 'Market Implementation' module processes the data of the other two modules and executes the market mechanism. All three communicate exclusively with the 'Database' module. Our proposed architecture describes how these four components interact with each other to meet the essential LEM functionalities. More sophisticated local systems that for instance include the flexible control of certain loads can easily be served with the same architecture as the market signals remain the same. More complicated or less complex market mechanisms can also be included in the same architecture. It thus allows for all necessary functionalities independent of the complexity of the system.
Furthermore, to answer the second research question, we describe a case study that implements the deduced IT-architecture as a specific instantiation and discuss the advantages and disadvantages of the implemented technologies. Thus, we fill the research gap of a detailed IT-architecture description for a local energy market. We do not directly compare different IT-architectures to measure the efficiency of our approach, which is a limitation of our work. Due to cost reasons of field experiments, it was not possible to implement several IT-architectures in the project and compare them. Also, our study does not explicitly measure the effectiveness of the IT-architecture. Nevertheless, expert interviews with participants reveal that they do not recognise most transmission interruptions and are satisfied with the system's overall reliability. From our point of view, the related questions must be discussed in the scientific community and between researchers and practitioners. This paper is intended to be the starting point of a discussion on the IT-architecture of LEMs and suitable technologies. Thus it contributes to the maturation of this concept for a decentralized organization of energy systems and markets and helps practitioners with new LEM projects in their planning process and daily operation.