1.2 设备状态监测与智能维护发展趋势

1.2.1 监控与数据采集系统

随着传感器的日益廉价和多样化，我们能获取的数据不仅在体量上不断增大，而且可以获取很多以前难以获得的信息。同时工业和生活的发展变化带来的新需求也不断驱动监控与数据采集系统的发展。总的来说，监控与数据采集系统正朝着开放和标准化的方向发展，同时随着通信、软件技术和计算机计算能力的提升，系统已经能够实现过往难以实现的远程、即时和大计算量的功能，因此监控与数据采集系统可以应用到港口、建筑和航空航天等各类工业场景以及交通和家居等生活场景。由于各个领域的需求不同，不同领域的监控与数据采集系统结构、特性和功能也不尽相同。从功能角度上看，监控与数据采集系统可以分为两大类：控制型和应用型。

控制型监控与数据采集系统：所谓控制型监控与数据采集系统，指的是系统是出于控制的目的而构建。比如典型的分布式控制系统（Distributed Control System, DCS）和工业监控与数据采集（Supervisory Control and Data Acquisi-tion, SCADA）系统都属于这一类。由于主要目的是控制，因此系统把稳定性、敏捷性和安全性放在首位。系统的数据采集主要是作为控制程序的输入，实现设备或过程的精准、快速控制，因此系统对数据传输的即时性要求极高，数据一般通过工业总线和以太网等稳定快速的媒介传输，通常大部分数据在设备端通过可编程逻辑控制器（Programmable Logic Controller, PLC）或工控机即时处理，远程监控中心只接收一些即时性要求不高的状态指示数据，起到对全局的监测作用。

应用型监控与数据采集系统：应用型监控与数据采集系统则是指系统出于除控制之外的其他功能和应用而构建的系统。比如汽车服务应用系统和互联网单车租借系统，以及近期比较热门的智能家居系统和车联网系统，都属于这一类。在工业领域，预测与健康管理系统（Prognosties and Health Management System，PHMS）也属于这一类。这类系统对数据传输和处理的即时性要求相对较低，而侧重于大数据量分析和相关功能应用的实现。比如汽车服务应用系统中的车况诊断、油耗分析和紧急求助等，预测与健康管理系统中的故障诊断和剩余寿命预测等。随着传感技术、通信技术的发展，应用型监控与数据采集系统的功能不断丰富，小到定位追踪的生活化应用，大到设备维护的工业化应用，应用型监控与数据采集系统都扮演着重要的角色。

控制型和应用型监控与数据采集系统的分类并非泾渭分明。实际上，大部分监控与数据采集系统都是两者的结合，这也是监控与数据采集系统的发展趋势。比如在工业监控与数据采集系统中，不仅有设备和生产过程的自动化控制，还有基于采集数据的设备状态监测和健康评估。在工业4.0的背景下，信息、物理系统的结合不仅加快了自动化控制的进程，同时大量获取的信息催生了丰富的功能和应用，两者的基础都是信息的获取。实际上，监控与数据采集系统正是信息化的产物，监控与数据采集系统的发展与信息化技术的发展紧密相关，到今天已经经历了三代。

第一代监控与数据采集系统起源于20世纪70年代，一般采用专用计算机和专用操作系统。如电力自动化研究院为华北电网开发的SD176系统以及日本日立公司为我国铁道电气化远动系统所设计的H-80M系统。

第二代监控与数据采集系统出现在20世纪90年代，开始基于通用计算机技术，广泛采用VAX机和PDP机，操作系统使用UNIX或类UNIX系统。因为计算机价格非常昂贵，所以一般采用集中控制，计算机用量少，同时由于技术复杂、系统不具有开放性，少有人熟悉，导致系统维护升级、设备改造更新、多系统网络互联、多系统信息交换都非常困难。

第三代监控与数据采集系统出现在20世纪90年代，其通信部分基于网络技术，管理部分结合数据库技术，控制系统采用通用微型计算机或单片机，网络协议开放，易于多系统之间互联，数据库可以帮助管理人员储存大量的数据，从而进行数据挖掘、运行分析等工作。采用通用微型计算机使系统价格急剧下降，为使用者节省了大量资金。系统维护简单，易于更换和升级，有利于系统长时间不间断运行。

当前，监控与数据采集系统正逐渐向第四代过渡。Internet、FCS、GSM、GPRS等网络技术的利用，GIS、GPS、面向对象技术、神经网络技术、专家系统的融入，Windows、Linux、RTOS等操作系统的使用，SQL、ODBC、OPC等标准的完善，都预示着第四代监控与数据采集系统将会更加适合社会需求，更加广泛应用于社会各个领域。可以说，监控与数据采集系统随着社会和工业的发展而发展，近期比较热门的全生命周期、大数据和数据挖掘等概念无不和它相关。

1.2.2 监控与数据采集系统和CBM系统

CBM（基于状态维护）是一种全新的设备维护模式，其核心思想是在有证据表明故障将要发生时才对设备进行维护。它通过对设备工作状态和工作环境的实时监测，借助人工智能等先进的计算方法，诊断和预测设备未来的有效工作周期，合理安排设备未来的维修调度时间。CBM是一种基于设备实际状态的智能维护方式，相比传统的事后维护（Breakdown Maintenance）和定期维护（Periodic Maintenance）更加合理和高效。

监控与数据采集系统在设备维护领域的应用正是CBM思想的体现。系统通过对设备或生产过程状态数据的采集，在监测端实现其远程监测和智能维护，这个过程就是CBM思想在监测与维护系统上的实践。因此监测与数据采集系统的设计与开发需要借鉴CBM思想和相关标准，特别是在工业领域，监控与数据采集系统可以说是CBM系统的类型之一。

CBM系统用来监测复杂系统的运行，并为现场操作人员提供系统目前健康状况的准确评估。如果可能，CBM系统还能预测系统或子系统的剩余寿命。剩余寿命是从设备目前状况到期望失效点的运行时间。失效标准必须根据运行环境定义，例如失稳点，性能、价格或者噪声水平的最低限。OSA-CBM包含了建立一个CBM系统所需的各个功能模块，并为状态监测的硬件要求，设备故障诊断、预测及维修决策方案的人机界面提供了一套规范。OSA-CBM将CBM系统分成七层不同的技术模块，分别为：数据采集模块（Data Acquisition）、数据处理模块（Data Maipulation）、状态监测模块（Condition Monitoring）、健康评估模块（Health Assessment）、预诊断模块（Prognostics）、决策支持模块（Decision Support）、表述模块（Presentation）。一个完整的CBM系统结构应当具有从数据采集到给出具体维修建议等一系列功能。CBM系统的主要功能包括：传感和数据获取、信号处理和特征提取、产生警告、失效或故障诊断和状态评估、预诊断（预测未来健康概况和估计剩余寿命）、辅助决策（维修建议或为特定现场运行准备的资产评估）、管理、控制数据流动与测试时序、对历史数据存储和存取管理、系统配置管理和人机系统界面。CBM系统的组成模块如图1-2所示。

OSA-CBM的体系结构将CBM系统分成具有不同功能的7个层次，定义了不同层次之间的数据接口和通信协议，保证CBM系统内部不同层次模块的互操作性和互换性。OSA-CBM定义的CBM框架和标准组件如图1-3所示，它们通过计算机网络技术及中间件技术松散结合在一起，构成开放式系统。OSA-CBM体系结构使用UML语言定义一个面向对象的系统模型并使用抽象接口描述语言AIDL（Abstract Interface Document Language）定义界面规范。AIDL语言是文本式语言，可以转换为用户选择的中间件接口描述语言，如DCOM MIDL、Web-based/XML、CORBA IDL等。由于表述模块通常用于显示和存取底层模块的数据，而并不为其他模块提供任何信息，OSA-CBM没有定义它的数据接口，而决策支持模块针对不同的故障和设备硬件提供不同处理机制和维护方法，其接口定义也没有规定。CBM系统被划分为相互独立的组件，这些组件就是各层的模块，各层模块可以独立设计开发，按照不同的需要灵活组合。CBM系统的层次结构划分也反映了系统数据流向，每个模块都应该能直接从其需要的层获取所需的数据，但总体上数据的流动还是按照相邻的层顺序流动，从传感器上采集数据，通过各个不同功能的中间层模块处理，传送到决策支持模块，确定设备的故障原因和维护时间。图1-3中的箭头方向描述了数据流向。

1.2.3 监控与数据采集系统和大数据

当今世界，数据无处不在，已经渗透到当今每一个行业和业务职能领域，成为重要的生产因素。监控与数据采集系统作为通过数据收集、处理和应用，来实现对象的监测、控制、分析等功能的系统，将与大数据技术、物联网技术、云计算技术密不可分地联系在一起。本小节主要针对大数据技术中分布式计算技术和流计算技术，展望未来监控与数据采集系统的发展。

1.2.3.1 大数据的内涵

什么是大数据？麦肯锡全球研究所给出的定义是：一种规模大到在获取、存储、管理、分析方面大大超出了传统数据库软件工具能力范围的数据集合，具有海量的数据规模、快速的数据流转、多样的数据类型和价值密度低四大特征。维克托·迈尔-舍恩伯格及肯尼斯·库克耶编写的《大数据时代》指出，大数据是指不用随机分析法这样的捷径，而采用所有数据的方法。

IBM首先提出了大数据的3V特点：Volume（大量）、Velocity（高速）、Variety（多样），随后又补充了Value（低价值密度）这个维度，在后续发展中又增添了Veracity（真实性），形成了所谓5V的大数据特征。但大数据的主要难点并不在于数据量大，因为通过对计算机系统的扩展可以在一定程度上缓解数据量大带来的挑战。其实，大数据真正难以对付的挑战来自于数据类型多样、要求及时响应和数据的不确定性。数据类型多样使得一个应用往往既要处理结构化数据，同时还要处理文本、视频、语音等非结构化数据，这对现有数据库系统来说难以应付；在快速响应方面，在许多应用中，时间就是利益；在不确定性方面，数据真伪难辨是大数据应用的最大挑战。追求高数据质量是对大数据的一项重要要求，最好的数据清理方法也难以消除某些数据固有的不可预测性。

大数据技术内容广泛，大规模并行处理（MPP）数据库、数据挖掘、分布式文件系统、分布式数据库、云计算平台、互联网和可扩展的存储系统等，均可视为大数据技术的一部分。

1.2.3.2 传统监控与数据采集系统的局限性

监控与数据采集系统大致分为三个过程：数据采集、数据存储、响应处理。以工程机械远程监控与数据采集系统解决方案为例，其主要采用GPS全球定位系统、3G/4G无线通信技术和GIS三种技术的组合。在机械设备机身上安装控制器或者是数据采集装置，控制器通过数据采集装置获取机械设备的状态信息，同时通过GPS接收地理位置，而后通过无线通信发送机械设备状态到监控中心，实现对工程机械设备的远程监控。

随着时代的发展，传统监控与数据采集系统面临着数据量大、数据多样化、数据快速化以及数据价值高、数据密度低的挑战。高频率的数据采集如位置信息、故障信息和工况信息，使得数据量上升到太字节（TB）甚至是拍字节（PB）级别。传统的单一数据库存储技术已经无法满足如此庞大的数据存储需求。同时包括设备位置信息、工况信息、故障信息、车辆熟悉、保养维修、人员管理、设计图样、视频和音频等多源异构数据带来了数据处理和存储的挑战。大量网页信息、图片信息等半结构化和非结构化数据挑战着数据处理和存储能力。对于实时性要求高的数据如故障信息等，需要快速的系统更新速度以及对用户查询的高速响应。另外，在大量繁杂数据如几个月的故障信息中找到有价值的数据，进行深度的数据挖掘，也是传统监控与数据采集系统难以胜任的。

1.2.3.3 大数据技术的优势

监控与数据采集系统面临大量的多源异构的数据采集。而大数据应用的第一步是多源异构大数据的感知、融合、表示。业界已经提出了一系列的抽取算法以应对大数据的异构性，针对大数据动态性和时效性的特点，工业界研究开发出许多成熟稳定的开源框架以应对海量动态数据的高效接入。在海量数据的存储方面，当前研究的热点主要集中在分布式文件存储系统、分布式键值对存储、分布式数据库存储方面。在2003年的学术会议上，谷歌发表了GFS分布式文件存储系统的相关文章，次年在OSDI会议上发表了Google的分布式计算框架MapReduce的论文，两年后在OSDI会议上发表了分布式数据库BigTable的文章。Google这三篇重量级论文的发表，极大地普及了分布式计算的核心技术并推动其发展，多种开源分布式计算产品相继出现并得以应用。其中以Ha-doop开源项目最为流行，形成了自己的生态圈。2010年Facebook推出了针对海量小文件的文件系统Haystack，类似的还有淘宝推出的文件系统TFS。键值对存储也是重要的存储系统，2007年Amazon提出的Dynamo是一个以键值为模式、去中心化的完全分布式存储系统。NOSQL数据库是另一种非常重要的分布式存储类型。开源界根据BigTable开发了基于HDFS和Zookeeper的分布式列示存储数据库Hbase。在海量数据分布式计算模型方面，Google研发了Ma-pReduce计算模型，适用于海量离线数据的批处理。鉴于MapReduce离线分析的局限性，Yahoo！和Twitter分别开发了流式数据处理框架S4和Storm来处理实时性比较强的业务。在海量数据分析方面，学术界研究出一系列针对海量数据的高数据分析速度和挖掘能力。另外，基于大规模分布式架构的中间件技术如分布式消息队列也被开发出来，如RabbitMQ、Kafka等，通过消息传递进行分布式系统的集成。随着需求的不断变化和研究的广泛与深入，分布式计算将产生更多激动人心的技术，这些技术将被逐渐应用到未来的监控与数据采集系统中。

1.2.3.4 典型的大数据监控与数据采集系统框架

基于大数据的监控与数据采集系统需要更好地解决大数据量、多源异构数据、数据实时性高、数据价值密度低的挑战，同时为数据的深入挖掘提供更为方便的计算处理平台。一种典型的系统框架如图1-4所示。

整体架构分为数据源采集、数据处理、应用开发三部分，其中数据处理包括实时数据处理分析、数据集成与批量数据分析以及元数据管理。大数据技术主要应用于实时数据处理、批量数据处理这两部分。

（1）实时数据处理 架构中的实时数据处理分析主要利用了大数据技术中的流计算技术。由于监控与数据采集系统面临的数据可能存在实时性强、价值密度不高、数据量庞大的特点，因此如何在数据的预处理过程中实现对数据的初步提取、清洗和存储就显得非常重要了。流计算技术正是为了解决这一问题应运而生的。

流数据处理方面的主流产品分为三个级别：

◇商业级：IBM InfoSphere Stream、IBM Stream Base。

◇开源流计算框架：Yahoo S4（Simple Scalable Streaming System）、Twitter Storm、Facebook Puma、Spark Streaming、Linkedin Samza。

◇公司基于自身需求开发：Facebook Puma、淘宝银河流数据处理平台、百度Destream。

其中国外的流数据处理主流产品是Yahoo S4、Twitter Storm、Facebook Puma、Spark Streaming。

Yahoo S4是一个面向在线数据流的通用的、可伸缩的实时处理框架。S4能够通过扩展廉价硬件的规模来构建一个高可用集群。并且它采用去中心的对等架构，不存在单点故障问题，同时使得S4的部署和维护变得更加方便。开发者能够通过S4提供的编程接口根据自己的业务处理逻辑开发实时数据处理任务，此外开发者可以自定义事件（Event）。在Yahoo S4中的处理单元是PE（Processing Elements），能够对特定的事件类型进行count、join等处理。S4的通信层是基于UDP实现的，能够进行可插拔。S4虽然具有可扩展性，但它不支持动态增删节点以及动态部署，并且它没有事件的可靠处理机制，所以可能会造成事件的丢失。此外，S4应用的并行处理取决于节点的数目，不能够进行调节。

Storm是一套分布式、可靠、可容错的用于处理流式数据的系统。其流式处理作业被分发至不同类型的组件，每个组件负责一项简单的、特定的处理任务。Storm集群的输入流由名为Spout的组件负责。Spout将数据传递给名为Bolt的组件，后者将以指定的方式处理这些数据，如持久化或者处理并转发给另外的Bolt。Storm集群可以看成一条由Bolt组件组成的链（称为一个Topology）。每个Bolt对Spout产生出来的数据做某种方式的处理。

Sparking Streaming是一个准实时的流式处理框架，属于BDAS（Berkeley Data Analytics Stack）软件栈中的实时数据流处理类型。BDAS是以Spark为基础的软件栈，包含了批处理、交互式查询以及实时数据流的处理三种类型，并且BDAS支持HDFS文件系统，能够运行在YARN之上进行分布式计算。其中，批处理主要是采用Spark实现的，Shark能够进行数据的SQL查询，Sparking Streaming则是只对在线数据流进行处理。Spark Streaming进行分布式计算时，会首先根据batch大小对输入数据进行秒级单位的分段操作，之后再对每个分段进行批处理操作，最后将计算结果进行存储。其中batch是以时间作为单位。Spark Streaming同Spark、Shark同属于一个软件栈，在不同应用场景下的数据能够共享，同时也降低了开发人员的学习成本。

Facebook Puma是一个数据流处理系统，一般与Facebook Data Freeway数据传输系统和HBase结合使用。Puma服务器也是采用了去中心化的对等架构，便于用户部署和维护。Puma工作时，PTail将数据流传递给Puma进行计算，再将计算结果存储在HBase中。

而国内的流数据处理主流产品有银河流数据处理平台、腾讯实时计算平台。银河流数据处理平台是通用的流数据实时计算系统，以实时数据产出的低延迟、高吞吐和复用性为初衷和设计目标，与S4很相似，采用Actor模型构建分布式流数据计算框架（底层基于Akka），功能易扩展，提供容错功能，而且对数据和运行状态可监控。银河流数据处理平台具有处理流数据和静态数据的能量，能够提供灵活的实时数据输出，并提供自定义的数据输出接口以便扩展实时计算能力。银河流数据处理平台目前主要是为淘宝数据魔方提供实时的交易、浏览和搜索日志等数据的实时计算和分析。

腾讯实时计算（Tencent Real-time Computing, TRC）平台是腾讯的数据平台部转为海量数据实时处理而构建的提供基础计算能力的服务平台。从全局流程的流数据实时计算体系的角度看，整个TRC由核心的平台支撑层和扩展的平台应用层构成。平台支撑层主要包括实时数据接入、实时数据处理、实时数据存储，平台应用层主要包括实时算法预测、实时模型训练、实时效果统计、实时系统监控、实时数据展示。当前，该平台每天支撑公司千亿次实时数据接入、万亿次实时计算、千亿次数据访问，业务应用包括广点通广告推荐、视频推荐、电商推荐、游戏道具推荐、微信实时多维分析以及微信系统实时监控等。

（2）批量数据处理 批量数据处理方面，Google研发了MapReduce计算模型，适用于海量离线数据的批处理大数据技术。由Google公司2003年研发的Google文件系统GFS和2004年研发的MapReduce编程模型以其Web环境下批量处理大规模海量数据的特有魅力，在学术界和工业界引起了很大反响。2006年Nutch项目子项目之一的Hadoop实现了两个强有力的开源产品HDFS和MapReduce。Hadoop成为典型的大数据批量处理架构，由HDFS负责静态数据的存储，并通过MapReduce将计算逻辑分配到各数据节点进行数据计算和价值发现。Hadoop顺应了现代主流IT公司的一致需求，之后以HDFS和Ma-pReduce为基础建立了很多项目，形成了Hadoop生态系统。Hadoop生态系统如图1-5所示。

Hadoop生态系统各组件作用如表1-1所示。

MapReduce采用无共享大规模集群系统。集群系统具有良好的性价比和可伸缩性，这一优势为MapReduce成为大规模海量数据平台的首选创造了条件。其次，MapReduce模型简单、易于理解、易于使用。它不仅用于处理大规模数据，而且能将很多繁琐的细节隐藏起来（比如，自动并行化、负载均衡和灾备管理等），极大地简化了程序员的开发工作。而且，大量数据处理问题，包括很多机器学习和数据挖掘算法，都可以通过MapReduce来实现。第三，虽然基本的MapReduce模型只提供一个过程性的编程接口，但在海量数据环境、需要保证可伸缩性的前提下，通过使用合适的查询优化和索引技术，MapReduce仍能够具有很好的数据处理性能。

大数据技术中的分布式存储技术可以解决监控与数据采集系统中庞大的数据量，分布式计算技术如批量处理系统MapReduce等可以解决监控与数据采集系统的数据批量处理问题，而流计算技术可以满足监控与数据采集系统的实时性要求。Hadoop等大数据处理平台同时为监控与数据采集系统提供了数据挖掘的平台，方便提升监控与数据采集系统的数据分析能力。

大数据技术不仅广泛应用于状态监测领域，也用于实时应用点击、物联网等新兴行业。利用大数据所构建的监控与数据采集系统将具有强大的高速数据处理及存储能力，具备深度数据挖掘的数据处理平台，利于实现整个制造业中各类设备的全生命周期管理与信息化、智能化施工的目标。