【IT168 技术】　　今天的电力公司在控制成本的同时，还必须向客户提供优良的服务可靠性。这些行业目前正在十年前技术的重压下挣扎，必须现代化 IT 资源和现有技术来满足当前业务和管理需求，实现良好的可视化和跨电网的电力控制。

　　今天，电力公司面临最大挑战的一个特定领域是 Advanced Metering Systems (AMS) 和位于一个新的智能电网架构顶层的支持软件。我们把注意力集中在具体的行动上，讨论 iTKO LISA™ 如何在较少的成本和时间延误的风险下提交新功能。

　　纵览全球能源行业，在网络和消费者层都有急需优化能源基础架构。政府已经强制执行了效能举措，这是由客户账单和津贴资助的 — 根据 US Government Accountability Office (GAO) 资料显示，2009 年共计 34亿美元的资助经费用于 United States 的智能电网项目，214 亿美元分配给世界各地。

　　本文中，我们将讨论：

　　现代化智能电表和智能电网的挑战。

　　服务虚拟化如何减轻促进高效开发和动态企业应用程序测试。

　　通过捕获部署软件资产行为，同时虚拟化那些尚未存在的行为，服务虚拟化可以帮助在电力行业中的开发和 QA 团队来控制软件生命周期中的依赖和约束，从而帮助确保可靠的服务交付。

　　现代化能源软件基础架构的风险

　　样例基础架构由大量新技术和现有技术组成，这些技术必须被整合来满足分布式 IT 环境的需求(如图 1 所示)。

图 1. 复杂的 Utility IT 基础架构

　　要使智能电表和智能电网计划得以实施，电力行业提供商必须处理难以计数的大量软件相互连接和遗留实现。在电网上安装数百万新设备可能会导致数以千计的新集成活动，这些集成活动在过去的电力公司中是完全不支持的。

　　更困难的是，电力公司必须在一个规定的、具有挑战性的交付模式中提交先进的测量技术和智能电网技术 — 很显然这必须是可靠的。

　　AMS 和智能电网危险因素包括：

　　◇ 新的端点和系统：一个电力客户必须在一个首年 “试用” 窗口安装 800,000 个新智能电表：一项复杂的工作，这个项目涉及到超过 600 种不同的电表、固件和软件配置组合。这才是开始。

　　◇ 解除市场管制：因为在 US 大多数电力市场是不受控制的，有几十个新零售商进入市场，他们区别客户供应的产品，不仅仅考虑价格，也考虑定制基于 web 的系统和家用单元来管理能源使用。这创建了许多必须验证的客户使用案例。

　　◇ 遗留系统：现有电力公司的 IT 基础设施已经过时，其中很多组件都是 10 年前、甚至 20 年前部署的，这些组件是为粗粒度数据和电网控制(包括测量像平均计量和计费之类的)设计的。这有一个更现代的多层方法，提供更多可视性、灵活性和更多的能源使用控制模式，但是遗留系统通常会发现适应资源需求很困难。

　　当您为了在期限内完成而推行一个新智能电网或者 AMS 实时系统时，如果系统提供不准确的数据或慢慢停下来时会怎么样?如果系统在生产过程中失败，可能会引发对整个网络的性能和可靠性的怀疑，最终会对收益产生影响，或者导致公用行业供应商与监管机构发生争执。

　　电力正在从一个变数和数据量相对较少的 IT 环境移入另一个环境中，在这个新环境中，每个客户电表现在都是一个联网的计算机，作为一个控制点将新数据推入电网并将数据传播到底层遗留系统。技术数量、运算次数、以及任何一个能源公司的 IT 系统和基础架构需要处理的数据量都呈指数增长。

　　我们来看一个非常简化的典型能源软件基础架构视图。图 2 突出显示了新的且令人印象深刻的高风险努力，实现了智能电网和智能电表，提供了新级别的控制和预测。 

图 2. 不可用系统和未完成系统如何约束新 “智能” 技术的交付 

　　这个简化图展示了一个能源公司的典型软件架构以及由此引起的约束推出新技术。

　　您的开发团队期望如何交付一个巨大的任务，特别是一夜之间，使用一个互相依赖的软件环境，而这些软件并没有全部建立或全部可用?

　　我们发现电力的 IT 团队正在同这些交付问题作斗争：

　　◇ 高度依赖不可用或者受限系统。

　　◇ 数据复杂度和可变性影响集成和测试效果。

　　◇ 在事务方面惊人的增长，通过整个电网影响系统。

　　◇ 无法验证端到端系统的精确性和服务性能。

　　我们来仔细看看这些问题。

　　问题 1：增长的依赖性

　　开发团队很难接受一个复杂的分布式系统支持新的使用场景：

　　◇ 一个 meter-to-customer 事务可能需要经过十几个不同的消息协议来进行转换，然后与记录和服务系统进行通信，那些记录的服务系统在您开发和集成系统来支持 AMS 时可能很少(或者几乎不)访问。

　　◇ 运营团队可能会限制访问关键系统，每周只向您的开发团队预留 2 小时。

　　◇ 您的系统需要同第三方服务或系统进行通信，这在您的团队控制之外。

　　◇ 一些您需要使用的组件可能还没有开发。

　　从一个用户角度来看，开发和 QA 团队需要验证系统中数千个事务场景 — 每次只有一个系统在使用环境，但是对于其他团队来说它会污染环境中的数据。

　　问题 2：数据复杂性

　　电力 IT 团队不得不根据实时系统和波动的事务模式来构建软件;这种情况的一个主要副作用是很难建模真实、健壮的测试数据来贯穿整个软件生命周期：

　　◇ 客户和能源事务数据的波动性，以及跨实时系统跟随状态性事务的需求，使自动化 AMS 实现 VS 应用程序的测试看起来似乎不可能。

　　◇ 为了避免法规遵从和数据损坏问题，敏感的客户账户信息和实时事务数对于测试和开发团队需要被控制和屏蔽。

　　◇ 团队经常要花费 60% 的测试周期或者更多时间来构建和拆卸数据，给其他团队发电子邮件或者打电话来证实或者重置特定数据场景等等。这种效率和成本是不能接受的。

　　我们需要减轻测试数据对实时系统和架构中其他团队的影响。

　　问题 3：增加的交易量

　　数千个新智能端点增加到一个正在运行的智能电网实现中将生成大量不确定性的系统可靠性：

　　◇ 如果大部分电表损坏，将会发生什么?它们能够准确地记录断电时期吗?如果数百万的电表每小时向系统发送一次使用数据，电网会做何反应?成千上万个 Transactions Per Second (TPS) 对基础架构有何影响?

　　◇ 我们发现一些公司正在尝试逐个测试遭受智能电表端点攻击的系统的可靠性，通过将几个物理电表钉在一个木板上然后在网络中运行或者手工编码伪造 “存根” 来模拟这些电表。但实践不足以解释所有可能的使用状况和交易量需求。

　　传统电力 IT 基础架构从来不需要解释这个水平的使用状况。

　　问题 4: 无力验证端到端系统

　　跨越现代电力系统的很多技术层和依赖性增加了验证软件可靠性的困难和成本：

　　◇ 人工测试 — 既可以在用户接口进行、也可以在单个端点进行 — 是电力行业当时的规则。这些测试方法对根用户提供较少的可视性，可能会引发很多问题。

　　◇ 验证也是一个常见的人工任务;测试人员必须花费时间试着通过电话验证输出，人工在记录系统中查看预期数据结果。

　　◇ 误报和故障是常见的。例如，可能会有一个网站或者服务说它 “确定” 某个事务发生了，但实际上在首段没有状态改变。

　　团队需要能够以一个自动模式确定一个端到端命令是否被正确处理，以及数据是否依据预期策略在每个中间层传递。

　　服务虚拟化 — 电力公司的一个备用的、不受云计算软件约束的解决方案 — 采取下一个步骤完成硬件虚拟化，通过虚拟化行为、性能以及依赖性服务和应用程序的数据。很多团队都是用这个实践来虚拟化依赖性应用程序行为、自动化数据场景和构建可测试的系统模型(现在还没有模型规范)。

　　服务虚拟化提供了一个解决方案来处理硬件虚拟化限制，比如：

　　◇ 为您提供每周 7 天每天 24 小时访问服务终端。

　　◇ 移除系统和软件容量约束。

　　◇ 跨分布式系统处理数据波动。

　　◇ 减少或消除第三方系统非生产使用的成本。

　　服务虚拟化用于模拟约束和/或不可用组件，允许电力行业的 IT 团队以更少的风险和较低的总项目成本交付缩紧时间期限(图 3)。 

　　图 3. 通过在软件生命周期中自动化开发和测试依赖性，您可以消除电力约束 

　　电力行业的开发和 QA 团队可以利用服务虚拟化来减少软件生命周期中的依赖项和约束性，可以延迟项目或者影响应用程序性能。表 1 展示了这个实践如何被用来应对现代智能电表/智能电网实现的挑战：

　　表 1. 解决问题的实践方案