基于实时仿真的分析服务
Erlangen-Nürnberg 大学的 Toni Donhauser在他最近发表的非常有趣的博士论文（德语）中给出了一个很好的例子，说明如何将与生产同步的数字孪生用于砌体工厂中基于仿真的自动化订单调度。作为核心的仿真功能允许初始化制造系统的在制品以精确反映当前状态并创建准确的短期预测，作为比较替代方案和优化生产计划的基础，以防万一意外的中断。Tecnomatix Plant Simulation (Siemens)用于实施仿真模型。
由于Plant Simulation以广泛的功能和高昂的许可费用而闻名，这篇博文将介绍这种与生产同步的数字孪生的替代实施方案，它基于开源框架并建立在易于操作、按使用付费的 AWS 基础设施上，可以使用Docker、Terraform和LocalStack在本地部署和测试完整的设置（无需 AWS 帐户）。
1、场景和范围
下图显示了一个虚构和简化的订单处理流程，并将作为一个最小示例来说明如何实施系统的数字孪生：
订单创建后将被公司接收并接受（ingest），并订购完成订单所需的原材料（order_material），让订单等待相应的材料到达（wait_for_material）。交付材料后，订单进入缓冲队列 ( wait_for_sop )，等待在产能受限的生产步骤中进行处理，该步骤一次只能处理一个订单。最终，完成的订单交付给客户并离开系统。
每当请求订单的材料时，都会分配一个初始的预计到达时间 (ETA)。但是，意外的供应商特定流程偏差或其他交付问题可能会在任何时间点引入延迟，因此在订单等待材料交付时可以进行 ETA 更新。由于生产步骤使用容量受限的资源并且代表系统可能的瓶颈，因此此处任何计划外的未充分利用都可能会延迟每个即将到来的订单并降低系统吞吐量（取决于时间表看起来有多紧）。因此，一旦发生订单的任何 ETA 更新，就希望能够量化任何时间变化的影响。
2、同步数字孪生：概念和实施
下图显示了一个简单的事件处理管道，能够摄取定义的事件并保持系统状态（event tracking），这反过来又支持基于仿真创建预期订单完成时间和延迟的预测（event analysis）。将使用一个简单的网络仪表板来可视化结果。
2.1 数据生产者发布事件
在生产系统中处理订单期间，数据生产者正在发布有关进度的信息，例如订单处理步骤的开始或结束。虽然这些事件实际上会在物理制造系统中发生，但可以使用仿真模型在开发过程中为数字孪生创建测试数据（有关此物流仿真用例的另一个示例，请参见Virtual Commissions上的这篇文章）。
2.2 使用 AWS Kinesis 捕获事件
Kinesis是一项 AWS 服务，用于连续缓冲和实时处理流数据。Kinesis 流将数据生产者和消费者分离，并由可配置数量的分片组成，每个分片每秒最多可以摄取 1 MB 或 1000 条数据记录。每条记录都根据其指定的分区键值放入一个分片中，这很重要，因为仅在分区键级别保证记录的有序处理。
在所描述的场景中，按订单处理对于 ETA 订单更新变得至关重要，因为在任何较早提交的更新之前不得处理预期延迟的消息。
2.3 使用 AWS Lambda 处理事件
Lambda是 AWS 的function-as-a-service产品，它允许按需运行代码，按调用次数和执行时间付费。Lambda 函数可以轻松地与 SQS 和 DynamoDB 等其他服务耦合。由于 AWS 按需配置函数运行时，NodeJS 和 Python 的较短冷启动时间使它们成为实现 lambdas 的流行选择。
为处理订单更新而实现的 lambda 很简单，只需使用作为调用的一部分提供的事件中的数据更新指定 DynamoDB 表中受影响订单的相应项目。
2.4 使用 DynamoDB 持久化系统状态
DynamoDB用作快速、灵活和托管的 NoSQL 数据库。虽然这种类型的数据库在设计上缺乏一些关系数据库的便利（例如在数据库级别强制执行引用完整性的适当方法，或者复杂的 ORM 和模式管理工具的可用性），但对于我们的简单用例来说刚好，因为仅涉及更新单个项目和基本查询。DynamoDB 需要一个分区键和一个可选的范围键，两者结合使用以唯一标识存储的项目。对于订单，字符串 id 可以用作分区键。DynamoDB 的一个不错的功能是启用流的选项，自动提供有关表更新的信息。这样，订单 ETA 更新可以触发新的预测。
2.5 仿真未来
AWS 允许将 Lambda 函数用作 DynamoDB 流事件消费者，因此仿真运行可以预测每次状态变化时的未来订单完成时间。对于每次运行，从 DynamoDB 获取当前系统状态（实际上可能需要多个请求，因为单次扫描只能返回最多 1 MB 数据的页面）。
根据注册的流程时间戳，可以识别每个订单当前相关的流程步骤。
仿真模型是使用Casymda从上面显示的流程图生成的。为了这个概念证明的简单性，假设处理时间是确定性的。实施模型块以考虑在制品的已经经过的处理时间- 模拟开始时的实体（初始化在线模拟模型的可能性之一，在Hanisch 和 Tolujew，2005 年经常被引用的论文中讨论，Hotz，2007年进一步探索）。在执行期间，以预测的流程步骤完成时间的形式收集预测指标。
目前，AWS 允许 Lambda 函数执行最多需要 15 分钟，因此即使是复杂的模型也可以以这种方式运行。但是，频繁且长时间运行的计算可能会使创建专用服务更具吸引力。
2.6 预测持久性和可视化
在每次运行结束时，收集的结果会保存在第二个 DynamoDB 表中，仪表板应用程序可以从中访问和可视化数据。
Plotly Dash是一个流行的分析网络应用程序框架。只需编写 Python 代码，即可快速创建动态仪表板。在底层，它使用Flask为React网站提供带有图表的浏览器。数据查询和分析使用 Python 在后端完成。实现的仪表板只包含一个简单的甘特图。使用间隔回调实现自动仪表板刷新-循环轮询数据库以获取更新。仪表板的 Docker 容器可以在 AWS 上运行（例如 ECS/Fargate，但由于 LocalStack 的免费版本不包含此功能，因此仅在本地运行以进行演示）。
3、本地运行
要从克隆的存储库中本地运行设置，需要安装 Docker 和 Terraform。
尽管性能无法与实际的云服务相媲美，但LocalStack是在本地模拟大量 AWS 服务（包括 Kinesis、Lambda 和 DynamoDB）的绝佳选择。LocalStack 可以在 Docker 容器中启动，根据需要生成更多容器，例如用于执行 Lambda：
docker-compose up localstack在部署 Lambda 函数之前，需要打包函数代码及其依赖项：
docker-compose up package-ingest-lambda package-simulation-lambda
Terraform是一个伟大而广泛的工具，它可以自动配置配置文件中描述的基础设施资源（但是，请查看本文以获得更细致的分析）。要创建所有必需的资源，需要在相应目录中使用两个 terraform 命令：
cd terraform
terraform init # (only required once)
terraform apply
# (enter 'yes' when prompted to confirm the changes,
# or use -auto-approve)
cd ../ # return to project root为防止没有调用过LocalStack重启后调用apply时出现404错误terraform destroy，请先删除main.tf旁边的文件terraform.tfstate。
创建成功后，可以再启动两个容器，一个服务于仪表板，一个运行仿真模型来模拟真实的事件生产者：
docker-compose up dashboard emulation在（重新）开始任何测试运行之前，需要清除 DynamoDB 表：
docker-compose up truncate-tableshttp://localhost:8050现在应该显示空仪表板，而http://localhost:5001应该显示 Casymda 网络画布动画控件。
4、示例流程
开始仿真时，订单将在源头创建并流经定义的流程。同时，仪表板应稍有延迟地更新，并可视化系统中当前存在的所有订单的相关流程步骤的完成时间（x 轴）（y 轴）。图表中的垂直线表示模拟运行开始并创建预测的时间点。
当Order-2的预期未来材料交付延迟发生（橙色）时，会产生一个有趣的情况：
由于生产步骤的产能限制（最多同时一个订单），Order-2的延迟（橙色）应该也会延迟Order-3（红色）的生产开始。
5、结束语
尽管给出的示例很简单，但可以想象到很多扩展。从业务的角度来看，检查一个更复杂的过程会很有趣，包括例如原材料库存和不同的补货策略。同样，可以评估随机或计划的机器维护间隔的影响。这也可能要求自动确定最佳决策备选方案，例如考虑特定订单的到期日期或吞吐量目标。有趣的技术扩展可能包括对摄取的事件数据进行初步分析，使用AWS Kinesis Data Analytics等流处理解决方案来识别相关模式并仅在出现关键流程偏差的情况下触发预测/优化运行。
原文链接：Real-Time Simulation-based Analytics Services
BimAnt翻译整理，转载请标明出处