CN106656706A - 基于软件总线的面向服务的机器人开放式控制系统及方法 - Google Patents

Abstract

本发明提出基于软件总线的面向服务的机器人开放式控制系统及方法。系统包括：（1）面向服务的机器人开放式控制系统。控制系统的功能模块以服务的方式进行封装，使其能够被组合和应用，因而具有开放式、可扩展、服务松耦合等特点。（2）软件总线是整个分布式控制系统的核心组件，主要功能是为不同节点提供透明的传输机制，解除了用户与消息协议的耦合。（3）支持分布式控制系统的开发。通过传输层引入时间触发以太网(TTEthernet)，保证控制系统数据传输的实时性与确定性，并且通过负载均衡来减少总线节点热点访问问题。本发明提供一种用户对单个或多个机器人分布式控制系统进行开发的面向服务框架，在保证数据传输的实时性下提高控制系统的开发效率。

Description

基于软件总线的面向服务的机器人开放式控制系统及方法

技术领域

本发明涉及一种支持分布式机器人控制的开放式系统结构，具体涉及基于软件总线的面向服务的机器人开放式控制系统。

背景技术

机器人控制系统是机器人的核心，传统的机器人控制系统大多采用封闭式结构，这种结构的优点是结构简单，能实现高效的控制。但是，随着机器人技术的发展以及控制系统的整体复杂性提高，封闭式的控制系统的局限性日益显现。主要表现为：扩展性差，可移植性差，容错性差，难以维护和升级。由于存在以上的局限，开放式机器人控制系统是一种解决以上问题的可行方案。开放式控制机器人控制系统具有可扩展，可移植，服务化，可重用等特性，可以大大减低控制系统二次开发的成本和维护成本，具有很大的实用价值。

国内关于开放式控制系统的工作主要有，中国科学院自动化研究所的“开放式工业机器人视觉控制平台”（公开号：CN1417006）、深圳市中科睿成智能科技有限公司的“开放式机器人系统”（公开号：CN102431023A）。国外日本及欧美一些国家在相关领域开展大量工作，如NASA和NBS提出的NASREM机器人控制系统，日本AIST研究所开发的OpenRTM-aist机器人控制软件开发平台。国内外现有的开放式机器人控制系统，虽然已经取得了一系列的研究成果，但层次化的开放式控制系统仍存在组件耦合度高，不能实现组件的运行时配置等问题。

对于自动化控制领域的应用，系统功能的扩展导致带宽的需求越来越高，并且该领域的对系统的实时性与确定性有严格要求。因此，控制系统网络必须满足如下要求：1、提供高带宽2、控制的数据流必须具备实时性与确定性。针对以上要求，实时以太网成为一种新型的、有前景的候选技术。其中，以时间触发以太网（Time-Triggered Ethernet）技术为比较成熟一种。

发明内容

本发明的目的在于克服现有技术存在的上述补助，提供基于软件总线的面向服务的机器人开放式控制系统及方法。

本发明的目的至少通过如下技术方案之一实现。

基于软件总线的面向服务的机器人开放式控制系统，其按层次结构划分为五个层，分别是：应用服务层，总线消息层，服务总线代理层，传输层和总线管理层；其中，

应用服务由开发者根据统一的服务定义描述服务并实现服务功能，或者通过已有的服务组合而成；由于消息层对服务的消息进行封装，所以应用服务并不需要考虑通信细节，只需专注于服务的功能逻辑即可；

总线消息层为应用服务提供对外请求的消息作为接口，不同的消息对应不同处理逻辑；由于系统对传输的消息进行序列化进程，使得消息能够实现跨平台传输；

服务总线代理层作为应用服务层和传输层的中介，为总线提供了一层封装，主要功能是处理服务与软件总线之间的通信细节；

传输层的功能是实现应用服务与软件总线之间的消息传递，任务是保证消息可靠的，有序的，准确无误的和实时的在服务与软件总线之间进行传输；

总线管理层是控制系统的核心，系统中的各个服务通过软件总线进行连接并进行统一管理，服务之间的消息传递都需要经过软件总线进行转发和路由，并且处理服务组合、服务注册等重要逻辑。

进一步地，所述软件总线由以下部分组成：服务总线代理，总线节点，总线管理器和存储节点；为了实现控制系统中服务之间的松耦合关系，采用自定义消息，通过消息序列化技术使消息能够在服务和软件总线之间传递，能够提供跨平台、跨语言的消息传输机制，服务的开发无需关注如何与软件总线通信的细节。

进一步地，所述系统传输层中支持分布式控制系统的开发的方法，由于服务之间的松耦合关系，控制系统中服务可以部署在不同的物理节点上，提高了系统的灵活性；为确保系统能够满足机器人控制的实时性与确定性，在传输层上引入时间触发以太网来保证控制系统的实时性与确定性，对于实时性与确定性要求较高的服务使用时间触发流量传输数据，确保该服务的实时性与确定性；此外，为避免单一总线节点出现热点访问问题成为系统的瓶颈，通过分布式总线节点及总线节点的负载均衡来提高整个分布式控制系统的效率。

利用所述的控制系统的控制方法，其包括如下步骤：

S1、服务注册；

在本控制系统中，包含三个角色，分别是服务请求者，服务提供者和服务注册中心；服务请求者发送请求服务消息，通过查询服务注册中心，获取服务信息并绑定服务，再根据服务所提供的接口执行任务；服务提供者提供了服务的具体功能实现；通过注册操作在服务注册中心中发布服务的接口和描述信息，使得服务请求者可以查询和访问该服务；服务注册中心提供并维护了一个可用服务目录，允许服务请求者查找感兴趣的服务的接口；

S2、服务组合；

每次客户的请求都是以业务流程的形式进行请求，而业务流程可以分解为若干服务的有序组合；一个业务流程信息以有向无环图的形式表示，其中每个节点表示一个服务组件；此步骤是应用服务层为用户提供一个方便的接口来实现具体的任务要求；

S3、用户向软件总线请求相关服务或流程；

请求/应答模式是服务消息主要交换模式，用户以业务流程形式请求组合服务，在同一流程中，服务A需要服务B提供服务并返回应答消息，就此服务A需要通过总线消息层选择合适的消息，并通过服务总线代理向总线发送消息；

由于采用适应分布式总线节点的架构，因此在服务转发消息之前需要通过负载均衡模块来确定需要转发的总线节点；负载均衡首先根据消息的信息，通过负载均衡算法选定目标总线节点的节点号；服务总线代理层根据这个节点号查找服务的总线表，并将表中的信息填入消息中转发消息到对应的总线节点；

S4、软件总线的调度；

以系统丢包率和响应时间比的多目标函数作为测量标准，通过调节任务的优先级及传输周期对总线资源进行优化分配；调度主要涉及对传输的消息进行合理的调度，满足系统的实时性要求；调度方法主要在总线管理层里实施；

S5、软件总线的消息处理；

一个服务通过请求消息向其它服务发起请求；接收到相关请求消息的服务会做出应答，并发送一个或多个应答消息；发送请求消息的服务不需要知道目标服务的具体位置，只需按照预先定义好的消息协议向总线发送消息；

发送到软件总线的消息类型有：结果消息、状态消息、注册消息、请求消息和应答消息，此步骤主要在软件总线管理层中完成；

S6、被请求的服务的消息处理；

被请求的服务根据接收的信息提取相关的调用函数及调用参数，然后将调用参数传递给服务的内部函数进行调用，得到的处理结果通过服务总线代理API返回到软件总线上；

S7、软件总线处理返回消息；

软件总线接收到来自服务的结果消息，从消息的内容判断是单个服务请求结果还是业务流程中的一个中间结果；若是单个服务请求结果，直接将结果消息转发到请求服务上；若是业务流程的中间结果，则将中间结果转发到业务流程当中给的下一个服务当中。

与现有技术相比，本发明的优点和效果有：

本发明相对于已有的控制系统，具有兼容性，开发效率高，支持分布式控制系统的开发等优点。用户可以通过服务的添加、组合及替换来完成系统的升级和重新配置，并且用户只需要将精力集中在服务的功能构造上，降低了系统开发成本和提高系统开发效率。另外，服务可以部署在不同的物理节点上，通过时间触发以太网来确保实时服务数据传输的实时性与确定性，并且对于具有分布式总线节点的控制系统，提供了负载均衡功能来解决热点访问问题。

附图说明

图 1为分布式机器人控制系统结构。

图 2为控制系统层次结构。

图 3为软件总线的组成。

图 4为总线节点包含模块。

图 5为总线管理器示意图。

图 6为实施例基本控制流程图。

图 7为一种基于时间触发以太网的分布式控制系统拓扑结构。

图 8为服务的注册示意图。

图 9为服务流程的拓扑结构实例图。

图 10为配置服务组合流程图。

图 11为反馈调度模块框架图。

图 12为请求与应答的执行流程图。

具体实施方式

下面结合实例对本发明作进一步详细的描述，但本发明的实施方式不限于此。

本实例的基于软件总线的面向服务的机器人开放式控制系统，如图1所示，不同类型的机器人以及其它设备节点能够通过软件总线进行相互的消息通信。软件总线是整个分布式控制系统的核心组件，主要功能是为不同节点提供透明的传输机制，解除了用户与消息协议的耦合。本发明通过引入面向服务的软件架构，将传统机器人控制系统的功能服务化，通过提供服务注册、服务的组合及替换等功能，使得整个系统可以直接通过服务的新增及组合来大幅提高系统二次开发的效率，并且服务的替换能够为系统带来额外的冗余性。此外，针对分布式机器人控制系统的通信的实时性问题，本发明提出一种基于时间触发以太网的分布式机器人控制系统，保证控制系统的实时性及确定性。本发明主要内容包括：

1）面向服务的开放式控制系统体系层次模型

控制系统按层次结构划分为五个层次，分别是：应用服务层，总线消息层，服务总线代理层，传输层和总线管理层。下面将对每一层的功能进行介绍，如图 2所示。

应用服务层：应用服务层中的实体为服务，所有系统用户所需要的功能和资源都被封装成服务。应用服务层主要是面向开发者的一层，开发者只需按照服务的标准定义来生成服务配置文件即可。服务在启用前，必须首先向总线进行注册，以使总线获取服务的信息，并对系统中的所有服务进行统一管理。服务信息由用户在服务配置文件中进行设定，主要包含服务ID，服务名，服务描述，服务中提供的函数等信息。服务在启动时，首先从服务配置文件中读取服务配置信息，并将特定信息包含在注册请求中，提交给软件总线。当软件总线接收到服务的注册请求并对请求做出回应后，服务才能开始正常工作。

总线消息层：总线消息层是向应用服务层提供各种消息封装。应用服务根据自身需求，向总线发送特定的消息。分别有：注册消息、订阅消息、发布消息、状态消息和心跳消息等。

服务总线代理层：服务总线代理层作为应用服务层和传输层的中介，为总线提供了一层封装，主要功能是处理服务与软件总线之间的通信细节。在发送消息时，用户可以将封装好的消息通过API 传递给服务总线代理层，服务总线代理层将通过传输层最终将消息发送到软件总线上；服务总线代理层也从传输层获取软件总线转发过来的消息，并通过API传递给应用服务层。消息的序列化工作将由服务总线代理中的序列化模块完成，不再由用户负责，用户无需再了解消息协议的使用细节。对于具有分布式总线节点的控制系统，服务总线代理层向服务提供负载均衡功能，使服务的消息能够转发到合理的总线节点上。

传输层：传输层的功能是实现应用服务与软件总线之间的消息传递，任务是保证消息可靠的，有序的，准确无误的在服务与软件总线之间进行传输。另外，传输层也需保证消息能够实时地响应用户的实时应用。为了满足上述要求，本发明通过在传输层上支持时间触发以太网来保证整体系统的实时性能、可靠性与确定性。

总线管理层：总线管理层是控制系统的核心，系统中的各个服务通过软件总线进行连接并进行统一管理，服务之间的消息传递都需要经过软件总线进行转发和路由。

2）软件总线功能平台

软件总线由服务总线代理，总线节点，总线管理器和存储节点四部分组成，如图 3所示。下面分别介绍这几个组成部分。

服务总线代理：每一个应用服务都包含自己的服务总线代理，服务总线代理负责服务与总线的交互，包含服务接口模块，网络通信模块，请求管理模块等功能模块。服务接口模块包含总线 API 和消息序列化模块。总线 API 为总线提供了一层封装，是服务与总线交互的接口，服务通过总线 API 将自身产生的消息传递给总线，总线采用的消息协议和消息的传输方式等细节对服务用户而言是透明的；消息序列化模块根据总线的消息协议对总线 API 接收到的用户消息进行序列化，再由网络通信模块将消息传递给软件总线。请求管理模块，是负责本地服务之间消息传递的逻辑模块。对于实时性要求较高的流程，一般会将流程中包括的服务部署在本地节点。因此每当服务需要发送消息时，都先经过请求管理模块处理，若目标服务就在本地节点，就无需发送至总线上，直接到达本地服务。这样处理的既满足实时性较高的应用场景，也进一步减轻总线上的负载。网络通信模块主要负责服务与软件总线的通信细节，包括消息发送队列的管理，软件总线连接池的管理，网络 I/O模式，网络通信协议的选择等。负载均衡模块负责在总线代理发送消息之前选定某个总线节点。

总线节点：总线节点是整个总线架构的核心，主要负责流程消息的转发调度，以及流程和服务信息的管理。软件总线由一个或者多个总线节点组成。总线节点都包含请求管理模块，订阅发布管理模块，网络通信模块，实时调度模块，如图 4所示。请求管理模块是总线节点的核心，主要负责流程消息的转发和路由，从消息接收队列中获取服务消息，并根据消息的流程信息查找转发路由表，更新消息的目标服务，再将消息加入消息发送队列中。转发路由表是请求管理模块的重要组成部分，存储着系统中常用的流程信息，转发路由表的命中率对总线节点的性能有很大的影响。订阅发布管理模块负责服务或总线节点的消息订阅和消息发布。服务或总线可以通过订阅方式来接收某些类型的消息，同时地，能够提供这些类型消息的其他服务或总线会把这些消息发布到总线上。一般而言，服务或总线会通过订阅时所设置的参数来过滤消息。例如，总线之间通过发布自身的心跳消息，并订阅其它节点的心跳消息来互相传递各自的状态（如出错、超负载等），并由各自的总线管理器进行合理的处理。实时调度模块主要负责根据消息的优先级对消息接收队列和消息发送队列中的消息进行调度， 主要目的是提高总线的实时性，因为控制系统的实时性有着比较高的要求。网络通信模块主要负责总线节点与服务之间的通信细节管理，包括服务连接池的管理，网络 I/O 模式，服务消息的解析等。网络通信模块从服务获取消息，解析后放到消息接收队列中，当消息处理完毕后，再从消息发送队列中取出消息，封装后根据路由信息发送到目标服务。

总线管理器：总线管理器负责总线节点的管理，维护总线节点的状态。总线节点周期性地向总线管理器报告自身状态，超过一定期限没有发送状态的总线节点将被当作出现故障。服务总线代理周期性地向总线管理器获取总线节点状态，以更新自身的总线状态列表，如图 5所示。

存储节点：存储节点包括数据存储和流程管理两个模块。数据存储模块负责系统中服务信息和流程信息存储。总线节点在接收服务的注册请求时，需要将服务信息存储到数据存储模块中；当总线节点处理流程请求时，若出现转发路由表不命中的情况，需要从数据存储模块中获取对应的流程信息。流程管理模块主要负责系统中服务组合配置（流程配置）以及服务状态的管理。

3）分布式机器人控制系统开发框架

由于服务之间的松耦合关系，控制系统中服务可以部署在不同的物理节点上，提高了系统的灵活性。本发明提供了一种区别于传统机器人控制系统集中式控制的开发框架，由于面向服务的框架屏蔽了服务与总线之间的通信细节，因此只需要服务根据已定义的服务描述向软件总线注册，服务就能部署在不同的物理节点中，提高整个控制系统的灵活性。-

为保证整体系统分布式节点的数据传输实时性与确定性，本发明引入时间触发以太网来满足要求。时间触发以太网是基于时分复用(TDMA)的实时以太网之一,在所有节点通过时间同步算法维持一定的时钟精度下，保证时间触发流量能够严格按照时间调度表来进行消息的发送与接收。时间触发以太网定义了时间触发流量(TT traffic)、速率限制流量(RCtraffic)及尽力而为流量(BE traffic)来满足不同应用的流量需求。时间触发流量具有周期性特点及在每个周期有预先定义好的传输窗口，一个TT帧的发送从发送节点到接收节点的路径已经在预先定义好。因此，在TT帧的发送窗口的时间内，该TT帧便独占此时数据传输的链路。这样就确保了时间触发流量的低时延及低网络抖动。在时间触发以太网中，时间触发流量是最高优先级。速率流量控制流量，定义连续两个RC帧之间的最小传输时间间隔，来控制该RC流的速率。尽力而为流量利用之前两种流量剩余的带宽，处于最低优先级。

基于时间触发以太网的分布式机器人控制系统的一种拓扑结构如图 7所示，机器人节点及其他设备节点连接在TTEthernet交换机中，调度表存储在交换机和需要实时服务的节点当中，全局的时钟由高精度时钟及时钟同步算法维护。对于实时要求较高的服务，如机器人控制服务、基于传感器的碰撞检测服务等，可以在相应的节点上部署实时性最高的时间触发服务。该服务根据用户定义的调度表按照确定的时间发送数据到相应的节点，每个节点按照在预定义的时间窗口接收时间触发消息数据并转发，使在调度表定义的时间下，该服务可以独占链路的所有带宽。除了时间触发流量以外，还可以用速率限制流量来传输如监控视频流。一般来说，控制信号及传感器信号的周期固定，帧长较短，并且实时性要求最高，因此可用时间触发流来发送。而对于速率固定的实时性要求较高的应用，可用速率限制流来发送。其它非实时的业务用尽力而为流来传输数据。

此外，为避免单一总线节点出现热点访问问题成为系统的瓶颈，本发明通过分布式总线节点及总线节点的负载均衡来提高整个分布式控制系统的效率。

本发明的控制系统的功能模块以服务的方式进行封装，使其能够被组合和应用，因而具有开放式、可扩展、服务松耦合等特点。本发明机器人控制系统利用服务的松耦合性来实现机器人的控制，并且可以在一定程度上扩展控制系统，应对不同的任务环境。

以下进一步举例说明。

本实例应用于固高六自由度机器人(GRB3016型)的控制系统上，发明设计一种通用的开放式结构控制系统，如图 1所示，不同类型的机器人以及其它设备节点能够通过软件总线进行相互的消息通信，总体架构的分层结构如图 2所示。软件总线由服务总线代理，总线节点，总线管理器和存储节点四部分组成，如图 3所示。每一个应用服务都包含自己的服务总线代理，服务总线代理负责服务与总线的交互。总线节点是整个总线架构的核心，主要负责流程消息的转发调度，以及流程和服务信息的管理。软件总线由一个或者多个总线节点组成。总线节点都包含请求管理模块，订阅发布管理模块，网络通信模块，实时调度模块，如图 4所示。总线管理器负责总线节点的管理，维护总线节点的状态。总线节点周期性地向总线管理器报告自身状态，超过一定期限没有发送状态的总线节点将被当作出现故障。服务总线代理周期性地向总线管理器获取总线节点状态，以更新自身的总线状态列表，如图 5所示。本实例应用服务由：人机交互服务，轨迹规划服务，反解服务，机器人运动控制服务，正解服务，软件总线配置服务。服务部署在一台PC机上，软件总线部署在两台PC机上。

实施例的基本流程如图 6所示，人机交互服务为用户提供与机器人控制的接口，用户可以根据自己的需求来操作机器人。例如机器人示教过程或称自定义的组合服务。在此例用户在人机交互服务中导入示教文件，示教文件的坐标位置根据流程的信息转发到下一个服务，即轨迹规划服务中，在此例为直线插补服务。直线插补服务根据上一服务提供的位置信息，生成中间的轨迹，并将轨迹信息转发到下一个服务当中，即反解服务中。反解服务根据上一服务提供的中间轨迹，生成机器人六关节的角度数据，然后将此服务转发到机器人运动控制服务中，该服务负责机器人的运动控制。然后，运动控制服务将机器人反馈的关节信息生成机器人末端位姿并返回到机器人交互服务。其中，在整个流程的运作过程当中，软件总线配置服务都参与了其中，为各个服务提供总线必要的信息以及对服务发送到总线的消息进行转发等功能。在消息的转发过程中，请求消息、应答消息及心跳消息是以时间触发流量进行传输，服务的注册消息和状态消息等非实时消息以速率限制流量进行传输。为保证整体系统分布式节点的数据传输实时性与确定性，本发明引入时间触发以太网来满足要求。基于时间触发以太网的分布式机器人控制系统的一种拓扑结构如图 7所示，机器人节点及其他设备节点连接在TTEthernet交换机中，调度表存储在交换机和需要实时服务的节点当中，全局的时钟由高精度时钟及时钟同步算法维护。对于实时要求较高的服务，如机器人控制服务、基于传感器的碰撞检测服务等，可以在相应的节点上部署实时性最高的时间触发服务。该服务根据用户定义的调度表按照确定的时间发送数据到相应的节点，每个节点按照在预定义的时间窗口接收时间触发消息数据并转发，使在调度表定义的时间下，该服务可以独占链路的所有带宽。除了时间触发流量以外，还可以用速率限制流量来传输如监控视频流。一般来说，控制信号及传感器信号的周期固定，帧长较短，并且实时性要求最高，因此可用时间触发流来发送。而对于速率固定的实时性要求较高的应用，可用速率限制流来发送。其它非实时的业务用尽力而为流来传输数据。整个系统的时间调度表已根据需求离线生成，供控制系统的调用。本实例的控制基本流程包括以下步骤：

1、服务注册

在本控制系统中，包含三个角色，分别是服务请求者，服务提供者和服务注册中心。服务请求者发送请求服务消息，通过查询服务注册中心，获取服务信息并绑定服务，再根据服务所提供的接口执行任务。服务提供者提供了服务的具体功能实现。通过注册操作在服务注册中心中发布服务的接口和描述等信息，使得服务请求者可以查询和访问该服务。服务注册中心提供并维护了一个可用服务目录，允许服务请求者查找感兴趣的服务的接口。

在本系统当中，服务注册中心部署在总线节点上，服务提供者需要将服务描述的文件发布到总线上，总线在本地维护一个可用服务目录，供服务请求者查询使用。注册中心需要返回有关服务、服务的工作方式、所使用的参数及其返回值等信息。服务请求者根据这些信息，向总线节点发送调用的消息，进行服务的请求。总线节点需要检查当前注册服务是否为实时服务，若是实时服务，则需要根据实际更新时间调度表或者拒绝该服务注册。

服务在初始化时，需要完成服务的注册过程。向总线发送服务描述文件，里面包含了服务中可调用的接口、服务从属的机器人ID、服务的QoS等信息，过程如图 8所示。总线接收到这些初始化信息后，存储在总线节点的数据存储模块（数据库）中，方便以后查询。另外，总线为服务的分配ID并将ID及它的地址添加到路由表中。服务注册成功后，由总线返回一条注册成功的消息到服务上，这样就完成了服务的注册过程。在此之后，服务可以正常的向总线发送请求服务。

2.服务组合

在此，每次客户的请求都是以业务流程的形式进行请求，而业务流程可以分解为若干服务的有序组合。一个业务流程信息以有向无环图的形式表示。其中每个节点表示一个服务组件。图 9表示一个服务流程的结构实例，包括：流程的规模、每个节点的编号、每个节点所代表的服务ID。从图中可以看到，整个组合服务由4个服务组成，1号节点服务先启动，执行完毕后1号节点的结果会发送到总线上，总线根据流程的拓扑将结果转发到下一个服务节点上。依次执行，最后3号、4号节点的结果会由总线负责返回给用户使用。当用户或者服务向总线发起请求时，如果该请求被接纳，则总线会为该请求创建一个唯一的请求实例信息，负责维护本次请求的执行状态。

服务组合（流程配置）的配置过程如图 10所示，主要包括以下几个步骤：

新建一个组合服务，在已注册的服务当中选取一个添加到其中。

根据前一服务的输出参数及业务需求，添加与之匹配的输入参数的服务。

如果需要添加新的服务，则返回继续添加。否则完成服务组合配置。

3.用户向软件总线请求相关服务或流程

对于本系统来说，请求/应答模式是最主要的服务消息交换模式。服务A需要B提供服务并返回应答消息。首先服务A将需要服务B处理的数据封装为一条请求消息，向总线发送请求消息。总线接收到服务A的请求消息后，将查询本地的路由表，并将请求消息转发到服务B中。此时服务A处于阻塞状态，一直等待服务B返回应答消息。服务B接收到请求消息后，根据消息调用本地的函数，并返回合适的应答消息到总线上。总线根据应答消息查询路由表，将应答消息转发到服务A中。

本发明提供订阅/发布消息交换模式来使服务可以自由向总线发布和订阅消息，对于实时性要求不高的服务可以用这种模式来进行消息交换。例如，服务A定时发布心跳消息（消息中包含服务的当前状态和消息队列长度等）到总线上。服务B和服务C向总线注册订阅了服务A的心跳消息来监测服务A的工作状态。总线根据服务A发布的消息查找订阅的服务A心跳消息的列表，逐一向服务B和服务C转发这条消息。引入订阅/发布这种机制，是为了减少服务之间的耦合程度，服务可以根据订阅的消息类型自由得获取消息，不必每次都向特定服务请求消息。

由于本发明可以适应分布式总线节点的架构，因此在服务转发消息之前需要通过负载均衡模块来确定需要转发的总线节点。负载均衡首先根据消息的信息，通过负载均衡算法选定目标总线节点的节点号。服务总线代理根据这个节点号查找服务的总线表，并将表中的信息填入消息中转发消息到对应的总线节点。服务总线代理软件总线配置服务中得到当前软件总线的节点数目及其对应的负载情况。

4.软件总线的调度

本发明提出两级调度方案，以系统丢包率和响应时间比的多目标函数作为测量标准，通过调节任务的优先级及传输周期对总线资源进行优化分配，调度模块框架如图 11所示。

第一级调度作用是计算任务优先级。这一级调度提出一种改进的EDF动态调度算法，首先，由模糊反馈控制器预测每一个控制环的资源利用率需求值，然后由优先级配置器根据资源利用率需求值、死期、重要性等属性计算任务优先级，最后根据优先级把任务消息插入就绪任务队列并将优先级映射到本地操作系统优先级。

第二级调度作用是调节各任务的传输周期。首先，由PID控制器计算出整体总线资源利用率，然后由周期调节器根据总线资源利用率调节任务周期，通过调节任务的传输周期对总线资源进行优化分配，进一步优化系统性能。

5. 软件总线的消息处理

一个服务通过请求消息可以向其它服务发起请求。接收到相关请求消息的服务会做出应答，并发送一个或多个应答消息。一般地，发送请求消息的服务不需要知道目标服务的具体位置，只需按照预先定义好的消息协议向总线发送消息，这样的机制实现了服务之间的解耦合。

发送到软件总线的消息类型有：结果消息、状态消息、注册消息、请求消息和应答消息。总线节点都包含请求管理模块，订阅发布管理模块，网络通信模块，实时调度模块，如图 4所示。

请求管理模块是总线节点的核心，主要负责流程消息的转发和路由，从消息接收队列中获取服务消息，并根据消息的流程信息查找转发路由表，更新消息的目标服务，再将消息加入消息发送队列中。转发路由表是请求管理模块的重要组成部分，存储着系统中常用的流程信息，转发路由表的命中率对总线节点的性能有很大的影响。

订阅发布管理模块负责服务或总线节点的消息订阅和消息发布。服务或总线可以通过订阅方式来接收某些类型的消息，同时地，能够提供这些类型消息的其他服务会把这些消息发布到总线上。一般而言，服务或总线会通过订阅时所设置的参数来过滤消息。例如，总线之间通过发布自身的心跳消息，并订阅其它节点的心跳消息来互相传递各自的状态（如出错、超负载等），并由各自的总线管理器进行处理。

实时调度模块主要负责根据消息的优先级对消息接收队列和消息发送队列中的消息进行调度，主要目的是提高总线的实时性，因为控制系统的实时性有着比较高的要求。

网络通信模块主要负责总线节点与服务之间的通信细节管理，包括服务连接池的管理，网络 I/O 模式，服务消息的解析等。网络通信模块从服务获取消息，解析后放到消息接收队列中，当消息处理完毕后，再从消息发送队列中取出消息，封装后根据路由信息发送到目标服务。

图 12示了一个信息包从源服务（实例是人机交互服务）经由软件总线转发到目的服务的执行流程。

主要包含以下几个步骤：

（1）源服务通过总线 API 将消息传递给服务总线代理。总线 API 由服务接口生成模块根据用户定义的服务接口文件生成，为服务提供了一种与总线的交互方式。消息最终将被存储在服务总线代理的发送队列中。

（2）服务总线代理根据消息协议对消息进行序列化，服务总线代理根据负载均衡模块的结果，选定一个总线节点，并将消息转发到目标总线节点。

（3）总线节点接收到请求消息后存储到接收队列中，请求管理模块将根据实时调度模块的调度结果从接收队列中选出当前优先级最高的消息进行处理。

（4）请求管理模块根据选出消息的流程 ID，服务 ID，函数 ID 等信息，在总线节点的转发路由表中查找该消息目标服务。如果查找成功，则直接转到步骤（8），否则转到步骤（5）。

（5）总线节点向存储节点发起请求，获取消息目标服务的详细信息。

（6）存储节点接收总线节点的请求，根据请求中提供的消息的流程 ID，服务 ID，函数 ID 等信息对数据库进行查询，获取目标服务的信息，并将查询结果返回给总线节点。

（7）总线节点获取存储节点返回的结果，使用结果中的目标服务信息更新自身的转发路由表。然后转到步骤（4）。

（8）总线节点将消息发送到目标服务的服务总线代理。

（9）目的服务的服务总线代理接收总线节点发送的消息，根据消息协议对消息进行反序列化，再通过总线 API 将消息传递给服务的应用层进行处理。

6. 被请求的服务的消息处理

被请求的服务根据接收的信息提取相关的调用函数及调用参数，然后将调用参数传递给服务的内部函数进行调用，得到的处理结果通过服务总线代理API返回到软件总线上。

7. 软件总线处理返回消息

软件总线接收到来自服务的结果消息，从消息的内容判断是单个服务请求结果还是业务流程中的一个中间结果。若是单个服务请求结果，直接将结果消息转发到请求服务上。若是业务流程的中间结果，则将中间结果转发到业务流程当中给的下一个服务当中。

Claims (4)

1.基于软件总线的面向服务的机器人开放式控制系统，其特征在于按层次结构划分为五个层，分别是：应用服务层，总线消息层，服务总线代理层，传输层和总线管理层；其中，

应用服务由开发者根据统一的服务定义描述服务并实现服务功能，或者通过已有的服务组合而成；由于消息层对服务的消息进行封装，所以应用服务并不需要考虑通信细节，只需专注于服务的功能逻辑即可；

总线消息层为应用服务提供对外请求的消息作为接口，不同的消息对应不同处理逻辑；由于系统对传输的消息进行序列化进程，使得消息能够实现跨平台传输；

服务总线代理层作为应用服务层和传输层的中介，为总线提供了一层封装，主要功能是处理服务与软件总线之间的通信细节；

传输层的功能是实现应用服务与软件总线之间的消息传递，任务是保证消息可靠的，有序的，准确无误的和实时的在服务与软件总线之间进行传输；

总线管理层是控制系统的核心，系统中的各个服务通过软件总线进行连接并进行统一管理，服务之间的消息传递都需要经过软件总线进行转发和路由，并且处理服务组合、服务注册等重要逻辑。

2.根据权利要求1所述的基于软件总线的面向服务的机器人开放式控制系统，其特征在于所述软件总线由以下部分组成：服务总线代理，总线节点，总线管理器和存储节点；为了实现控制系统中服务之间的松耦合关系，采用自定义消息，通过消息序列化技术使消息能够在服务和软件总线之间传递，能够提供跨平台、跨语言的消息传输机制，服务的开发无需关注如何与软件总线通信的细节。

3.根据权利要求1所述的基于软件总线的面向服务的机器人开放式控制系统，其特征在于所述系统传输层中支持分布式控制系统的开发的方法，由于服务之间的松耦合关系，控制系统中服务可以部署在不同的物理节点上，提高了系统的灵活性；为确保系统能够满足机器人控制的实时性与确定性，在传输层上引入时间触发以太网来保证控制系统的实时性与确定性，对于实时性与确定性要求较高的服务使用时间触发流量传输数据，确保该服务的实时性与确定性；此外，为避免单一总线节点出现热点访问问题成为系统的瓶颈，通过分布式总线节点及总线节点的负载均衡来提高整个分布式控制系统的效率。

4.利用权利要求1所述的控制系统的控制方法，其特征在于包括如下步骤：

S1、服务注册；

在本控制系统中，包含三个角色，分别是服务请求者，服务提供者和服务注册中心；服务请求者发送请求服务消息，通过查询服务注册中心，获取服务信息并绑定服务，再根据服务所提供的接口执行任务；服务提供者提供了服务的具体功能实现；通过注册操作在服务注册中心中发布服务的接口和描述信息，使得服务请求者可以查询和访问该服务；服务注册中心提供并维护了一个可用服务目录，允许服务请求者查找感兴趣的服务的接口；

S2、服务组合；

每次客户的请求都是以业务流程的形式进行请求，而业务流程可以分解为若干服务的有序组合；一个业务流程信息以有向无环图的形式表示，其中每个节点表示一个服务组件；此步骤是应用服务层为用户提供一个方便的接口来实现具体的任务要求；

S3、用户向软件总线请求相关服务或流程；

请求/应答模式是服务消息主要交换模式，用户以业务流程形式请求组合服务，在同一流程中，服务A需要服务B提供服务并返回应答消息，就此服务A需要通过总线消息层选择合适的消息，并通过服务总线代理向总线发送消息；

由于采用适应分布式总线节点的架构，因此在服务转发消息之前需要通过负载均衡模块来确定需要转发的总线节点；负载均衡首先根据消息的信息，通过负载均衡算法选定目标总线节点的节点号；服务总线代理层根据这个节点号查找服务的总线表，并将表中的信息填入消息中转发消息到对应的总线节点；

S4、软件总线的调度；

以系统丢包率和响应时间比的多目标函数作为测量标准，通过调节任务的优先级及传输周期对总线资源进行优化分配；调度主要涉及对传输的消息进行合理的调度，满足系统的实时性要求；调度方法主要在总线管理层里实施；

S5、软件总线的消息处理；

一个服务通过请求消息向其它服务发起请求；接收到相关请求消息的服务会做出应答，并发送一个或多个应答消息；发送请求消息的服务不需要知道目标服务的具体位置，只需按照预先定义好的消息协议向总线发送消息；

发送到软件总线的消息类型有：结果消息、状态消息、注册消息、请求消息和应答消息，此步骤主要在软件总线管理层中完成；

S6、被请求的服务的消息处理；

被请求的服务根据接收的信息提取相关的调用函数及调用参数，然后将调用参数传递给服务的内部函数进行调用，得到的处理结果通过服务总线代理API返回到软件总线上；

S7、软件总线处理返回消息；

软件总线接收到来自服务的结果消息，从消息的内容判断是单个服务请求结果还是业务流程中的一个中间结果；若是单个服务请求结果，直接将结果消息转发到请求服务上；若是业务流程的中间结果，则将中间结果转发到业务流程当中给的下一个服务当中。