成到高层企业系统中。 针对现有专用实时网络成本高、协 议 多 样、互 联 互 操 作性有限的问题，本文采用一种基于 ＳＯＡ 的面向自动化领 域的开放控制系统架构，提 供 设 备 “即 插 即 用”机 制，支 持系统的动态可 重 构 性；考虑工业自动化系统对实时性的 要求以及设备的计算和存储资源限制，在 满 足 开 放 性、通 用性的同时，从架构精简和消息压缩两个方面降低设备的 计算和存储负担，减少网络传输流量，提高系统的实时性。 １ 基于ＳＯＡ和智能设备的工业控制系统架构 车间现场中包括各种智能设备：ＲＦＩＤ 阅 读 器、传 感 器、ＰＬＣ等。所有设备通过适用于工业控制现场的以太网 络连接在一起。考虑到现场设备间的通信所需的带宽不是 很大，通信距离 相 对 较 近，所以可以选择使用屏蔽双绞 线 的以太网作为通信网络。 本系统基于 ＳＯＡ 架 构，提供服务和设备的动态发现、 即插即用功 能。系统分为设备层、中 间 件 层、车 间 服 务 管 理平台、上层应用层。总体架构如图１所示。 图１ 系统架构 设备层：包括各种车间现场设备，如 ＲＦＩＤ、传 感 器、 ＰＬＣ、机器人 等。每个设备使用嵌入式的设备级 ＳＯＡ 架 构，实现对设备动态发现和查找的支持；设 备 功 能 封 装 成 服务，对外提供服务接口，可以被其它服务调用。 中间件层：向上提供统一的服务接 口；为 应 用 层 提 供 面向服务的网络功能；实现各类控制信息的上传与下达。 车间服务管理 平 台：管理车间的设备和设备提供的服 务，完成车间 级 的 设 备 注 册、服 务 注 册、服 务 发 现、服 务 组合、服务调用、服务监控及事件管理等功能。 上层应用：ＭＥＳ、ＥＲＰ等上层应用系统可以通过设备 提供的服务接口直接访问设备和服务，也可以通过车间服 务管理平台查找和调用设备和服务。 ２ 基于ＳＯＡ和智能设备的工业控制系统模块设计 ２．１ 设备框架设计 设备提供 的 功 能 封 装 成 服 务，对外只发布服务接口。 每个设备可以有一至多个功能服务。当设备进入系统或者 设备增加新的功 能 服 务 时，系统能自动发现新的设备与服 务，新增的设备与服务也能与其它设备和服务进行交互， 这个过程系统能 够 自 动 完 成，不对环境和用户造成干扰与 影响。这要求设备必须满足以下几点要求：①能 够 使 用 网 络级的发现机制自动向注册中心公布服务，不需人工干预； ②注册时，设备只提供少量信息；③支持服务的动态查询； ④消息格式易于解析和存储。 目前能用于支持设备动态加入和发现的服务发现协议 及中间件技术有 ＤＰＷＳ［１１］、Ｊｉｎｉ［１２］、ＵＰｎＰ［１３］等。Ｊｉｎｉ技 术 是基于Ｊａｖａ语言的，需要Ｊａｖａ虚拟机的支持，故对于计算 能力和资源有限的设备来说不是优先选择的方案；ＵＰｎＰ 较适用于小型的家庭网络；Ｊｉｎｉ与 ＵＰｎＰ都是使用广播机制 进行服务的广 告 和 查 找，故对网络流量影响较大，相 对 而 言使用组播方式的 ＤＰＷＳ对网络流量的影响较小。但 已 有 的研究证明，ＤＰＷＳ用于高资源设备 （如 ＰＣ）时，性 能 很 好，但用于低资源 设 备 （如 ＰＬＣ）时，速 度 过 慢，因 为 其 技术开销和网络流量仍然较大［１０］。 本系统采 用 的 设 备 框 架 如 图 ２ 所 示，由 两 部 分 组 成： 服务和中间件层。每个 网 络 节 点 （设 备）上部署一个中间 件层，使设备具有即插即用网络功能。中间件层屏蔽了 底 层设备的异构性，服务提供者只需定义服务接口以及实现 服务功能，而服务调用者只需在客户端 （如 控 制 端）调 用 服务，两者都不必考虑消息传输和转换等底层的消息机制。 图２ 设备框架 · ２６５ · 第３３卷 第２期 武善玉，张平，李方：基于ＳＯＡ 的机器人物流系统架构研究 中间件层包括存储模块、发 现 模 块、事 件 处 理 模 块、 消息引擎等几个模块。 设备服务：封装设备提供的功能。每个设备可以有一 至多个功能服务。 存储模块：保存设备描述和服务信 息，为 设 备 与 设 备 或设备与其它应用系统之间的交互提供数据支持。信 息 库 采用树型结构 组 织 管 理。当设备需要增减功能服务时，存 储模块能相应地更新现有服务的集合。此 外，本 模 块 还 提 供基本的服务管理功能，如启动、停止等。 发现模块：发 现 机 制 参 考 ＷＳ－Ｄｉｓｃｏｖｅｒｙ标 准［１４］实 现。 设备接入网络 后，发现模块向网络公布它的信息，具 体 过 程是：将设备包含的服务信息通过组播方式发送出去。客 户端收到这个消息时，将该消息存储在其远程服务缓存中， 作为端对端控制该设备的信息基础。当设备要从网络中卸 载时，发现模块以组播方式发送一个消息，客 户 端 收 到 该 消息，将远程服务缓存中存储的该设备消息删除。新 接 入 网络的设备，也可以通过自身的发现模块向网络组播发送 查找消息，寻找它需要的设备。其它设备接收到查询请 求 后，验证是否与自身匹配，如果匹配则单播回发匹配消息。 但是在网络环 境 中，可能有数量较多的设备或服务满 足条件，因此会同时产生很多匹配响应消息，导 致 客 户 端 消息缓冲区突然收到大量的匹配响应而造成溢出。因 此 需 要对这种服务发现算法进行改进。针 对 这 个 问 题，在 查 询 请求中规定一个最大响应延时 Ｘ，匹配的设备需要在最大 响应 延 时 区 间 ［０，Ｘ］内随机选择一个 发送延时发送响 应消息。 事件处理 模 块：参 考 ＷＳ－Ｅｖｅｎｔｉｎｇ［１５］标 准 的 事 件 处 理 机制。设备间 通 过 “发 布／订 阅”的事件机制进行异步通 信。网络中的设备可以向感兴趣的设备订阅事件，得 到 被 订阅设备的响应 后，被订阅设备在工作过程中状态发生变 化时 （典型的变化如出现系统错误等异常），会向已经订阅 的设备发送相应的事件通知消息。接收到事件通知消息的 设备将根据消息包含的信息和数据决定下一步的动作。 服务调用模 块：与 服 务 发 现、存储和事件管理模块交 互完成服务的执行。 消息处理模 块：是中间件层的主要功能模块。包 括 消 息解析器和消 息 队 列。在 中 间 件 层，消息的交互通过服 务 调用的方式来触 发：中间件层负责将服务调用映射成发送 出去的消息、将接收到的消息映射成实际的服务操作。本 系统中，设备中的消息格式采用压缩的 ＸＭＬ格式，在保留 ＸＭＬ易读优点的基础 上，压 缩 ＸＭＬ 消 息，降 低 设 备 的 存 储负担和网络传输流量 （如图３所示）。 接口：设备 提 供 两 类 接 口。接 口 １使 用 ＨＴＴＰ 协 议， 基于 ＴＣＰ传输；接 口２使 用 ＵＤＰ 传 输，只用于服务发现 过程，即服务发现过程的消息传输使用 ＵＤＰ协议。 图３ 消息处理模块 ２．２ 车间服务管理平台设计 车间服务管理平台的主要作用是实现车间级服务发 现； 维护和管理车间设备及其服务信息，作为上层应用发现车间 设备和服务的信息基础；实现服务组合功能；上层应用系统 可以通过服务管理平台实现对服务的调用 （如图４所示）。 图４ 服务管理平台结构 基本服务管 理 模 块：按 照 与２．１节 的 “发 现 模 块”相 同的发现机制实现车间级的服务发现，所有已发现的设备 及其包含的服务集中存储在设备管理子模块，此 外 设 备 的 当前状态信息也存储在设备管理子模块。 服务组合模 块：执行服务组合描述，实现将设备提供 的功能服务组合成为更复杂的服务，或将不同设备组合成 为复杂 “机 器”。也可将不同层次的服务组合成一个 “流 程服务”。 消息转换模块：本系统设备层消息格式是使用压缩的 ＸＭＬ消息，而上层应用 系 统 中 往 往 是 使 用 ＸＭＬ 格 式 的 消 息，故在服务管理平台中设置消息转换模块实现二者的转 换。由于车间级流动的消息都是压缩的 ＸＭＬ格式，故对实 时性要求较高的车间层的网络流量将大大降低。消 息 流 类 型分布参考图１ （ｂ）。 服务调用模块：完 成 服 务 调 用，同 时，设 置 缓 存，支 持异步的服务调用。