# Edge Computing Architectures for Enabling the Realisation of the Next
Generation Robotic Systems

Achilleas Santi Seisa1, Gerasimos Damigos2, Sumeet Gajanan Satpute1, Anton
Koval1 and
George Nikolakopoulos1 This work has been partially funded by the European
Unions Horizon 2020 Research and Innovation Programme AERO-TRAIN under the
Grant Agreement No. 953454.1 The authors are with the Robotics and AI Team,
Department of Computer, Electrical and Space Engineering, Luleå University of
Technology, Luleå 2 The author is with Ericsson Reasearch, Luleå Corresponding
Author’s email<EMAIL_ADDRESS>
###### Abstract

Edge Computing is a promising technology to provide new capabilities in
technological fields that require instantaneous data processing. Researchers
in areas such as machine and deep learning use extensively edge and cloud
computing for their applications, mainly due to the significant computational
and storage resources that they provide. Currently, Robotics is seeking to
take advantage of these capabilities as well, and with the development of 5G
networks, some existing limitations in the field can be overcome. In this
context, it is important to know how to utilize the emerging edge
architectures, what types of edge architectures and platforms exist today and
which of them can and should be used based on each robotic application. In
general, Edge platforms can be implemented and used differently, especially
since there are several providers offering more or less the same set of
services with some essential differences. Thus, this study addresses these
discussions for those who work in the development of the next generation
robotic systems and will help to understand the advantages and disadvantages
of each edge computing architecture in order to choose wisely the right one
for each application.

###### Index Terms:

Robotics; Edge Computing

##  I Introduction

Currently, the robotics community is pushing the autonomy levels for the next
generation of applications with autonomous robots [1]. Among the typical
examples, one can highlight the multi-session simultaneous localization and
mapping (SLAM), with multiple robots in exploration or map-based navigation
missions that include collaborative online point cloud map merging and at the
same time provide estimation of robots’ localization [2]. These tasks are
computationally expensive and are demanding an extensive amount of memory and
computational resources. As a response to these demands, the edge computing
has a high potential to solve these tasks by offloading them from the on-board
computers and support faster executions by providing capacity for real-time
processing. Additionally, the integration of the edge architectures with the
also emerging 5G communication technologies with gigabit speeds and low
latencies will allow to establish a ubiquitous communication between robots
[3, 4]. A typical example of such a demanding application is when solving the
multi-robot SLAM problem that is also critical for the robots’ risk-aware
navigation [5, 6] in dynamically changing environments that demands low
latencies, as well as a minimal lag in the response to high-level control
commands, efficient visual representation, security and privacy of data [7].

Towards these challenges, it is expected that the development and utilization
of edge computing and 5G technologies can drastically boost the levels of
robotic autonomy and result in overcoming existing on-board hardware
limitations, which will foster answering these challenges. Alike on-board
computers, edge platforms can handle huge amount of data at a very high
processing speed, provide strong computation capacity and real-time data
transmission. In comparison to cloud computing, edge computing has the
capacity to enable local computing, thus dealing more efficiently with big
volumes and velocities of generated local data [8]. Moreover, it will provide
lower latencies due to the significantly smaller distance between the edge
connected robots and the edge datacenters. Thus, in this article, we analyze
different types of cloud architectures with the focus on edge-based
architectures, especially for robotic systems.

Edge computing is a promising technology that may foster solving some of the
existing fundamental challenges in the field of robotics that will allow to
push the realisation of the next generation of robotic systems with higher
levels of autonomy and longer operational times. In order for the robotic
platforms to operate for a longer period of time, they need to be lighter and
have a lower computational load locally, while being equipped with sensors
that are capable to generate the necessary data required for low-level
autonomy and mission execution. Additionally, in the collaborative missions
with the multi-agent systems it is crucial that in some tasks all the robots
are able to communicate with each other and exchange data in real-time. At the
same time, some processes will require information that was collaboratively
generated by all robots [2].

With the utilization of edge computing technologies, data that are generated
from on-board robotic sensors can be sent to the edge allowing to offload
demanding computational processes. After processing these data, control
commands can be generated, that shall be sent from the edge back to the
robots. Moreover, there is a need for a suitable communication technology as
5G network, to close the entire control loop using an edge architecture. Thus,
edge computing will provide high computation power, storage resources and
minimal time delays, since edge servers are close to the source of data, while
5G network solutions will reliably provide high data bandwidth with consistent
low latencies [9].

Even with the development of edge computing, some data might need to be sent
to the cloud [10] for further processing and storage purposes. Moreover, the
fog computing [10] paradigm gained high interest, so that the final edge
ecosystem for robotic applications could be a hybrid edge-(fog)-cloud robotic
system for distributed data and computational processes. A detailed review on
edge computing is presented in [11], where researchers focus on edge computing
general concepts, while the current work addresses the utilization of edge
computing exclusively for robotic applications.

Figure 1: Data processing and storage layers

Thus, the main contributions of this article is to present, compare and
analyze different edge/cloud-based architectures for robotic applications,
while analyzing the technologies behind these architectures. Prior to the
presentation and analysis of each of the architectures, we will dive into the
four layers of computing (CLOUD, FOG, EDGE, ROBOTS) architectures, from a
robotic systems perspective and with a focus on what each of these layers
offers or enables to the field. Moreover, we will present a brief review of
related computational technologies, such as Virtual Machines (VMs), Containers
and Kubernetes, why and how each one can be used for deploying applications to
the edge. Additionally, simulation and development tools will be presented and
compared for a first time ever from a robotics perspective. A comparison of
the edge and cloud providers and the types of services they offered, regarding
the computational resources for the robotic applications are also examined. To
elucidate these terms, in Section V we present several edge-based robotic
applications and we state the importance of the mentioned approaches.

The rest of the article is structured as it follows. In Section II edge/cloud-
based architectures for computing robotic systems will be discussed. In
Section III we present the main solutions and software that exist today for
edge-based applications, while in Section IV we set forth a review about
available edge and cloud providers. In these Sections, it is essential to
investigate the advantages and disadvantages of these solutions for each
application. In Section V, we are presenting various robotic applications
running mainly on the edge. Finally, we conclude this article in Section VI by
summarizing all the parameters we have to consider when deciding for a cloud-
based solution for robotic applications.

##  II Cloud - Fog - Edge

The constantly increasing need for computational power and storage resources
has led into the development of various computing architectures [12].
Researchers from several fields of technology like deep learning [13], video
analytics [14], industry 4.0 [15] are constantly trying to utilize the
available architectures or propose new ones, in order to solve existing
challenges and to provide new opportunities [16]. All these architectures are
based on four different computing and storage layers, as depicted in Fig. 1,
where the bottom layer is formed from the connected devices. Generally, these
layers can be considered as it follows:

  1. 1.

DEVICES LAYER - multiple robotic systems

    1. (a)

Data generation

    2. (b)

Light data processing

    3. (c)

Low level control

    4. (d)

Other processes needed locally

  2. 2.

EDGE LAYER - offloads computational load from robotic systems to remote
entities

    1. (a)

Large volume real-time data processing

    2. (b)

On premises data visualization

    3. (c)

High level control

    4. (d)

Micro data storage

  3. 3.

FOG LAYER - extended EDGE LAYER with multiple heterogeneous interconnected
nodes

    1. (a)

Local networking

    2. (b)

Control response

  4. 4.

CLOUD LAYER - provides ample storage and computation capabilities, however,
alike EDGE and FOG layers, this has long response latency

    1. (a)

Big data processing

    2. (b)

Data storage

Giving a closer look at each architectural layer, from the robotics
perspective, it will allow us to provide better understanding of the
opportunities and challenges that can be addressed using one or another
architecture.

At its base, the DEVICES LAYER is represented by individual robots that are
equipped with application driven sensors like cameras and lidars for
perception, navigation and inspection tasks. These sensors can produce
gigabytes of data, which has to be processed on-board in order to enable the
autonomous capabilities of the robotic platform. However, due to the limited
computational power, only light data processing, which is required, for
example, for a single robot SLAM and low level control, can be performed on-
board. While in more demanding applications, which involve multiple robots,
there is a need to extend this layer with EDGE or FOG layers. These layers
allow for real-time data processing of large data batches that are streamed
from the network connected robots to the edge server, where heavy computations
that require low latencies are carried out. One of such examples is the multi-
session SLAM in which multiple SLAM missions are performed collaboratively by
multiple robots that explore the same environment. Besides that, the FOG LAYER
allows to extend the exploration mission to multiple environments, thus
creating a network of heterogeneous interconnected nodes. The CLOUD LAYER
excels over the EDGE and FOG layer in terms of storage and computational
capabilities, but in comparison to EDGE layer that is located close to the
DEVICES layer, CLOUD layer is located much further away from the DEVICE layer.
Additionally to that, CLOUD layer is commonly characterized by long response
latencies, which can be explained to the long distance between the DEVICE and
the CLOUD layer, and thus the robotic challenges for the next generation
robotic systems cannot be fully addressed by solely this layer. Thus, one can
observe various architectures that are based on the collection of these
multiple layers.

##  III Virtual Machines - Containers - Kubernetes

With the advent of cloud computing and virtualization, many applications apart
from robotics are exploring the optimal possible utilization of such
technologies. Though virtualization options are a known discussion in the
academia and industry, here we make an effort and touch on the three most
popular virtualization technologies as well as discuss their characteristics
and compare them in terms of benefits and drawbacks for cloud robotics
applications.

###  III-A Virtual Machines

A virtual machine (VM) is a computer resource that utilizes software instead
of a physical computer to deploy applications and run programs and processes
[17]. VMs also provide a complete emulation of low-level hardware devices like
CPU, Disk, RAM, networking devices, and others. VMs can be configured
accordingly, to support any application topology and provide a stable platform
regarding dependency issues (operating system compatibility, specific software
packages, etc.). Specifying computational resources (in Fig 2, e,g. time
deviation of a procedure in the edge with different rates) and resource
scaling, redeploying VM applications on different host computers, isolating
sensitive applications, as well as running VMs in the Edge cloud are some of
the benefits that VMs offer in cloud robotics-related applications.
Furthermore, VMs provide a more dynamic and interactive development experience
when compared with other virtualization technologies. The latter derives from
the fact that VM encompass a full-stack system, as well as utilizing an entire
operating system and what one may provide, e.g. a Graphical User Interface.

Figure 2: A procedure was offloaded to the edge as a VM application (also
reproduced with containers and k8s). Five different rates where selected for
that procedure and the time deviation was measured for each one of them. The
mean time of that process coincides with time corresponding rate.

###  III-B Containers

Containers are software packages that include all the software dependencies
required to execute the contained software application. The main difference
between container and VM is that VM emulates an entire machine down to the
hardware layers, while containers only emulate the software components. Such
software components might be system libraries, external software packages, and
other operating system level applications [18]. Because containers are only
emulating software components, they are more lightweight and easy to iterate.
Additionally, most container runtime systems provide robust pre-made container
(image) repositories. A popular example in robotic applications could be the
Robot Operating System (ROS) image. Another key benefit of container
technologies is that software packages, contained in the constructed images,
can be stacked in levels and produce a novel and more complete application.
These flexible characteristics of containers, i.e., lightweight and easy to
iterate, are responsible for the birth of another technology, container
orchestration.

The generic topology architecture of containerized applications for robotic
systems is shown in Fig 3. As it is indicated, Data are sent from the robots
to the edge and then commands generated from the containers are sent back to
robots. Data processing, high level controllers and advanced algorithms can be
deployed to the application containers for various robotic missions.

Figure 3: Architecture of containerized applications for robotic platforms

###  III-C Kubernetes

Kubernetes (k8s) is an open-source platform that orchestrates container
runtime platforms systems across network-connected hardware infrastructure
[19]. K8s was initially developed by Google that needed an efficient way of
managing billions of container applications weekly. In such systems, the
surface of additional needs became present. Reliability, scalability,
robustness, security, and others are essential requirements in real-world
applications. k8s bundles a set of containers into a group (called a pod) and
manages their life cycle. An example of such a set could be an application
server, an SQL database, a Model Predictive Control (MPC) running apart from
the robot, a set processing SLAM, and others. K8s will manage these pods
performing multiple essential tasks, such as reducing network overhead,
increasing resource usage efficiency (load balancing between copies of the
same application, either to the same machine or across the cloud cluster),
hardware resources designated for your specific configuration (Fig 2),
monitoring and much more since k8s is a rapidly progressing state of-the-art
technology. To conclude this section we want to present a small topology
architecture example illustrated in Fig 4. Here you can see how multiple
agents are all connected to the Edge cloud where different applications are
orchestrated by K8s. In this example, K8s is responsible for scheduling
resource-demanding computational jobs (on different worker nodes), managing
network traffic and can also be utilized for redundancy requirements.

Figure 4: Kubernetes architecture for robotic platforms

##  IV Edge Providers

Before we start designing a cloud-based architecture, we have to be aware of
the available providers in the related region and the services they provide.
In Table I we go through some of the main cloud and edge providers and cloud
solutions that are provided. When we are using the term edge, we are thinking
in terms of minimal latency, network hops and distance from the source of
data. Thus, it is more likely that local edge providers, that are not
mentioned in the Table below, will be better options. Table I can be utilized
as a common ground for acknowledging the available providers and services they
offer, while the cloud computing solutions are available in various locations
around Europe. Since we are interested in low latency we did not take under
consideration solutions that might be available only outside Europe. The
sources for Table I were extracted from [20], [21] and [22].

TABLE I: Comparison overview of the existing cloud solutions for robotic applications Services and Solutions |  | Amazon - AWS
---
| Microsoft - Azure
---
| Google - GCP
---
| Simulation Software for
---
Robotics Application
| Robomaker:
---
Good for simulations
Deployed applications run on the
local robot and not on the cloud
Limited location servers
|
| Virtual Machines
---
| Elastic Compute Cloud (EC2):
---
Access other AWS services
Many OS options
GPU graphic or compute instances
Security
Many location servers
Complex
Price variations (expensive)
Lightsail:
Simple and easy to use
Upgradable to EC2
Affordable
Images on virtual private server
Instances of several OS
Some location servers
Some service options
Limited CPU capacity
| Azure Virtual Machine (AVM):
---
High availability
Security
Scalability
Slow
Few options for low size VMs
| Google Compute Engine (GCE):
---
Easy to use
Many CPU and GPU options
High-performance VMs
Easy to scale
Container support
Some location servers
High overhead
Slow auto-scaling
| Containers
---
| Elastic Container Service (ECS):
---
Manages containers in clusters
Integrates with the AWS ecosystem
Control plane is totally free
Many location servers
| Azure Container Instances (ACI):
---
Instances of Linux and Microsoft OS
Many CPU and GPU options
Many location servers
Fast and easy to use
Security
Complex
Expensive
| Kubernetes
---
| Elastic Kubernetes Service (EKS):
---
Flexible
Easy to migrate workload to another
platform
Good for complex applications
Offers more control
Control plane is charged
| Azure Kubernetes Service (AKS):
---
Flexible
Reduced management overhead
Control Panel is free
Some location servers
| Google Kubernetes Engine (GKE):
---
Open-source container orchestration
Prebuilt kubernetes applications and
templates
Ease to migrate traditional workloads
Limited location servers

These cloud solutions, can work as an ecosystem. For example, Amazon Web
Services (AWS) [23] can be combined so Amazon Elastic Kubernetes Service (EKS)
can be integrated to Amazon Elastic Compute Cloud (EC2), to deploy and manage
containerized applications at scale. The same idea applies with Google Cloud
[24], where Kubernetes Engine (GKE) monitoring tools can be integrated to
Google Cloud Compute Engine (GCE).

###  IV-A Amazon AWS

Amazon’s AWS provide several options in terms of cloud computing and is the
leader of cloud computing. Each option has some advantages and disadvantages.
We will go through the Table’s I data and analyze the options for deploying a
robotic application. Amazon AWS Robomaker is a good cloud-based option for
developing, testing, deploying intelligent robotics applications and running
simulations. The downside is that there are not many servers across the world
so in most cases Robomaker can not be used as Edge. An additional drawback and
reason that Robomaker can not be used as Edge is that although the development
happens on cloud, the deployed application runs locally on the robot. Amazon
Lightsail is an affordable and good option for deploying applications with low
demands. It is easy to deploy instances of several OS and has the option to be
upgraded to EC2 for higher demands. EC2 is the main cloud compute option of
AWS. It offers plenty OS options and there are available servers all across
the world, and provides the choice for Kubernetes orchestration for the
containerized applications [23], [25].

###  IV-B Microsoft Azure

Microsoft Azure has less compute services compared to AWS and less location
servers and is the second largest platform for cloud/edge computing solutions.
Azure offers smooth hybrid-cloud environment which is of great importance as
mentioned in Section II. AVMs provide security and scalability but few options
for low size VMs. In contrast, Azure ACI and AKS provide a wide range of
solutions, such as GPU, CPU options, fast and easy environment and are
available in many locations [26], [25].

###  IV-C Google Cloud

Google Cloud offer less location and service options compared to AWS, but has
a handful of options for cloud solutions. GCE provide many CPU and CPU option,
high performance VMs and container support. The GKE offers prebuild kubernetes
applications and templates and it is quite easy to migrate traditional
workloads. Additionally provides outstanding open-source options [24], [25].

Latency, safety concerns are some of the issues that should be addressed. The
continuous development and the combination of edge computing and 5G networks
can be the answer to these challenges. When thinking of edge computing
solutions, since time delays is one of the most important parameters, local
edge providers should be considered. Local providers, in most cases, will have
their servers closer to the client’s source of generated data, thus they will
be able to provide lower latency. Additionally, requests can be more flexible
regarding provided services. Most of the times, local providers offer VMs,
docker hub and Kubernetes solutions as well as several storage and security
options.

##  V Edge Robotics Applications

In this Section, we present some edge-based robotic applications, selected
from research articles and the state-of-art. The following applications, use
some of the technologies, architectures and services mentioned above.

Computational offloading to the edge and or the cloud for robotic platforms is
a topic that nowadays has become more and more relevant. The generated amount
of data that robots produce and has to be analyzed at each moment in almost
real-time, must be respected. Offloading this computational effort will bring
great advantages in terms of latency and computational capacity, which is a
very important factor to keep in mind. Researchers and engineers have been
trying, in the last couple of years, to offload some computational demanding
procedures to the edge and the results in some cases are notable.

In [27], a platform is presented for a heterogeneous robotic system focused on
search missions. A lightweight traversal algorithm deployed in the edge is
proposed for high available search. A group of robots will perform a
cooperative mission to search and find artifacts in a predefined area, quickly
and intelligently, while edge computing is used for offloading the task
partitioning algorithm, considering real data processing and low latency.
Thus, the UAV sends data to the edge when performing traversal tasks. In [28],
social fog robotics systems are introduced for responsive human-robot
interaction and several architectures are presented. The response rate of
robots is validated and the whole system is examined in terms of latency. SLAM
tasks are offloaded to the edge and the system’s architecture is presented in
[29], where edge is used for real-time decisions. The architecture of this
system has the following four layers, each one for a different cause. The
robot and edge layer is used for data processing and analysis, while the fog
layer is used for distributed storage and the cloud layer is used for
monitoring and for general mission control. In [30] the edge is used to reduce
the delay and energy consumption of deep learning models by analyze the
performance of edge servers and estimate time delays, to establish a mechanism
on intelligent data envelopment for intelligent social robots. In [31], deep
robot learning distributes compute, storage and networking resources between
the cloud and the edge for the task of object recognition and grasp planning
by a mobile robot. In [32], the edge is used for offloading a dynamic self-
balancing navigation controller, while cloud is used for assisted
teleoperation and visual recognition of dynamic self-balancing robots that can
detect and pick up objects, while being teleoperated.

Some articles are focused on offloading controllers on the edge. In [33], [34]
and [35] the MPC is proposed to be offloaded to the edge. These articles are
focused mainly on evaluating latency, long time delays and uncertainty. The
control in [34] is composed with the combination of a LQR (locally) and MPC
(Edge) control, while in [33] two MPC are implemented, one on a local Edge and
one on a Cloud. The computationally heavy MPC is offloaded to the Edge. In
[35] a variable horizon strategy for a cloud-based MPC is presented and a
remote MPC is used to control a ball and bean system. In [36] applications,
containing remote controller, run in a Mobile Edge server in a form of Docker
Containers. These application are controlling two robotic arms for cooperation
tasks in an industrial environment, while in [37] and in [38] the utilization
of fog layer to enhance the capabilities of industrial robotics has been
proposed. In [39] a switching multi-tier control is presented. The switcher is
choosing between a local controller which operates as a safety controller and
an Edge controller which runs more sophisticated algorithms with optimal
performance.

As mentioned in Section III, in many cases edge computing is based on
kubernetes components. An edge architecture and an open-source network is
presented in [40], where the kubernetes container orchestration middleware is
highlighted for the deployment of virtual networks spanning distributed edge
and cloud resources. The goal of [41] is to automate the process of making
decision in terms of placement of the expected workload. In this article,
generated data from various sensors from smart home, cities, construction and
robots are distributed to edge, fog and cloud. This process is achieved by
using kubernetes orchestration. In [42], studied plugins based on Container
Network Interface (CNI) to provide low-latency edge services, that can be used
in robotic applications [43]. Finally, in [44], a methodology based on docker
and kubernetes for ROS-based robotic application is presented. In that case,
the architecture was evaluated by experimental results obtained by a mobile
robot interacting with an industrial agile production chain.

Mobile edge computing (MEC) has been recognized as a promising technique.
Thank to the advantages of saving energy for users, providing low latency and
achieving security, MEC has received increasing attention in both academia and
industry. In that context, a different but interesting approach is presented
in [45]. In this article, researcher suggested a MEC system, where aerial
robots are equipped with servers to provide MEC services to ground users.

##  VI Conclusions

Edge-based robots set the state-of-art in the field of robotics. The
significant possibilities have attracted the attention of researchers and
engineers. Despite the attention, there is great room for improvement and
future directions. Even though edge can play a remarkable role in multi-agent
systems, in terms of robot communication and collaboration, there are not so
many articles towards this direction. Furthermore, edge capabilities regarding
computational power can be be exploited even more in the future, so more heavy
and demanding tasks can be offloaded there. The rapid development of
communication (5G networks) and computing technologies (cloud, fog, edge
computing) will provide more possibilities and solve current challenges, hence
will help the robotics field to move towards fully autonomous systems. In that
concept, we investigated, presented, analyzed and compared the different
architectures, typologies and their components. Most of these technologies and
methods are recently developed thus, we wanted to display a general idea of
all these terms and spread awareness of various solutions. Additionally, we
would like to inspire researchers to engage with this area and contribute in
their own way.

## References

  * [1] G. Nikolakopoulos and A. Agha, “Pushing the limits of autonomy for enabling the next generation of space robotics exploration missions,” _Computer_ , vol. 54, no. 11, pp. 100–103, 2021.
  * [2] A. Agha, K. Otsu, B. Morrell, D. D. Fan, R. Thakker, A. Santamaria-Navarro, S.-K. Kim, A. Bouman, X. Lei, J. Edlund, _et al._ , “Nebula: Quest for robotic autonomy in challenging environments; team costar at the darpa subterranean challenge,” _arXiv preprint arXiv:2103.11470_ , 2021.
  * [3] T. Taleb, K. Samdanis, B. Mada, H. Flinck, S. Dutta, and D. Sabella, “On multi-access edge computing: A survey of the emerging 5g network edge cloud architecture and orchestration,” _IEEE Communications Surveys & Tutorials_, vol. 19, no. 3, pp. 1657–1681, 2017.
  * [4] Y. Zeng, Q. Wu, and R. Zhang, “Accessing from the sky: A tutorial on uav communications for 5g and beyond,” _Proceedings of the IEEE_ , vol. 107, no. 12, pp. 2327–2375, 2019.
  * [5] B. Lindqvist, S. S. Mansouri, J. Haluška, and G. Nikolakopoulos, “Reactive navigation of an unmanned aerial vehicle with perception-based obstacle avoidance constraints,” _IEEE Transactions on Control Systems Technology_ , 2021.
  * [6] B. Lindqvist, S. S. Mansouri, P. Sopasakis, and G. Nikolakopoulos, “Collision avoidance for multiple mavs using fast centralized nmpc,” _arXiv preprint arXiv:2109.01012_ , 2021.
  * [7] G. Nikolakopoulos, A. Panousopoulou, and A. Tzes, “Experimental controller tuning and qos optimization of a wireless transmission scheme for real-time remote control applications,” _Control Engineering Practice_ , vol. 16, no. 3, pp. 333–346, 2008.
  * [8] Y. Jararweh, A. Doulat, O. AlQudah, E. Ahmed, M. Al-Ayyoub, and E. Benkhelifa, “The future of mobile cloud computing: integrating cloudlets and mobile edge computing,” in _2016 23rd International conference on telecommunications (ICT)_. IEEE, 2016, pp. 1–5.
  * [9] “The next wave of 5G innovation with Time-Critical Communication ericsson,” https://www.ericsson.com/en/internet-of-things/iot-connectivity/cellular-iot/time-critical-communication, accessed: 2022-02-25.
  * [10] H. Wang, T. Liu, B. Kim, C.-W. Lin, S. Shiraishi, J. Xie, and Z. Han, “Architectural design alternatives based on cloud/edge/fog computing for connected vehicles,” _IEEE Communications Surveys & Tutorials_, vol. 22, no. 4, pp. 2349–2377, 2020.
  * [11] N. A. Sulieman, L. Ricciardi Celsi, W. Li, A. Zomaya, and M. Villari, “Edge-oriented computing: A survey on research and use cases,” _Energies_ , vol. 15, no. 2, p. 452, 2022.
  * [12] M. De Donno, K. Tange, and N. Dragoni, “Foundations and evolution of modern computing paradigms: Cloud, iot, edge, and fog,” _Ieee Access_ , vol. 7, pp. 150 936–150 948, 2019.
  * [13] F. Wang, M. Zhang, X. Wang, X. Ma, and J. Liu, “Deep learning for edge computing applications: A state-of-the-art survey,” _IEEE Access_ , vol. 8, pp. 58 322–58 336, 2020.
  * [14] Y. Wang, W. Wang, D. Liu, X. Jin, J. Jiang, and K. Chen, “Enabling edge-cloud video analytics for robotics applications,” _IEEE Transactions on Cloud Computing_ , 2022.
  * [15] P. Pace, G. Aloi, R. Gravina, G. Caliciuri, G. Fortino, and A. Liotta, “An edge-based architecture to support efficient applications for healthcare industry 4.0,” _IEEE Transactions on Industrial Informatics_ , vol. 15, no. 1, pp. 481–489, 2018.
  * [16] J. Pan and J. McElhannon, “Future edge cloud and edge computing for internet of things applications,” _IEEE Internet of Things Journal_ , vol. 5, no. 1, pp. 439–449, 2017.
  * [17] T. V. Doan, G. T. Nguyen, H. Salah, S. Pandi, M. Jarschel, R. Pries, and F. H. Fitzek, “Containers vs virtual machines: Choosing the right virtualization technology for mobile edge cloud,” in _2019 IEEE 2nd 5G World Forum (5GWF)_. IEEE, 2019, pp. 46–52.
  * [18] C. Pahl and B. Lee, “Containers and clusters for edge cloud architectures–a technology review,” in _2015 3rd international conference on future internet of things and cloud_. IEEE, 2015, pp. 379–386.
  * [19] J. Shah and D. Dubaria, “Building modern clouds: using docker, kubernetes & google cloud platform,” in _2019 IEEE 9th Annual Computing and Communication Workshop and Conference (CCWC)_. IEEE, 2019, pp. 0184–0189.
  * [20] P. Kaushik, A. M. Rao, D. P. Singh, S. Vashisht, and S. Gupta, “Cloud computing and comparison based on service and performance between amazon aws, microsoft azure, and google cloud,” in _2021 International Conference on Technological Advancements and Innovations (ICTAI)_ , 2021, pp. 268–273.
  * [21] P. Pierleoni, R. Concetti, A. Belli, and L. Palma, “Amazon, google and microsoft solutions for iot: Architectures and a performance comparison,” _IEEE Access_ , vol. 8, pp. 5455–5470, 2020.
  * [22] M. Saraswat and R. Tripathi, “Cloud computing: Comparison and analysis of cloud service providers-aws, microsoft and google,” in _2020 9th International Conference System Modeling and Advancement in Research Trends (SMART)_ , 2020, pp. 281–285.
  * [23] M. Forster and G. N. Masters, “Products,” 1998. [Online]. Available: https://aws.amazon.com/products/compute/?nc2=h_ql_prod_cp
  * [24] “Products and services; google cloud.” [Online]. Available: https://cloud.google.com/products
  * [25] A. Bartwal, S. Dhyani, J. Subedi, and R. Dangayach, “Aws vs azure vs gcp: Difference between cloud platforms,” Dec 2021. [Online]. Available: https://k21academy.com/amazon-web-services/aws-solutions-architect/aws-vs-azure-vs-gcp/
  * [26] “Directory of azure cloud services: Microsoft azure.” [Online]. Available: https://azure.microsoft.com/en-us/services/
  * [27] A. Barnawi, M. Alharbi, and M. Chen, “Intelligent search and find system for robotic platform based on smart edge computing service,” _IEEE Access_ , vol. 8, pp. 108 821–108 834, 2020.
  * [28] S. L. K. C. Gudi, S. Ojha, B. Johnston, J. Clark, and M.-A. Williams, “Fog robotics for efficient, fluent and robust human-robot interaction,” in _2018 IEEE 17th International Symposium on Network Computing and Applications (NCA)_. IEEE, 2018, pp. 1–5.
  * [29] V. K. Sarker, J. P. Queralta, T. N. Gia, H. Tenhunen, and T. Westerlund, “Offloading slam for indoor mobile robots with edge-fog-cloud computing,” in _2019 1st international conference on advances in science, engineering and robotics technology (ICASERT)_. IEEE, 2019, pp. 1–6.
  * [30] Y. Sun, “Cloud edge computing for socialization robot based on intelligent data envelopment,” _Computers & Electrical Engineering_, vol. 92, p. 107136, 2021.
  * [31] A. K. Tanwani, N. Mor, J. Kubiatowicz, J. E. Gonzalez, and K. Goldberg, “A fog robotics approach to deep robot learning: Application to object recognition and grasp planning in surface decluttering,” in _2019 international conference on robotics and automation (ICRA)_. IEEE, 2019, pp. 4559–4566.
  * [32] N. Tian, A. K. Tanwani, J. Chen, M. Ma, R. Zhang, B. Huang, K. Goldberg, and S. Sojoudi, “A fog robotic system for dynamic visual servoing,” in _2019 International Conference on Robotics and Automation (ICRA)_. IEEE, 2019, pp. 1982–1988.
  * [33] K.-E. Årzén, P. Skarin, W. Tärneberg, and M. Kihl, “Control over the edge cloud-an mpc example,” in _1st International Workshop on Trustworthy and Real-time Edge Computing for Cyber-Physical Systems, Nashville, United States_ , 2018.
  * [34] P. Skarin, J. Eker, M. Kihl, and K.-E. Årzén, “Cloud-assisted model predictive control,” in _2019 IEEE International Conference on Edge Computing (EDGE)_. IEEE, 2019, pp. 110–112.
  * [35] P. Skarin, J. Eker, and K.-E. Årzén, “Cloud-based model predictive control with variable horizon,” _IFAC-PapersOnLine_ , vol. 53, no. 2, pp. 6993–7000, 2020.
  * [36] I. A. Tsokalo, H. Wu, G. T. Nguyen, H. Salah, and F. H. Fitzek, “Mobile edge cloud for robot control services in industry automation,” in _2019 16th IEEE Annual Consumer Communications & Networking Conference (CCNC)_. IEEE, 2019, pp. 1–2.
  * [37] S. M. Salman, V. Struhar, A. V. Papadopoulos, M. Behnam, and T. Nolte, “Fogification of industrial robotic systems: Research challenges,” in _Proceedings of the Workshop on Fog Computing and the IoT_ , 2019, pp. 41–45.
  * [38] M. S. Shaik, V. Struhár, Z. Bakhshi, V.-L. Dao, N. Desai, A. V. Papadopoulos, T. Nolte, V. Karagiannis, S. Schulte, A. Venito, _et al._ , “Enabling fog-based industrial robotics systems,” in _2020 25th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA)_ , vol. 1. IEEE, 2020, pp. 61–68.
  * [39] Y. Ma, C. Lu, B. Sinopoli, and S. Zeng, “Exploring edge computing for multitier industrial control,” _IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems_ , vol. 39, no. 11, pp. 3506–3518, 2020\.
  * [40] R. Figueiredo and K. Subratie, “Edgevpn. io: Open-source virtual private network for seamless edge computing with kubernetes,” in _2020 IEEE/ACM Symposium on Edge Computing (SEC)_. IEEE, 2020, pp. 190–192.
  * [41] P. Kochovski, R. Sakellariou, M. Bajec, P. Drobintsev, and V. Stankovski, “An architecture and stochastic method for database container placement in the edge-fog-cloud continuum,” in _2019 IEEE International Parallel and Distributed Processing Symposium (IPDPS)_. IEEE, 2019, pp. 396–405.
  * [42] J.-G. Cha and S. W. Kim, “Design and evaluation of container-based networking for low-latency edge services,” in _2021 International Conference on Information and Communication Technology Convergence (ICTC)_. IEEE, 2021, pp. 1287–1289.
  * [43] S. Qi, S. G. Kulkarni, and K. Ramakrishnan, “Understanding container network interface plugins: design considerations and performance,” in _2020 IEEE International Symposium on Local and Metropolitan Area Networks (LANMAN_. IEEE, 2020, pp. 1–6.
  * [44] F. Lumpp, M. Panato, F. Fummi, and N. Bombieri, “A container-based design methodology for robotic applications on kubernetes edge-cloud architectures,” in _2021 Forum on specification & Design Languages (FDL)_. IEEE, 2021, pp. 01–08.
  * [45] F. Zhou, Y. Wu, H. Sun, and Z. Chu, “Uav-enabled mobile edge computing: Offloading optimization and trajectory design,” in _2018 IEEE International Conference on Communications (ICC)_. IEEE, 2018, pp. 1–6.


# Robust Operating Envelopes with Uncertain Demands and Impedances in
Unbalanced Distribution Networks

Bin Liu  Julio H. Braslavsky  and Nariman Mahdavi  Bin Liu (corresponding
author), Julio, H. Braslavsky and Nariman Mahdavi are with Energy Systems
Program, Energy Centre, Commonwealth Scientific and Industrial Research
Organisation (CSIRO), Mayfield West 2304, Australia. Emails: {brian.liu,
julio.braslavsky<EMAIL_ADDRESS>
###### Abstract

Operating envelopes (OEs), as a key enabler to facilitate DER integration,
have attracted increasing attention in the past years. However, uncertainties,
which may come from load forecast errors or inaccurate network parameters,
have been rarely discussed in OE calculation, leading to compromised quality
of the hosting capacity allocation strategy. This letter studies how to
calculate OEs that are immune to such uncertainties based on a linearised
unbalanced three-phase optimal power flow (UTOPF) model. With uncertain
parameters constrained by norm balls, formulations for calculating Robust OEs
(ROEs) are presented along with discussions on their tractability. Two cases,
including a 2-bus illustrative network and a representative Australian
network, have been tested to demonstrate the effectiveness and efficiency of
the proposed approach.

###### Index Terms:

Distributed energy resources (DERs), feasible region, operational envelopes,
robust optimisation, uncertainty modelling, unbalanced optimal power flow

##  I Introduction

The penetration of distributed energy resources (DERs) has been rapidly
increasing worldwide in the past years, leading to a series of issues that
require close coordination among transmission system operators (TSOs),
distribution system operators (DSOs) and emerging DER aggregators when DERs
are operated via virtual power plants (VPPs) [1]. Operating envelope (OE),
which specifies the operational range for customers with DERs at the
connection point that is permissible within the network operational limits, is
identified as a key enabler in potential future power system architectures and
has gained increasing interest from both industry and academia to manage DER
export/import limits and to facilitate DER participation in electricity
markets [2]. Although substantial advances have been made in developing
approaches to calculating OEs in recent years, uncertainties, which may come
from load forecasting and inaccurate network parameters, are typically ignored
in the calculations, which may lead to unreliable OE allocations. To address
this issue, this letter proposes a method to calculate robust OEs (ROEs) that
are immune to such uncertainties. The problem, based on a linearised
unbalanced three-phase optimal power flow (UTOPF) model, is formulated and
solved via convex optimisation techniques. The proposed approach is tested on
both an illustrative and a representative Australian network.

##  II Calculating OEs via Deterministic UTOPF

Based on UTOPF, a deterministic approach to calculating OEs can be formulated
as

$\displaystyle\max_{P_{m},Q_{m}}{f(P)}$ (1a) $\displaystyle
V^{\phi}_{i_{\text{ref}}}=V^{\phi}_{0}\leavevmode\nobreak\
\leavevmode\nobreak\ \forall\phi$ (1b) $\displaystyle
V^{\phi}_{i}-V^{\phi}_{j}=\sum\nolimits_{\psi}{z_{ij}^{\phi\psi}I^{\phi}_{ij}}\leavevmode\nobreak\
\leavevmode\nobreak\ \forall\phi,\forall ij$ (1c)
$\displaystyle\sum_{n:n\rightarrow i}{I^{\phi}_{ni}}-\sum_{m:i\rightarrow
m}{I^{\phi}_{im}}=\sum_{m}{{\mu_{\phi,i,m}(P^{\text{}}_{m}-\text{j}Q^{\text{}}_{m})}/{(V^{\phi}_{i})^{*}}}\leavevmode\nobreak\
\leavevmode\nobreak\ \forall\phi,\forall i$ (1d) $\displaystyle
V^{\text{min}}_{i}\leq|V^{\phi}_{i}|\leq
V^{\text{max}}_{i}\leavevmode\nobreak\ \forall\phi,\forall i$ (1e)

where $f(P)$ is the objective function, reflecting the efficiency and fairness
in calculating OEs. $i_{\text{ref}}$ is the index of the reference bus and
$V^{\phi}_{0}$ is its fixed voltage at phase $\phi$ (known parameter).
$V^{\phi}_{i}\leavevmode\nobreak\ (i\neq 0)$ is the voltage of phase $\phi$ at
node $i$. $I^{\phi}_{ni}$ is the current in phase $\phi$ of line $ni$: flowing
from bus $n$ to bus $i$. $P_{m}$ is the active power demand of customer $m$
while $Q_{m}$ is the reactive power demand. For simplicity, all $P_{m}$ and
$Q_{m}$ are treated as variables in the formulation. However, they will be
fixed as the forecasted values if they are uncontrollable.
$\mu_{\phi,i,m}\in\\{0,1\\}$ is a parameter indicating the phase connection of
customer $m$ with its value being $1$ if it is connected to phase $\phi$ of
bus $i$ and being $0$ otherwise. $V^{\text{min}}_{i}$ and $V^{\text{max}}_{i}$
are the lower and upper limits of $|V_{i}|$, respectively.

In the formulation, the objective function aims at maximising $f(P)$ in order
to obtain the desired OEs, subject to (1b) specifying the voltage at the
reference bus, (1c) formulating voltage drop in each line, (1d) assuring
Kirchhoff’s current law is satisfied, and (1e) representing voltage magnitudes
constraints. It is noteworthy that only voltage magnitude constraints are
considered in this letter and other constraints can be conveniently
incorporated.

Noting that for most distribution networks, differences of voltage angles in
each phase are sufficiently small [3] and nodal voltages throughout the
network are around $1.0\leavevmode\nobreak\ p.u.$, (1d) can be linearised by
fixing $V^{\phi}_{i}$ in the denominator on the right-hand side of (1e),
leading to a compact formulation of (1) with linear constraints as

$\displaystyle\max_{p_{1},q_{1}}{f(p_{1})}$ (2a)
$\displaystyle[A_{1},A_{2}][p_{1}^{T},p_{2}^{T}]^{T}+[B_{1},B_{2}][q_{1}^{T},q_{2}^{T}]^{T}+Cl=b$
(2b) $\displaystyle Dv+El=d,\leavevmode\nobreak\ Fv\leq f$ (2c)

where $p_{1}$ and $p_{2}$ are vectors consisting of active powers from active
customers, i.e. VPP participants, and passive customers, whose active powers
need to be forecasted or estimated, respectively; $q_{1}$ and $q_{2}$ are
vectors consisting of reactive powers that are controllable and that need to
be forecasted or estimated, respectively; $l$ and $v$ represent the vectors
consisting of state variables related to line currents and nodal voltages,
respectively; $A=[A_{1},A_{2}],B=[B_{1},B_{2}],C,b,D,E,d,F$ and $f$ are
constant parameters with appropriate dimensions.

Noting that only $p_{1}$ and $q_{1}$ are independent variables, (2) defines
the FR, as a function of $q_{1}$, for $p_{1}$. Therefore, if all realised
values of $p_{1}$ fall within the FR, the integrity of the network can be
guaranteed. After removing state variables $v$ and $l$, the FR for $p_{1}$ can
be expressed as the following polyhedron.

$\displaystyle\mathcal{F}(q_{1})=\left\\{p_{1}\left|\begin{matrix}FD^{-1}EC^{-1}(A_{1}p_{1}+A_{2}p_{2}+B[q_{1}^{T},q_{2}^{T}]^{T}-b)\\\
\leq f-FD^{-1}d\\\ \end{matrix}\right.\right\\}$ (3)

By denoting $vec(X)^{T}H_{i}x=[FD^{-1}XC^{-1}x]_{i}$ with $vec(\cdot)$ being
the vectorising operator for a matrix and $[\cdot]_{i}$ indicating the
$i^{th}$ row of a matrix or the $i^{th}$ element of a vector,
$H_{i}=C^{-1}\otimes([F]_{i}D^{-1})^{T}$ with $\otimes$ being the Kronecker
product, and $t_{i}=[f-FD^{-1}d]_{i}$, (3) is equivalent to

$\displaystyle\mathcal{F}(q_{1})=\left\\{p_{1}\left|\begin{matrix}vec(E)^{T}H_{i}(A_{1}p_{1}+A_{2}p_{2}+B[q_{1}^{T},q_{2}^{T}]^{T}-b)\leq
t_{i}\leavevmode\nobreak\ \forall i\\\ \end{matrix}\right.\right\\}$ (4)

Therefore, seeking OEs through the deterministic approach with controllable
$q_{1}$ is equivalent to solving

$\displaystyle\max\nolimits_{(p_{1},q_{1})}\\{f(p_{1})|s.t.\leavevmode\nobreak\
\eqref{fr_new}\\}$ (5)

##  III Robust Operating Envelopes

###  III-A Uncertainty Modelling

Comparing (1) and (2), errors in forecasting $P_{m}$ for passive customers and
uncontrollable $Q_{m}$, and inaccuracies in $z^{\phi\psi}_{ij}$ will lead to
uncertainties in $p_{2},q_{2}$ and $E$, respectively. In this letter, such
uncertainties are formulated as

$\displaystyle\mathcal{E}=\mathcal{E}_{1}\cap\mathcal{E}_{2}=\\{E|vec(E)=e_{1}+J_{1}x,\norm{x}_{\infty}\leq\gamma_{1}\\}$
$\displaystyle\cap\\{E|vec(E)=e_{2}+J_{2}x,\norm{x}\leq\gamma_{2}\\}$ (6a)
$\displaystyle\mathcal{P}=\mathcal{P}_{1}\cap\mathcal{P}_{2}=\\{p_{2}|p_{2}=u_{1}+U_{1}y,\norm{y}_{\infty}\leq\rho_{1}\\}$
$\displaystyle\cap\\{p_{2}|p_{2}=u_{2}+U_{2}y,\norm{y}\leq\rho_{2}\\}$ (6b)
$\displaystyle\mathcal{Q}=\mathcal{Q}_{1}\cap\mathcal{Q}_{2}=\\{q_{2}|q_{2}=w_{1}+W_{1}z,\norm{z}_{\infty}\leq\theta_{1}\\}$
$\displaystyle\cap\\{q_{2}|q_{2}=w_{2}+W_{2}z,\norm{z}\leq\theta_{2}\\}$ (6c)

where $e_{i},u_{i},w_{i},J_{i},U_{i},W_{i},\gamma_{i},\rho_{i}$ and
$\theta_{i}$ are constant parameters describing the uncertainty sets, and
$x,y,z$ are random variables; The $\infty$-norm constraint in
$\mathcal{E}_{1},\mathcal{P}_{1}$ and $\mathcal{Q}_{1}$ provides a general
lower/upper bound for the random variable while the norm constraint in
$\mathcal{E}_{2},\mathcal{P}_{2}$ and $\mathcal{Q}_{2}$, which can take
1/2/$\infty$-norm or other types of norms, is to further reduce the
conservativeness of the uncertainty set.

Several remarks on uncertainty modelling are given below.

  1. 1.

Constant parameters can be chosen depending on the physical truth or
historical error distributions. For example, if $E$ is usually within 10%
error of $\bar{E}$, where $\bar{E}$ is the nominal value of $E$, we can set
$\mathcal{E}=\mathcal{E}_{1}$, $e_{1}=vec(\bar{E})$, $J_{1}=diag(e_{1})$, and
$\gamma_{1}=10\%$. As another example, if $p_{2}$ falls in $[0,p^{max}_{2}]$
and its forecast error follows a multivariate normal distribution with
expectation and covariance being $0$ and $\Sigma$, respectively and 2-norm is
used in $\mathcal{P}_{2}$, for $\mathcal{P}_{1}$ we can set $u_{1}$ as a
vector with all its elements being $p^{max}_{2}/2$, $U_{1}=diag(u_{1})$ and
$\rho_{1}=1$. Noting that now $y^{T}\Sigma y$ follows a _Chi-square_
distribution with freedom degrees of $n$, for $\mathcal{P}_{2}$ we can set
$u_{2}=\bar{p}_{2}$, where $\bar{p}_{2}$ is the forecasted value of $p_{2}$,
$U_{2}=diag(u_{2})$ and $\rho_{2}=(\chi^{2}_{n,1-\epsilon})^{1/2}$ to
guarantee that $p_{2}$ now falls within $\mathcal{P}_{2}$ with a confidence
level of $1-\epsilon$.

  2. 2.

Moreover, constant parameters can also be chosen depending on the confidence
level of satisfying (4), leading to equivalent chance-constrained optimisation
problems. However, this is beyond the scope of this letter and interested
readers are referred to [4] for more discussions.

  3. 3.

$\mathcal{E}$, $\mathcal{P}$ and $\mathcal{Q}$ can be formulated as other
types of convex sets, which, however, may affect the tractability of the
formulated problem if two or more uncertainties co-exist. More discussions
will be provided in the next section.

###  III-B Robust OEs

For the convenience of discussion, we here assume both $q_{1}$ and $q_{2}$ are
controllable, thus removing uncertainties in $q_{2}$. However, similar to
dealing with uncertainty in $p_{2}$, the proposed approach can be easily
extended to the case when uncertainty in $q_{2}$ exists.

####  III-B1 With uncertainty only in E

Fixing $p_{2}$ at $\bar{p}_{2}$ and denoting
$h_{i}=H_{i}(A_{1}p_{1}+A_{2}\bar{p}_{2}+Bq-b)$, taking the robust counterpart
(RC) with respect to $E$ in the $i^{th}$ inequality in (4) leads to the
following formulation [5, 4].

$\displaystyle\max_{E\in\mathcal{E}}{vec(E)^{T}H_{i}(A_{1}p_{1}+A_{2}\bar{p}_{2}+Bq-b)}=\delta^{*}(h_{i}|\mathcal{E})$
$\displaystyle=\min_{\tau_{i1},\tau_{i2}}\\{\delta^{*}(\tau_{i1}|\mathcal{E}_{1})+\delta^{*}(\tau_{i2}|\mathcal{E}_{2}))\big{|}\tau_{i1}+\tau_{i2}=h_{i}\\}$
$\displaystyle=\min_{\tau_{i1},\tau_{i2}}\\{\sum\nolimits_{j}(e_{j}^{T}\tau_{ij}+\delta^{*}(J_{j}^{T}\tau_{ij}|\mathcal{X}_{j}))\big{|}\sum\nolimits_{j}\tau_{ij}=h_{i}\\}$
(7a)
$\displaystyle=\min_{\tau_{i1},\tau_{i2}}\\{\sum\nolimits_{j}e_{j}^{T}\tau_{ij}+\gamma_{1}||J_{1}^{T}\tau_{i1}||_{1}+\gamma_{2}||J_{2}^{T}\tau_{i2}||_{*})\big{|}\sum\nolimits_{j}\tau_{ij}=h_{i}\\}\leq
t_{i}$ (7b)

where $\delta^{*}(y|\mathcal{X})=\sup_{x\in\mathcal{X}}{y^{T}x}$ is the
conjugate of the support function $\delta(x|\mathcal{X})$,
$\mathcal{X}_{1}=\\{x|\norm{x}_{\infty}\leq\gamma_{1}\\}$ and
$\mathcal{X}_{2}=\\{x|\norm{x}\leq\gamma_{2}\\}$ with $||\cdot||_{*}$
representing the dual norm. Moreover, $\delta^{*}(y|\mathcal{X})$ is always a
convex function [6].

Accordingly, removing the _min_ operator in (7b) leads to a robust FR (RFR)
that is robust to uncertain $E$ and maximising $f(p_{1})$ over
$(p_{1},q,\tau_{ij})$ in this RFR will report the desired ROEs.

####  III-B2 With uncertainty only in $p_{2}$

With $vec(E)$ fixed at $\bar{e}$ and denoting
$g_{i}=A_{2}^{T}H_{i}^{T}\bar{e}$, for the $i^{th}$ constraint in (4), taking
the RC with respect to $p_{2}$ leads to

$\displaystyle\max_{p_{2}\in\mathcal{P}}{g_{i}^{T}p_{2}}=\delta^{*}(g_{i}|\mathcal{P})$
$\displaystyle=\min_{\phi_{i1},\phi_{i2}}\\{\delta^{*}(\phi_{i1}|\mathcal{P}_{1})+\delta^{*}(\phi_{i2}|\mathcal{P}_{2}))\big{|}\phi_{i1}+\phi_{i2}=g_{i}\\}$
$\displaystyle=\min_{\phi_{i1},\phi_{i2}}\\{\sum\nolimits_{j}(u_{j}^{T}\phi_{ij}+\delta^{*}(U_{j}^{T}\phi_{ij}|\mathcal{Y}_{j}))\big{|}\sum\nolimits_{j}\phi_{ij}=g_{i}\\}$
(8a)
$\displaystyle=\min_{\phi_{i1},\phi_{i2}}\\{\sum\nolimits_{j}u_{j}^{T}\phi_{ij}+\rho_{1}||U_{1}^{T}\phi_{i1}||_{1}+\rho_{2}||U_{2}^{T}\phi_{i2}||_{*})\big{|}\sum\nolimits_{j}\phi_{ij}=g_{i}\\}$
$\displaystyle\leq t_{i}-\bar{e}^{T}H_{i}(A_{1}p_{1}+Bq-b)$ (8b)

where $\mathcal{Y}_{1}=\\{y|\norm{y}_{\infty}\leq\rho_{1}\\}$ and
$\mathcal{Y}_{2}=\\{y|\norm{y}\leq\rho_{2}\\}$.

Similarly, removing the _min_ operator in (8) also leads to an RFR that is
robust against uncertain $p_{2}$ and maximising $f(p_{1})$ over
$(p_{1},q,\phi_{ij})$ in this RFR leads to ROEs when uncertainty only appears
in $p_{2}$.

####  III-B3 With uncertainties in both E and $p_{2}$

In this case, bilinear uncertainty exists in (4), making the RC reformulation
generally intractable. However, as discussed in [4], a tractable reformulation
is achievable when one the uncertainty set follows specific types, as we show
next.

For example, if $\mathcal{P}$ is formulated as (9), there is a total number of
$2^{n_{t}}\tbinom{n}{n_{t}}$ extreme points in $\mathcal{Y}$.

$\displaystyle\mathcal{P}=\mathcal{P}_{1}\cap\mathcal{P}_{2}=\\{p_{2}|u+Uy,y\in\mathcal{Y}=\mathcal{Y}_{1}\cap\mathcal{Y}_{2}\\}$
(9)

where $u=u_{1}=u_{2}$, $U=U_{1}=U_{2}$,
$\mathcal{Y}_{1}=\\{y|\norm{y}_{\infty}\leq\rho_{1}\\}$ and
$\mathcal{Y}_{2}=\\{y|\norm{y}_{1}\leq n_{t}\rho_{1}\\}$ with $n_{t}\leq n$
and $n$ is the cardinality of $y$.

As a special case, if $n_{t}=1$, the $2n$ extreme points in $\mathcal{Y}$ can
be expressed as $\\{\pm y_{1},\cdots,\pm y_{k},\cdots,\pm y_{n}\\}$ with
$y_{k}\in\mathbb{R}^{n\times 1}$ being a vector with the $k^{th}$ element
being $\rho_{1}$ and all the other elements being 0. Based on (7b), the
tractable RC for the $i^{th}$ constraint in (4) can be formulated as

$\displaystyle\min_{\tau_{i1},\tau_{i2}}\\{\sum\nolimits_{j}e_{j}^{T}\tau_{ij}+\gamma_{1}||J_{1}^{T}\tau_{i1}||_{1}+\gamma_{2}||J_{2}^{T}\tau_{i2}||_{*})\big{|}\sum\nolimits_{j}\tau_{ij}=h_{i}(\pm
y_{k})\\}$ $\displaystyle\leq t_{i}\leavevmode\nobreak\ \forall
k\in\\{1,2,\cdots\\}$ (10)

where $h_{i}(\pm y_{k})=H_{i}(A_{1}p_{1}+A_{2}u\pm A_{2}Uy_{k}+Bq-b)$.

Several remarks on calculating ROEs are given below.

  1. 1.

In this letter, a _strictly equal_ allocation strategy, i.e. OEs of all active
customers being equal to each other, will be used, leading to a linear
formulation of $f(p_{1})$. However, other objective functions can be
conveniently applied.

  2. 2.

Noting that (4) is linear in $E$, in $p_{2}$ and in $q_{2}$, a tractable RC
for this constraint can always be derived with single uncertainty, i.e. when
uncertainty appears only in $E$ or appears in $p_{2}$ and/or $q_{2}$, and if
the uncertainty set is convex. When bilinear uncertainty exists, a tractable
RC formulation is achievable if there is a finite number of extreme points for
at least one of the uncertainty sets, as shown in (III-B3). However,
enumerating all extreme points itself can be very challenging.

  3. 3.

The problem (5) with single uncertainty becomes linear programming (LP)
problem when 1-norm or $\infty$-norm is used in (6), and becomes second-order
cone programming (SOCP) problem when 2-norm is used. However, the RC of (5)
with single uncertainty is always a convex programming problem if the
uncertainty set is convex.

  4. 4.

Compared with (4), a _buffer_ term is added to the left side of (4) in its RC,
leading to enhanced _robustness_ of the solution. When $\gamma_{i}$,
$\rho_{i}$, or $\theta_{i}$ equals 0, the RC deteriorates to the deterministic
formulation as shown in (4).

  5. 5.

Due to the unbalances and mutual couplings of all phases in a distribution
network, and the fact that the active power of a VPP customer may vary between
0 kW and its allocated OE, there is another type of uncertainty related to the
difference between the optimal solution of $p_{2}$ and its realised value
$\hat{p}_{2}$. Although this is beyond the scope of this letter, the approach
proposed in [7] to addressing such uncertainty can potentially be applied on
top of an RFR developed in this letter.

  6. 6.

When extra constraints on $p_{1}$ and $q_{1}$ exist, an additional constraint
$L_{1}p_{1}+L_{2}p_{2}\leq r$ can be added to (3) and (4).

##  IV Case Study

Two distribution networks, one of which is a 2-bus illustrative network
(TwbNetwork) and the other one is a real Australian network (AusNetwork), will
be studied. For the illustrative network, where its topology is presented in
Fig. 1, an ideal balanced voltage source with the voltage magnitude being
$1.0\leavevmode\nobreak\ p.u.$ is connected to bus 1. A three-phase line
connects bus 1 and bus 2, and its impedance matrix can be found in [7].

Figure 1: Network topology of the 2-bus illustrative example.

Of the three customers, $S_{2}=P_{2}+\text{j}Q_{2}$ is fixed while
$P_{1},P_{3},Q_{1}$ and $Q_{3}$ are to be optimised with $f(p)=-P_{1}-P_{3}$
with $P_{1}=P_{3}$, aiming at maximising the total exports from customers 1
and 3. Moreover, the default export/import limits for both customers are set
as 7 kW, and controllable reactive powers are assumed to be within [-1 kVar, 1
kVar]. Lower and upper voltage magnitude limits are set as
$0.95\leavevmode\nobreak\ p.u.$ and $1.05\leavevmode\nobreak\ p.u.$,
respectively. The Australian network has 33 buses and 87 customers, of which
30 are VPP participants whose OEs are to be calculated. For the remaining 57
customers, their reactive powers are fixed while active powers are treated as
uncertain parameters. The default limits on active and reactive powers are the
same as those in the illustrative network, and other data can be found in [7].

For network impedances, $x$ represents the mutual impedances of line $12$ for
the illustrative network and refers to the positive, negative and zero-
sequence impedances of all line codes of lines “46-47”, “69-67”, “49-50”,
“40-41”, “54-59”, “45-50”, “67-68”, “44-45”, “61-62” and “52-54” for the
Australian network.

Simulation results are presented in Table I and Fig.2, where the OEs
calculated by deterministic approach, denoted as DOEs, are also presented for
comparison purposes.

Table I: DOEs and ROEs calculated under various uncertainty when $q_{1}=0$, $\mathcal{E}=\mathcal{E}_{1}$ with $e_{1}=vec(\bar{E})$ and $J_{1}=diag(e_{1})$, and $\mathcal{P}=\mathcal{P}_{2}$ with $u_{2}=\bar{p}_{2}$ and $U_{2}=diag(u_{2})$ (left/right: with fixed $q_{1}(=0)$/with optimised $q_{1}$). Uncert. | Norm | Optimal Obj. (kW) |  Comp. Time ($\times 10^{-2}$seconds)
---|---|---|---
TwbNetwork | AusNetwork | TwbNetwork | AusNetwork
Deter. | N/A | -9.9/-13.7 | -78.7/-112.3 | 0.3/0.5 | 1.0/1.2
$E$ |  $\infty(\gamma_{1}=5.0\%$) | -9.2/-12.8 | -49.2/-58.3 | 1.2/1.1 | 6.9/11.8
$\infty(\gamma_{1}=10.0\%$) | -8.6/-11.9 | -36.3/-43.1 | 1.1/1.5 | 7.0/16.7
$p_{2}$ |  1($\rho_{2}=20.0\%$) | -9.4/-13.2 | -78.1/-111.7 | 0.5/0.3 | 6.0/6.8
2($\rho_{2}=20.0\%$) | -9.4/-13.2 | -77.8/-111.4 | 0.8/1.1 | 3.1/3.8
$\infty(\rho_{2}=20.0\%$) | -9.4/-13.2 | -75.4/-109.0 | 0.6/0.6 | 6.6/6.8
$(E,p_{2})$ |  $(\infty,1)$ ($\gamma_{1}=5.0\%$, $\rho_{2}=20.0\%$) | -8.7/-12.3 | -48.7/-56.1 | 4.7/4.2 | 4314.0/6194.5

(a) Uncertainty only in $E$.

(b) Uncertainty only in $p_{2}$.

(c) Uncertainty in both $E$ and $p_{2}$.

(d) Under various uncertainties.

Figure 2: FRs and OE points for the illustrative network under various
uncertainties (DFR: deterministic FR; DOE: deterministic OE; ROE: Robust OE;
_fq_ : with fixed $q_{1}(=0)$, _cq_ : with optimised $q_{1}$).

Simulation results clearly show that ROEs are more conservative compared with
DOEs, and a higher level of uncertainty leads to a more conservative
allocation strategy, as shown in Fig.2(a). Moreover, as shown in Table I and
Fig.2, RFRs and allocated OEs with optimised controllable reactive powers can
be significantly different from those with fixed controllable reactive powers,
leading to ameliorated OEs. On computational time, ROEs can be calculated
efficiently for both networks except in the case when bilinear uncertainty
exists in the Australian network. Moreover, setting up the optimisation model,
which is in Julia, for this case can also be computationally demanding. In
fact, for the Australian network, it takes at most 9 seconds to set up the
optimisation model when there is single uncertainty, while the setup time can
be as high as 1789.9 seconds when bilinear uncertainty exists due to a large
number of constraints in (III-B3), implying computational efficiency can be
potentially improved by investigating more efficient programming techniques.

##  V Conclusions

This letter studies the calculation of OEs when single or bilinear uncertainty
exist in demands and network impedances, leading to various tractable
formulations with generalised or specific uncertainty set formulations.
Simulation results show the differences of OE allocation strategies
geometrically when with and without considering uncertainties, and demonstrate
the efficiency of the proposed approach. Noting that the proposed approach is
built on a linear UTOPF model, further improving accuracy in linearising UTOPF
and investigating robust formulations under other types of uncertainty sets
are potential research directions in this area.

## References

  * [1] “Open Energy Networks Project - Energy Networks Australia Position Paper,” ENA and AEMO, Melbourne, Australia, Tech. Rep., 2020. [Online]. Available: https://tinyurl.com/4bd9tr5n
  * [2] M. Z. Liu, L. N. Ochoa, S. Riaz, P. Mancarella, T. Ting, J. San, and J. Theunissen, “Grid and market services from the edge: using operating envelopes to unlock network-aware bottom-Up flexibility,” _IEEE Power and Energy Magazine_ , vol. 19, no. 4, pp. 52–62, 2021.
  * [3] H. Ahmadi, J. R. Marti, and A. von Meier, “A linear power flow formulation for three-phase distribution systems,” _IEEE Trans. Power Syst._ , vol. 31, no. 6, pp. 5012–5021, 2016.
  * [4] D. Bertsimas and D. D. Hertog, _Robust and Adaptive Optimization_. Belmont, Massachusetts: Dynamics Ideas LCC, 2022.
  * [5] A. Ben-Tal, L. E. Ghaoui, and A. Nemirovski, _Robust optimization_. Princeton, New Jersey, US: Princeton University Press, 2009.
  * [6] S. Boyd and L. Vandenberghe, _Convex Optimization_. Cambridge, England: Cambridge University Press, 2004.
  * [7] B. Liu and J. H. Braslavsky, “Robust operating envelopes for DER integration in unbalanced distribution networks,” _arXiv preprint arXiv:2212.03976_ , 2022.