【Jason English, 副总裁，营销传播, iTKO】
【Chris Kraus, LISA 产品经理和主管，EMEA Practice, iTKO】
今天的电力公司在控制成本的同时，还必须向客户提供优良的服务可靠性。这些行业目前正在十年前技术的重压下挣扎，必须现代化 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 实时系统时，如果系统提供不准确的数据或慢慢停下来时会怎么样？如果系统在生产过程中失败，可能会引发对整个网络的性能和可靠性的怀疑，最终会对收益产生影响，或者导致公用行业供应商与监管机构发生争执。
#p#
智能电表/智能电网现代化的挑战
电力正在从一个变数和数据量相对较少的 IT 环境移入另一个环境中，在这个新环境中，每个客户电表现在都是一个联网的计算机，作为一个控制点将新数据推入电网并将数据传播到底层遗留系统。技术数量、运算次数、以及任何一个能源公司的 IT 系统和基础架构需要处理的数据量都呈指数增长。
我们来看一个非常简化的典型能源软件基础架构视图。图 2 突出显示了新的且令人印象深刻的高风险努力，实现了智能电网和智能电表，提供了新级别的控制和预测。
图 2. 不可用系统和未完成系统如何约束新 “智能” 技术的交付
这个简化图展示了一个能源公司的典型软件架构以及由此引起的约束推出新技术。
您的开发团队期望如何交付一个巨大的任务，特别是一夜之间，使用一个互相依赖的软件环境，而这些软件并没有全部建立或全部可用？
我们发现电力的 IT 团队正在同这些交付问题作斗争：
◇ 高度依赖不可用或者受限系统。
◇ 数据复杂度和可变性影响集成和测试效果。
◇ 在事务方面惊人的增长，通过整个电网影响系统。
◇ 无法验证端到端系统的精确性和服务性能。
我们来仔细看看这些问题。
问题 1：增长的依赖性
开发团队很难接受一个复杂的分布式系统支持新的使用场景：
◇ 一个 meter-to-customer 事务可能需要经过十几个不同的消息协议来进行转换，然后与记录和服务系统进行通信，那些记录的服务系统在您开发和集成系统来支持 AMS 时可能很少（或者几乎不）访问。
◇ 运营团队可能会限制访问关键系统，每周只向您的开发团队预留 2 小时。
◇ 您的系统需要同第三方服务或系统进行通信，这在您的团队控制之外。
◇ 一些您需要使用的组件可能还没有开发。
从一个用户角度来看，开发和 QA 团队需要验证系统中数千个事务场景 — 每次只有一个系统在使用环境，但是对于其他团队来说它会污染环境中的数据。
问题 2：数据复杂性
电力 IT 团队不得不根据实时系统和波动的事务模式来构建软件；这种情况的一个主要副作用是很难建模真实、健壮的测试数据来贯穿整个软件生命周期：
◇ 客户和能源事务数据的波动性，以及跨实时系统跟随状态性事务的需求，使自动化 AMS 实现 VS 应用程序的测试看起来似乎不可能。
◇ 为了避免法规遵从和数据损坏问题，敏感的客户账户信息和实时事务数对于测试和开发团队需要被控制和屏蔽。
◇ 团队经常要花费 60% 的测试周期或者更多时间来构建和拆卸数据，给其他团队发电子邮件或者打电话来证实或者重置特定数据场景等等。这种效率和成本是不能接受的。
我们需要减轻测试数据对实时系统和架构中其他团队的影响。
问题 3：增加的交易量
数千个新智能端点增加到一个正在运行的智能电网实现中将生成大量不确定性的系统可靠性：
◇ 如果大部分电表损坏，将会发生什么？它们能够准确地记录断电时期吗？如果数百万的电表每小时向系统发送一次使用数据，电网会做何反应？成千上万个 Transactions Per Second (TPS) 对基础架构有何影响？
◇ 我们发现一些公司正在尝试逐个测试遭受智能电表端点攻击的系统的可靠性，通过将几个物理电表钉在一个木板上然后在网络中运行或者手工编码伪造 “存根” 来模拟这些电表。但实践不足以解释所有可能的使用状况和交易量需求。
传统电力 IT 基础架构从来不需要解释这个水平的使用状况。
问题 4: 无力验证端到端系统
跨越现代电力系统的很多技术层和依赖性增加了验证软件可靠性的困难和成本：
◇ 人工测试 — 既可以在用户接口进行、也可以在单个端点进行 — 是电力行业当时的规则。这些测试方法对根用户提供较少的可视性，可能会引发很多问题。
◇ 验证也是一个常见的人工任务；测试人员必须花费时间试着通过电话验证输出，人工在记录系统中查看预期数据结果。
◇ 误报和故障是常见的。例如，可能会有一个网站或者服务说它 “确定” 某个事务发生了，但实际上在首段没有状态改变。
团队需要能够以一个自动模式确定一个端到端命令是否被正确处理，以及数据是否依据预期策略在每个中间层传递。
#p#
解决方案：虚拟化依赖性，验证可靠性
服务虚拟化 — 电力公司的一个备用的、不受云计算软件约束的解决方案 — 采取下一个步骤完成硬件虚拟化，通过虚拟化行为、性能以及依赖性服务和应用程序的数据。很多团队都是用这个实践来虚拟化依赖性应用程序行为、自动化数据场景和构建可测试的系统模型（现在还没有模型规范）。
服务虚拟化提供了一个解决方案来处理硬件虚拟化限制，比如：
◇ 为您提供每周 7 天每天 24 小时访问服务终端。
◇ 移除系统和软件容量约束。
◇ 跨分布式系统处理数据波动。
◇ 减少或消除第三方系统非生产使用的成本。
服务虚拟化用于模拟约束和/或不可用组件，允许电力行业的 IT 团队以更少的风险和较低的总项目成本交付缩紧时间期限（图 3）。
图 3. 通过在软件生命周期中自动化开发和测试依赖性，您可以消除电力约束
电力行业的开发和 QA 团队可以利用服务虚拟化来减少软件生命周期中的依赖项和约束性，可以延迟项目或者影响应用程序性能。表 1 展示了这个实践如何被用来应对现代智能电表/智能电网实现的挑战：
表 1. 解决问题的实践方案
| 问题 | 解决方案 |
|---|---|
| 不可用或者受限系统上的依赖项 | 虚拟服务环境允许开发和测试团队虚拟化约束服务和组件行为，通过捕获数据和事务上下文和提供一个在外观和行为上看起来像真实事情的虚拟服务 来实现的在软件生命周期中的开发和测试。 |
| 数据复杂性和多变性 | 使用虚拟服务测试数据管理。通过跨系统捕获数据事务的复杂性，团队获得健壮、稳定的虚拟数据场景，以及有效响应逼真的模拟客户会话、状态交易、时间和数据等的复杂行为。您将需要对开发和测试过程的关键客户和系统数据表现冷淡或者模糊不清，以至于安全性和私有策略不被妥协。 |
| 增长的交易量 | 虚拟化性能测试配置了一个大容量虚拟仪表 阵列，可以将数千个 TPS 推入系统或者当它们在负载下执行时模拟像仪表控制 和仪表数据管理系统 这类中间组件。使用这种方法，团队可以使用 AMS 计划需求的流量扩展他们的系统规模。 |
| 无力验证端到端系统 | 连续的构建和验证服务支持基于服务的端到端测试和组合应用程序类型。您可以在本机测试复杂的端到端工作流，并直接验证在每个对给定事务流程有益的组件中是否出现期望行为。 |
#p#
服务虚拟化和连续验证的益处
这些示例仅限于 AMS 和智能电网技术，不能代表所有的电力客户场景（其中服务虚拟化和连续验证可以取得巨大收益）。虽然如此，在复杂不断变化的环境中推出新功能的挑战可能会有所减缓。在 AMS 和智能网络分类中，共同的客户在很短时间内已经取得了令人信服的成果。客户应该：
◇ 为了实现平行开发，减少系统约束性：
增加已交付和测试的软件功能高达 68%。
实现快速上市（在 3 个月的周期中 10 周就可以交付）。
◇ 实现自动化和测试数据场景每周 7 天每天 24 小时可用：
在前 2 周减少 80% 的测试数据管理成本。
稳定波动数据和减少建立/拆卸效率。
◇ 模拟数百万新端点的影响：
自动交付高容量模拟环境。
减少 90% 的测试实验室环境创建成本。
◇ 以较少的故障启动连续的验证：
端到端工作流完全透明。
增加客户规范和减少损失，因为服务级性能和质量不是很糟糕。
电力公司面临着现代化 IT 资源和现有技术来满足当前业务和管理需求的挑战。在本文中，我们解释了服务虚拟化如何减轻 AMS 动态企业级应用程序的开发和测试以及支持一个位于新智能电网架构顶部的软件的实现，来确保可信和有效的服务交付。
作者简介：
Jason English 在多年为技术和客户公司，比如 HP、IBM、EDS、Delphi、TaylorMade、Sun、Realm、Adaptec、Motorola 和 Sprint，执行营销计划和设计面向客户的业务流程的过程中获得了许多经验。作为 i2 Technologies 公司的 in2action 交互咨询单元的执行监制人，他负责在大规模增长期间向国外发送消息来构建易于理解的工作流和 front-ends to B2B 合作系统。在此之前，他是一名 “首席架构师” ，管理 Agency.com 的 Fortune 500 客户端的客户体验。除了生产传统广告和电视广告之外，他也成功设计了几个计算机游戏的国际版本。
Chris Kraus 是一名测试专家和架构战略家，在计算软件开发、产品管理和扩展企业软件支持方面有 17 年的经验。作为 iTKO's LISA SOA 测试软件套件的产品经理，Chris 应用项目管理和开发经验来细化 LISA 特性，贯穿整个软件交付生命周期更好地适应客户质量需求。Chris 之前是企业级软件平台公司 webMethods 的一名零售和制造业经理，监管需求、客户售前展览，并进行每年度 US$16M 的培训。在供应链软件提供商 i2 Technologies 公司中，他在 i2 基础架构组中负责业务流程版本发布、工作流以及监控引擎。在 i2 之前，他在 software AG 公司工作，在 software AG，Chris 专攻跨平台产品安装和管理。作为一个软件工程师、项目经理和解决方案架构师，Chris 从工作的公司，比如 like Citi、TD Ameritrade、Lenovo、Tandy、Rubbermaid、TI 和 TxDoT 学到了很多行业知识，确保应用程序交付生命周期的质量。
【编辑推荐】
