网格现代化:经验教训

介绍

公用事业公司正在采用新技术，以使其电网现代化，并应对分布式能源(如太阳能、电动汽车和电池存储)造成的负荷变化。开拓者的前进道路往往是最具挑战性的。本着早期开拓者的精神，本文试图分享一些经验教训。

在之前的论文中我们讨论过对于电网现代化的情况下以及网格现代化能力。在本文中，我们将讨论从开创电网现代化努力中获得的十大经验教训，以帮助其他人在他们的旅程中。虽然这些工作涉及电网运营和规划与工程，但本文主要关注规划与工程。

十大网格现代化经验教训:

1. 遗留数据模型将在从来没有预想的方式使用。
2. 不要假设数据是可用的。
3. 此前，当数据以新的方式使用未识别数据质量问题可能会暴露出来。
4. 理解关键路径和依赖项目之间的依赖关系是至关重要的。
5. 当混合多种交付方法时，拥有清晰一致的里程碑是至关重要的。
6. 在迁移到敏捷交付时要注意。
7. 计划需要充分考虑到环境的大小，并对其进行伸缩以处理大量数据。
8. 投入额外强调共同的环境管理。
9. 尽早制定计划，并进行多轮临时数据供应以满足需求。
10. 算法调优可能会对调度造成严重破坏。

数据模型——遗留数据模型将以从未设想过的方式使用

当公用事业试图合理化数据模型来管理不同领域的数字信息时，他们可能会被几十年前做出的决定所困扰。今天可用的处理能力使用例成为可能，这在短短几年前是无法想象的。准确的电网连接模型要求通常存储在客户支持系统中的电表信息与存储在配电和传输系统中的电路和资产信息相连接。试图将这些信息以一种准确的方式组合在一起，以反映电力网络的努力可能会受到未能预见未来需求的数据模型和系统的阻碍。

数据可用性——不要假设数据可用

其中一个关键的电网现代化的用例是在给定的时间节点，以发展资本和noncapital响应解决方案的能力，预测负荷。开发用于网络上的每个节点的长期时间序列预测需要的历史负荷数据，经济数据，负荷增长的数据，气象数据，地理信息系统的海量（GIS）数据，分布式能源（DER）的数据和电网连接信息。当如此大量历史数据的处理，它可以很容易忽略显著数据差距可能的预测产生不利影响。因此，最好是把数据质量计划，以确定数据缺口，并制订一个计划敲定任何发布日期之前解决这些问题。

的先进计量基础设施（AMI）的数据逻辑聚合可以缺少监督控制和数据采集（SCADA）数据的替代品，提供电气层次的构筑。不完整的，因为他们从来没有被用来获取在这些特定的负载水平和消费型材电气层次是常见的。它可以是具有挑战性解开从幻像数据质量问题，合法的数据质量问题。例如，尚未通电的资产可能会出现完全一样，已经被不正确地映射到他们的消费数据资产。这是因为他们都将显示为没有使用数据电气层次，如果你还没有占到资产的运行状态。

另一个缺少数据验证的例子是公用事业领域的准确天气数据的可用性。为了在预测生成中有效地利用天气数据，必须完成三个维度的验证:

必须完成气象数据映射(经度和纬度)到网络中的节点。

创建节点位置和气象站之间的距离限制。

确保天气数据的完整性。(根据我们的经验，气象站每小时丢失的数据可能高达20%。)



数据质量——当以新的方式使用数据时，以前未识别的数据质量问题可能会暴露出来

依赖于在遗留数据结构中创建和维护的信息的新系统和流程存在发现隐藏在现有生产系统中的数据质量问题的风险。除非有人开始以一种新颖的方式使用数据，否则这些数据质量问题并不重要，也不会得到解决。一个全面的数据质量计划应该通过以下方式来解决数据质量问题:

清楚地识别每个数据实体的记录系统和真实系统。

• 建立质量管理流程和标准，可主动配置文件数据源，以识别基于一组定义的业务规则和阈值数据质量问题。
• 从源头上纠正任何数据质量问题的根本原因，以避免向系统注入新的数据质量问题。
• 识别数据管家在企业层面，而不是职能部门内管理和更改数据模型数据定义。

虽然数据质量问题由各个电力公司确定的类型将是独一无二的自己的生态系统，有事情看出来：

• 客户映射到多个电路-如果在客户服务和计费系统，客户账户的关系是一个结构，而不是与实际电网的一个组成部分，如变压器，有一个小的机会，一个给定的客户可以映射到多个电路。当多个变压器与给定结构相关联，并且不同的电路与每个变压器相关联的发生这种情况。
• 为DER数据记录 -由于分布式能源通常是客户拥有的，许多公用事业公司可能选择不在其资产管理系统中包含它们。为了准确预测负荷分布，建立DERs记录系统至关重要。实用程序需要开始跟踪客户DER数据。

集成计划——理解关键路径和依赖项目之间的依赖关系是至关重要的

为了交付网格现代化规划功能，需要将多个平台、IT和业务流程、执行方法以及第三方供应商及其工具与清晰的执行路线集成在一起。如果不这样做，很容易忽略跨功能依赖关系，忽略架构包含指南，或者不理解一个工作流或平台上的开发和更改以及它们对其他工作流或平台的影响。糟糕的计划是失败的根本原因，尤其是在这种复杂的转换中。

为确保成功执行，必须考虑综合规划的下列要素:

• 方案规划,跨项目的集成计划，在最高级别上提供了交付功能的关键路径。这考虑了所有平台的依赖性，即数据和分析平台提供连接模型，并反过来与可视化产品集成，以生成概要文件或预测结果。为平台和能力开发、变更管理和依赖于它们的工作活动，必须在较低的层次上创建计划进度表。在规划阶段，理解平台、环境和工具的限制是至关重要的，以产生一个现实的规划计划。
• 利益相关者和沟通计划 -考虑到成功实现所需的依赖关系、复杂性和执行方法，通常很难使涉众保持一致。业务涉众特别需要嵌入到规划计划的开发和结果中。在很多情况下，业务用户对于验证后端计算非常关键(例如，没有用户界面的技术发布)。它们通过在实际发布之前提供有价值的反馈，以及用户界面，帮助降低实现风险。
• 解决方案的完整性,为了保持解决方案的完整性，在计划中需要有一个把关功能。这将确保需求在被设计和构建时的可追溯性，以及功能设计规范的创建。这个功能也可以作为一个门来确保整个环境、集成和测试策略与解决方案定义一致。

方法对齐——当混合多种交付方法时，有明确的对齐里程碑是至关重要的

任何使用多种交付方法(瀑布式和敏捷)交付的大型程序，如果不仔细管理的话，很快就会变得非常复杂，难以协调。从组件、应用程序、跟踪和发布的角度来考虑大型转换是很有帮助的。

• 组件,一种可用于解决业务问题的技术，但如果不与其他组件结合，它本身就不能完全发挥功能。
• 应用程序-为解决业务用户的问题而组合的一组技术组件，其中包括持久数据存储。
• 跟踪,可以认为是需要一起交付的一组功能，以解决一个或多个业务用户的业务问题。track可以组合一个或多个应用程序来交付所需的功能。
• 发布 -软件的生产版本。


对准里程碑同时使用敏捷与瀑布方法学项目的关键

方法(敏捷vs.瀑布)通常是由团队决定的，而团队通常是围绕应用程序组织的。强烈建议同一个应用程序团队中的所有成员共享相同的交付方法。考虑到大多数大型企业都处于敏捷成熟度之旅的某个阶段，企业中的所有应用程序团队都使用相同的方法是极不可能的。因此，交付给大型企业的应用程序很有可能是敏捷或瀑布方法，它们依赖于与其他方法一起交付的应用程序。对于一个包含通过两种方法交付的项目的规划，关键是要有关键的校准里程碑。这将有助于避免敏捷产品引入变更的风险，因为没有变更请求，阶段门控(或称为瀑布)项目是无法处理的。为了协调这两种交付方法，我们推荐以下关键的校准里程碑:

• 阶段- - - - - -在分析阶段的最后，对每个项目将交付哪些功能以及它们将在哪里进行握手有一个清晰的理解是至关重要的。
• 设计阶段,在设计阶段的最后，理解敏捷产品和瀑布项目之间接口的细节是至关重要的。敏捷产品可能会继续更改那些不会影响与瀑布项目的接口协议的组件，但是那些依赖的组件现在需要处于变更控制之下。虽然这将降低一些与敏捷产品相关的敏捷性，但它将防止瀑布项目中的进度滑倒。
• 测试阶段,一旦单元测试、回归测试和功能系统测试完成，阶段门控项目和敏捷产品就需要进入集成系统测试。在这一点上，敏捷产品应该处于一个强化的冲刺阶段，只解决错误修复，而不是引入任何新功能。
• 部署,在上线的最后一个里程碑阶段，需要将这些功能发布到生产中，共同交付端到端解决方案。

敏捷交付——在迁移到敏捷交付时要注意

随着越来越多的组织将敏捷交付作为一种加速速度和提高质量的方法，我们已经看到许多组织在他们沿着敏捷交付路径的最初步骤中遇到了挫折。我们建议采用一种谨慎的方法来决定是否以及何时应该使用敏捷方法交付产品。方法是工具包中的一种工具，为这项工作选择合适的工具非常重要。我们发现以下标准对于决定哪些产品应该转移到敏捷交付方法以及何时转移非常有用。

• 高频率的变化-不断演进的产品往往非常适合敏捷交付方法。这些产品可以维持一个持久的待办事项列表，从而允许sprint团队建立动力。
• 结构稳定,对于刚刚踏上敏捷之旅的组织来说，如果产品正在进行重大架构修订，那么要取得成功可能会更具挑战性。为了避免返工，成熟的敏捷组织建议避免对R1(发行版1)产品采用敏捷交付方法。让产品架构决策稳定下来，然后将r2和其他产品转移到敏捷交付模型中，以降低失败的风险。
• 限制相互依赖关系,像伸缩敏捷框架(SAFe)这样的框架被设计用来处理具有多种相互依赖关系的复杂程序，但仍在开发敏捷能力的组织最好选择相互依赖关系有限的产品。在以瀑布和敏捷方法交付解决方案的环境中，敏捷产品与瀑布项目的纠缠越多，产品实际具有的敏捷性就越低。
• 业务准备,不要小看这从商业拥抱关键敏捷概念要求，如最低可行的产品，基于容量的冲刺或自组织的团队组织的变化量。选择一个有同情心的商业社会，并试图拉拢敏捷怀疑论者之前创建您的组织中证明点。

图1:如何调整不同的执行方法


• 缺乏清晰的需求当业务团体不清楚他们想要什么，并且真正需要探索“可能的艺术”的情况下，允许业务“看到它并相信它”的迭代方法可能就是一张门票。
• 避免业务关键解决方案-在尝试将任何业务关键产品迁移到敏捷交付方法之前，最好确保组织已经达到了敏捷成熟度的水平。
• 产品稳定,如果产品有显著的性能或稳定性问题，那么将交付方法从瀑布式转换到敏捷式可能不是最好的策略。这只会带来更多的波动性。很有可能，如果挑战持续存在，它们将正确或错误地归咎于交付方法。
• 避免在河流中间换马在产品发布的最后更改交付方法是最有效的。这样一来，所有的新工作都是从敏捷交付方法开始的，而不是在项目还在进行的时候试图改变交付方法。

海量数据量——计划需要充分考虑环境的大小，并对环境进行伸缩以处理海量数据量

对于大型公用事业来说，时间序列负载分析和预测所需的数据量是巨大的。一个拥有500万个智能电表，每小时产生4次读数的公用事业公司每年将产生1750亿次读数。这些AMI读数将与DER和SCADA数据相结合。如果网络中有50万个d，那么一年就有175亿个读数。假设网络中有5000个连接a站、b站和电路的节点，每年需要创建175亿个(96个间隔/天* 365天* 5000个节点* 10个SCADA点)记录，才能创建网络中所有节点的负荷曲线。加上其他不那么重要的实体，如项目、网络组件等，每年可以增加近2000亿个记录。10年的历史数据和10年的预测将代表4万亿的记录。如果将平均记录大小考虑为100字节，则环境中的存储容量为400tb。不仅在生产环境中，而且在开发、测试和性能测试等较低级别环境中，对这些数据量进行充分的规划是非常重要的。

强大的数据湖——特别强调共享环境管理

正如在长度在电网现代化的能力上一篇文章中讨论的那样，现代电网的规划和工程能力高度依赖于强大的数据湖。一旦各种各样的用于电网现代化所需的信息（资产，电网连接，使用情况，天气，经济，负荷增长，DER，程序，GIS等）数据湖中可用，有可能会各种各样的整个消费者关心这个数据的企业。在数据湖冲突的程序要求，可按计划肆虐，如果不妥善管理。这就是为什么它的关键，制定了详细的可用性和任何共享环境升级计划。

数据供应需求——尽早计划，并为多轮临时数据供应进行规划，以满足需求

当设计新颖的问题的解决方案，你往往不知道你不知道的东西。正是看到真实数据解决方案的早期原型，以提供解决方案设计的反馈至关重要。

使用真实数据的早期解决方案原型至关重要

解决方案开发的迭代过程为任何数据可视化或预测解决方案提供了关键的反馈循环。为了在数据密集型解决方案中适应这种反馈循环，必须计划多轮特别的数据供应。同样重要的是，在解决方案定义过程中，任何业务需求都应尽早包括数据供应需求。这将为数据提供充足的时间。由于涉及到数据量，数据供应往往是帐篷中的一根长杆。

算法调整 - 它可以在一个时间表肆虐

开发预测模型常常是一种反复试验的过程，因为假设要用数据来检验，然后再调整和检验。算法会不断调整，直到它们最适合历史数据。这个调优过程可能意味着添加更多的数据源和更改现有的和历史的数据源。这些改变会严重破坏你的计划，所以以下几点很重要:

• 定义操作水平协议，以适应周转时间，如数据验证和业务审查，以避免进度延误。
• 为算法调优计划足够的时间和资源。当您第一次尝试开发新算法时，可能会花费比预期更长的时间。
• 在获取和加载所有数据之前，要验证用于训练算法的数据源的数据质量。

虽然每个公用事业的电网现代化进程将以不同的速度进行，但这些经验教训可以帮助您避免为新问题构建解决方案时所固有的一些缺陷。