如何将Kafka用于工业物联网状态监测和预测性维护译文
过去，在大家的眼中，制造业往往只是与设备以及硬件有关。如今，软件和服务已经从制造业的成本中心，变成了利润创造中心。一种名为设备即服务(Equipment-as-a-Service，EaaS)模式能够通过诸如Apache Kafka等事件流平台，提供的可靠且可扩展的实时数据处理服务，进而实现地将维护工作外包给了服务供应商。
下面，我将和您探讨那些用于状态监测和预测性维护的物联网软件，是如何协助构建新的产品，并改善设备综合效率是(Overall Equipment Effectiveness，OEE)的。
首先让我们来看看状态监测和预测性维护这两个术语。由于尚无标准定义，因此一些文献会将状态监测视为预测性维护的一个主要组成部分。当然，也有将后者解释为能够利用机器学习的现代化软件。更有甚者，会将这两个术语视为同义。
现代化维护的策略和目标
现代化维护的策略与目标主要着眼于更加有效地、更优化地利用资源。而这些往往是建立在基于状态的维护策略之上的。那么，工业物联网/工业 4.0到底能够在车间层面上实现并带来哪些优势呢?
以维护替代修理
缩减计划外的停机时间
通过优化，去除不必要的维护工作
减少负面的财务影响
优化生产力
提高设备综合效率(OEE)
从孤立的视角上升到整个企业的视角
与此同时，设备的操作员则会关注如下方面：
通过检测异常和分类错误，来判断设备运行正常吗?
通过剩余使用寿命(Remaining useful life，RUL)和首次故障时间，来判断设备还能运转多久?
通过传感器监控和根本原因分析，来判断设备运行正常吗?
状态监测和预测性维护的本质
状态监测是指监测设备的振动、温度等状态参数，以识别指定检查指标在故障中显着变化的过程。它是预测性维护的重要组成部分。我们可以通过状态监测来安排维护，或采取其他行动，以防止故障产生危害。也就是说，状态监测可以在被检测项发展成为重大故障之前，及时或预先提供相关信息。
而预测性维护技术将有助于识别在役设备的状况，以估计何时需要实施维护。它有效地方便了运维人员对设备实施纠正性维护，进而防止了设备发生意外故障。此外，由于维护任务是按需触发的，因此预测性维护会比常规方式更节省成本。
当然，只有保证基础架构和软件的可靠性、可扩展性、以及实时性的基础上，状态监控和预测性维护才能很好地发挥作用。这通常源于合理的、基于总体拥有成本(TCO)和投资回报(ROI)的成本风险分析与投入。
设备即服务(EaaS)是新的商业模式
作为一种以服务为驱动的商业模式，设备即服务(EaaS)体现在向最终用户出租设备，并收取使用设备的定期费用上。该模式能够为双方提供如下好处：
EaaS提供商(如，OEM和设备制造企业)能够按需提高产品在研发、以及数字孪生(Digital Twins)等方面的设计，规划常规性的收入，以及提供预测性维护服务。
·客户(如制造型工厂)可以在EaaS软件的帮助下，优化设备的利用率和自身生产率，减少资本支出(CAPEX)、运营开支(OPEX)、以及运营成本等各类总体成本。
可以说，只有当状态监控和预测性维护能够7×24小时地、稳定且持续地收集、处理和分析传入的数据流时，EaaS才是一个成功的商业模式。
将Apache Kafka用于工业物联网/工业4.0
作为一种事实上的事件流的标准，Apache Kafka往往被全球工业物联网/工业4.0部署在他们的边缘和混合云环境中。下图展示了一个结合了公共云和边缘事件流的智能工厂架构模型：
由5G Kafka和AWS Wavelength实现的、低延迟的混合边缘云架构
在边缘处，Kafka虽然可以从具有操作技术(operational technology，OT)的设备上收集数据，但是它被普遍认为属于软实时(soft real-time)，且并不适合嵌入式系统设备。具体讨论请参见--《Apache Kafka不是硬实时，但在自动化和工业物联网中无处不在》一文。
尽管如此，Kafka仍然适用于关键任务型低延迟的用例。例如：端到端延迟为几毫秒的状态监控和预测性维护场景。下图是一个在5G环境中，Kubernetes利用Kafka和ksqlDB的示例：
基于Outposts和Confluent的AWS Wavelength低延迟5G用例
使用事件流和流处理的动态数据
状态监控和预测性维护需要基于事件的架构，来收集、处理和分析动态数据。传统的IIoT(Industrial Internet of Things，工业物联网)平台是专有的、不灵活的，无法扩展的，且不适合跨供应商与不同标准的集成。而Kafka的原生流处理是一种开放、灵活、可扩展的技术，并可用于实现跨物联网接口的数据集成。
针对上述矛盾，让我们看两个例子：一个是使用Kafka Streams进行无状态状态的监控，另一个是使用ksqlDB和TensorFlow进行预测性维护。需要明确的是：这些只是示例而已，其中的集成库可以被任何其他技术所替代。例如，用于流处理的Apache Flink、基于云端的ML(机器学习)平台、以及用于“最后一公里”集成的专有物联网边缘平台等。以下便是使用Kafka构建状态监控和预测性维护的基本设置：
来自设备PLC的传感器事件--Scada IoT
在上图的左侧，我们可以看到由存储和转发事件所产生的Kafka日志。而在右侧，各种设备会实时地捕获传感器上的数据。该架构可在任何规模的环境中实时运行。例如，某些Confluent客户会利用Confluent Cloud进行每秒10GB或更多的数据处理。
设备、PLC(可编程逻辑控制器)、以及传感器等之间的物联网集成，是通过Kafka Connect或其他API实现的，同时可以用到MQTT、OPC-UA、REST/HTTP、文件、以及不同的开放或专有接口。如果您对此感兴趣，可以参考《用于工业物联网集成的Kafka和PLC4x》和《Kafka即现代数据历史学家》两篇文章。
使用Kafka Streams进行无状态监控
下图显示了如何实时地去分析在温度峰值的Kafka原生状态监控：
使用Kafka Streams进行无状态监控
该示例是使用Kafka Streams实现的。这是一个基于Java的库，可以被嵌入到任何应用程序中。业务逻辑在实时处理大数据的同时，能够持续监控传感器的数据。其中，只有显示温度峰值超过100度的相关事件，才会被转发到另一个Kafka主题(topic)处。而任何对此感兴趣的消费者(consumers，如实时警报系统或批量报告)都会捕获到。
由于应用程序是无状态的，只能逐个处理事件，因此无状态监控能力，对于实现根据复杂的业务逻辑，过滤或转换流式ETL(Extract-Transform-Load)来说非常实用。
使用ksqlDB进行有状态的预测性维护
虽然无状态流处理已经很强大了，但有状态流处理(stateful stream processing)能够解决更多的业务问题。如下示例展示了Kafka原生的ksqlDB微服务，是如何实现有状态的流处理，以及持续检测异常的：
使用Kafka和ksqlDB进行有状态预测性维护
如上图所示，一个一小时的滑动窗口会不断汇总来自各个传感器的温度峰值。消费者会实时使用这些数据，去主动根据预定义的阈值采取行动。例如，数据科学团队可以通过分析历史数据，来确定平均超过100度的十多个温度峰值，是如何显著增加断电风险的，并据此实时地提醒设备操作员，按需进行维护。
使用Kafka和TensorFlow采取实时的机器学习
上述简单的业务逻辑，可以被用来改进OEE和维护流程。如果我们嵌入机器学习，则能够使状态监测和预测性维护达到更好的效果。通常，在不需要改变架构的情况下，分析模型可以像任何其他业务逻辑一样，被嵌入到Kafka的应用中。您可以通过查看如下链接，了解更多相关内容：
Kafka简介和用于模型训练与部署的机器学习
使用Kafka进行模型服务与评分的架构和权衡
使用Kafka原生模型部署的流式机器学习
使用Kafka、Streams、ksqlDB、TensorFlow、DL4J、H2O等代码示例
下图是一个带有ksqlDB和嵌入式TensorFlow模型的示例：
使用Kafka的KSQL和TensorFlow进行实时机器学习
如上图所示，一个ksqlDB类型的用户定义函数(user-defined function，UDF)被嵌入到了该模型中。该模型使用无监督式的自动化编码器，在Kafka应用程序中实时地进行异常检测。
这种架构智能地解决了数据科学团队和生产团队之间的错配问题。数据科学家可以使用Python和Jupyther notebook进行快速原型设计和模型开发;而生产团队则会在集群中部署ksqlDB的查询，以实现大规模的实时评分。您可以通过如下优秀的Github项目进行深入学习。该项目使用Kappa架构，实现了关注点的分离，可被用于互联汽车的基础架构，并使用MQTT和Kafka进行预测性维护：
带有Apache Kafka的MQTT Kubernetes和用于流式机器学习的Tensorflow Kappa架构
使用完全托管的Kafka式设备即服务
如下图所示，根据麦肯锡最近发布的一份行业趋势报告，制造型企业往往希望提供机械和设备即服务，并获得丰厚的利润：
麦肯锡关于设备即服务的报告
过去，在独自运维设备时，企业往往面临着“过晚的维护会导致无法修复，而过早的维护会拉高成本”的两难局面。如今，EaaS为客户担负了设备的运营与维修。设备供应商只需设定好一个最佳维护服务的提供方式，便可提供更好的客户体验。
目前，许多制造企业都会将Kafka和事件流，运行到他们的设备上，或连接到云服务中。许多现代化的IIoT服务也会利用完全托管、且真正无服务器的Kafka解决方案(如，Confluent Cloud)，让他们能够真正关注业务问题，而不必去操作事件流的基础架构。以下是一些与完全托管式Kafka相关的文章，其中不乏用于使用数字孪生来构建设备即服务的产品：
Kafka数字孪生用例
带有Kafka的数字孪生和数字线程式物联网架构
专注业务逻辑并使用托管事件流的无服务器Kafka
Apache Kafka的各种产品、供应商和云服务的比较
小结
上文展示了Kafka生态系统的事件流，如何为制造型企业提供新的设备即服务模式。其中，无状态和有状态的流式分析，能够实时地为大规模数据做出主动和预测性的决策。这种架构可以被用在一到多个云服务区域、数据中心的内部部署、以及外部边缘与混合架构的任意组合中。可以说，该方式将成为下一代物联网平台和设备服务事件流的主要处理方式。
译者介绍
陈 峻 （Julian Chen），51CTO社区编辑，具有十多年的IT项目实施经验，善于对内外部资源与风险实施管控，专注传播网络与信息安全知识与经验；持续以博文、专题和译文等形式，分享前沿技术与新知；经常以线上、线下等方式，开展信息安全类培训与授课。
原文标题：Kafka for Condition Monitoring and Predictive Maintenance in Industrial IoT，作者: Kai Wähner
图片使用申明：原创文章图片源自‘Canva可画’平台免费版权图片素材；引用文章源自引用平台文章中所使用的原图。