雾计算在智能电网需求调度中的应用

余文辉，尹立彬，梁耀文

(1.中国南方电网有限责任公司 生产技术部，广东 广州 510623；2.湖南大学 电气与信息工程学院，湖南 长沙 410006)

0 引 言

为了克服日益增长的能源消耗成本对各国经济和社会的影响，研究者们一直致力于需求侧管理的解决方案。这些解决方案允许在消费者层面上监控消费行为。随着信息和通信技术的出现，这成为可能[1]。

随着云计算的出现，一些问题的集中解决似乎比分布式解决更为有利[2]。云可以提供高容量的复杂问题解决方案。然而，与终端用户保持远距离的云服务器以及消费者连接的设备生成的大量数据可能会对延迟和服务质量(QoS)造成严重问题。幸运的是，雾(fog)计算作为一种很有前途的范例被引入，通过将处理转移到网络的边缘来解决这些问题[3]。它可以对云计算进行补充，可以与云计算存在交互[4]。

近年来，越来越多的研究致力于智能电网环境下雾计算新兴技术的开发。文献[5]在雾和云之间使用智能网关来减少处理延迟。文献[6]中的平台使终端用户能够通过定制的控制来实现能源管理，同时最小化实现成本。文献[7]提出了一种三层云-雾结构，其目的是最大限度地减少能量损耗，平衡能量过剩。Zahoor等提出了一种用于资源管理的云-雾模型[8]。为智能电网提供不同类型的计算服务。在文献[9]中，讨论了面向服务的中间件方法对于使用云计算和雾计算开发和操作智能城市服务的挑战的贡献。

本文介绍了一种用于能耗管理的云-雾结构。利用能源成本激励来更好地控制需求。当所有的消费者都将消费转移到产生新的需求高峰的低价期时，这种行为可能会导致需求的不良再分配。在这一激励策略中，最终目标是降低所有用户的总能源成本，这些用户属于具有一个或多个住宅的智能建筑。为此，每个设备计划必须依赖于所有其它设备的计划。因此，负责调度的实体必须具有系统的全局视图。这个问题可以在云端解决。然而，这会产生高延迟以及密集的数据传输。所以，本文选择雾计算来缓解这些问题。本文提出在雾层执行分布式合作博弈，每个雾节点负责调度一个或多个建筑物的能量需求。

1 电量需求规划

1.1 系统模型

(1)

(2)

因此，这栋楼的用户每天的总用电需求可以用式(3)表示

(3)

(4)

(5)

不可中断的设备操作由两个约束保证

(6)

由于加载阶段的处理是顺序的，因此加载阶段只有在其前面的阶段完成时才开始。因此，约束条件为式(7)

(7)

假设降低所有消费者的总日成本时，将目标函数f定义为计算该成本的函数

(8)

然后可以将日费用最小化问题表述为一个约束问题

(9)

该问题可以很容易地通过云集中解决，使用许多解决凸问题的技术，如内点法(IPM)[10]。然而，中央服务器需要知道系统中所有设备的信息(能量消耗、运行时间、最大和最小功率、开始和结束时隙、功率分布……)。这可能导致必须通过通信网络传输的大量数据和高延迟。因此，使用多智能体系统(Multi-agentsystem，MAS)和博弈论技术，使用fog计算以分布式方式调度每个设备的能源需求。

1.2 分布式需求调度博弈

即使优化问题能够以中心化的方式解决，提出一种接近终端用户的分布式解决方法也更为有利。这将有助于优化延迟，并减少传输的数据量。除了云-雾架构外，建议使用MAS来实现分布式能源消耗调度。如图1所示，通过一个智能代理(代理表示可以具有自主活动能力的软件或实体，同理，智能代理表示具有一定智能程度，能自主活动的软件或者实体)来表示系统中的每个实体。

从图1中可知整个云-雾系统架构分为3层：云端层、雾层以及终端用户层。假设消费设备配备了传感器和执行器，允许它们与其它消费代理交互。在住宅内，传感器/执行器与该代理之间的通信可以使用低功耗蓝牙和ZigBee技术。以太网、PLC或Wi-Fi技术可用于将建筑代理与消费者代理和雾代理互连。后者可以通过光纤或WI-MAX与云通信。

图1 基于MAS的能源需求调度云-雾系统的体系结构

所以该建议的思想是，独立的个体调度可能导致将峰值负荷转移到低能源价格的时段。因此，提出了一种依赖于总能源需求的定价策略，根据系统中所有设备的总消耗来安排每个设备的消耗。这有助于减少需求高峰，平衡每个时隙的能源负荷。把需求管理的职责分配给雾代理，每个代理将负责调度一些建筑物的消耗。节点构建的选择将在第2节讨论。为了实现最佳调度，光纤陀螺代理必须相互协作。因此，本文提出一个合作博弈，描述如下：

(1)玩家：雾代理。

(2)策略：每个雾代理f决定能量矢量Xf，其表示分配给f的设备的时间表。

(3)效用函数：每个雾代理f的uf(Xf;X-f)。

最大化uf的效用函数可表示为

(10)

式中：X-f=[X1,…,Xf-1,Xf+1,…,XF]表示包含除f之外所有代理的计划的向量，而F是活动雾代理的数量。

在这个游戏中，每个雾代理确定要负责的设备的需求计划，同时尝试增加其利润。函数成本在增加并且严格凸的假设导致纳什均衡的存在[11]及其唯一性[12]。

假设雾代理f知道调度向量X-f，则可以通过求解局部最优化问题来获得其自身的最佳调度

(11)

在此认为这个问题是f的局部问题，因为唯一的变量是它自己的消耗时间表Xf。问题P等于

(12)

为了显示局部决策向量，重写问题以获得

(13)

这个问题与问题(12)的目标相同。然而，P1只包含节点f的局部变量，一旦知道所有其它fog节点的代理函数和总需求D-f，fog代理就可以使用IPM来解决这个问题。算法1给出了协作算法的详细内容。

算法1： 由代理f执行的需求调度

determineXfusing IPM; senddfto the next agent;

repeat

receiveDandL;

iff==L.firstthen

ifDdid not changethen

announce game over;

End game;

endif

updateD;

rearrangeL;

sendDandLtoL.first;

endif

Xf=IPM(D-f);

endif

sendDtoL.next;

untilreceivegame_over

雾代理根据代理列表L顺序进行游戏。后者最初由云代理确定，然后由雾代理更新。在第一次迭代期间，列表中的第一代理f使用其实际的每日需求和随机D-f来解决问题(13)。然后，它将其每日需求df放入全局需求D中，并将其发送到列表L中的下一个代理。这个新代理l在考虑接收到的D时确定其向量dl，将其添加到D并将其发送到下一个代理。该过程重复，直到到达列表中最后一个将D发送给f的代理为止。如果D发生变化，f重新排列列表L，并将其与请求一起发送给新的列表头。否则它宣布游戏结束，每个雾代理将每个决策向量返回给有关建筑物。

随着博弈的进行，能量消耗遵循单调递减的行为，并且雾代理会依次更新它们的消耗计划。此外，代价不能为负，这意味着当迭代次数趋于+∞时，代价趋于正不动点。因此，算法收敛到对应于该不动点的唯一纳什均衡。

2 雾节点的分配

(14)

决策变量zbf指示b的需求是否将由f调度。每个建筑物的消耗量由一个且只有一个连接的雾节点确定，这由以下两个约束条件来确保

(15)

第二决策变量vf指示雾节点是否处于活动状态。如果禁用雾节点，则不会为其分配建筑物。因此，约束条件为

(16)

在将建筑物分配给雾节点时，旨在实现3个目标：①最小化能源调度过程的总延迟；②减少活动雾节点的数量；③合理平衡活动节点上的调度费用。

(17)

当雾节点顺序执行消耗调度时，总处理延迟可以表示为所有活动节点完成其任务所花费的时间总和

(18)

处理延迟取决于判决矢量的大小，该判决矢量与属于分配给该节点的建筑物的设备数量以及雾节点(CPU等)的特性成比例。可以通过以下方式表示处理延迟

(19)

(20)

式中：n表示迭代次数，Ti,j表示列表L中两个连续节点之间交换消息的延迟，并且取决于节点之间的距离、链接质量和消息大小。后者是恒定的。

(21)

这些延迟取决于消息的大小，消息的大小取决于节点处理的设备数量，雾节点与建筑物之间的距离以及链接的质量。因此可以确定此延迟为

(22)

用αbf(βfb)在节点f和建筑物b之间交换设备配置文件(调度)的延迟。lbf和lfb表示恒定的开销延迟。值得一提的是αbf和βfb取决于节点之间的距离，链路质量(干扰、衰落……)和消息大小。

作为第二个目标，旨在优化活动雾节点的数量。把确定活动节点数f2的目标函数定义为

(23)

第三个目标是在考虑每个节点的容量的同时，将设备公平地分布在节点上。目标函数f3可以表示为

(24)

系数δf随着雾节点的容量增加而增加，这意味着功能较强大的节点相比功能较弱的节点可以处理更多的设备；这反映了系统的公平性。最后，可以将多目标问题定义为

(25)

受到式(14)、式(15)和式(16)所示的约束。由于问题的复杂性，可以在云端进行处理。选择雾节点的过程如下：

(1)每个消费者代理将其设备的信息和配置文件发送给建筑代理；

(2)建筑代理将其设备的总数传输到它可以与之通信的雾节点。

(3)雾节点发送此信息及其特征(CPU、距建筑物的距离、质量链接等)到云；

(4)云代理解决问题(25)，确定列表L并将解返回到雾节点；

(5)每个雾代理通知其指定的建筑代理；

(6)后者将从用户收集的信息发送到相应的节点；

(7)雾代理执行协同调度博弈并将时间表返回给建筑物，这些建筑物会将时间表传送给消费者代理。

3 实验评估

在本文的模拟中，考虑了10座带有多个公寓的建筑物，以及10个不同容量的可用雾节点。每个用户有10到20个可变换的(洗碗机、洗衣机、烤箱、烘干机……)和不可变换的(冰箱、照明、微波炉……)设备。在分析南京的能源需求时，注意到需求高峰在晚上5：00 pm至8：00 pm，而从7：00 am到8：00 am则不那么重要，每个时隙等于1 h，因此有24 h插槽。

3.1 云-雾模型性能评估

首先评估雾-云模型。图2描绘了延迟行为随消费者数量变化的函数。正如预期的那样，延迟随着用户数量的增加而增加。但是，基于雾的调度延迟仍与基于云的调度延迟相距甚远，后者迅速增加。如图2所示，所激活节点的最佳数量也随着用户数量的增加而增加，这可以解释这一点。例如，前者从拥有500个消费者的3个节点增加到拥有1000个消费者的6个节点。

图2 消费者数量功能延迟

为了表明选定的激活雾节点数是最佳的，在改变激活节点数的同时遵循调度延迟，并将用户数设置为1000。图3描述了当增加激活雾节点数时的延迟行为。

图3 活动雾节点数量功能的延迟

从图3可知，当此数字较低时，延迟非常高，这可以通过以下事实来解释：雾节点不如云那么强大。因此，雾节点必须处理大量决策变量，即使通信延迟非常低，由于重要的处理延迟，这些决策变量也会产生重要的总延迟。随着激活更多的雾节点，延迟减小，直到达到6个活动节点。然后，由于通信延迟的增加，它又增加了。实际上，随着玩家数量的增加，游戏需要更多的时间来收敛。在特定的点上，无法用减少的处理延迟来补偿增加的通信延迟。但是，由于与云解决方案中的数据大小相比，交换数据的大小非常小，因此性能仍然比基于云的计划更好。而且，增加率低于减少活动节点数的情况。

在图4中，解释了分配给每个雾节点的设备数量。值得一提的是，同一建筑物的所有设备均分配给同一雾节点。注意，3个激活的节点调度了大多数设备，这可以通过以下事实来解释：这3个节点比其它节点更强大。2号节点的功能较弱，并且为其分配了较少设备的建筑物。

图4 分配给每个活动雾节点的设备数

3.2 需求调度评估

f(523)=200×0.127+100×0.141+100×0.155+100×0.169+23×0.183=76.109元

图5显示了白天的总需求分布及其相应的成本，其中时间段1对应于早上6点。当不使用调度机制时，高峰时间(晚上7点)的需求超过670 kWh，而采用本文的调度方法时为500 kWh。通过调度，负载可以更好地按小时分配。消耗的能量不会改变。然而，建筑消耗的每日总能源成本却降低了。初始需求的成本达到806元，而当基于成本最小化计划消耗时，该成本降低至750元。不幸的是，目前只能降低峰值需求，但是由于不可移动的负载，还不能完全消除峰值需求。

图5 能源总需求及其成本

4 结束语

在本文中，为用户端的能耗调度提出了一种云-雾架构。并且提出了一种基于博弈的分布式能源需求调度方法，旨在最大程度地减少住宅公寓的总能源成本。通过选择雾计算来优化延迟和必须通过通信网络传输的数据量。另外，提出了一种雾-气选择模型，该模型允许将每个建筑设备分配给雾气节点，同时最小化延迟和活动节点的数量，并公平地平衡活动节点上的调度负载。所获得的结果表明，即使总需求没有变化，当改变家电需求时，每日总成本也会降低。仿真结果表明，增加节点数并不意味着减少延迟。有一个最佳数量的已激活雾节点可以生成最小的调度延迟。在未来的工作中，可以整合深度学习机制，以使建筑物自行决定选择哪个雾化节点。