Synergies and scaling of use case combinations in the field of asset logging and labeling

Abstract

The digitalization of the energy sector enables a broad range of new digital use cases and business models. For instance, blockchain-technology can be used for the verification of tamper-resistant storage of asset data (asset logging) or manipulation-resistant guarantees of origin for electricity (labeling). Yet, it is associated with high implementation and operating effort. But many of these use cases require similar players, interfaces, data sets and data processing, so that synergies can result from a joint implementation. We thus evaluate these synergies in implementation and operating effort for use cases in the field of asset logging and labeling using a bottom-up evaluation of the components based on a methodology of Dossow (Energies 16:2424, 2022). Additionally, we extend this methodology to analyze the scalability of the use cases by assessing the relative effort reduction for an increasing number of players involved. The analysis already shows substantial synergies for combinations of two use cases. Yet, especially for combinations of three or more use cases a high effort reduction potential is derived. The highest synergies are obtained among the asset logging use cases, while a combination of asset logging and labeling use cases shows lower synergies in comparison. The analysis of the scaling of the use cases demonstrates that for labeling use cases the main effort driver is the number of consumers, while for asset logging use cases the number of asset operators shows to be more relevant. Thus, scaling effects outweigh the effort reduction potential of use case combinations especially for combinations of asset logging and labeling cases.

Introduction

The current decentralization of the energy sector leads to a number of challenges for asset operators, regulators and other affected parties. While many processes require ongoing monitoring, processing and storage of asset data, with the growing number of decentralized assets the increasing amount of data causes new challenges for the system. To target these challenges, in the research project InDEED digital data processing processes are developed and tested in a sandbox approach (Forschungsstelle für Energiewirtschaft e.V 2022). One of the tested technologies is the blockchain, which due to the cryptographic hash references provides tamper-resistant data records, constitutes a single source of truth by its consensus mechanism and shows relatively high resilience due to its distributed and redundant data storage (Djamali 2021).These attributes can be used to enable new use cases in the energy sector, or to simplify the implementation of existing use cases (Bogensperger et al. 2018). Among others, these include use cases from the application fields of ‘asset logging’ (Djamali 2021; Merkle 1987; Hinterstocker et al. 2020)—the collection, documentation, and usage of asset data—and labeling of electricity (Bogensperger et al. 2023a; Sedlmeir et al. 2021a). Thereby, due to high interference and overlaps between the use cases of these fields, potential synergies are stated by Djamali (2021) and (Bogensperger et al. 2018). This paper provides a structured analysis of the synergy potential for relevant asset logging and labeling use cases.

Background: digital use cases of the blockchain technology in the energy sector

Due to its tamper-resistant data records, the attribute of a single-source of truth as well as high resilience, the blockchain technology enables the implementation of a platform for the collection, documentation, and usage of relevant asset data of decentralized assets in the energy sector for direct or later verification as it is described by Djamali (2021). This application is referenced to as ‘asset logging’. It summarizes a broad number of use cases, like the validation of asset data to verify warranty or insurance conditions or the confirmation of the contractual provision of balancing power for the network operator. In (Djamali 2021), a concept for the technical implementation utilizing Merkle Proofs is suggested. The data is stored in Merkle Trees, which are a typical data structure for saving transactions and their corresponding metadata. By repeatedly hashing data points, a large amount of data can be represented by one single hash value. This hash value then is used as block-header of the previous block. For the verification of the data integrity via Merkle Proof only the adjacent hashes of the path from the Merkle root to the data point under consideration are required, leading to a low computational overhead (Djamali 2021; Merkle 1987; Hinterstocker et al. 2020).

While this implementation concept enables to verify data without initially and constantly revealing it, for the verification itself the raw data still needs to be revealed and processed. Thus, it is not suitable for use cases in which very big amounts of data have to be processed, in which the data is highly sensitive and should not be revealed or in which verification is necessary constantly. One such application field is the labeling of electricity, e.g. for manipulation-resistant guarantees of origin for electricity with high temporal and spatial resolution or regional direct marketing as described in Hinterstocker et al. (2020). To implement this use case, Zero-Knowledge Proofs can be utilized as described in Bogensperger et al. 2023a. By this cryptographic method the existence of data or correctness of processes can be verified, without revealing the underlying data itself. Thus, for proof of origin the correct matching of electricity generation and consumption according to a defined, public set of rules can be verified, without for example revealing sensitive data about the electricity consumption of private households (Bogensperger et al. 2023a; Sedlmeir et al. 2021a). Moreover, a reliable labeling of electricity is also stated as a prerequisite for other use cases, especially for energy communities and peer-to-peer trading, which are use cases frequently discussed in the context of blockchain applications in the energy sector (Bogensperger et al. 2018). While the focus in those use case analyses formerly mainly lied on their technical implementation and process description, a full use case evaluation also requires an estimation of the effort of its implementation and maintenance. Many of the use cases under consideration require a relatively similar setup, including usage of the same player groups, interfaces, data sets and using similar data processing on the blockchain. Thus, a combined implementation of use cases might lead to savings in implementation and operating effort.

State of research: multi-use and synergies

The combination of use cases and multi-use of components and interfaces has been examined mostly for use cases in the area of smart charging of electric vehicles or battery storage systems. Thereby, mainly increased revenue opportunities by combining use cases compared to the revenues of one individual use case. (Kern et al. 2022) for example show, that the combination of the electric vehicle smart charging use cases ‘PV self-consumption optimization’ and ‘arbitrage trading’ could yield substantially higher revenues, than the use case ‘PV self-consumption optimization’ individually, due to different profitability of the use cases in different seasons. (Chukwu et al. 2019) examine the revenues of combining up to four different use cases, obtaining an increase in revenues by combining multiple use cases. A similar benefit from multi-use is found by Englberger et al. (2020) for smart charging of a stationary battery storage. While these papers among others show increased revenue potential from combining use cases, they usually focus on the operation phase and do not consider the implementation of the necessary infrastructure (Dossow and Hampel 2022). To analyze such potential synergies from a simultaneous implementation of use cases, (Dossow and Hampel 2022) develop a methodology for a bottom-up component-based analysis of the implementation of use case combinations of smart charging of electric vehicles. They thereby assess the necessary players, interfaces and data sets for each use case and evaluate synergies based on overlaps in these elements.

Equivalently to the multi-use in smart charging, also digital use cases may benefit from a combined usage of necessary components, interfaces and the underlying data processing, as suggested by Djamali (2021). Moreover, other than in smart charging, where use cases are mostly applied sequentially, digital use cases in the field of asset logging and labeling can be applied simultaneously. Thus, the use cases are not interfering with each other, indicating a high potential for multi-use. Other than in smart charging processes, besides the implementation effort, also savings in the ongoing effort constitute a relevant factor for consideration due to the more complex underlying data processing structures including the blockchain.

While no synergy analyses yet have been performed on digital use cases based on the blockchain technology, another example besides smart charging of utilizing one digital infrastructure for multiple purposes can be found in the recent developments of smart meter infrastructure towards “an infrastructure for multipurpose metering rather than on several single purpose metering systems” [Koponen et al. 2008, p. 4]. This enables the utilization of various elements of the metering infrastructure for multiple metering purposes. (Cotti et al. 2013) for example study potential synergies between the gas and electricity sector due to smart multi-metering. Analogously, a high synergy potential is stated by Bogensperger et al. (2018) for digital blockchain use cases in the energy sector which rely on the same data basis. They argue that the blockchain specifically unfolds its strengths in the context of platform infrastructures, incorporating multiple use cases. They focus their analysis on the fields of asset logging and labeling, which provide a reliable and tamper-resistant data base of asset data and electricity flows, respectively. This data base then could be utilized for multiple other use cases. A combined implementation of these use cases thus should be considered before their implementation, especially in cases of high overlaps between the use cases’ players, interfaces, required data and data processing. To assess these overlaps and thus the synergy potential of these use cases, the methodology of Dossow and Hampel (2022) is adapted and applied towards digital use cases from the fields of asset logging and labeling. Additionally, the methodology is extended to evaluate how a scaling of use cases, represented by an increasing number of players, influences these synergies.

The adapted methodology is described in Sect. “Methodology”, with Sect. “Synergy analysis” explaining the analysis of the effort of individual use cases and use case combinations developed by Dossow and Hampel (2022) and how it is adapted in this paper for use cases in the field of asset logging and labeling. Section “Scaling of effort” describes how the methodology is extended for the scaling of effort with an increasing number of players. The results are presented in Sect. “Results”, giving a detailed description of the use cases under consideration in Sect. “Use case description”, of the effort reduction potential of use case combinations in Sect. “Effort reduction potential resulting from combined implementation” and showing the scaling of the described use cases in Sect. “Effort reduction potential resulting from scaling”. Section “Discussion and conclusion” discusses the results and their limitations.

Methodology

The methodology of Dossow and Hampel (2022), originally developed for use case combinations in the field of smart charging of electric vehicles, is adapted in several aspect, to suit for the analysis of digital blockchain use cases.

Analogously to Dossow and Hampel (2022), a use case thereby defines as follows:

“A use case describes the functionality of a system from the user’s perspective. It highlights boundary conditions, involved players, contexts, interactions, and the added value created by the use case. A user can be a person interacting with the system, a role, an organization, or another system. […] The goal of defining use cases is to establish a common understanding of the behavior and scope of a system among relevant stakeholders, such as those involved in a project.” (Dossow and Hampel 2022)

Yet, as described in more detail in Sect. “Synergy analysis”, the definition of use case combination and effort differ from Dossow and Hampel (2022) in this paper due to the different field of application:

• We define a use case combination as the simultaneous usage of the soft- and/or hardware infrastructure for more than one use cases. This may include the simultaneous usage of data, interfaces, data verification process or the integration of players.

• Effort is defined as a combination of the effort of primary implementation of a market ready solution, as well as operating effort and maintenance.

An important influencing factor for the implementation and operating effort of a use case not analyzed in Dossow and Hampel (2022) is the number of players participating in a use case (combination). Thus, additionally to applying the methodology to a different field, we extend the methodology for an analysis of the scaling of effort with an increasing number of players, focusing its analysis on the player group of asset owners. The methodology introduced in this paper does not analyze the attribute of scalability of a system as the “ability […] to accommodate an increasing number of elements or objects, to process growing volumes of work gracefully, and/or to be susceptible to enlargement.” (Bondi 2000). Instead, the analysis assumes that these elements can be accommodated and focuses on a bottom-up analysis of the scaling of the effort of a use case, depending on the elements included. Based on this, it can be used to analyze the impact of an increasing number of players on the implementation and operating effort of one use case as well as use case combinations comparatively.

Synergy analysis

The methodology of Dossow and Hampel (2022), consists of five steps, starting with the use case description, followed by the identification of relevant use case combinations, which build the base for the evaluation of the effort reduction potential resulting from multi-use. Those steps are accompanied in Dossow and Hampel (2022) by the assessment of regulatory and technical challenges and a profitability analysis of use case combinations.

In this paper, we focus on the steps of use case description and evaluation of effort reduction (in the following numbered as steps 1 and 2) and extend it by an analysis of the scaling of effort with an increasing number of players (numbered as step 3). Steps 4, the assessment of regulatory and technical challenges, is discussed only briefly in Sect “Discussion and conclusion”. The adjusted methodology is shown in Fig. 1.

Fig. 1

Methodology for synergy and scaling analysis, adapted from (Dossow and Hampel 2022)

Use case description

As a basis for the other methodological steps, a detailed and structured use case description is suggested by Dossow and Hampel (2022). The considered aspects for the use case description are thereby adjusted to suit the application area of digital use cases in the fields ‘asset logging’ and ‘labeling’. Thus, the following categories are described:

• ‘Primary objective’ of the use case

• ‘Added value for the involved actors’ by participating in the use case

• ‘Data verification process’, differentiating between data verification via Merkle Proof and Zero-Knowledge Proof

The technical setup thereby analogously to Dossow and Hampel (2022) is described by a list of elements, classified in element classes as “players, interfaces between players, and data or information flows and processes (data sets) that are exchanged between the interfaces.” [Dossow and Hampel 2022, p. 4]. Those three classes are extended by a fourth element class, the data verification process. For each use case it is identified which of those elements are a) necessary for the implementation or b) optional (i.e., adding value but not mandatory) (Dossow and Hampel 2022).

Effort reduction potential resulting from multi-use

Based on the element-wise bottom-up analysis of each use case, (Dossow and Hampel 2022) derive an evaluation of the implementation and operational effort of one use case. The effort of a use case is calculated element-wise, depending on whether an element is necessary or optional for the use case, or if it is not required. Additionally, the effort is multiplied with a weighing factor, to determine the implementation and ongoing effort of the respective element. The weighing factors were determined in expert workshops and can be accessed in Table 2 in appendix A. The effort determination of one use case is described in formula (1):

$$\begin{gathered} EF_{{UC_{i} }} = \sum\limits_{m} {\left[ {WF_{m} \cdot \sum _{k} b_{{Element_{k} ,m}} (UC_{i} )} \right]} with\,b = \left\{ {\begin{array}{*{20}l} {1,\quad if\,the\,respective\,element\,is\,necessary\,for\,the\,use\,case} \hfill \\ {0,\quad if\,the\,respective\,element\,is\,not\,necessary\,for\,the\,use\,case} \hfill \\ {0.2,\quad if\,the\,respective\,element\,is\,optional\,for\,the\,use\,case} \hfill \\ \end{array} } \right. \hfill \\ EF = effort\,factor,\,UC_{i} = use\,case\,i,\,WF = weighting\,factor,\,m = weighting\,category,\,b_{{Element}} = necessity\,of\,element,\,k = index\,of\,element \hfill \\ \end{gathered}$$

(1)

This effort calculation sets the basis for the comparison of the effort of the individual implementation of a use case $U{C}_{j}$ versus the implementation in combination with a preexisting use case $U{C}_{i}$. To determine the effort of such a combined implementation, it is evaluated, if the elements included in the additional use case $U{C}_{j}$ are already included in the previous use case $U{C}_{i}$ or whether they need to be included additionally when adding the additional use case $U{C}_{j}$. An element of the additional use case $U{C}_{j}$ thus only generates effort for the use case combination if it is not already included due to the previous use case $U{C}_{i}$.

$$EF_{{UC_{i} }} + EF_{{UC_{j} }} = \sum\limits_{m} {\left[ {WF_{m} \sum _{k} b_{{Element_{k} ,m}} \left( {UC_{i} } \right)} \right]} + \sum\limits_{m} {\left[ {WF_{m} \sum _{k} b_{{Element_{k} ,m}} \left( {UC_{j} } \right)} \right]} = \sum\limits_{m} {\left[ {WF_{m} \sum _{k} \left( {b_{{Element_{k} ,m}} \left( {UC_{i} } \right) + b_{{Element_{k} ,m}} \left( {UC_{j} } \right)} \right)} \right]}$$

(2)

$$\begin{gathered} EF_{{UC_{i} + UC_{j} }} = \sum\limits_{m} {\left[ {WF_{m} \sum _{k} b_{{Element_{k} ,m}} \left( {UC_{i} } \right)} \right]} + \sum\limits_{m} {\left[ {WF_{m} \sum _{k} \beta _{{Element_{k} ,m}} \left( {UC_{j} } \right)} \right]} = \sum\limits_{m} {\left[ {WF_{m} \sum _{k} \left( {b_{{Element_{k} ,m}} \left( {UC_{i} } \right) + \beta _{{Element_{k} ,m}} \left( {UC_{j} } \right)} \right)} \right]} = \sum\limits_{m} {\left[ {WF_{m} \sum _{k} EF_{{k,UC_{i} + UC_{j} }} } \right]} with\beta = \left\{ {\begin{array}{*{20}l} {1,if\,the\,element\,is\,not\,necessary\,for\,UC_{i} \,but\,is\,necessary\,for\,UC_{j} } \hfill \\ {0,if\,the\,element\,is\,already\,necessary\,for\,UC_{i} \,or\,must\,be\,implemented\,in\,the\,same\,way} \hfill \\ {0.2,if\,the\,element\,is\,not\,necessary\,for\,UC_{i} \,and\,is\,optional\,to\,implement\,for\,UC_{j} } \hfill \\ {0.8,if\,the\,element\,is\,already\,optional\,for\,UC_{i} \,and\,is\,necessary\,for\,UC_{j} } \hfill \\ \end{array} } \right. \hfill \\ EF = effort\,factor,\,UC_{i} = use\,case\,i,\,WF = weighting\,factor,\,EF_{k} = effort\,factor\,of\,individual\,element,\,m = weighting\,category,\,b_{{Element}} = necessity\,of\,element,\,k = index\,of\,element,\,\beta _{{ELement}} = necessity\,of\,element\,of\,additional\,use\,case \hfill \\ \end{gathered}$$

(3)

In the case that an element is only optional for implementation, analogously to Dossow and Hampel (2022) 0.2 is used as element variable $b$ for the effort evaluation of individual use cases. Equivalently, 0.2 is also used as the element variable $\beta$ in the case of optional elements in use case combinations, while 0.8 is used as $\beta$ for elements necessary for one use case in a use case combination, which are already needed optionally for the preexisting use case. The corresponding element variables $b$ and $\beta$ are defined in formula (1) and (3), respectively. Figure 2 visualizes how $\beta$ is determined for simultaneous implementation of use cases.

Fig. 2

Example visualization of difference between separate and simultaneous implementation, from (Dossow and Hampel 2022)

While in general optionality may be weighed differently among different elements and use cases (i.e. one component may bring more or less benefit to a use case than another component), a selection of uniform $b$-values and $\beta$-values brings the benefit of a better comparability of results. Moreover, $\beta$-values should be selected such that the value in case of optional elements of a preexisting use case (we assume 0.8) equals one minus the value in case of optionality (we assume 0.2). This ensures that use case combinations are permutable, so the order in which use cases are combined does not affect the overall effort of a use case combination, benefiting the presentation and interpretation of results. For simplicity we thus use $b$-values and $\beta$-values equal to Dossow and Hampel (2022).

A comparison of the sum of the effort of implementing each use case individually (2) and the effort of a combined implementation of the same use cases (3) enables to calculate the synergies of two use cases by the effort reduction due to a combined implementation compared to a separate implementation, as described in formula (4). (Dossow and Hampel 2022)

$$ER = \left( {EF_{{UC_{i} }} + EF_{{UC_{j} }} } \right) - EF_{{UC_{i} + UC_{j} }}$$

(4)

For combinations of three use cases, the additional effort by introducing a third use case is determined based on the combinations of this third use case with each of the previous two use cases as described in formula (5). Thereby, for each element, additional effort by introducing a third use case is defined by the minimum of the effort values of a combination of each of the previous use cases with the additional use case.

$$EF_{{\left( {UC_{{i}} + UC_{{j}} } \right) + UC_{{l}} }} = \sum\limits_{k} {\left[ {{\text{min}}(EF_{{k,UC_{{i}} + UC_{{l}} }} ;EF_{{k,UC_{{j}} + UC_{{l}} }} )} \right]} with\,EF_{k} = effort\,factor\,of\,individual\,element,\,UC_{i} = use\,case\,i,\,k = index\,of\,element$$

(5)

While the calculation of the effort of a separate (2) or combined (3), (5) implementation is equal to Dossow and Hampel (2022), in this paper the application is not limited to combinations of up to three use cases. This comes due to the different definition of a “use case combination” for the field of digital platform use cases in comparison to Dossow and Hampel (2022), which addresses multi-use of charging strategies for smart electromobility. In the definition of Dossow and Hampel (2022) a use case combination enables to implement use cases “…either sequentially, in parallel or dynamically (interplay between sequential and parallel).” [Dossow and Hampel 2022, p. 3], giving the players “the opportunity to execute the use case of the combination that delivers the greatest added value at the corresponding time.” [Dossow and Hampel 2022, p. 3]. In contrast, as defined previously in this section, we describe a combination as “the simultaneous usage of (…) infrastructure for more than one use cases. “Thus, the use cases are not interfering with each other and a combination of more than two or three use cases can increase the synergies, as it does not reduce the added value of each use case, but only leads to effort reductions.

Therefore, the methodology is applied to analyze use case combinations for two use cases to combinations of all use cases included. The calculation of the effort for combinations of more than three use cases is performed equivalent to the calculation for combinations of three use cases described in (4), receiving an element-wise effort factor dependent on which elements are already necessary in the use case combination without the additional use case and which elements become necessary additionally. Same as for (Dossow and Hampel 2022), permutations of the use case order do not influence the total effort of the combination.

Scaling of effort

The scaling of a use case is based on the element-wise bottom-up analysis of each use case described in Sect. “Use case description”. Therefore, the calculation of a use case’s effort ${EF}_{U{C}_{i}}$ is extended by an element-specific scaling factor SF. This scaling factor is determined for each element class n (e.g. an interface or a data verification process) in dependency of the number of players of the player groups $g\in G$ associated with the specific element (e.g. the player groups connected by one interface, see also the example in Sect. “Effort reduction potential resulting from scaling”). This scaling factor is then multiplied with the effort calculation described in formula (1), which thus changes to the following:

$$\begin{gathered} EF_{{UC_{i} }} = \sum\limits_{m} {\left[ {WF_{m} \cdot \sum _{k} SF_{k} \cdot b_{{Element_{k} ,m}} (UC_{i} )} \right]} with\,SF_{k} = scaling\,factor\,of\,element\,k\,depending\,on\,element\,class\,n\,and\,player\,group\,g,\,b = \left\{ {\begin{array}{*{20}l} {1,if\,the\,respective\,element\,is\,necessary\,for\,the\,use\,case} \hfill \\ {0,if\,the\,respective\,element\,is\,not\,necessary\,for\,the\,use\,case} \hfill \\ {0.2,if\,the\,respective\,element\,is\,optional\,for\,the\,use\,case} \hfill \\ \end{array} } \right. \hfill \\ EF = effort\,factor,UC_{i} = use\,casei,WF = weighting\,factor,\,m = weighting\,category,\,b_{{Element}} = necessity\,of\,element,\,k = index\,of\,element \hfill \\ \end{gathered}$$

(6)

To analyze the impact of the number of players to the effort of one use case, the number of one or more player groups is varied. In general, all player groups can be used to analyze the scaling effects (in this paper, the number of asset owners is exemplarily varied, as described in Sect. “Effort reduction potential resulting from combined implementation”). The effort of use case combinations is calculated similar to the methodology described in 2.1., based on the scaled values for each element.

Results

In the following, the results applying the methodology described in the previous section to selected use cases from the field of asset logging and labeling are presented. Those use cases are identified and partially tested in a sandbox approach within the research project InDEED.

Use case description

Table 1 shows the use cases selected with their respective description. Relevant decision criteria for the selection of use cases was on the one hand the use cases’ relevance for theoretical evaluation and practical application. On the other hand, as the applied methodology requires a certain level of detail in the use case specification, only those use cases were selected which are sufficiently specified.

Table 1 Use case descriptions for the selected use cases in the area of asset logging and labeling

The first six use cases thereby are all instances of the field of asset logging, where “data from registered assets is logged and stored for the later or ongoing verification of certain propositions or processes.” [Djamali 2021, p. 3]. A detailed description of asset logging in general, as well as the underlying verification process can be found in Hinterstocker et al. (2020). As suggested by Hinterstocker et al. (2020), this asset data can be verified by the relatively simple concept of the Merkle proof, enabling the tamper-proof storage of asset data with relatively low computational effort.

In (Djamali 2021), relevant use cases in the field of asset logging are analyzed, identified and prioritized via expert workshops. Warranty management, operation contracting, and service and maintenance models are identified as the most relevant use cases and described in more detail in the paper. As stated by Djamali (2021), the use cases “… share similar data and infrastructure requirements, so implementing one use case makes implementing the other use cases easier due to emerging synergies.” [Djamali 2021, p. 6]. To assess such potential synergies, these use cases are selected for the analysis of this paper. Additionally, the use case of regulatory requirements is identified among the most relevant use cases by Djamali (2021). Nevertheless, to define the necessary players and data sets for this use case it would require specification of the respective context. Therefore, it is not considered in the following analysis. Besides the use cases specified by Djamali et al. (2021a, b) describe the verification or the proof of the contractual provision of balancing services as additional relevant asset logging use case. The use case is further specified by Pleier (2023), where two different implementation concepts are established, using two different verification processes. The first variant, the verification by event logging, verifies the validity of data provided from the asset operator to the network operator, while the second variant automatically proofs the contractual provision of balancing services for a pool of aggregated assets as well as on an individual asset basis, utilizing a Zero-knowledge-proof (ZKP). Due to its detailed specification, enabling a clear determination of the players, interfaces, data and data processing necessary for the use case's implementation, as well as because of the use case’s relevance for transmission system operators, it is included into the analysis as well.

As stated by Bogensperger et al. (2018) besides high synergy potential among asset logging use cases, there is also a high potential between different application fields. Thus, labeling is included as an additional field, represented by the use case ‘guarantees of origin'. This use case aims to provide “consumers with a visualization of the origin of their individual electricity consumption. This includes precise information on the location of its generation with high temporal resolution.” [6, p. 3] ‘Guarantees of origin’ as one of the most specified use cases of the field fulfills the necessary requirements of a detailed use case description. Moreover, it represents a highly relevant use case for various users, as described by Bogensperger et al. 2023b. Thus, it may incorporate a high user potential which makes potential synergies to other use cases even more relevant. As already discussed in the introduction, the labeling of electricity cannot be verified by a Merkle proof like most of the asset logging use cases, but requires the more sophisticated method of ZKPs for verification. This method on the other hand is not suitable for data verification in most of the asset logging use cases, as in these use cases no mathematical operation can be performed to test data validity, like it is the case for guarantees of origin and—depending on the respective implementation— also for the proof of balancing services. Thus, two different verification mechanisms, Merkle proof and ZKP, are included into the analysis.

As described in Dossow and Hampel (2022), in addition to the description of the basic important aspects of each use case involved, a structured description of the technical design should be derived. This technical description specifies important aspects of the soft- and/or hardware infrastructure necessary and/or optional for a use case and serves as the basis for the synergy and scaling calculation described in Sect. “Effort reduction potential resulting from combined implementation” and “Effort reduction potential resulting from scaling”. As described in Sect. “Use case description”, those aspects are captured by defined component elements (players, interfaces, data sets and data verification process). These elements are presented in an element list, which can be accessed in appendix B. Analogously to Dossow and Hampel (2022), the technical design description is visualized to ensure a consistent use case description. Therefore, all players and the respective data verification process involved in a use case as well as the connections between the players (interfaces) are mapped in relation to each other. Additionally, the data sets exchanged between the players are specified for each use case per interface. The visualization of all use cases shown in Fig. 3 thus closely describes the contents of the element list, which is used for the calculation of synergies and scaling of effort. This visualization is published in more detail in an interactive website in Wasmeier et al. (2022). The simplified visualization shown in Fig. 3, the process for creating the simplified visualization of the system as well as a comparison of this system to the system architecture of smart electromobility was published in Dossow and Wasmeier (2023).

Fig. 3

Illustration of technical description of the selected use cases simplified from (Wasmeier et al. 2022), published in (Dossow and Wasmeier 2023)

Effort reduction potential resulting from combined implementation

In the second step, the implementation and operating effort for the use cases is assessed by deriving the qualitative effort estimation as total sum of the weighted numerical values of each element. Those are compared to the effort estimation of the combined implementation of use cases, which is calculated as described in Sect. "Effort reduction potential resulting from multi-use". The weighting factors $W{F}_{m}$ used for the calculation are displayed in Table 2 in appendix A.

The evaluation includes the absolute effort reduction potential, as well as the effort reduction potential relative towards the case where the use cases are implemented separately. For combinations of more than two use cases, the relative reduction in effort is determined in comparison to a separate implementation of all use cases included. This differs from Dossow and Hampel (2022), where for combinations of three use cases the relative effort reduction potential by including a third use case is compared to the combination of the previous two use cases. As permutations of use case combinations show equal effort reduction potential, they are not included in the analysis. Likewise, as the use cases ‘5.1) Proof of balancing services (event logging)’ and ‘5.2) Proof of balancing services (ZKP)’ are two implementation versions of the same use case, combinations of 5.1) and 5.2) are excluded from the analysis.

Both, absolute and relative effort reduction potential are categorized in the categories very high, high, medium high, medium, medium low and low based on their respective numerical values. Those categories are defined as comparative assessment of the effort reduction potential of combinations of two up to all use cases. The minimal relative effort reduction potential is realized for the combination of the use cases 4) and 6) and equals to 18% effort reduction compared to a separate implementation of both use cases. The maximum effort reduction potential of 63% is realized for the combination of the use cases 1) to 5) with the implementation version 5.1) for use case 5).

Figure 4 shows the effort reduction potential of combinations of two use cases. All use case combinations including just two use cases show medium low to low absolute effort reduction potential compared to combinations including more than two use cases. For the relative effort compared to a separate implementation, high effort reduction potential can be derived for a combination of the use cases ‘1) Warranty management’ and ‘2) Insurance policies’ and medium high effort reduction potential for combinations of those use cases with the use case ‘4) Service and maintenance models’, as those use cases require identical players, identical or similar interfaces and data sets and identical data verification processes. For combinations of the use cases 1), 2) or 4) with the use case ‘3) Operation contracting’, the analysis shows medium to medium high effort reduction potential, as this use case requires the “asset operator” as an additional player, while it does not require to include the player “third party”. Combinations of two use cases including the use cases ‘5) Verification / Proof of balancing services’ and ‘6) Guarantees of origin’ differ substantially in the players included and the required interfaces, data sets and the data verification process. They thus show medium to low relative effort reduction potential compared to the other combinations.

Fig. 4

Effort reduction potential for combinations of two use cases

Figure 5 shows the effort reduction potential for combinations of three use cases. The effort reduction potential thereby is on average substantially higher than for combinations of only two use cases. The absolute effort reduction potential is mainly categorized as medium. The relative effort reduction potential is categorized as very high or high for combinations of the use cases 1), 2), 3) and 4), with very high reduction potentials for combinations that include both use case 1) and 2) and high potential for the other combinations. The other combinations, also including the use cases 5) and/or 6) show medium to medium high relative effort reduction potential.

Fig. 5

Effort reduction potential for combinations of three use cases

Both the absolute as well the relative reduction potential are the highest among all use case combinations for combinations of more than three use cases, as it can be derived from Fig. 6. The absolute reduction potential is categorized as medium high for all combinations of four use cases and as (very) high for combinations of five use cases. The relative effort reduction potential for combinations of four use cases is determined as very high for combinations of the use cases 1), 2), 3), 4) and the implementation 5.1) (which uses the same verification process as the use cases 1)-4)). For the other combinations (which use the Zero-Knowledge-Proof for data verification) the relative reduction is either medium high or—when the combination contains at least three use cases from the cases 1) to 4)—high. Combinations of five use cases show very high effort reduction potential for combinations containing all use cases 1) to 4) and high potential for all other combinations. Combinations of all six use cases show very high absolute and relative effort reduction potential, independently of the implementation version of use case 5.

Fig. 6

Effort reduction potential for combinations of more than three use cases

In total, the analysis of the effort of use case combinations shows particularly strong synergies for the combined implementation of the use cases ‘1) Warranty management’, ‘2) Insurance policies’, ‘4) Service and maintenance models’ and to a reduced extent also to the use case ‘3) Operational contracting’. Those use cases all require relatively similar player groups and thus also relatively similar interfaces and data sets. Generally, an overlap in actors often induces also high overlaps especially in interfaces, but also data sets. Use cases with equal actors involved thus usually show very high synergies, leading to the element category ‘integrated actors’ being especially relevant for synergies among use cases. Additionally, the use cases 1) to 4) rely on the same data verification process, increasing the use cases’ synergies. Lower effort reduction potential is derived for combinations with the use cases ‘5) Verification / Proof of balancing services’ and ‘6) Guarantees of origin’, which differ more in those elements, so that less synergies can be achieved by a combined implementation of the use cases. For the use case 5), the implementation version ‘5.1) Proof of balancing services (event logging)’ shows higher synergies to the use cases 1) to 4) than the implementation version ‘5.2) Proof of balancing services (ZKP)’, as 5.1) uses the same data verification process as 1) to 4). Yet, often results between 5.1) and 5.2) are relatively close, indicating that the usage of the same verification process may not have equally high influence on results like the involvement of the same actors.

All use cases thereby require an integration of the actors of the ‘asset owner’ and the ‘service provider’ as well as an interface to submit asset data from the asset of the first to the database of the latter. This indicates a certain synergy potential among all of the uses analyzed, which is also confirmed by the fact, that the lowest synergy potential derived still reaches an 18% effort reduction potential. Moreover, all of the use cases rely on a database of the service provider, as well as on a blockchain, which needs to be connected by an interface to the asset, so that it can receive hash values from the asset for verification purposes.

Effort reduction potential resulting from scaling

To assess the scaling of the use cases, the effort values are analyzed for an increasing number of players as described in Sect. “Scaling of effort”. Therefore, the number of asset owners is varied, as this is the only player group included in all use cases. The number of the players of the other player groups are kept fixed in the analysis. The scaling factors SF for each element class in dependency of the number of players are defined in the following way:

• For the element class player, SF is the number of players of the specific player group.

• For the element class interface, SF is the average of the numbers of players of the two player groups connected by the interface.

• For the element class data, SF is the number of players of the player group where the data is captured.

• For the element class data verification process, SF is the number of service providers, which offer the data verification service.

The calculation for the scaling factors is exemplary displayed for some of the elements in Fig. 7. The scaling factors for each element, as well as the number of players that are used for the other player groups is shown in the elements list in appendix B (Fig. 13).

Fig. 7

Example: Calculation of effort reductions for x asset owners, 2 service providers and 5 asset operators

The number of asset owners is varied between 1 and 30. An increasing number leads to an increase in total effort, but a decrease in the effort per asset owner for individual use cases as well as use case combinations. This can also be seen in Fig. 8, which shows the total effort value on the left and the effort value per asset owner on the right for a number of 1 to 30 asset owners for all use cases but use case ‘6) Guarantees of origin’. This use case is depicted in Fig. 9, as due to the high effort for including a high number of consumers, the effort of this use case exceeds the effort of the use cases 1) to 5) so far, that the other use cases cannot be distinguished clearly.

Fig. 8

Absolute qualitative effort value (left) and effort per asset owner (right) for all use cases but use case 6)

Fig. 9

Absolute qualitative effort value (left) and effort per asset owner (right) for all use cases including use case 6)

As can be observed in Fig. 8, the rise in effort for an increasing number of asset owners differs among the use cases, depending on the number of interfaces, which need to be installed, and the amount of data sets, which need to be collected repeatedly for each additional asset owner. Those use cases with a higher rise in effort per additional asset owner (which require a medium high effort to include additional asset owners), like the use cases 5.1) and 5.2), show a lower decrease in effort per asset owner. The use cases ‘1) Warranty management’ and ‘2) Insurance policies’ show the strongest decrease in effort per asset owner for an increasing number of asset owners included. As shown in Fig. 9, the scaled effort of the use case ‘6) Guarantees of origin’ lies substantially above the effort of all other use cases due to the high effort for including a large number of consumers into the use case, an player group which is only required for this use case.

To analyze the influence of use case scaling on use case combinations, as an exemplary combination Fig. 10 shows the effort values and the effort per asset owner for the use cases ‘1) Warranty management’ and ‘3) Operation contracting’, as well as the combined and the separate implementation of both use cases. It can be observed that the effort for the separate implementation of both use cases rises more with an increasing number of players than the combined implementation, leading also to a stronger decrease in the effort per asset owner for the combined implementation.

Fig. 10

Absolute qualitative effort value (left) and effort per asset owner (right) for the use cases ‘1) Warranty management’ and ‘3) Operation contracting’ in combined and separate implementation

Figures 11 and 12 compare the separate and combined implementation of all use cases, with Fig. 11 excluding use case 6) and Fig. 11 including all use cases. As implementation version for use case 5), 5.2) is selected. Thus, 5.1) is not included in Figs. 11 and 12. In both cases the effort value for the separate implementation rises substantially stronger than the effort value for the combined implementation. Yet, while for use case combinations of all use cases without 6) also the effort per asset owner for combined implementation lies visibly below the effort for separate implementation, for the use case combination including 6), the effect cannot be recognized that clearly. This can mainly be attributed to the strong influence of the scaling itself for use case 6), which exceeds the influence of use case combinations to the effort reduction potential by far. Due to the high effort necessary to include a high number of consumers in the use case ‘6) guarantees of origin’, the effort of this use case exceeds the effort of the other use cases by far. Because of this, also the effort reduction potential by use case combinations including use case 6) is not substantial compared with the scaling effect of this use case. Thus, the comparatively low synergies of the use case 6) towards the other use cases, as well as the high effort value of the scaled use case 6) mainly come from the high effort for including the player group of consumers, which are not required for any of the other use cases.

Fig. 11

Absolute qualitative effort value (left) and effort per asset owner (right) for the combined and separate implementation of all use cases but use case ‘6) guarantees of origin’

Fig. 12

Absolute qualitative effort value (left) and effort per asset owner (right) for the combined and separate implementation of all use cases including use case ‘6) guarantees of origin’

Discussion and conclusion

This paper analyzed the synergies in terms of implementation and operational effort reduction potential for use cases in the field of asset logging and labeling, applying a methodology developed by Dossow and Hampel (2022). We show substantial synergies among the use cases, supporting the assumption of Djamali (2021) and (Bogensperger et al. 2018) of synergies among digital blockchain use cases in the energy sector for use cases from the fields of asset logging and labeling. A number of adjustments is made to suit these application areas as described in Sect. “Methodology”. These adjustments show the importance of a clear and context-related definition of the terms “use case” and “use case combination”, as well as of the elements under consideration. Also, the regulatory and technical challenges (step 4) are not assessed specifically in the analysis, as those are covered by literature. An examination of the regulatory challenges for asset logging can be found in Klausmann et al. (2021) and for labeling in Gneisenau (2022). The technical implementation of the suggested platform and the associated challenges of asset logging are discussed in Djamali (2021) and in Sedlmeir et al. 2021b the technical framework of the labeling platform is described. Step 5, a profitability analysis is not performed, as the current stage of use case definition for the described use cases is not yet sufficient to deduce valid profit potential.

Generally, combinations of the use cases 1) to 4) show higher synergies than combinations with the use cases 5) or 6), as these have higher similarities between each other. Yet, the main driver, especially for absolute, but also for relative effort reductions, is the number of use cases included in one combination. This suggests that, from the point of view of effort reduction, when asset logging and labeling use cases are implemented, it should be aimed for a combined usage of infrastructure. Moreover, also if initially only one or a small number of use cases is implemented, the infrastructure should be designed in a way that it is able to include additional use cases easily.

The evaluation in this paper represents a comparative analysis of the qualitative effort assessment of the included use cases and possible combinations among these use cases. Therefore, use case combinations classified as having low synergies in comparison can still show substantial effort reduction potential. Overall, all use case combinations show considerably lower effort for a combined implementation compared to a separate implementation.

We show that the methodology developed by Dossow and Hampel (2022) for the smart charging infrastructure of electric vehicles can be transferred towards digital blockchain use cases from the fields of asset logging and labeling. This indicates that it may also be transferred to other fields in the energy sector. Nevertheless, the methodology needs to be adjusted accordingly for each application. For example, it may be applied to the field of multi-metering to gain more advanced insights on potential synergies among different energy sectors as proposed by Cotti et al. (2013). Nevertheless, other than the assessment of benefits from multi-use by increased revenues as conducted by Kern et al. (2022); Chukwu et al. 2019) for smart charging of electric vehicles and by Englberger et al. (2020) for stationary battery storage, the methodology determines a comparative evaluation of synergies among different use case combination by a qualitative effort estimation. Therefore, a comparison of the results among different application fields cannot be performed that easily. Nevertheless, a comparison of the methodological process, accounting for necessary adjustments of the methodology for the respective application field, can yield important insights on the application fields, the respective use cases and the methodology itself. Such a comparison was performed by Dossow and Wasmeier (2023) for the use case visualization of digital blockchain use cases shown in Fig. 3 against the use case visualization of electric vehicle smart charging use cases applied in Dossow and Hampel (2022). This comparison, besides the use case visualization, also accounts for necessary methodological adjustment and shows an example of how a comparison and classification of the results may be achieved among different application fields.

By analyzing the scaling of the effort of the use cases under consideration, this paper could extend the methodology by another crucial aspect of the effort assessment. In this paper, the analysis is focused on one player group. Yet, the methodology can be applied to any one or more player groups included. It shows that the effort per asset owner reduces clearly with an increasing number of asset owners for all use cases considered. Especially for combinations with the use case ‘6) guarantees of origin’, the scaling effects exceed the influence of use case combinations to the effort reduction potential by far. This implies that especially for labeling use cases or other use cases including consumers, the main focus of an infrastructure should lie on its scalability and only as a second priority on the ability to include additional use cases.

The analysis of Sect. “Results” evaluates the synergies under the assumption that those use cases need to be implemented completely, without any preexisting technical setup or components. Nevertheless, a common availability of certain measuring infrastructure and components like the smart metering infrastructure among consumers and asset owners could significantly change the results of the analysis. Moreover, also some of the use cases discussed might be of sufficiently high interest for a user to justify its implementation and operating effort independently of the additional value by other use cases. In that instance, the more relevant question regarding synergies is the question which additional effort the implementation of an additional use case may bring. This effort can be assessed by the same methodology introduced in Sect. “Methodology”, but is not the focus of the results in Sect. “Results”. The analysis of the synergies of the asset logging use cases to a preexisting labeling use case or the assumption a preexisting smart metering infrastructure for consumers and asset owners could yield further insights into potential synergies of the use cases discussed.

This paper assesses synergies and scaling of digital data use cases on a basic component level, focusing on the actors and interfaces. Thus, technical attributes were highly simplified. Further research could analyze the technical conduct of the elements in multi-use and scaling. This could bring insights into how technical components and processes can be designed so that they can efficiently enable multi-use and into how an infrastructure can be created in a way that it is scalable. Yet, the simplified component-based analysis of this paper already indicates which elements are used by multiple use cases and/or which elements are the main drivers of effort in scaling. Thus, it reveals for which elements the possibility of multi-use or efficient scaling attributes would bring the highest overall effort reductions for a system.

Appendix

Appendix A: applied effort estimates

The elements were multiplied with a weighting factor as described in chapter 2.1.2. in formula (1). The weighting factors were derived based on expert estimates for the implementation as well as the operating effort, derived in an internal workshop. The average of those factors as well as the final weighting factor for the total effort are shown in Table 2.

Table 2 Weighting factors derived from expert workshops

Appendix B: elements list

The element list below shows the categorization of the analyzed use cases for each element into necessary, optional, or not included, as well as the elements weighing factor, derived from expert workshops as described in appendix A, and the scaling factor for each element class as shown in Fig. 13. The number of players assumed for the scaling analysis equals the scaling factor for the respective player group. For the player group asset owner, which was varied in the analysis, the number of asset owners is expressed by the variable x. The numbers of players of the other player groups were chosen as fixed numbers, representing an arbitrary potential scaling scenario.

Fig. 13

Element list with weighting factors and scaling factors for the considered use cases from the field of asset logging and labeling