Multi-Objective Power Distribution Operations: Characterizing Conflict and System Volatility

With the rapid proliferation of distributed energy resources and advancement in sensing and control, deploying advanced applications has become crucial for power distribution operations to achieve resilience, economy, decarbonization, and other system mandates. However, conflicts can arise when multiple applications attempt to control the same devices, potentially leading to oscillatory system behavior and suboptimal performance. This paper aims to characterize conflicts and measure the resulting system performance through relevant metrics when applying various deconfliction solution techniques. First, we introduce a conflict matrix that comprehensively registers the conflicts between different applications. Next, we propose a novel metric to quantify the severity of conflicts, facilitating their prioritization and resolution. Finally, we quantify application success and system volatility after different techniques have been applied to resolve conflict. Three competing applications, namely resilience, decarbonization, and conservation voltage reduction, are considered to showcase potential conflicts. Two deconfliction solution techniques, exclusivity and compromise, are implemented, and their impacts on the apps’ performance are evaluated using a modified IEEE 123-bus model as the demonstration test system. Applying the derived conflict metric and relevant volatility metrics provides a quantitative assessment of the system’s performance and the impact of conflicting setpoints.


I. INTRODUCTION
Advanced distribution systems need to integrate and orchestrate a growing number of increasingly intelligent subsystems and grid-edge devices while serving multiple system-level mandates such as satisfying customers, maintaining reliability and profitability, decarbonizing generation, maximizing resilience, and achieving equity [1].While early distribution automation efforts introduced device-specific controls operating at discrete time scales, advanced distribution management systems (ADMS) and distributed energy resource (DER) management systems enable dataand control-rich environments supporting complex functions [2].More recently, research on modular platform-based approaches to distribution system operations has grown.Such The associate editor coordinating the review of this manuscript and approving it for publication was Akin Tascikaraoglu .
technology enables system operators to deploy a tailored set of best-of-breed algorithms and applications to leverage increasing numbers of grid-edge devices and intelligent subsystems [3].In Fig. 1, a comprehensive set of objectives is summarized, which can be formulated and employed as advanced applications for enhancing distribution operations.Such applications' objectives may align with one or more of the system-level mandates, but any set of functional applications cannot be expected to balance these competing objectives organically.Therefore, conflict can be observed when such applications are integrated into the ADMS without system-level orchestration [4].
Existing research on numerical methods for resolving conflict in distribution operations can be broadly categorized into three groups: (1) optimal power flow (OPF), (2) multi-objective optimization (MOO), and (3) multicriteria decision-making (MCDM).OPF-based techniques formulate a global optimization problem incorporating the objectives of each application and can find the optimal setpoints [5], [6]; however, it is challenging to provide a single, quantifiable, and comprehensive system objective.Unlike OPF-based solutions, MOO techniques keep all optimization objectives separate [7], [8] and form a set of optimal solutions known as the Pareto-front [9].Finally, MCDM techniques represent a branch of operations research models designed to resolve conflicting objectives and criteria under high uncertainty [10].While these numerical methods offer a promising way to resolve conflicts between application objectives, there are several challenges: (1) some applications may be hesitant to share their specific objectives and constraints, which can hinder the collaborative problemsolving process; (2) integrating new applications into the existing framework can be complex and demanding; and (3) it is difficult to formulate a problem for determining the optimal device setpoints when only partial information is available.
An architecture and a taxonomy of concepts, strategies, and approaches that can be used to deconflict setpoint commands issued by competing apps is proposed in [4].Implementing deconfliction requires understanding system conflict, and the degree of conflict can influence the choice of the deconfliction method.Furthermore, the implementation will need to understand the app's objective, and it is important to quantify the app's performance and its deviation from its intent due to the deconflicted solutions.This demonstrates the need for a systematic way to characterize conflict and quantify the disagreement between competing apps.Moreover, understanding system volatility and application performance is vital for ensuring efficient and stable power distribution operations despite diverse objectives.
This paper aims to address the needs mentioned above and provides specific contributions.
• A novel metric to identify and assess the level of conflict that arises in multi-objective power distribution operations, enabling more effective decision-making and implementing appropriate solutions.
• Quantitative analysis of system volatility using three relevant metrics: variance; system variability index; and volume.• Demonstration of conflict with three competing apps (resilience, decarbonization, and conservation voltage reduction [CVR]) and system performance evaluation using two deconfliction methodologies (exclusivity and compromise).

II. APPLICATION CONFLICT
In this section, we summarize how a conflict can be characterized when applications with different objectives have mismatched sets of requested device setpoints.First, a Conflict Matrix is constructed to capture the discrepancies between the preferred setpoints of the applications.Next, a conflict metric is derived based on the constructed matrix to quantify the level of conflict between the applications.

A. CONFLICT REPRESENTATION
A Conflict Matrix is created by organizing the requested setpoints provided by different applications in a tabular format [4].In the matrix, the set of controllable setpoints in the system is arranged in a series of columns, each corresponding to an application (see Fig. 2).Each column vector in the matrix describes the app's intent (D j ).Similarly, each row vector in the matrix represents the set of competing apps for a given controllable point (A i ).If an application does not have a preference for a particular device's setpoint, it may leave the corresponding cell empty.Note that as new applications are added, or existing ones are removed, the matrix should be updated to reflect the current set of applications and their requested setpoints for the shared devices.Please refer to Table 1 for the glossary associated with the Conflict Matrix shown in Fig. 2.

B. MEASURING CONFLICT
The level of disagreement between competing apps can be quantified using a suitable metric.A conflict metric should be symmetric, bounded, and consistent [11].Such a metric informs the system operators about the degree of disagreement between competing apps and facilitates the selection of appropriate techniques to resolve the conflict.This work uses a centroid (or weighted centroid) of conflicting setpoints to calculate the Euclidean distance between the centroid and application-requested setpoints [12], [13] in deriving a conflict metric.

1) SETPOINTS NORMALIZATION
The controllable points in a typical distribution system are associated with controllable DERs, switching devices, and A matrix representation of apps conflicting with each other while controlling a set of devices.Note that an ''xx'' element at a location (i , j ) in the matrix represents that an i th controllable point is not considered by j th app.As new apps and/or controllable devices are introduced, the matrix has the ability to adapt and evolve accordingly.
regulator taps.Thus, depending on the type of device, the controls generated by applications are either continuous (γ To quantify the conflict arising from these varying control sets, we normalize the setpoints based on the maximum conflict a controllable point could see.For example, a regulator tap can observe a control signal from −16 to +16.Similarly, a battery can be charged (+ve P) or discharged (−ve P) with its rated power limit.Suppose γ j i and γ j i represent a control signal's lower and upper bound, respectively.The normalized setpoint is then given by: This ensures that the normalized setpoint requested by i th app in j th controllable point is always between 0 and 1.

2) METRIC DERIVATION
In this section, we describe the mathematical derivation of a metric to quantify conflict.First, we calculate the centroid based on the matrix elements shown in Fig. 2. Specifically, the centroid is a mean of setpoints requested for a controllable point by various apps.Note that even though the matrix shown in Fig. 2 represents m apps, the centroid calculation is based on the actual number of apps requesting control on a particular point.For example, 2 nd and 4 th applications do not consider controllable point #2; therefore, the centroid calculation discards those applications, i.e., |A 2 | < m.The centroid is a vector (n × 1), where n is the number of controllable points in the system Conflict Matrix.Mathematically, it is given by (2).
Next, we calculate the distance between the setpoints requested by each app to the centroid vector.For each app, the distance is calculated, and a distance vector d c is formed.Observe that, in each element of d c , the app index is kept fixed.The distance vector is shown by (3).
The average distance to the centroid is the conflict metric and is calculated using (4).
Using ( 3) and ( 4), the conflict metric can be represented by The final conflict metric is derived by substituting the generic expression for the element of the centroid vector (C A q ) from ( 2) in (5).
Using this conflict metric, system operators and decision-makers can prioritize and allocate resources for deconfliction measures, such as load shedding, reconfiguration, voltage regulation, system losses, etc.The metric can also aid in evaluating the effectiveness of implemented solutions and guide the development of strategies to mitigate conflicts in power distribution operations.

III. QUANTITATIVE ANALYSIS OF SYSTEM VOLATILITY
Conflicts in distribution operations can emerge from commands issued concurrently or in subsequent iterations of the competing applications.Such control command collisions can create a scenario where devices respond to commands arbitrarily, thus creating oscillating system behavior.In this section, we summarize three relevant metrics that can be used to measure the system volatility over a period of time.Initially, we establish a mathematical representation to articulate the evolution of device status over time.This representation will subsequently serve as the foundation for explicitly defining relevant metrics.
Let = {ψ 1 , ψ 2 , . . ., ψ n } represent the set of devices in a system.Suppose ψ j = {µ j (t j 1 ), µ j (t j 2 ), µ j (t j 3 ), . . ., µ j (t j k )} represents the state of j th device (or controllable point) during a certain time under consideration.The set of sampling periods can be represented using: Similarly, the change in the device state during the sampling period is: Note that the sampling period is not a constant time interval, and a device can change its state at any time as requested by competing apps running asynchronously.

A. VARIANCE
System volatility during multi-objective distribution operations depends on the degree to which the system states vary or change with time.In this regard, variance is used to understand the deviation of a sequence of system states, each of which is a function of the device states for a given time under consideration.It can be measured in various time resolutions such as hourly, daily, weekly, monthly, or yearly and indicates how oscillatory the system state was in the past. VAR

B. STATE VARIABILITY INDEX
The dynamic range of a device state and fluctuations in that device setpoint contribute to the volatility of the system.We define a measure of state variability over a period that relates the total length of sampled setpoints dispatched to a device.This metric is inspired by the variability index for irradiance and PV output variability [14], and in this context is referred to as state variability index (SVI).For a given time under consideration, SVI for a device is calculated as: where, Fig. 3 shows an example of conflict and it also includes a demonstration of how to calculate the system volatility metrics discussed earlier.Note that the setpoints are normalized, and the choice of time units is arbitrary in this simplified illustration.

IV. MULTI-OBJECTIVE DISTRIBUTION OPERATIONS
This section presents the distribution system network model and defines three competing apps with diverging objectives.Competing apps leverage the network model and operational constraints to inform decision variables that impact the operation of the distribution system and achieve their objectives.

A. DISTRIBUTION SYSTEM NETWORK MODEL
Power distribution networks are unbalanced owing to unequal single-phase loads and the non-uniform arrangement of threephase overhead and underground lines [15].The power flow model employed to characterize unbalanced three-phase distribution systems is outlined in ( 14) - (16).Note that for a multiphase distribution network, the set of available phases at bus i is represented within the sets j ∈ {a, b, c}, the set of buses is represented by V, and the set of edges is represented by E.
where P where is the square of voltage magnitude at bus i, S φψ ij is the complex power flow in line, and z φψ ij is an element of the complex impedance matrix.The system voltages are to be maintained within the acceptable ANSI limits as shown in (17).
A 32-step voltage regulator (VR) with a range of ±10% is assumed [16].Let m φ be the turn ratio for the VR connected to phase φ of line (i, j) with values ranging from 0.9 to 1.1.Consider a binary variable denoted as u φ tap,i ∈ {0, 1}, which is defined for each tap position, where the index i ranges from 1 to 32.Additionally, a vector n i is introduced, with elements belonging to the set {0.9, 0.90625, . . ., 1.1}, where each successive element differs by 0.00625 per unit (pu).
Then, V φ tap,i the model for a VR is represented using (18).For a multi-phase gangoperated VR, a single M φ , and u φ tap,i variable is defined for each phase.
The batteries' operating constraints are summarized in (19).Note that (x) and (x) represent the upper and lower bound for the dispatch signal (p i batt ) and state of charge (soc).
where i is the battery's rated energy capacity, η c , η d is the charging/discharging efficiency, and λ c , λ d represent the charge/discharge status of a battery.

B. COMPETING APPS
We design three competing apps with the primary goal of demonstrating operational conflicts.These apps are solely for demonstration purposes and are intentionally limited in their capabilities compared to commercial ADMS applications.They do not represent the objectives or sophistication of realtime operations.Three objectives are arbitrarily selected from Fig. 1, and an optimization problem is formulated for each objective.For simplicity, we have chosen linear objectives for each of the competing apps.The distribution network is modeled using linear constraints, incorporating certain binary decision variables.As a result, the optimization problem for the competing apps, as discussed in this section, can be classified as a mixed-integer linear program.

1) RESILIENCE
The resilience app's objective is to maximize the instantaneous reserve within the system.It achieves this by charging the batteries and ensuring the highest state of charge (SoC) is maintained to handle potential grid emergencies [17].
Mathematically, the app is formulated as: 2) DECARBONIZATION The decarbonization app aims to minimize imports from the grid, which is assumed to have a high percentage of fossilfuel-based generation.At the same time, it also ensures excess PV is used within the feeder (supplying loads and charging batteries), thereby maximizing the utilization of renewable energy [18].This objective is summarized in (21).
Note that the objective defined in ( 21) is non-linear due to absolute values.However, it can be linearized by defining an auxiliary variable and including additional inequality constraints (a ≥ p grid and a ≥ −p grid ) [19].To maximize the use of stored power, the second stage of the problem aims to minimize the resistive loss during charging and discharging by increasing the terminal voltage of the batteries.However, increasing the terminal voltage beyond the recommended range can lead to accelerated degradation; operating batteries within their specified voltage limits is essential to maintain efficiency.This is ensured by the voltage limit constraints discussed earlier in this section.
where β j is the set point for j th battery as computed from the first stage as described in (21).

3) CONSERVATION VOLTAGE REDUCTION (CVR)
CVR is a technique used in distribution systems to reduce energy consumption by lowering the voltage supplied to end-users while maintaining acceptable performance levels.Distribution system operators can achieve significant energy savings by implementing CVR and reducing voltage levels [20].This reduction in energy consumption directly translates to reduced costs for purchasing electricity, especially during peak demand.In this section, we define metrics that can effectively quantify the performance of the application under consideration.
When different deconfliction solutions are demonstrated, the chosen metric will serve as a standardized measurement, enabling the evaluation of the application's effectiveness and overall success in meeting its objectives.
• R: This metric quantifies the resilience app's performance and is defined as the average instantaneous reserve within the system.In mathematical terms, the reserve capacity is reflected in the average SoC of the batteries, which indicates how much energy is available at any given moment.
• D: Performance of the decarbonization app is evaluated based on the reduction in megawatt-hours of energy generated from fossil-fuel sources.This metric assesses the app's effectiveness in decreasing energy consumption derived from the grid and fossil-fuel-based distributed generators.
• C: This metric assesses the capability of the CVR app to lower voltage levels while staying within acceptable limits.Mathematically, it quantifies the average deviation between v (which represents the voltage upper limit) and the actual voltage at different nodal points.A successful CVR app would achieve significant voltage reduction and thus maximize the average deviation.A success metric is defined to quantify the impact of different deconfliction solutions on the app's objective.For example, a success metric for the resilience app is given by where R(ex.) represents the resilience metric during the exclusivity case and Q is the set of deconfliction solution techniques.The success metrics for decarbonization and the CVR apps are similarly defined.

V. DEMONSTRATION
In this section, we demonstrate conflict in distribution operations using three competing apps described in Section IV.
The conflict metric and system volatility are quantified using the metrics discussed earlier in this paper.A modified IEEE 123-bus test case1 is selected for demonstration.Timeseries load and solar profiles are used to generate different scenarios that the competing apps take as input to request device setpoints that achieve their respective objectives.Fig. 4 shows the modified IEEE 123-bus test feeder with resource parameters and simulated profiles.

A. SIMULATION SETUP
Load and solar profiles are generated at 15-minute intervals over a 24-hour period for the demonstration.Device status information, specifically battery SoC values, are provided along with the profile data.This set of profile and device status information is taken by any running competing apps to produce new device setpoint requests.Note that apps can send out device setpoints on arbitrary time intervals, not just the same 15-minute interval that profile updates are provided, and further can stop and start producing setpoints entirely at any time, including restarting at arbitrary intervals.The competing apps are implemented in the Python programming language where the optimization formulation is modeled and solved using PuLP [21].
If two or more apps have specified different setpoint values for the same device it is said to be in conflict.The Conflict Matrix maintains requested setpoint values for all competing apps over all devices for which setpoint requests have been made.When a new setpoint request is generated by an app, all previously maintained setpoints for that app are cleared from the matrix before the new setpoints are stored.Therefore, only the most up-to-date setpoints for each app figure into deconflicted setpoint values.

1) DECONFLICTION SOLUTION
Two basic deconfliction solutions have been implemented for the demonstration: exclusivity and compromise.An exclusivity solution is associated with a specific single competing app and once that app makes a setpoint request, only that app will be used to determine the setpoints for those devices for which it has made requests.Note this implies that if the app associated with the exclusivity solution has not yet generated a request, or has not done so for a specific device ever over the simulation period, other competing apps will be included in the determination of setpoints dispatched to devices.The assumption with this policy is that the exclusivity app is considering devices for which it has not requested a setpoint as a ''don't care'' rather than limiting device dispatches to only those requested by the exclusivity app.
Like exclusivity, a compromise solution is also associated with specific apps, but in this case it is a set of multiple apps rather than a single app.For any apps that are part of the compromise set, setpoint requests that are in conflict for a given device are deconflicted, while any setpoint requests for that same device for apps not in the compromise set are disregarded (assuming any apps in the compromise set have ever made a request for that device).The deconflicted setpoint value for the compromise solution that has been implemented for the demonstration is simply to average the device setpoints for all apps in the compromise set.

2) GRIDAPPS-D IMPLEMENTATION
A deconfliction framework consisting of separate processes or components communicating over the GridAPPS-D message bus has been implemented.These components are: The Deconfliction Simulator generates time-series-based load and solar profiles published on the message bus.Additionally, the simulator is the interface to DERs dispatching new setpoints and providing updates on device status such as battery SoC values, also done over the message bus.The Competing Apps component uses the time-series profiles and device status messages from the simulator to determine and then request new device setpoints, published to the message bus, based on their specific objective.The Deconfliction Pipeline implements the workflow that maintains an upto-date Conflict Matrix and produces a Resolution Vector by applying a specific deconfliction solution methodology, compromise or exclusivity, for the demonstration [4].The input to the pipeline is the requested device setpoints sent by Competing Apps and the output is deconflicted device setpoints sent to the Deconfliction Simulator.
The deconfliction solution methodology used for the demonstration is a pluggable component of the Deconfliction Pipeline process.Thus, the pipeline consists of two parts: 1) Core capability to implement the deconfliction workflow that is independent of the methodology, e.g., maintaining the Conflict Matrix and publishing deconflicted device setpoints.2) Solution methodology that produces deconflicted device setpoints in the form of a Resolution Vector.
A Resolution Vector is simply a single setpoint value, deconflicted according to the solution methodology, per device that appears in the Conflict Matrix.Due to the unpredictable timing of competing app setpoint requests mentioned earlier, the Deconfliction Pipeline immediately produces a Resolution Vector for every setpoint request.This results in possibly several different setpoints being dispatched to the same device in quick succession when the competing apps are producing requests based on each newly generated profile and device status message.Further, the deconflicted setpoints computed when the first app that requests setpoints for a new profile timestamp will be based on older requests (meaning associated with a previous timestamp) for all other apps as maintained in the matrix.

B. SIMULATION RESULTS
The three competing apps are simulated within the GridAPPS-D platform for the exclusivity and compromise deconfliction methods.Fig. 5 shows the setpoints for a battery and substation regulator (reg1a).The resilience app charges batteries to maximize the instantaneous reserve in the system.Similarly, the decarbonization app discharges batteries to reduce imports and charges them during peak renewable generation to reduce exports.The CVR app has the overall lower tap position for the substation regulator, thus minimizing the system voltage for CVR benefit.
For the exclusivity method, the deconfliction solutions are simply the app-requested setpoints.In contrast, the compromise method considers the setpoints requested by all competing apps and calculates the deconfliction solution based on those setpoints.Therefore, the total number of control commands dispatched to devices is lower for the exclusivity method.Since the setpoints requested by apps arrive in the deconfliction pipeline asynchronously, the compromise method should evaluate a new solution as soon as it receives a new setpoint from any of the apps.

1) CONFLICT METRIC
Fig. 6 shows the conflict at various times as setpoints are received from the competing apps.It is observed that conflict is lower during the afternoon (i.e., peak PV generation).This is because the competing apps show similar behavior; for example, the decarbonization and CVR apps aim to charge the batteries using excess PV.Similarly, the tap positions are relatively lower due to excessive reverse power  flow, as the apps must satisfy voltage limit constraints.
practicality of the conflict metric lies in its ability to describe the status of the system and inform certain solution strategies.One such application is its utilization in driving consensus within cooperative solution strategies and devising incentive mechanisms centered around conflict mitigation [22].Moreover, the conflict metric can serve as a foundation for developing a set of rules aimed at efficiently and expeditiously resolving conflicts [23].

2) SYSTEM VOLATILITY METRICS
The system volatility metrics are evaluated using the formulation described in Section III and are summarized in Table 2.The compromise method has the lowest variance as the deconfliction solution for a device is the mean of setpoints requested from competing apps.The CVR exclusivity has the highest SVI, as this app uses a combination of batteries and regulators for voltage reduction.The battery setpoints are oscillatory for the CVR app compared to resilience and decarbonization (see Fig. 5).Similarly, the volume is highest for the compromise solution technique.This is because this method calculates a new setpoint as it gets a new request from any of the apps.It is observed that there is no consistent agreement on which solution leads to increased volatility in the system based on a single metric.However, studying the variance, state variability, and volume metrics together can provide a more comprehensive and insightful analysis that leads to informed decisions.

3) APP SUCCESS METRIC
Table 3 shows the app performance for different deconfliction solution techniques.The three metrics defined in Section IV-C are calculated for a day-long simulation.The success metric is also reported for each method using (24), where the exclusivity method is considered the best for respective apps.For example, the highest value of R be seen with the resilience exclusivity method, and the success metric is 1.The success metric is measured by how close it is to its maximum achievable value of 1.It can be seen that app performance with the compromise method is between the best and worst methods.For example, the CVR app performance is the highest (i.e., 1) for the CVR exclusivity method and lowest for decarbonization exclusivity (i.e., 0.392).The app performance with the compromise method is 0.696, i.e., in between 0.392 and 1.

VI. CONCLUSION
In this paper, we presented a novel metric for quantifying conflict in multi-objective power distribution operations, where the proliferation of controllable devices has led to increased interactions and potential conflicts between different applications.The conflict quantification metric introduced provides a robust and standardized approach to assess the level of interference and incompatibility between competing applications.Moreover, the paper also presents a set of relevant metrics to measure system volatility resulting from the operation of controllable devices and changes in the system state.These additional metrics offer a comprehensive view of the system's performance, enabling utilities to monitor and identify potential volatile points caused by the interaction of multiple applications during distribution operations.
We are currently applying these metrics in developing innovative deconfliction methodologies in our own research and further exploring the applicability of this decision-making framework in other contexts.By employing these metrics, utilities can make informed decisions, select effective deconfliction methodologies, and monitor system performance, ultimately enhancing power distribution operations' overall efficiency and reliability in the presence of diverse and competing applications.

FIGURE 1 .
FIGURE 1.Summary of application objectives aimed towards achieving various system-level mandates.

φ
ij and Q φ ij denote the real and reactive power flow in branch ij, incoming at bus j, p φ inj,j represents net injection at bus j, which is the aggregation of load (p j load ), battery (p j batt ), and solar photovoltaic (PV) (p j pv ).

1 .
φ j = m φ V φ i where, m φ = Taking the square of the voltage equation, defining m 2 φ = M φ , n 2 i = N i , and realizing that (u φ tap,i ) 2 = u

FIGURE 6 .
FIGURE 6. Conflict metric for different deconfliction solutions.The variance of conflict metrics for a day-long simulation is also presented for each solution.

TABLE 1 .
Nomenclature for conflict characterization.
3, . . .|T j |} represents indices of the sampling period.If the status of a device remains constant during the specified period of time, SVI ψ j is unity.For n C. VOLUMEThis metric measures the total number of setpoints sent to devices over time.Mathematically, this metric is calculated as:VOL = j∈D |ψ j |(13)FIGURE 3. Illustration of application conflict and calculation of system volatility metrics.A single device is controlled by two apps asynchronously.

TABLE 2 .
Summary of system volatility metrics for deconfliction methods.