Colin Breck 和 Percy Link 将带大家探索特斯拉VPP虚拟电厂的架构演进，VPP物理上是一个分布式电源网络(包括solar光伏、wind风电、batteries电池储能乃至于电动车)，VPP用软件将这些分布式电源聚合起来、对外整体提供更智能更灵活的发电、配电和可用性，所以VPP可以看作为是一个聚合系统（不同于系统集成、ESB，这是一种全新系统架构，与ESB不同在于它本身有很重的业务逻辑，只是同时还有很重的对外交互，对外交互部分相当于ESB的量级且交织在业务逻辑流程当中，实际上它就是当下的微服务架构），由垂直整合的硬件和软件组合集成而成，包括云和边缘计算。
Transcript
Link：电网是人类有史以来创造的最大最复杂的机器，这是一项了不起的工程壮举，能提供可靠、安全、按需供电。这个电网是建立在20世纪的技术基础上的，有大型集中式化石燃料发电，只有几个控制点。我们现在面临着一项迫切的挑战，即过渡到放弃化石燃料，以防止气候变化。幸运的是，我们现在也有了新的工具。像光伏、风电和水电这样的清洁能源价格低廉而且越来越便宜。但是：单独依靠这些新能源不足以取代化石燃料、是无法独立支撑像现在这个可靠电网的（电网可靠性会明显下降，参考美帝德州冰风暴大停电。直接说结论：新能源发电具有间歇性和随机性，高比例新能源并网需要大规模输出稳定的可调节电源进行调峰）
Breck：软件是聚合各种组件并与电网协作的关键，我们用软件可以实现的是将人们家中的数千个小电池/电动车聚集在一起、作为分布式电源、创建虚拟发电厂，为电网、家庭或企业提供价值。它结合了分布式计算中一些最有趣和最具挑战性的问题，以及分布式可再生能源中一些最具挑战性的问题。这就是我们在特斯拉工作的原因。我们将致力于这些令人兴奋的软件挑战，同时也将加速世界向可再生能源的过渡。我们将带您经历特斯拉虚拟发电厂的演变，并分享分布式计算和物联网的架构、模式和实践，帮助我们应对这些复杂和令人兴奋的挑战。
Link：我是Percy [Link]. 技术团队leader，我们团队负责构建Tesla's 能源优化和电力交易市场平台。
Breck：我是Colin[Breck]. 我领导团队构建并运维Tesla能源IoT云平台. 在我们开始之前先声明一下。我们不代表特斯拉说话，我们只是代表我们的个人经历。
How does The Grid Work?
Link：首先先介绍一些关于电网如何工作的背景知识，以及电池在其中的角色，以便您能够理解软件问题。电网的棘手之处在于：供需必须实时匹配 supply and demand have to match in real-time，否则频率和电压可能会偏离、损坏设备并导致停电。电网本身没有储存电力的能力，所以电力供给侧和需求侧两端需要某种控制，以时刻保持供需平衡。老式集中式化石燃料发电可以根据需求增减电力供应，需要控制的发电厂数量相对较少，这使得维持平衡相对简单。随着更多的可再生能源进入电网，情况开始变化，首先：可控性显著降低，发电量不可能轻易跟上需求量，我们也不想减少发电量（弃风弃光）否则我们就会失去这些清洁电量。第二，不确定性和快速变化。清洁能源无法精确预测，更不用说还可能快速地变化波动。第三，分布。分布式电源会带来许多独立、互相隔离的小型发电机（一盘散沙很难协调控制，需要聚合）
在一个包含大量风电光电电源的电网当中，供电高峰和用电高峰在时间上可能完全不匹配，这种偏差会导致电能盈余过剩和紧缺不足，而且变化还可能非常快。幸好我们有电化学储能：电池，电池可以在电能过剩时充电、在紧缺时放电，电池的响应非常快（想想UPS和电动车的疯狂加速能力），可以胜任填补这种偏差（比较之下抽水储能的响应速度就不够了）足以抵消任何快速波动和不平衡。这种快速反应实际上甚至是一种创新，一种超越旧电网的机会！这不仅仅是一种妥协。
要实现这些，需要安装巨型电池，电池容量相当于典型的煤炭或天然气发电厂，电池在整个场景当中是关键。我们也可以利用家庭当中已经安装的小一些的电池比如备用电源、家庭太阳能配套电池等，我们可以用这些小电池和太阳能将家庭和企业聚合成虚拟的发电厂。本次演讲当中，我们会带你领略VPP带给Tesla能源平台的进化，分为四个阶段，每个阶段都为下一阶段奠定基础.，我们从 Tesla能源平台开始，之后讲一下我们是如何学习参与能源市场、以及我们如何学习开发软件来对一个电池建模、在世界上最大的电池上做这个算法。然后说说我们的第一个VPP. 我们从中学习到了如何聚合并且近实时地直接控制上千个家用电池。最后我们聊聊怎么把这一切聚合起来参与到能源市场。
Tesla Energy Platform
Breck：Tesla能源平台的架构对2C居民用户和2B工业用户都要考虑到，对居民用户平台要支持比如power wall电力墙电池（特斯拉产品，停电时可以为家庭提供数小时或数日的备用电源）、solar roof太阳能屋顶（特斯拉产品），它和power wall搭配可以提供不止是备份电源同时也最大化利用太阳能的产品组合（考虑近期的得克萨斯冰风暴、气候变化导致的中美超级寒潮都会更频繁：夏天更热冬天更冷，让这些产品更具吸引力）
Tesla能源平台是一个集成产品，聚合了光伏、储能，除此以外还创造性提供如Storm Watch（特斯拉服务，为用户提供风暴潮、冰冻预警）这种服务，当风暴接近时可以自动为你的powerwall充满电。用户可以在移动app上体验该系统的实时性能，用户还可以在app上控制一些行为，比如在低成本时间优先充电。
对于2B端工业客户，Tesla能源平台支持用于大规模储能的power pack和megapack等产品，以及工业级太阳能。用户可以用PowerHub软件平台实时监控系统性能，或者查询数天、数周甚至数年的历史性能。现在，这些光伏、储能、运输和充电功能都具备一个边缘计算平台。这个边缘计算平台和各种传感器/控制器交互，比如逆变器、总线控制器和power stages.
Tesla能源平台运行一个完整的Linux操作系统，并提供本地数据存储、计算和控制，同时还通过WebSocket与云保持双向流式bi-directional通信，因此它可以定期向云发送一些应用的量测数据，频率高达每秒一次。它也可以接收云端下达的控制命令。我们主要关注的是云上的IoT物联网平台：Tesla能源平台。
Tesla能源平台的基础一是线性可扩展的WebSocket前端，它负责连接和安全。它背后有一个Kafka集群，用于接收来自数百万物联网设备的大量遥测数据。Kafka可以持久化消息、解耦数据生产者和消费者、支持跨多个下游服务共享遥测数据，还有一个发布订阅服务，支持双向的指令传输来监控IoT设备。这三个服务一起作为整个Tesla的共享基础设施，在之上我们可以构建高层服务（比如下面即将讲到的AutoBidder编排微服务），另外还有一些面向最终用户的应用。
能源产品的APIs大致分为三部分：第一个是用于从设备查询遥测告警和事件的APIs，可以按时序将它们串流化。第二个APIs是资产管理服务，描述能源资产和这些资产之间关系，第三个是用于指挥和控制电池等设备的APIs。现在，这些api的后台服务由大约150个多种语言的微服务组成，太多了，在本文中无法详细描述。我只提供对每个领域微服务的概述。
我们将在稍后研究虚拟电厂时深入研究其中的一些问题。主要还是介绍在物联网规模下处理实时数据的挑战。想象当每个人家里都安装了电池。要支持交互式查询和遥测数据汇总，这些查询包括过去一天或一周的电力输出是多少，我们使用了InfluxDB，这是一个专用的开源时间序列数据库，我们的目标是客户可以随时查询历史数据。我们开发了很多低延迟流式服务，用于数据入库和转换ETL。在一开始我们就创建了规范化的Kafka主题，进入其中的数据经过过滤清洗成为严格规范的数据格式，这是最佳实践，这样下游消费服务得到的都是统一的规范数据。这里的一个独特挑战就是流式遥测数据的实时聚合，这些数据来自上千个电池，我们会详细剖析这个服务因为它是VPP的基础之一。
资产管理服务有四个目标：一是把各种业务系统抽象统一到一个一致的API. 二是提供数据的唯一源端，有冲突数据的时候以他为准。三是提供了一种类型系统，应用程序可以依赖于相同类型设备(如电池)的相同属性。第四它描述了能源资产之间唯一的关联关系，比如哪些设备可以与哪些设备相互通讯、谁可以控制什么设备。该服务完全依赖于Postgres 数据库来描述关联关系（传统关系库负责关联关系），我们用Kafka集成各种业务系统的变更，直接从IoT设备采集变更，系统规模伸缩的时候这样更可靠，因为设备本身往往是最可靠的数据来源，自我报告它们的配置、状态和关系。Digital twin数字孪生是一种对物理设备如电池、逆变器、充电器在软件中进行虚拟建模的表达方式，我们做了大量的数字孪生建模来表示各种资产的当前状态和关系（用Akka）
最后还有一些服务负责对IoT设备下达指令做控制，比如命令电池在某个电力设定条件下持续放电特定时间。类似遥测和资产，我们需要一种实时表达方式、表达大规模的、有状态的、时刻接收流式数据的物联网设备。还要考虑到通过网络控制IoT设备的不确定性、对这种不确定也要建模表达（聚合系统对各种级别上的容错、时序、状态提出了更高要求）
Akka登场
Akka是整个微服务系统的核心，Akka可以看做是一个用于构建分布式计算的工具集，它倡导actor模型，这是建立独立实体状态的最佳模型没有之一，actor提供了基于全异步、不变消息的并发并行开发模型，对于IoT来说actor模型确实超棒，我会演示一些例子。另一个我们大量使用的Akka功能组件是反应式流Akka Streams. 它提供一系列复杂原语（与业务完全无关的精简指令）用于flow control流控、concurrency并发、data management数据管理，而且全都自带反压backpressure（构建真正高可靠系统的核心要素），这样可以确保服务具备有界资源约束，一般来说，所有开发人员开发的都只是个函数，由Akka Streams来处理所有的系统动态、进程的随需伸缩，以此自适应系统和消息容量的变化。
Alpakka子项目提供大量Reactive Streams反应式流接口，用于链接Kafka or AWS S3，我们大量使用Alpakka来与Kafka 交互，我们实际上没有直接使用Kafka streams，因为我们发现它的接口太简陋了，而且是生态圈锁定的，Akka Streams则提供了更通用的流式工具。就像任何的大型平台一样，我们也有混合使用各种语言，但是我们的首选是Scala. 因为它是Akka的开发语言，之后我们爱死了这个语言丰富的类型系统，我们也成了函数式编程的超级粉，我们用函数式构建大型复杂分布式系统。我们喜欢编译时安全、不可变性、纯函数、组合、还有把错误建模为数据而不是抛出异常这些让人见微知著的细节。
对于小团队，深入掌握一门首选语言及其生态圈最高效的工具能让你生产力爆棚、工作变得顺滑、复杂系统整体质量提升。我们主要的微服务运行在Kubernetes，Akka 和K8s 的搭配不能再赞了：
1. Kubernetes可以处理coarse-grained粗粒度失效，比如pods上线下线、运行或重启；
2. Akka可以处理fine-grained细粒度失效比如circuit breaking或者是重试一个请求、还有对实体状态的建模比如电池的充放电；
3. Akka Streams则用于处理实时消息流；一开始平台使用原始的 HTTP 和 JSON ，有利于快速开发，近两年我们转向了gRPC，我们选对了。
gRPC现在是我们开发新服务的首选，对旧服务的扩展也用它，它带来三方面好处：严格的格式协议，使得系统更可靠；客户端代码生成很方便；最后有点出乎预料的好处是我们看到因为有严格格式协议跨团队协作改善了很多，我们不只是在gRPC上看到这个，因为我们也用protobuf做流式消息格式，包括Kafka上的消息，我们有一个共享仓库，格式协议放在上面跨项目共享。我已经多次提到严格格式、Scala中的丰富类型、protobuf中的严格模式，以及用于系统集成的这些严格资产模型。约束最终提供了自由，它们允许微服务和团队的解耦，约束实际上是大规模分布式系统可靠性的基础。
构建特斯拉能源平台的收获：我们很幸运，从第一天起就接受了反应式系统的原则，这产生了令人难以置信的强大incredibly robust,、可靠reliable和高效effective的系统。响应流是处理系统动态和提供资源约束的重要组件，同时也为流提供了丰富的通用API。构建这些复杂的服务，尤其是在物联网中，需要的是分布式计算的工具包。对我们来说，那就是Akka。对于其他人来说，可能是Erlang OTP；我认为现在我们也看到了支持相同构建块的有状态无服务器serverless平台的发展。我想象了一下，这就是我们未来为这些系统编程的方式。这包括状态管理、对单个实体进行规模化建模、工作流管理、流接口，然后允许运行时处理并发性、分布和故障。严格契约使系统可靠、使服务和团队解耦并且改进协作。
Single Battery Market-Participation 单电池参与市场交易
Link：在Tesla能源平台之上，我们构建了第一个电厂app，在这个阶段，我们学习了如何将电池的实时预测和优化功能产品化。在这个例子中，我们从一个非常大的电池开始，也就是Hornsdale霍恩斯代尔电池，这是世界上最大的电池，100兆瓦MW，129兆瓦时MWh，大约是一个燃气涡轮机的大小。霍恩斯代尔不仅是当前、还能在未来更多可再生能源不断投入使用的情况下，持续帮助保持电网的稳定。它实际上还降低了用户成本（指参与调频）：在极端情况下，比如发电机解列下线时，霍恩斯代尔会几乎瞬间做出反应，以平衡可能导致停电的大频率扰动。即使在正常情况下，传统发电机的响应也比指令信号滞后几分钟，而电池几乎可以在瞬间遵循频率调节指令。这有助于维护一个安全的电网频率（紧急调频支撑，参与调频服务以及备用容量服务可以直接从电网公司获得固定收益，但是对服务质量和功率有高可靠要求。电池储能因为容量限制，难以支撑大电网的调峰服务，调峰一般由抽水储能等大容量储能支持）
这个大电池通过能源市场为电网提供服务，为什么我们必须参与能源市场?回想一下供需必须实时平衡的要求，而市场是使两者保持平衡的经济有效途径。市场参与者就未来的电能生产、消费提出报价和时间要求；运营商采用能够以最低价格提供服务的参与者。我们想用电池协助消纳新能源、在未来更多可再生能源上线时帮助电网保持稳定，我们就必须要参与能源市场。怎么参与能源市场？通过软件！为此，我们建立了Autobidder自动投标机器人来运营Hornsdale大电池，现在我们已经把它打包为一个产品提供，这是自动投标机器人的UI：
这是一个专业的工具，是为控制室操作员准备的，他们每天都在看它。屏幕上有很多信息，但它的基本工作流程就是获取数据（比如从Tesla能源平台获取霍恩斯代尔大电池的实时信息）、预测价格（请求预测和优化服务）和可再生能源产量、决定一个最优出价、然后提交、5分钟运行一次，这是澳大利亚电力市场的固定节奏。
宏观上看，优化问题是一种折中，在各种市场产品当中折中，对于电池来说它可以为电网削峰平谷，但是它的电能有上限，所以需要折中选择时段启用它。Autobidder自动投标机器人构建在Colin 所介绍的 Tesla能源平台的应用层，Autobidder包含好几个微服务，它与Tesla 能源平台以及第三方APIs（比如电力市场数据服务）都有交互，Autobidder本质上是一个工作流编排平台，那么你可能会问我们为什么要自己开发而不是直接找一个开源来用？这里面的关键在于这是一个运营系统，不同于批处理任务或者离线作业，它涉及到钱和物理操作、它很关键。Autobidder也重度使用Akka、scala，避免引入其他新语言和过多技术栈，系统核心是编排微服务，它运行自动竞标工作流程，这就是我们的原则：保持核心尽可能简单、外围服务继续复杂。
市场数据服务封装了复杂输入数据的ETL，这些数据会在市场周期相关的不同时间线上进入系统。市场数据服务处理这些时间线，并且在读取、写入数据或丢失数据时处理回调。
预测和优化服务用来跑算法代码，还有一个与电力市场接口交互的投标服务。Autobidder编排微服务、市场数据服务和投标服务都是用Scala写的，Scala给我们提供了很棒的并发语义、函数式编程类型安全性以及跨团队组合最佳实践。不过预测和优化服务是Python写的，这是因为实现算法的快速改进和迭代开发对我们来说非常重要，Python中有一些关键的数值计算和解析库，而且我们团队中的算法工程师对Python用的更流畅。用Python写这些服务的核心逻辑可以更顺畅地迭代（特斯拉由经验丰富的机器学习工程师、优化工程师和市场交易专家组成的团队创建了一个预测和优化算法库，算法包括经典统计，机器学习和数值优化。标准库包含以下功能：价格预测、负荷预测、发电预测、调度优化、智能投标。算法可以适应新的市场和服务，并通过体验数据不断改进，以在动态的市场环境中保持高财务表现。预测和优化服务的算法保持持续的迭代更新）
市场数据服务、投标服务和编排微服务之间通过gRPC通讯，就像Colin所说它的好处是严格的契约、代码生成和协作。编排微服务与预测和优化服务之间的通信使用AmazonSQS消息队列，这个MQ为我们提供了消息持久化，有四个好处：一是在消费端失败的情况下可以重试；二是服务之间不必保持网络长连接情况下也很容易支持长时间运行的任务（support long-running tasks without a long-lived network connection between services.）我们使用不可变的输入-输出消息模型、消息具有严格的模式格式；第三：这允许我们持久化不可变的输入和输出消息，并将它们用于回归测试backtesting，这是我们整个团队任务的一个重要部分（预测和优化服务算法持续更新迭代以及配套回归测试，相应的采用了python以及历史消息持久化）
最后，SQS可以支持我们的worker池模式（Akka典型模式），预测和优化是Python写的，它的并发语义支持很笨，而SQS消息队列允许我们实现跨worker并发，而不是在worker中做并发。值得注意的是，这些服务是纯函数：接收输入数据、产出输出数据、没有副作用，这使它们更具可测试性，并使这些重要的算法更改改进更加安全，同时还减轻了算法工程师编写I/O代码的负担、允许我们用Scala并发来写I/O（聚合系统需要重度对外交互，须要强有力的I/O、并发支持）. 从宏观、整体的角度上俯瞰这些workflows工作流会发现：他们都是有状态的，这种状态是由业务事件驱动的一系列事实数据按照时序叠加而成，状态包括当前是什么业务事件以及之前业务事件的叠加，业务事件之间可能会有多个依赖，比如预测业务事件就需要依赖其他数个业务事件的结果才能进行。
在宕机情况下，比如重新启动编排微服务pod（K8S），我们不希望丢失当前工作流的状态，我们不希望从空白重新启动它。我们可以在检查点checkpoints拍下snapshots快照。如果工作流失败，可以从最后一个检查点恢复它（EventSource）。我们将这种状态保存在表示工作流状态机的actor中。Akka持久化特性通过检查点和事件日志event journal.支持透明状态恢复。
我们学到的重要一课是：业务事件的业务逻辑（business logic of stage execution）和纯函数尽可能与 actor保持隔离，这样让业务逻辑的测试和组合更简单 and the new archetyped API naturally helps with that decomposition. 在我们的团队中，实现算法的快速开发和迭代改进是非常重要的，所以我们在系统的特定位置使用了Python。我们还需要最小化算法迭代破坏工作流的风险。有几件事对我们来说非常有效，可以将风险降至最低，那就是要有一个算法服务的输入-输出模型，它可以使代码更简单、更易于测试和严格的契约，还允许自由地更改算法的内部逻辑，而系统其余部分不受影响。
对我们来说，从核心系统中抽象出外部数据源和服务的杂乱细节是很重要的。这实际上是整个云平台的一个基本租户。这些工作流必然是有状态的，但是将状态与业务逻辑事件纠缠在一起会导致代码复杂化，隔离开来才能保持业务逻辑事件的可测试和可组合性。
Peak-Shaving Virtual Power Plant 虚拟电厂参与调峰
Breck：我们来看看我们的第一个VPP. Percy刚才讲了我们如何基于平台和算法用一块大电池参与电力市场，现在来看看我们怎么扩展它的应用、如何衡量、建模和控制上千个居民电力墙电池来对电网削峰平谷。先看看需求：这是电网总负荷的图表，以兆瓦为单位。电网负荷随天气和季节的变化而变化。这是一个温暖夏日的典型负荷图。左边是午夜，最小负荷在凌晨4点左右，那时大多数人都在睡觉，然后高峰负荷是下午6点左右，那时很多人都在开空调或做饭。
高峰负荷非常昂贵，电网一年只需要满足几个小时的高峰负荷。要满足负荷高峰电网就得按最大容量冗余建设，这导致大量成本浪费，除了满足负荷峰值，冗余的容量没有得到充分利用。另一种选择是从另一个电源区引入电力（比如德州从相邻州买电）而这通常要付出很高的代价。
如果我们能抵消需求、使负荷曲线更均匀，电力就会更便宜，这就是我们的目标。我们想在电网负荷高峰的时候介入：让powerwall电力墙电池放电，在其他时候由业主自主使用我们不介入。当我们的虚拟电厂增长到上千个powerwall电力墙和数十兆瓦的功率时，我们很快就得到了一个教训，那就是在峰值后立即给电池充电又会导致我们自己的峰值，弄巧成拙。解决方案是：不仅要控制电池何时放电，还要控制电池何时充电，并在时间上平均分布充电、有序充电、延长总的充电时间。
这是我们希望达成的目标图（现场演示），这是中午，我们想要预测是否将会出现负荷峰值，出现的话就让电池放电，一旦决定了，我们只控制在特定的虚拟发电厂项目中注册的power walls电力墙。我们不会随意控制没有登记在这些项目中的电源墙，所以不是每个客户都有这个功能。
Percy讲过，电网不是设计用来和小体量的市场主体交互的，所以我们需要聚合：把所有power walls电力墙聚合起来成为一个整体，就像一个传统的大型汽轮机。为此我们做了层次化的聚合、表达为云上的虚拟资源，第一层是表示一个地点site的数字孪生表达，所以这是一个带有power wall电力墙的房子；第二层是电气拓扑组合比如一个变电站substation、或者是地理含义上的一个地市/县，第三层又可以是物理分组表达比如一个电力链接点、或者也可以是逻辑上的，就像带一个电池的或电池加太阳能的站点sites，根据类型不同以不同的方式控制或优化。
所有站点sites 一起构成上层VPP，这样我们就可以像查询一个power wall一样快速查询上千个powerwalls、并以聚合为单位进行全局优化（很明显这都是actor）。对外，VPP可以很直观的看做为一个整体，但是在内部有各种各样的安装方式和家庭负荷，一些家庭有一块电池、一些有两块三块、电池并不是全部充满电，一些可能有一半电或接近没电，这得看家用负荷情况、当天的时段、光伏产量以及使用方式。
在这些sites的通讯上也有不确定性，因为它们都是通过internet联通的，有一些可能临时离线，最后，还会有新的sites定期上线，这都需要管理起来。随着时间的推移，固件在整个机群和正在升级和替换的硬件方面的能力不统一。业务逻辑中的数据模型如何表达这些不确定性非常关键，我们希望的是能明确比如说有10兆瓦时megawatt-hours的可用能源，但只有95%的sites在线上报信息，只有服务端才能基于服务的本地上下文决策如何处理这些不确定性，我们处理这些不确定性的方式之一就是站点级抽象site-level abstraction. 即使站点是异构的，这个边缘计算平台也提供了站点级的遥测数据，如功率power、频率frequency和电压voltage，为我们提供了一致的抽象、一致的软件。
另一种处理这些不确定性的方式是在虚拟电厂中汇总遥测数据。人们不想面对怎么控制单个的 power wall电池这种问题，他们想/能操心的是为了削峰在下午5点到6点放电10兆瓦这种明确需求，这是一个非常困难的工程挑战，它结合了流式遥测和资产建模技术，为了在软件中为每个站点建模，也就是所谓的数字孪生，我们用actor来表示站点，actor会管理状态，比如来自电池的最新遥测值，actor会运行一个状态机，如果站点离线、遥测延迟，则相应更改其行为，同时它还为并发和计算提供了方便的模型。
程序员需要操心的是用actor为单个站点建模，Akka运行时会将其扩展到数千或数百万个站点，它们之间的交互都是一致的，而您不需要担心这个问题。特别是对于物联网来说，这是一个非常强大的抽象，我们基本上从不担心线程、锁或并发bug。更高级别的聚合也可以由单个actors表示，actors“自动”维护它们之间的关系，也就是所表达的物理/逻辑聚合之间的关系（数字孪生）。然后，通过近实时地向内存中的层次结构发送消息来聚合遥测数据，而在任何级别上聚合的实时程度实际上只是消息量和延迟之间的权衡（可控） Then the telemetry is aggregated by messaging up the hierarchy in-memory in near real-time, and how real-time the aggregate is at any level is really just a trade-off between messaging volume and latency.
我们可以查询层次当中的任意节点，得知任意一个点的聚合值、或者查询一个站点的最新遥测值、还可以在层次中从任意一个点开始向上向下导航、由一个运行在Akka cluster中的服务执行这种实时分层聚合，Akka cluster支持一组不同角色的pods彼此透明通讯、第一组是线性伸缩pods、它从Kafka流式读取数据，基于Akka Streams的反压、有界资源约束进行低延迟流式数据处理、之后会与另一组运行所有上述数字孪生虚拟表达actors 的pods进行消息通讯，流式处理从Kafka读取到一个站点site的消息时、它们会基于site ID将消息转发给表达该site 的actor ，它们不必关心这个actor在集群的确切位置，Akka运行时透明处理消息投递，这就叫位置透明location transparency. 这个site actors用同样方式与上级父actors通讯，整个聚合层次都是如此。
还有一组API pods内存聚合服务负责在site站点级别保存客户端请求或聚合遥测，因为它们可以位置透明滴自由查询集群，这就是整个服务组合，这个组合为上千个power walls提供内存化in-memory、准实时的遥测聚合。这是一种架构，提供了极佳灵活性的架构，特别是当与Kubernetes一起管理pod时，因为actor只是在计算机的这个基底上运行。它们是在堆上运行的。
单个pod失败或重新启动时在这个pod上的actors将简单地迁移到另一个pod上恢复，运行时处理这一切。程序员不需要操心。集群也可以伸展或缩小，actors将在集群之间自动再平衡。Actors可以使用Akka持久性自动恢复他们的状态。在本例中，我们实际上不需要使用Akka持久性，因为当电池的下一条消息在几秒钟后到达时，actor可以重新发现rediscover它的关系以及最新状态。
为了结束本节，在汇总了遥测技术以了解虚拟发电厂的可用容量之后，让我们看看电池实际上是如何被控制的。第一步是采取过去的测量，预测，并决定多少兆瓦的排放，如果我们将达到高峰。在高层次上，这个度量、预测、优化和控制的循环基本上是连续运行的。这个回路的控制部分是真正的闭环控制。
一旦确定了一个聚合控制设定值、我们就可以持续监控每个站点的离散遥测、观测站点的响应、为该站点调整设定值以使误差最小化、还可以观察这整个过程。Autobidder可以决策控制整个系统，从规模上看，这可能足以抵消新建一座天然气尖峰发电厂的需求。也可以根据目标决定控制层次结构的某一个子集。
我前面提到的控制服务通过查询资产管理服务动态地解析这个目标下的各个站点sites ，这是因为站点可以随时间变化：安装了新的站点（为新校区新增变电站）、虚拟层次结构也可能改变、单个站点的属性也可能会改变，比如你添加了第二个电池。控制服务在每个站点查询电池遥测，可能有上千个站点使用内存聚合服务来决策如何让每个站点的电池放电。给快没电的电池放电是没有意义的，您可以将其看作有点类似于数据库查询计划 database query planner，基本上是尝试计划执行。
然后，控制服务向每个站点site发送一条带有放电设定值和时间段的消息，这条消息必须要得到ack/acknowledgment（它将不断地重试，直到获得站点的ack、或者超时）。因为这些电池的逻辑聚合非常庞大，我们使用Akka Streams在这些巨大的集合上处理流式数据以保持资源约束，包括：解析站点sites、读取所有的遥测数据、发送所有的控制设定。
大规模的聚合系统需要与各种不同APIs和数据处理模式交互，不要妄想可以继续开发傻瓜crud微服务就能解决，那样其实你没有做任何有效工作（比如认为VPP+电力市场只是个toB接单平台或者竞价排名论坛、调度交易撮合）。你需要流式语义来处理海量数据，还得做到低延迟、资源限制（准实时流式处理海量数据），这只是个开始，真正需要的是支持对有状态实体建模的运行时平台，它支持位置透明location transparency、并发concurrency、伸缩性scaling和弹性resilience.不确定性是分布式物联网系统固有的，因此我们需要在数据模型、业务逻辑甚至客户体验中接受它，而不是试图逃避它。物联网设备之间的物理和虚拟关系的表达，尤其是它们还会随时间变化，是物联网中最困难的问题，相信我，但也是创建伟大产品的关键。
基于一个全局大目标的直接控制没有考虑本地需求，这会导致矛盾，比如一场风暴正在接近，全局大目标是让电池放电以避免高峰，但是房主想要一个充满的电池以防停电。这就引出了我们演示的最后一部分：联合优化的虚拟电厂co-optimized virtual power plant.
Market-Participation Virtual Power Plant 虚拟电厂参与电力市场
Link：回顾一下，到目前为止，我们已经建立了一个基础平台，首先，优化单个大电池，以参与电力市场，然后聚集、优化和控制数千个电池，以达到一个全局大目标。在最后一部分，就像Colin说的，再次聚集、优化和控制数千个电池，但这一次不仅仅是为了一个全局大目标，我们要协同优化本地和全局目标。
Colin演示的削峰平谷虚拟电厂以一个全局大目标为优化方向，并将控制决策向下传递到站点，而市场虚拟电厂将优化本身分配到云中的站点。在这种情况下，这些站点实际上参与了控制决策。这种分布式优化之所以成为可能，是因为特斯拉建立了自己的硬件，并完全控制固件和软件。这使得本地和中心的程序以及它们之间的相互关系能够快速迭代，而且这种协作是跨团队的，而不是跨公司的。
我们说这个虚拟发电厂能协同优化局部和全局目标，这是什么意思呢？让我们以一个非虚拟的发电家庭为例：一个拥有太阳能发电的家庭，使用了power wall电力墙家庭电池，电力墙可以在太阳能发电过剩时充电，在高负荷时放电。这要归功于设备上的本地程序，目的是要么使客户的账单最小化，要么使他们自己使用的太阳能产量最大化。这就是局部优化。
协同优化本地和全局目标又是什么样的呢？一种方式是，局部优化可以考虑进来全局目标的信息，如市场电价（这是电网为了实时平衡全局目标而报的市场价格）。在这个例子中，负电价出现在夜里，也许是风电过剩造成的、可能会让电池提前充电。而下午的高电价可能是意料之外的用电高峰造成、它会要求电池放电，而不是按以往的节奏等到晚上。要注意的是，这一切都得遵守关于向电网馈电的当地规定。
在协同优化虚拟电厂中，Autobidder每15分钟生成一个价格预测时间序列，特斯拉能源平台控制组件将这些预测分发到站点。然后局部优化开始运行、在给定的局部和全局目标的情况下为电池制定计划。然后站点将这些计划反馈给特斯拉能源平台，平台接收、聚集计划（类似接收聚集遥测），然后Autobidder自动投标机器人使用这些汇总的计划来决定如何投标。
这种分布式算法有两个很大的优点。一个是伸缩性。我们在这里利用了边缘计算能力，我们并没有解决跨整个站点的一个巨大的优化问题，所以随着更多的站点加入聚合，我们不必担心我们的优化中心会失效。另一个巨大的好处是应对不可避免的通讯时断时续的弹性，当站点短时或较长时间掉线时，它们仍然持有全局价格时序数据最后一个版本、它们仍然可以基于最接近的全局目标继续参与协同优化，然后，如果站点离线时间超过了价格时间序列的长度，它们就会恢复到纯粹的局部优化。在连接服务降级情况下，这是合理的行为，它仍在为本地站点创造价值。然后，从服务的另一个角度来看，遥测聚合对下线的站点开箱即用。如果站点在一定时间内没有报告信号，它们将被聚合排除掉（聚合判断其下线）。然后Autobidder自动投标机器人可以保守地出价（假定离线站点无法参与市场投标）
特斯拉独特的垂直硬件、固件和软件集成使这种分布式算法成为可能。垂直集成使我们能够构建更好的整体解决方案。这种分布式算法使虚拟电厂更有弹性。在分布式系统不可避免的通信故障中，设备仍能够以合理的方式运行。
这种算法之所以成为可能，是因为特斯拉能源平台的高质量和扩展性，拥抱不确定性和真实模型。同时，该算法对软件平台也有一定的帮助。算法提高了产品的整体价值。在构建特斯拉能源虚拟发电厂的过程中，我们发现，虽然算法显然对虚拟发电厂的成功很重要，但整个系统的架构和可靠性是解决方案的关键。
Breck：这个系统允许我们提供前所未有的可靠绿电。
Link：为电网平衡可再生能源。
Breck：在寒潮风暴灾难情况下提供灵活的能源方案。
Link：高度集成的产品和服务给予用户超级体验。