网格现代化：经验教训

通过Joshua Biggins，拉曼萨尔纳，Amit Kumar克里斯汀•卡尔霍恩 2019年10月|文章|20分钟阅读|本文的电子邮件|下载

介绍

公用事业公司正在拥抱新技术，以使其电网现代化，并应对由诸如太阳能电动汽车和电池存储等分布式能源资源创建的变化的负载型材。开拓者前进的道路通常是最具挑战性的。本文在早期先锋的精神下，试图分享一些经验教训。

在以前的文章，我们讨论电网现代化的理由和网格现代化能力。在本文中，我们将讨论从开创网格现代化工作中吸取的10个经验教训，以协助他人的旅程。虽然此类努力跨越电网运营和规划和工程，但本文主要侧重于规划和工程。

十大电网现代化的经验教训：

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

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

随着公用事业的尝试将数据模型合理化以管理各个领域的数字信息，他们可能会因几十年前的决定而困扰。今天可用的加工能力使得可以在短时间内几乎无法设想使用案例。准确的网格连接模型需要仪表信息通常存储在客户支持系统中，以连接到存储在分发和传输系统中的电路和资产信息。以准确代表电网的方式拼接该信息的努力可以通过无法设想未来需要的数据模型和系统来推迟。

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

关键的网格现代化用例之一是预测给定节点随时间变化的负载的能力，以便开发资本和非资本响应解决方案。对网络中每个节点进行长期时间序列预测，需要大量的历史负荷数据、经济数据、负荷增长数据、天气数据、地理信息系统(GIS)数据、分布式能源(DER)数据和电网连通性信息。在处理如此大量的历史数据时，很容易忽略可能对预测产生不利影响的重大数据缺口。因此，明智的做法是，在确定任何发布日期之前，设置一个数据质量程序来识别数据差距，并制定一个计划来修复它们。

高级计量基础设施(AMI)数据的逻辑聚合可以替代缺失的监控和数据采集(SCADA)数据，前提是正确构建电气层次结构。不完整的电气层次结构是常见的，因为它们从来没有被用于获得这样特定水平的负载和消耗情况。将合法的数据质量问题与虚假的数据质量问题区分开来可能具有挑战性。例如，未激活的资产可能与未正确映射到其消费数据的资产看起来完全相同。这是因为如果您没有考虑资产的操作状态，那么它们都将显示为没有使用数据的电气层次结构。

错过数据验证的另一个例子是公用事业境中准确的天气数据的可用性。此验证必须完成三个维度，以有效地利用预测生成天气数据：

必须将天气数据映射（经度和纬度）完整为网络中的节点。

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

确保天气数据的完整性。（在我们的经验中，气象站可能缺少高达20％的小时数据。）



当数据以新方式使用数据时，数据质量 - 先前未认出的数据质量问题可能会暴露

依赖于创建和维护传统数据结构的信息新系统和流程运行揭示隐藏现有生产系统中的数据质量问题的风险。直到有人开始以一种新颖的方式使用数据，这些数据质量问题并不重要，也不会得到修复。一个全面的数据质量项目应到位，以解决数据质量问题是：

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

• 建立质量管理流程和指标，以主动剖析数据源，以基于一组已定义的业务规则和阈值识别数据质量问题。
• 修复源中任何数据质量问题的根本原因，以避免将新的数据质量问题注入系统。
• 识别数据管理员，以便在企业级而不是在功能竖井中管理对数据模型和数据定义的更改。

虽然每个应用程序识别的数据质量问题的类型对它们自己的生态系统来说都是独特的，但有一些事情需要注意:

• 客户映射到多个电路 -如果客户服务和计费系统中的客户帐户关系是与一个结构而不是与实际电网的一个组件(如变压器)相关联的，那么给定的客户可以映射到多个电路的可能性很小。当多个变压器与一个给定的结构相关联，而不同的电路与每个变压器相关联时，就会发生这种情况。
• 记录的DER数据-由于分布式能源资源通常是客户拥有的，因此许多公用事业公司可能选择不将其包含在其资产管理系统中。为DERS建立记录系统至关重要，以便准确地预测负载概况。实用程序需要开始跟踪客户DER数据。

综合规划 - 了解依赖项目之间的关键路径和依赖关系至关重要

提供网格现代化规划能力，多个平台，IT和业务流程，执行方法以及第三方供应商以及其工具需要与明确的视线集成到执行。如果没有这一点，它很容易错过交叉能力依赖，忽略架构包含指南，或者根本根本不了解开发和改变一个工作流或平台以及它们对他人的影响。糟糕的规划是失败的根本原因，特别是在这种复杂的转变中。

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

• 计划计划 -跨项目的集成计划，最高级别提供了提供能力的关键路径。这对所有平台依赖性的帐户占 - 即，数据和分析平台馈送连接模型，并与可视化产品的集成，以进行配置文件生成或预测结果。规划时间表必须在较低级别的平台和能力开发，更改管理和工作活动中创建，这取决于它们。了解规划阶段的平台，环境和工具限制以产生现实计划计划至关重要。
• 利益相关者和沟通计划-它往往是难以对齐的利益相关者的依赖性，复杂性和执行办法要成功实现给定的。企业利益相关者的特别需要在程序中嵌入计划的发展和转归。经常有地方企业用户验证到后端的计算（例如，技术版本，而不会用户界面）的关键实例。他们帮助在实际发布前提供有价值的反馈降低实施风险，用户界面完成。
• 解决方案的完整性,要维护的解决方案的完整性，有需要在规划把关功能。这将确保的，因为他们正在设计和建造要求的可追溯性和功能设计规范的创建。这个功能也作为一个门，以确保整体环境，集成和测试策略与解决方案的定义一致。

方法对准 - 当混合多种递送方法，关键是要具有清晰对准里程碑

任何具有多个传送方法（瀑布和敏捷）提供的大型程序都可以在不仔细管理的情况下迅速变得非常复杂。在组件，应用程序，曲目和发布方面，思考大量转型是有帮助的。

• 成分 -一种可用于解决业务问题的技术，但其本身在而不是与其他组件组合的情况下完全运行。
• 应用程序 -为解决业务用户的问题而组合的一组技术组件，其中包括持久数据存储。
• 轨道 -可以认为是需要一起交付的一组功能，以解决一个或多个业务用户的业务问题。track可以组合一个或多个应用程序来交付所需的功能。
• 版本,软件的生产版本。


对齐里程碑对于同时使用敏捷方法和瀑布方法的项目是至关重要的

方法论（敏捷与瀑布）一般是由团队决定，球队通常被组织内的应用程序。强烈建议，同样的应用团队中的所有成员共享相同的交付方法。鉴于大多数大型企业都在他们的敏捷成熟过程中，有时它是极不可能的，整个企业的应用程序团队都使用相同的methodology.Therefore，极有可能交付给大型企业应用将是要么敏捷或瀑布方法依赖于应用程序正在与其他方法交付。对于通过这两种方法被传递，其中包括项目计划，关键是要有重点对准里程碑。这将有助于避免变化的风险由雅居乐的产品，相门（也称为瀑布）项目不能没有变更请求处理引入。这两种交付方法之间的协调，我们推荐以下重点对准里程碑：

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

敏捷交付 - 注意迁移到敏捷交付

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

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

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


• 缺乏要求清晰度 -In situations where the business community doesn’t have a clear idea of what they want and really need to explore the “art of the possible,” an iterative approach that allows the business to “see it to believe it” may be just the ticket.
• 避免业务关键解决方案 -在尝试将任何业务关键产品迁移到敏捷交付方法之前，最好确保组织已经达到了敏捷成熟度的水平。
• 产品稳定性 -从瀑布转换到敏捷的瀑布的交付方法对于体验显着性能或稳定性问题可能不是最好的策略。它只引入额外的波动性。如果挑战持续存在，他们将正确地或错误地归咎于交付方法。
• 避免更改马中游 -在产品发布的最后更改交付方法是最有效的。这样一来，所有的新工作都是从敏捷交付方法开始的，而不是在项目还在进行的时候试图改变交付方法。

大规模数据卷 - 计划需要充分考虑大小调整环境并将其缩放以处理大规模数据量

时间序列负荷分析和预测对于大型实用程序所需的数据量是巨大的。一个有500万智能电表的效用，每小时生成四个读数将每年创造175亿读数。那些AMI读数将与DER和SCADA数据组合。如果网络中有五百万个米，则每年可能有175亿读数。假设有5,000个节点组合网络中的一站子，B-驻地和电路，需要创建175亿（96个间隔/日* 365天* 5,000节点* 10 SCADA点），以创建负载用于网络中所有节点的配置文件。添加其他不如此重要的实体，如项目，网络组件等，每年可以加入近2000亿录的记录。十年的历史数据和10年的预测将占四万亿纪录。如果考虑平均记录大小是100个字节，则您正在查看环境中的400 Tberytes的存储空间。对于这些数据卷充分规划，而不仅仅是生产，而且在较低的级别环境中是至关重要的，也是如开发，测试和性能测试。

强大的数据湖 - 额外重视共享环境管理

正如在上一篇关于网格现代化能力的文章中详细讨论的那样，现代网格的规划和工程能力高度依赖于健壮的数据湖。一旦网格现代化所需的各种信息(资产、网格连接、使用情况、天气、经济、负荷增长、DER、程序、GIS等)在数据湖中可用，整个企业中可能会有各种各样的消费者对这些数据感兴趣。如果管理不当，数据湖上相互冲突的程序要求可能会对计划造成严重破坏。这就是为任何共享环境开发详细的可用性和升级计划的关键所在。

数据准备金要求 - 计划早和多轮即席数据的供应以满足需求

在设计新问题的解决方案时，你往往不知道自己不知道什么。用真实数据查看解决方案的早期原型非常重要，以便为解决方案设计提供反馈。

使用真实数据解决方案的早期原型是关键

解决解决方案开发的迭代过程为任何数据可视化或预测解决方案提供了一个关键反馈循环。为了适应数据密集型解决方案中的这一反馈循环，必须计划多轮ad hoc数据配置。同样重要的是，在解决方案定义过程中尽早包括数据供应要求的数据供应要求。这将允许有足够的时间提供数据供应。涉及数据卷，数据供应通常是帐篷中的长杆。

算法调优——它可能对调度造成严重破坏

发展预测模型往往是在试错的运动作为假设与数据测试，然后调整并再次测试。该算法一直在不断调整，直到他们最适合的历史数据。该调谐过程可能意味着增加更多的数据源和改变现有数据和历史数据源。这些变化可以按计划肆虐，所以它是非常重要的：

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

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