AWS 上的数字孪生：使用 L3 预测性数字孪生来预测“行为”

在上一篇博文中，我们讨论了数字孪生的定义和框架，这与我们的客户在其应用中使用数字孪生的方式一致。我们将数字孪生定义为“单个物理系统的动态数字表示，它通过数据进行动态更新以模仿物理系统的真实结构、状态和行为，从而加快获得业务成果。”此外，我们描述了一个四级数字孪生平衡指数（如下图所示），帮助客户了解他们的使用案例以及实现他们所寻求的商业价值所需的技术。

在本博文中，我们以电动汽车（EV，Electric Vehicle）为例来说明 L3 预测性级别如何预测物理系统的行为。示例使用案例将让您了解创建和支持 L3 预测数字孪生解决方案所需的数据、模型、技术、AWS 服务和业务流程。在之前的博文中，我们描述了 L1 描述性和 L2 信息性级别，在将来的博文中，我们将继续使用相同的 EV 示例来演示 L4 实时数字孪生。

L3 预测性数字孪生

L3 数字孪生专注于对物理系统的行为进行建模，在假设未来行为与过去相同的情况下，对持续运营下的未测量的数量或将来状态进行预测。这一假设对于短期展望是合理有效的。预测模型可以基于机器学习和/或基本原理（例如，物理模拟）。为了说明 L3 预测性数字孪生，我们将继续以 L1 描述性和 L2 信息性数字孪生博客中的电动汽车（EV，Electric Vehicle）为例，重点介绍三个使用案例：1/ 虚拟传感器；2/ 异常检测；以及 3/ 在非常短的时间内预测即将发生的故障。为了说明如何在 AWS 上实施，我们延伸了 L2 信息性博客中的 AWS IoT TwinMaker 示例，其中包含与这三项功能相关的组件。在接下来的章节中，我们将分别讨论这三项功能。

1.虚拟传感器

在我们的 EV 示例中，一个常见的挑战是根据电池的当前电荷状态（SoC，State of Charge）来估计车辆的剩余续航里程。对于驾驶员来说，这是一条非常重要的信息，因为如果 EV 受困，通常需要将它拖到最近的充电站。然而，预测剩余续航里程并非易事，因为它需要实施一个模型，该模型需要考虑电池的电荷状态、电池放电特性、对电池性能产生影响的环境温度，以及一些对预期的即将发生的驾驶情况的假设（例如，平坦或山区地形、被动或主动加速）。在我们的 L2 信息性博文中，我们非常粗略地计算了剩余续航里程，以便轻松将它硬编码到嵌入式控制器中。在下面的 L3 预测性示例中，我们将简单计算替换为 L1 描述性博文中的 AWS 合作伙伴 Maplesoft 提供的 EV 模拟的延伸。这一次，该模型纳入了一个虚拟传感器，该传感器根据上述关键输入因子来计算估计的续航里程。下面的 Grafana 控制面板中显示了基于虚拟传感器的车辆续航里程。

2.异常检测

对于工业设备，一个常见的使用案例是检测设备何时以非标称性能运行。通常，此类异常检测通过简单规则（例如，超出阈值，如温度超过 100°C）或更复杂的统计过程控制方法直接集成到控制系统中。这些类型的基于规则的方法将被纳入 L2 信息性使用案例中。实际上，在 EV 这样的复杂系统中检测非标称性能是一项具有挑战性的工作，因为单个组件的预期性能取决于整个系统的运行情况。例如，对于 EV 来说，硬加速过程中的电池放电比匀速行驶时要多得多。使用基于简单规则的电池放电率阈值是行不通的，因为系统会将每次硬加速视为电池异常事件。在过去的 15 年中，我们看到机器学习方法越来越多地用于异常检测，首先根据历史数据流描述正常行为，然后持续监控实时数据流的正常行为偏差。Amazon Lookout for Equipment 是一项托管式服务，它部署了监督式和非监督式机器学习方法来执行此类异常检测。下图显示了来自 Grafana 控制面板的屏幕截图，其中显示 Check Battery（检查电池）指示灯因检测到异常行为而亮起。

为了详细了解异常，我们在 AWS 管理控制台中检查了 Amazon Lookout for Equipment 的输出。控制面板显示了我们在检查时段内检测到的所有异常，包括导致 Check Battery（检查电池）指示灯呈红色亮起的异常。选择 Grafana 控制面板中显示的异常，我们可以看到在其中训练模型的四个传感器都显示了异常行为。Amazon Lookout for Equipment 控制面板以百分比形式显示每个传感器在检测此异常方面所做的相对贡献。电池电压和电池 SoC 的异常行为是这种异常的主要体现。

这与我们在合成数据集中引入异常并训练模型的方式是一致的。首先，我们使用了正常运行时段在所示的四个传感器上训练一个非监督式 Amazon Lookout for Equipment 模型。之后，我们在上面的 Amazon Lookout for Equipment 控制面板中显示的新数据集上评估了该模型，我们在该数据集上手动触发了故障。具体而言，我们在数据中引入了一个能量损失项，促使 SoC 下降得略快一些，这也会影响其他传感器。设计一个基于规则的系统来尽早发现这种异常以避免对汽车造成进一步损坏将是一项具有挑战的任务，尤其是在之前未观察到此类行为的情况下。不过，Amazon Lookout for Equipment 最初确实会检测到一些异常时段，并从某个时间点开始标记整个剩余时间内的异常。当然，每个传感器对异常检测所做的贡献也会显示在 Grafana 控制面板中。

3.故障预测

工业设备的另一个常见使用案例是预测部件的使用寿命终止，以便预先计划和安排维护。开发故障预测模型是一项非常具有挑战的任务，通常需要对特定设备在各种不同的操作条件下的故障模式进行自定义分析。在此使用案例中，AWS 提供了 Amazon SageMaker，它是一项完全托管式服务，可帮助训练、构建和部署机器学习模型。在下一节中，我们在讨论解决方案架构时将说明如何将 Amazon SageMaker 与 AWS IoT TwinMaker 集成。

在我们的示例中，我们创建了一个合成电池传感器数据集，该数据集已使用剩余使用寿命（RUL，Remaining Useful Life）手动标记。更具体地说，我们在合成电池模型中计算了一个能量损失项，以创建具有不同 RUL 的电池的数据集，并手动将较大的能量损失与较短的 RUL 关联起来。在现实生活中，工程师可以通过分析已达到使用寿命的电池的数据来创建此类带标记的数据集。我们使用了 XGBoost 算法，以 2 分钟批量传感器数据作为输入，对 RUL 进行预测。模型将派生自这些批量数据的特征作为输入。例如，我们使用滚动平均值对传感器数据进行了平滑处理，并比较了 2 分钟批处理开始和结束之间的传感器数据。请注意，通过使用滚动时段进行预测，我们能够以小于 2 分钟的粒度进行预测。在我们的示例中，电池的剩余使用寿命显示在控制面板中的 Check Battery（检查电池）符号下。这辆车的情况非常糟糕，预计电池即将发生故障！

4.架构

L3 预测性 DT 使用案例的解决方案架构基于为 L2 信息性 DT 开发的解决方案而构建，如下所示。架构的核心侧重于使用 AWS Lambda 函数来提取代表实际的电动汽车数据流的合成数据。使用 AWS IoT SiteWise 收集和存储车辆数据，包括车速、液位、电池温度、胎压、安全带和变速箱状态、电池电量和其他参数。历史维护数据和即将进行的计划维护活动在 AWS IoT Core 中生成并存储在 Amazon Timestream 中。AWS IoT TwinMaker 用于访问来自多个数据源的数据。存储在 AWS IoT SiteWise 中的时序数据可通过内置的 AWS IoT SiteWise 连接器进行访问，维护数据可通过 Timestream 的自定义数据连接器进行访问。

对于 L3 虚拟传感器应用程序，我们将核心架构扩展为使用 AWS Glue 以集成 Maplesoft EV 模型，方式是将 AWS IoT TwinMaker Flink 库用作 Amazon Kinesis Data Analytics 中的自定义连接器。对于异常检测，我们首先将传感器数据导出到 S3 来进行离线训练（图中未显示）。经过训练的模型通过 Amazon Lookout for Equipment 提供，以便通过调度程序对批量传感器数据进行预测。Lambda 函数为模型准备数据并处理其预测。之后，我们将这些预测反馈给 AWS IoT SiteWise，它们再经后者转发到 AWS IoT TwinMaker 并显示在 Grafana 控制面板中。为了进行故障预测，我们首先将传感器数据导出到 S3 进行训练，然后使用 Amazon SageMaker Ground Truth 进行标记。紧接着，我们使用 Amazon SageMaker 训练作业对模型进行了训练，并为生成的模型部署了推理端点。然后，我们将端点置于 Lambda 函数中，该函数由调度程序触发以进行批量推理。我们将生成的预测反馈给 AWS IoT SiteWise，它们再经后者转发到 AWS IoT TwinMaker 并显示在 Grafana 控制面板中。

5.实施 L3 数字孪生：数据、模型和关键挑战

在过去的 20 年中，使用机器学习、基于物理的模型和混合模型的预测性建模方法得到了改善，从而提高了预测的可靠性，使其更加有用。然而，我们的经验是，由于围绕将模型部署到业务使用的操作实践不够完善，因此，大多数预测工作仍会失败。

例如，对于虚拟传感器，关键任务是在集成的数据管道和建模工作流中开发和部署经过验证的模型。从云架构的角度来看，这些工作流易于实施，如上面的 EV 示例所示。更大的挑战是在操作方面。首先，为复杂的设备构建和验证虚拟传感器模型可能需要花费数年的时间。虚拟传感器通常用于传感器无法测量的熟练，因此根据定义，没有实际的验证数据。因此，验证通常是在研究实验室中进行的，使用一些非常昂贵的传感器在原型硬件上进行实验，或者对有限的验证数据进行目视检查以锚定模型。其次，一经部署，虚拟传感器仅在数据管道稳健并为模型提供所需数据的情况下工作。这听起来理所当然，但在操作上可能是一个挑战。实际传感器读数不佳、数据丢失、数据标记不正确、数据标记的站点间变化以及在检修过程中对控制系统标记所做的更改往往是导致虚拟传感器出错的原因。从根本上来说，确保高质量和一致的数据是一项业务运营挑战。企业必须为使用设备的技术人员制定标准、质量检查程序和培训计划。技术无法克服收集数据方面的不佳操作实践。

有了异常检测和故障预测，数据挑战就更大了。工程领导形成一种思维，确信自己的公司坐拥数据金矿，并想知道为什么他们的数据科学团队无法交付数据。实际上，这些数据管道确实很稳健，但它们是为完全不同的应用程序创建的。例如，用于监管或性能监控的数据管道不一定适合异常检测和故障预测。由于异常检测算法在数据中寻找模式，因此传感器读错、数据丢失和数据标记错误等问题可能会导致预测模型失效，但同样的数据对于其他使用案例来说是可以接受的。另一个常见的挑战是，被视为完全自动化的数据管道实际上并非如此。通常，需要人为判断的未记录的手动数据更正仅在工作流自动扩展且无法正常实施时才会被发现。最后，对于工业资产，故障预测模型依赖于人工收集的检测数据，因为它提供了对设备实际状况的最直接的观察结果。根据我们的经验，围绕收集、解释、存储和整合检测数据的操作流程不够稳健，无法支持故障模型。例如，我们发现检测数据在收集到几个月后才出现在系统中，而此时离设备出现故障的时间已经很久了。或者，检测数据由附在填写错误的检测数据记录上或与错误的设备相关联的手写注释构成。如果提供的数据不准确，即使是最出色的预测模型也会失败。

对于 L3 预测性数字孪生，我们鼓励客户开发和验证业务运营，以支持数字孪生的数据需求，就像工程团队自己构建数字孪生一样。拥有从数据收集到预测的端到端工作流思维模式，并根据预测采取行动是获得成功的关键。

总结

在本博文中，我们通过演练虚拟传感器、异常检测和故障预测的使用案例等描述了 L3 预测性级别。我们还讨论了在实施必要的业务流程以支持 L3 数字孪生的数据需求方面所面临的一些运营挑战。在上一篇博文中，我们描述了 L1 描述性和 L2 信息性级别。在后续博文中，我们会将 EV 使用案例延伸来演示 L4 实时数字孪生。在 AWS，我们很高兴能与客户一起开启数字孪生之旅，了解所有四个数字孪生级别，同时鼓励您在我们的网站上详细了解新的 AWS IoT TwinMaker 服务。

关于作者

Adam Rasheed 博士是 AWS 的自主计算部门的主管，他正在为自主系统的 HPC-ML 工作流开发新市场。他拥有超过 25 年的工业和数字领域中期技术开发经验，包括 10 年以上的航空、能源、石油和天然气和可再生能源行业的数字孪生开发经验。Rasheed博士在加州理工学院获得了博士学位，研究实验超高速空气热力学（轨道再入加热）。他被《麻省理工学院技术评论》杂志评为“世界 35 大创新人才”之一，并荣获了 AIAA Lawrence Sperry 奖，这是一项表彰在航空领域做出的早期贡献的行业奖项。他获得了 32 项以上的专利，并发表了 125 多篇技术出版物，涉及工业分析、运营优化、人工升力、脉冲爆炸、高超音速、冲击波诱导混合、太空医学和创新。

Seibou Gounteni 是 Amazon Web Services（AWS）的物联网专业解决方案架构师。他利用 AWS 平台功能的深度和广度，帮助客户构建、开发、运营可扩展且高度创新的解决方案，以交付可衡量的业务成果。Seibou 是一名仪表工程师，在不同行业的数字平台、智能制造、能源管理、工业自动化和 IT/OT 系统方面拥有 10 年以上的经验。

DavidSauerwein 博士是 AWS Professional Services 部门的数据科学家，他帮助客户在 AWS Cloud 上完成 AI/ML 之旅。David 专注于预测、数字孪生和量子计算。他获得了量子信息学博士学位。