当前位置:首页 > 最新资讯 > 行业资讯

如何将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

猜你喜欢