0 摘要
- （第一章）探讨和综述了机器人系统设计中的复用，包括设计方法级别复用（各种设计方法和原则）和体系结构级别复用（传统的智能组织到基于组件机器人工程）。介绍基于组件机器人工程（软总线技术CORBA和组件库技术）
- （第一章）介绍机器人系统设计中的一个重要模块，人机协作系统。
- （第二章）基础知识。
- （第三，四章）基于功能分析和UML模型对机器人协作系统软件进行建模和设计
- （第五章）基于LabVIEW对软件进行实现
- （第六章）针对当前软件的扩展性，提出一种软件设计参考模型。
目录
- 1 绪论
- 2 基础
- 3 机器人软件的分析建模
- 4-机器人软件的设计建模
- 5-软件构件的设计与实现
- 6-结论与展望
- 附录A-ROS系统软件开发概述
- 参考文献
1 绪论
1.1 机器人系统开发概述
- 如何科学而高效地设计机器人系统，一直是业界的热点问题。由于缺乏有效的软件集成方式，开发者在不断地重复“造轮子”，导致开发效率低下。一直以来，学者们不断在探索在机器人系统设计中的复用，包括方法复用和体系结构复用，在方法复用的探索上，研究者们不断提出新的系统化的机器人设计方法，在体系结构复用方面，研究者们期望能够得到一个通用的系统架构。（Wei and Jiachen et al., 2011）
- 分析领域内的复用
- 关于如何设计机器人系统，学者们从各个角度阐述了不同观点。在设计方法学上，一直存在着两种传统观点：基于符号处理的自顶向下方法和基于生物学原则的自底向上方法（Jones and Roth, 2004），不过当前的趋势是两种方法深度结合的混合设计方法。Pfeier（Pfeifer and Iida et al., 2005）在其论文中提出了一系列机器人的设计原则，包括通用的设计流程原则和具体的智能体设计原则两大类，在设计流程方面的原则包括“在构建中理解（Understanding by building）”的合成方法原则，紧急原则（系统应具有适应性，如能够在非正常情况下工作）等；智能体设计原则包括三构造原则（设计智能系统必须将环境，任务，智能体考虑在内），并行低耦合原则（与环境的交互任务必须是并行的，异步的，部分自主的，低耦合的）等等，为我们设计新一代机器人系统提供了指导。Yavuz提出了一种面向功能的概念分析方法来设计智能移动机器人，其主要流程分为：1）多学科功能分析；2）将功能分解至合适的细粒度；3）对于每一个子功能，找出多种实现手段和可替代功能；4）设计总体模型。其论文给出了一个案例，在案例中把机器人的功能分为三个大类：移动性（Mobility），导航（Navigation）和自主（Autonomy），同时考虑到机器人产品的商品性，提供了五个非功能性设计需求：简单的总体结构（Simple overall structure）；高效率（Cost effective）；鲁棒性的结构（Robust structure）；智能和具适应性的行为（Intelligent and adaptive behavior）；操作可靠（Reliable operation）。接下来使用FD树对这些需求进行分解，并选择使用机械，电子或软件的方法进行实现，最后给出一个总体的结构图。这种方法的优点是概念清晰，在功能较少的情况下设计简单，不过当系统变得复杂之后，设计仍然面临很多困难。2010年OROCOS的作者提出了以关注点分离为核心的BRICS设计原则并作为机器人开发最佳实践，BRICS提出了“5C模型”，即通信（Communication），计算（Computation），协调（Coordinator），配置（Configuration），构造（Composition）在设计和实现过程中得到分离，给予我们许多有益的启示。
- 设计领域内的复用
- 架构是构建复杂智能系统的基石，好的架构可以清晰描述如何将智能系统分解为子系统。关于寻求通用的系统架构，在20世纪90年代，学者们的关注点在于整体构建机器人的智能，提出了三种机器人范式：慎思式，反应式和混合范式（Arkin, 1998），随着计算机性能的快速发展，同时具有慎思式和反应式优点的混合范式已经称为主流。到21世纪初，不同厂商的机电设备，模块的不通用性已经成为制约机器人开发成本和设计周期的主要障碍，学者们的关注点从机器人系统的整体构建转移到基于组件技术的中间件研究，代表性成果包括软总线技术标准CORBA（Common Object Request Broke Architecture）（OMG）和组件库OROCOS（参考文献）。CORBA支持异构平台下对象的可互操作性和移植性方面具有很大开放性与灵活性，该标准主要特点是实现了软总线结构，通过功能抽象，屏蔽和隐藏底层诸如操作系统、开发语言和具体技术、协议等细节差异，形成一套统一的接口描述，从而解除了各个组件之间的紧密的耦合性；同时将各类应用模块按总线规范封装成组件，插入总线即可实现集成运行。OROCOS项目具体由四个C++组件库组成：实时工具集（RTT），运动学与动力学算法集（KDL），贝叶斯过滤库（BFL）与OROCOS组件库（OCL）：（1）实时工具集不仅是一个应用程序，还为机器人系统开发人员提供了大量的组件化应用案例；（2）运动与动力学组件是一个C++的函数库，提供了实时的动力学约束计算服务；（3）贝叶斯过滤库提供了一种专有的应用算法库，是由动态贝叶斯网络理论推导出的。这个理论可用于递归信息处理及基于贝叶斯规则的算法评估，例如卡尔曼滤波，粒子滤波算法等；（4）OROCOS组件库提供了一些典型的控制模块，如硬件接口模块，控制模块及模块的管理功能组件。
- 基于组件机器人工程
- 基于组件的软件设计，综合了设计方法层次和体系结构层次的软件复用（需要文献支撑），其理念受到业界广泛应用，历年来不断出现的机器人中间件（FINROC，2012）（GenoM3，2010）（OPRoS，2010），以ROS（机器人操作系统，2011）为代表，能够有效屏蔽操作系统、开发语言和网络协议的差异，为机器人开发提供多种通信和服务机制，是解决机器人组件化设计、消除机器人系统异构性问题的有效途径之一，目前已成为国际机器人研究的热点领域。（接下来介绍2010年基于组件机器人工程（Component-based robotic engineering）的提出）（Brugali and Shakhimardanov, 2010）（文献待阅读）
1.2 人机协作系统
1.2.1 人机协作系统的提出
- 智能移动机器人正在以惊人的关注度走进人类生产生活的各个方面，这已成为学界和工业界的共识。为了完成复杂的任务，机器人不仅仅需要在非结构环境下安全高效工作，而且需要与人有较高层次的合作与沟通。历史上移动机器人与人的交互模型主要有三种，第一种是遥操作，即人与机器人为主从关系，机器人实际上是人的工具，人与机器人构成控制闭环，人的作用就是控制器。这种交互方式的不足在于；1）如果工作人员离岗，机器人就停止工作，即人需要长时间在线；2）由于人控制的精确性和稳定性远远不如机器，机器人的工作能力被人所弱化；3）如果系统延时较大，如发生紧急事故，人不能立即操作机器人解决问题。第二种交互模型为监督控制，即人传递给机器人一个简单具体的指令清单，机器人按照指令清单执行动作，人主要进行机器人监控和流程控制。这种交互模型的不足在于1）由于机器人及所处环境未知且复杂，机器人指令清单设计困难2）非结构环境下难以保证机器人动作执行正确。第三种交互模型为全自主控制，人只需传递机器人一个抽象的任务目标，机器人借助人工智能技术自主感知环境，进行任务规划和执行。这种交互模型的不足在于，当前的人工智能技术（尽管飞速发展）与人类智能的差距太大，但技术还远未成熟。三种交互方式的控制结构示意图如下所示(徐坤, 2009)
图取自他人论文，尝试修改或者新建一套图
- 随着基于行为移动机器人研究的兴起，机器人自主性不断提升，人与机器人交互模型也相应有了新的发展——人机协作（HRC）。在这种模式下，人与机器人合作完成工作任务，机器人并不是人类的工具而是伙伴，能够跟人进行沟通，思考人类的意图，主动向人类提问或寻求帮助，将人类作为外界的消息来源，更好地完成目标。人机协作，作为新的人机交互模式，拥有极其广阔的研究价值
需要最新文献支持。
1.2.2 人机协作系统的特点（王挺, 2004）
- 在人机协作系统中，人通过某种方式参与到系统的感知，判断，决策过程中。与通常的半自主机器人不同，人类智能作为智能机器人系统的一个智能模块，和其他功能模块一样具有特点的功能与接口，由于其拥有所有环境信息，所以可认为具有最高级的智能。需要注意的是，人类智能无法直接作用于机器人的执行机构，而是需要与机器智能协作。
- 具体来讲，人类智能模块接收来自于机器人的系统状态信息、传感器环境信息和一定条件下可以获得的操作者直接观察到的环境信息, 对这些信息进行整理、抽取、分析、合并得到用以辅助机器智能操作的输出, 输出量应该在机器智能算法遇到局限时起到辅助和指导作用。按照传统的三层递阶体系结构分类，人类智能位于组织层，机器智能跨越组织层和协调层，是某种特定形式的人工智能算法，它接收系统状态信息，传感器环境信息和来自于人类智能模块的指导性输入，经运算得到相应的控制量输出，送给位于执行层的任务分解单元。在大多数情况下机器人可以凭借自身的智能算法完成移动功能，只有当机器人遇到复杂环境无法完全根据自身的算法获得有效输出的时候，人类智能模块的指导性输入量才被引入。体系结构示意图如下。
图取自他人论文
- 当然作为适当的功能保留，操作者应当具备对机器人的直接指令操作能力，并在任何时候对于机器人系统享有高于机器智能的优先控制权，但这时人机系统便退化成为人机交互系统(半自主系统)(体系结构示意图如下)，从图中可以看出人机系统与人机交互系统(半自主系统)的另一个区别在于前者人与协层交互，后者人与执行层交互。
图取自他人论文
1.3 本项目背景和意义
1.3.1 背景
- 智能移动机器人正在以惊人的关注度走进人类生产生活的各个方面，这已成对为学界和工业界的共识。人们机器人抱有极大的热情和期待，例如期待机器人能够代替人类去危险、有毒、有害的场所实施灾害救援任务，能够进入太空或其它星球完成太空探索任务，能够在我们步入老龄社会时承担助老任务，能够帮助残疾人实现生活自理……。但目前的科学技术水平距离人们的期待还有很长的路要走，机器人没有办法独立完成这些任务。本项目以“人”与“机器人”的协作为出发点，试图通过协作，充分发挥人与机器人各自的优势，以实际可行的方式，在一定程度上实现人们对机器人的期待。本项目充分利用机器人的精准、“钢铁之躯”和人类在意识、决策上的优势，实现任何单独一方难以完成的任务，具有极大的应用前景。
- 大量文献资料表明，人机协作乃至对等协作的人机交互方式是移动机器人控制的研究热点和发展方向。对机器人人机协作平台软件的研制，将有效提高机器人的工作效率和能力，进而提高机器人的自主性；采用新的软件复用方法和工具，将有望产生新的可复用的软件体系架构和软件开发过程模型，为以后的研究打好基础和提供指导，为同行提供可借鉴的经验。
- 本课题受国家“973”计划课题“核电站紧急救灾机器人的主从控制和自律协同”资助（编号2013CB0S35504）。
1.3.2 主要创新点
- 在机器人软件设计不成熟的背景下，基于UML规范对机器人协作平台软件进行建模和设计。基于模型的设计通用性好，可向同行提供有价值经验。
- 创新性的使用Actor编程模型对软件进行详细设计，软件模块化，扩展性能好。
- 提出一个机器人协作平台软件的通用参考模型，有望实现多机器人人机协作平台。
- 不仅提供了一种模型表示，还给出了实际开发过程。
1.4 人机系统相关工作
有待文献查取和写作
2 基础
2.1 本项目概述
暂时摆两张图
2.2 LabVIEW
2.2.1 LabVIEW执行系统（多线程，多任务）
- 在LabVIEW中，VI文件是基本的程序运行单元，一个VI包括前面板和后面板，开发者通过在前面板上放置控件，在后面板上进行图形编程的方式，制作虚拟仪器程序。每一个VI应用程序可以执行特定的任务，并拥有完整的人机交互界面。本节将介绍LabVIEW非常重要的特性——自动多线程，LabVIEW自动将每个应用程序分解为多个执行线程。本节先介绍LabVIEW单个应用程序的自动多线程原理，然后介绍VI的线程模型，最后介绍LabVIEW中的多任务。
2.2.1.1 LabVIEW的VI自动多线程
以下内容为摘抄，待修改
- 线程管理的复杂任务内化在LabVIEW执行系统之中。
- 所有线程管理的复杂任务在LabVIEW执行系统中都是透明的。基于文本程序设计的程序员必须学习新的复杂的编程方法来创建多线程应用程序。但是所有LabVIEW应用程序都可自动进行多线程化，无需修改任何代码。
- 除了操作系统的抢占式多任务处理，LabVIEW还采用了协同式多任务系统。在编译过程中，LabVIEW将分析VI查找可以同时运行的节点组合，这种节点组合也称为程序块。每个优先级和执行系统的组合都有一个运行队列数据结构，以保留哪些程序块能够一起运行。执行系统在激活一个线程的同时会从运行队列中重新找回并执行这个程序块。执行系统完成执行后，将存储其他的队列中符合输入条件的程序块，允许程序框图在4个可执行线程中的任何一个线程上执行。如果程序框图包含足够的并行机制，它可以在所有线程上同时执行。
- LabVIEW不能永久地给一个特定的线程分配程序块代码。下次运行VI时，LabVIEW将以不同的线程执行程序块。
下列程序框图上的红色长方形显示了LabVIEW如何将节点组合为程序块。
在该例中，程序框图由三个程序块组成，输入控件的程序块与显示控件的程序块是一样的。因此，该程序块在两个时间点执行。程序块在执行前后会进入休眠或延迟状态。左边第一个程序块开始执行后，第一个程序块即开始休眠，其他两个For循环程序块开始执行。VI准备开始执行显示控件程序块时，左右两个程序块停止休眠。
2.2.1.2 单个应用程序的线程模型
- 根据上一节的原理，VI根据实际编写的代码，自动分配个多个线程完成任务，这在多核处理器电脑中会带来性能提升。那么每一个VI中到底包含多少线程？
LabVIEW分配大致三类型线程：
- 1个UI线程，用于屏幕刷新和键盘鼠标输入。这个线程同时也用于特定VI的执行，譬如属性节点，非安全线程和DLL等。
- 内部线程，LabVIEW内部使用。如一对定时线程。
- 20个执行线程(每一个CPU)。
- 可选线程。如果使用ActiveX客户端工作，那么还会分配更多的线程。
关于20个执行线程，LabVIEW有5个 “执行系统”, 并且每个执行系统分4个不同等级分配线程。于是总共有20个线程（并且没有包含UI线程，也是用来执行的）。这5个执行子系统包括：Standard，I/O，DAQ，Other 1，Other 2，示意图如下所示。关于各个子系统的职能以及更多信息，请参考文献（Bitter and Mohiuddin et al., 2006）
2.2.1.3 LabVIEW中的多任务
介绍在LabVIEW中的线程，进程间通信方式，参考《LabVIEW宝典》
2.2.2 LabVIEW软件开发（项目管理，面向对象，CBSE扩展性）
- LabVIEW不仅仅用来编写概念验证代码和一次性测量程序，作为一种成熟的编程语言，依然支持复杂的软件工程实现各种应用。本节阐述了使用LabVIEW进行更复杂编程时会用到的功能特性。主要包括LabVIEW项目管理器，面向对象编程，和软件扩展性三个方面。
- 在本文的接下来部分，我们将通过LabVIEW面向对象编程和操作者框架来展示如何使用LabVIEW来构建大型程序。
都是教科书上的内容，先贴几张图
2.2.2.1 项目管理器
2.2.2.2 面向对象
2.2.2.3 扩展性
暂时摆图一张
3 机器人软件的分析建模
- 本项目将移动机器人软件开发过程建模为7个阶段：【需求建模（需求分析）】用例建模；数据流建模；【设计建模】早期设计；体系结构设计；构件选择和复用；构件精化；【软件实现】系统实现阶段。在第四，五，六章依次进行介绍。本章介绍分析建模部分的两个阶段：早期需求分析和结构化分析。
3.1 早期需求分析
- 早期需求分析的主要工作是基于用户场景产生用例模型，如果需要还应使用诸如活动图，泳道图等作为补充用例。本项目根据移动机器人的应用场景，撰写用户场景叙事，最终产生用例图和用例描述。
限于篇幅限制，只提供顶层用例图和一个用例的用例文档，其他查阅外部文档
3.1.1 用户场景叙事
- 机器人监管者（Supervisor）在本地工作站上，通过无线局域网与远程的P3AT移动机器人（P3-AT Mobile Robot）进行协作，完成巡逻，环境监测，危险排除等任务。具体来讲，机器人监管者可以使用两种方式与机器人进行协作：手动控制（Manual Synergetic Control）和语音控制（Voice Synergetic Control），为了更好地与机器人进行协作，机器人在监管者面前应该是透明的，即机器人本体状态及周围环境信息应实时展现给监管者。
- 在手动控制中，监管者在本地工作站上使用操纵杆对机器人进行远程控制，监管者能够直接控制机器人自身移动，操作机械臂等执行机构，监管者也可以在地图上点击一个目标点，命令机器人到达该点位置；在语音交互中，监管者对手机讲述中文语音，将声音信号传递给机器人，机器人收到语音信号后执行对应的任务，如“向前走五米”命令。
- 机器人应做到较底层的行为自主，能够做到自我保护，环境识别与推理，路径规划等。机器人能够在较高的思维抽象层次与监管者进行协作。机器人在工作过程中，监管者能够随时打断机器人，获得最终控制权。
- 在监管者向机器人发送协作指令的同时，机器人将自身的状态信息和采集到的周围环境信息传输回本地工作站，本地工作站对其进行建模，通过人机交互界面将信息可视化。监管者在本地工作站上将能够清晰地了解机器人的情况。
3.1.2 顶层用例图
见图Top Level Use Case.pdf
3.1.3 “语音协作控制”用例文档
- 用例名：语音协作控制
- 概述：监管者在本地工作站，使用安卓手机输入语音信号，对机器人进行远程控制。
- 参与者：监管者和P3-AT机器人
- 前置条件：工作站与机器人连接成功
- 主序列：
- 机器人与监管者交互定位
- 监管员要求进行语音协作控制
- 监管者使用手机输入进行语音信号录入，手机端将语音信号解释为中文命令，录入到本地工作站
- 本地工作站结合机器人状态数据，对命令进行初步分析，得到指令的抽象信息（类型，参数大小等），验证命令的合法性
- 如果命令合法，本地工作站对命令进行解释（翻译？），解释成机器人能够理解或直接执行的指令
- 如果解释成功，本地工作站将解释好的指令传递给远程机器人
- 远程机器人对指令进行执行，并在人机交互界面显示命令执行情况
- 如果命令执行情况正常，则在命令执行完毕后在人机交互界面显示执行结束情况
- 可替换序列：
- 步骤5：如果命令不合法，工作站人机交互界面上予以显示并停止，并要求监管者修改或者重新输入命令
- 步骤6：如果命令解释失败，工作站人机交互界面上予以显示并停止，并要求监管者检查命令或重新输入命令
- 步骤8：如果命令执行过程中出现失败，则在人机交互界面上予以显示并停止，并要求监管者重新输入命令。
- 步骤2-8：监管者放弃语音协作控制，控制结束。
3.2 面向数据流建模
- 数据流模型本是软件结构化分析方法的核心步骤，它从数据传递和加工的角度，刻画数据对象通过系统时如何转换数据。在本项目中其作为主要的需求分析表达方式，以提供对系统需求和流程的补充认识，在后面可以看到，数据流模型非常方便地映射为LabVIEW程序结构，使得软件开发效率大大提升。数据流模型的主要工作产品是数据流图（DFD）
3.2.1 为什么使用面向流程的建模方法
- 1.符合机器人结构的基本范式，便于从基本范式映射到软件模型。根据文献[Murphy.2001]，机器人的各种控制结构，都是由三种基元构成，即感知、规划、执行，各种机器人结构，都是三种基元经过不同抽象层次的分解和相互作用的结构。一般来讲，感知基元对传感器信息进行处理，生成感知/认知信息，规划基元对感知/认知信息进行处理，生成机器人能够直接执行的指令，而执行基元对指令进行处理，生成更加具体的执行器指令。整个过程可以非常直观地用数据流图表示
- 2.数据流模型可以直接映射到LabVIEW程序结构。LabVIEW开发平台使用图形化编程语言G语言，G语言设计的核心就是对数据流的表示[Hugo.1998]。
本文提供环境图（顶层DFD）、一个分解举例和底层DFD
3.2.2 顶层数据流模型
- DFD采取了系统的输入-处理-输出的观点，也就是说，流入软件的数据对象，经由处理元素变换，最后以结果数据对象的形式流出软件。带标记的箭头表示数据对象，圆圈表示转换。DFD使用分层的方式表示，即第一个数据流模型表示整个系统，随后每个后续层提供更多的细节[Pressman.2005]。
- 顶层数据流模型（环境图）将整个软件系统描述为一个转换，用圆圈表示，外部实体（方框）产生系统所使用的信息，带标记的箭头代表数据对象。
顶层数据流模型见Context Diagram.pdf
3.2.3 第一层数据流模型
- 根据用例模型，我们将DFD扩展到第一层。DFD的扩展遵循传统上对机器人结构的认识，即感知、规划和执行。
第一层DFD见First-Level DFD.pdf
3.2.4 数据流模型的精化
- 接下来应该对DFD进行求精，以获得更多需求信息，直到每一个泡泡都执行某一个单一的功能，这样该功能就很容易地成为一个程序构件。这里以Interacting management处理的精化为例，直观地，用户与软件交互按照目的划分，分为配置定位、配置地图、配置机器人、停止和启动四个方面，按照这种逻辑精化，得到第二层DFD。
DFD精化例子见Management.pdf
3.2.5 第二层DFD
- 进行DFD分解要注重每一个变换都要有相对高的内聚性，对每一个变换进行精化后的第二层DFD如下。
第二层DFD见Lowest-Level DFD.pdf
4-机器人软件的设计建模
- 基于并发构件的软件体系结构
使用像“软件系统的软件体系结构被设计成一个基于分布式构件的软件体系结构”的句式是否具有说服力？
- 在上一章中，已经使用面向流程的方法进行了需求分析，通过构建数据流图并进行精化，软件系统的每一个功能已经转化成DFD中的一个个变换和数据流动，接下来的设计建模过程，将基于需求分析模型设计软件体系结构，给出更多软件系统的表示信息，包括通信图，顺序图和状态图等。
- 本项目中， “机器人协作系统”被设计为一个基于并发构件的，分层控制的软件体系结构。
- 本项目中，设计建模的第一步就是将分析模型（主要为DFD）精化映射为构件模型，接下来设计构件间通信消息及通信消息模式，给出更多UML图形表示。【这里的DFD相当于“COMET”方法中设计子系统之前的集成通信图】
4.1 从数据流图到软件子系统的映射
- 在设计构件之前，需要先设计软件子系统，
- 在分析建模阶段，我们通过功能分解描绘了软件系统的逻辑模型，在设计建模阶段，我们将基于此设计“机器人协作软件系统”的各个子系统，设计目标是让每个子系统都能负责执行一个相对独立的功能。这样，当定义好子系统之间的接口之后，就可以独立进行各个子系统的设计了。
4.1.1 关注点分离
- 在子系统设计时需要解决关注点分离问题，即让不同的子系统关注不同的关注点，目的是让子系统的独立性更好。根据文献[Gomaa. 2011]，考虑不同的子系统组织准则，可以将软件系统分解为客户端子系统，用户交互子系统，服务子系统，控制子系统，协调者子系统，输入/输出子系统等，这些子系统组织准则同样可以应用于构件设计。
- 下面简要介绍各种子系统的特点
- 客户端子系统：一个客户端子系统是一个或多个服务的请求者。客户端子系统包括用户交互子系统，控制子系统和输入/输出子系统。
- 用户交互子系统：用户交互子系统提供用户接口，并且充当一个客户端/服务系统中的客户端角色，提供用户访问服务。
- 服务子系统：服务子系统为客户端子系统提供服务。服务子系统并不会发出任何请求，而是对来自客户端子系统的请求进行响应。
- 控制子系统：一个控制子系统控制系统中的一个特定部分。控制子系统接收来自外部环境的输入，产生面向外部环境的输出，其中通常没有人工干预。一个控制子系统通常是状态相关的。一个控制子系统可以从另一个给予其总体方向的子系统那里接收一些高层指令，然后持续地或者以按需的方式向其他结点提供低层控制或者发送状态信息。
- 协调者子系统：协调者子系统协调其他子系统的执行，例如控制子系统或服务子系统。所以协调者子系统相应地分成这两类：协调控制子系统的子系统和协调服务子系统的子系统。
- 输入/输出子系统：一个输入，输出或输入/输出子系统是一个代表其他子系统执行输入和/或输出操作的子系统，通常由一个或更多的设备接口对象组成，并且还可能包括提供本地化控制的控制对象和存储本地数据的实体对象。
- 本文将根据以上原则将数据流图中的各个流程转换为独立的软件子系统，在下一小节进行控制模式的选择之后，添加相应的控制子系统。
4.1.2 层次化的控制模式
- 并发软件体系结构中的控制模式主要包括集中式，分布式和层次化控制体系结构
- 集中式控制模式：集中式控制体系结构中只包含一个控制子系统。从概念上来说控制构件要执行一个状态图以总控全局并管理整个系统的行为顺序。
- 分布式控制模式：分布式控制体系结构中包含多个控制子系统。控制分布在各个控制模块中，控制模块通过点对点的通信实现重要事件的通知，也通过与集中式控制模式中类似的方式与外部环境交互。
- 层次化控制模式包含多个控制子系统，不过与分布式控制模式不同，存在一个协调者子系统，通过协调所有控制模块完成整个系统的控制。协调者提供高层控制，包括直接与各个控制模块进行通信并且决定各个控制模块的下一步动作，同时协调者也从控制模块中接收状态信息。
- 由于本项目需要处理多个输入输出，且需要一定的扩展性，所以采用层次化控制模式。
4.1.3 初始软件子系统图
- 根据前两小节的子系统组织准则，将数据流图转映射为如下所示的软件子系统图，可以确定以下子系统：
- 。。。
- 。。。
初始软件子系统图见Components-1st-Refinement-final.pdf
最后不能用构件图来画这几张图
*不难看出，这里得到的子系统图只是数据流图和控制构件的简单组合，“碎片化”严重，存在着多种子系统执行类似功能，以及控制构件控制单一构件的情况。在下一节基于构件的软件体系结构设计中，将针对这两种情况，对当前子系统图进行精化，生成构件图。
4.2 基于并发构件的体系结构
- 软件体系结构的设计，主要考虑系统的静态结构和动态结构。本节将基于前面生成的软件子系统图，生成静态的软件构件图即构件图，和动态的软件体系结构图即通信图。
- 软件体系结构的静态结构设计，通常都会应用得到广泛接受的基于构件的思想，本文也不例外。一个基于构件的软件体系结构由多个构件组成，其中每个构件相互独立且封装了信息，在外部暴露接口，通过接口与其他构件进行通信，所有与其他构件进行通信所需要的信息都包含在接口之中，并且接口与实现相分离。构件之间使用预先定义好的通信模式进行通信。良好设计的构件应能够在后续设计中得到复用。
- 由于本项目机器人协作系统涉及多个输入输出，所以需要开发一个并发的软件体系结构。这样在软件体系结构中，每一个构件都可以是并发的，进而可以是分布式的，软件构件可以部署到不同的物理结点上，这些特点可以极大增强软件体系结构的扩展性。
- 在本项目的基于构件的开发方法中，每一个子系统都被设计成一个分布式的独立构件。根据一定原则，多个构件可以组合得到复合构件。本文将对上节产生的子系统图进行精化，生成构件图，描述其静态结构（结构图）和动态结构（高层通信图）。
4.2.1 子系统图的精化——体系结构的静态视图
复合构件的组织原则：地理位置一致，功能类似
- 上一节生成了作为初始软件体系结构的软件子系统图并提出了相应问题。这一节将针对这些问题对软件体系结构进行精化，生成最后的构件图。
- 针对前一种情况，应将执行类似功能的子系统合并，虽适当降低了内聚性，但使得构件组织结构更合理；针对后一种情况，只需把控制子系统省略掉即可。
- 具体的精化步骤如下：
- 。。。
- 。。。
- 最后生成的构件图如下
软件子系统图见Components-2nd-Refinement-final.pdf
4.2.2 高层通信图——体系结构的动态视图
- 通信图是描述软件体系结构动态视图的主要方式，本节先简要介绍软件体系结构的主要通信模式，然后介绍本项目中构件与构件之间的通信方式，设计确定每条消息的名称和参数（接口规约）和精确语义。
4.2.2.1 体系结构通信模式
- 在从分析模型到设计模型的过渡中，最重要的决策之一就是与子系统之间需要哪种类型的消息通信，在分布式系统中，常见的消息通信模式如下：
- 异步（松耦合）消息通信：通过异步消息通信模式，生产者构件发送一条消息给消费者构件并且不等待其回复，生产者会继续执行，因为它要么不需要一个回复，要么在收到回复之前还要执行一些其他的功能。消费者收到消息，如果消费者正在处理其他事情，那么该消息会进入等待队列。由于生产者和消费者构件是异步执行的，因此可以在生产者和消费者之间建立一个先进先出的消息队列。当消费者请求消息但消息却没有到达时，该消费者会被挂起，当消息到达后，消费者会被唤醒继续工作。在分布式的环境中，任何可能会提高灵活性的地方都可能使用异步消息通信模式。该方法也可以用在发送者不需要接受者进行回复的情况下。
- 带回复的同步（紧耦合）消息通信：在这种通信模式下，生产者向消费者发送消息并等待消费者的答复，如果有多个生产者向消费者发送消息请求，则在消费者端建立一个消息队列。
- 不带回复的同步（紧耦合）消息通信：在这种通信模式下，消息生产者向消息消费者发送消息，并等待消息被消费者接收。当消息到达时，消费者接收消息并释放生产者，随后生产者和消费者一起继续执行消息收发过程。如果没有消息到来，消费者会挂起。
4.2.2.2 高层通信图设计
在前面的分析模型中，已经通过数据流图展现了信息以及在软件模块之间流动的方向，也就基本确定了模块间消息的类型。如下：
- 。。。此处写上软件设计中的消息类型
- 。。。
- 。。。
根据具体的项目需要，每条消息的接口规约如下：
- 。。。
- 。。。
- 。。。
最后的高层通信图如图所示。
4.2.3 构件间交互图——体系结构的动态视图
此处介绍各个用例的顺序图
- 。。。
4.3 软件构件部署
- 一个典型的系统的软件部署如图所示，每一个构件都被分配到一个特定的物理结点，结点之间通过互联网连接。具体情况如下：
- 。。。
- 。。。
- 。。。
5-软件构件的设计与实现
- 在体系结构设计完成之后，就开始进行构件级设计和编程实现，在本项目中，由于软件体系结构的分布式并发特性，我们创新性地使用LabVIEW开发平台及其多进程异步通信框架Actor Framework对机器人协作软件进行实现，在本节中，将先对LabVIEW开发平台及Actor编程模型做简单介绍，然后根据之前的设计模型进行进一步设计和详细编程实现，模型进一步设计包括构件模型映射为LabVIEW中的Actor编程模型，详细编程实现包括Actor实现及其各个通信模式的实现。
5.1 Actor编程模型的应用
5.1.1 LabVIEW Actor Framework
- LabVIEW于1986年由美国国家仪器公司发布，是一个虚拟仪器开发环境，其本质用途是为硬件提供可视化和控制接口。LabVIEW拥有独特的G语言，这种特性同时提供了人机交互和源代码（Dr. Sumathi and Prof. Surekha, 2007），给开发者提供了巨大的便利，关于LabVIEW的使用，请参考文献（Bitter and Mohiuddin et al., 2006），下面介绍本文主要使用的LabVIEW Actor Framework，一个基于面向对象的程序模板，其实现了Actor编程模型，提供了多进程通信的框架。
- Actor模型，于1973年被提出（Hewitt and Bishop et al., 1973），是一种并发运算上的模型，Actor是一种程序上的抽象概念，被视为并发运算的基本单元，当一个Actor接收到一则消息，它可以做出一些决策、创建更多的Actor、发送更多的消息、决定要如何回应接下来的消息。LabVIEW Actor Framework（操作者框架）是Actor模型在LabVIEW上的实现。操作者框架专为多进程程序设计，为了增强代码复用使用了面向对象编程，其模板提供了基本功能，包括创建操作者，创建消息，定义消息的响应函数，关于操作者框架的详细使用，请参考官方文档（。。。），本文接下来将对操作者框架进行概念性阐释，在下一节将对机器人协作系统软件进行映射。考虑是否引入1973年的Actor Model，只将LabVIEW Actor Framework阐述为一种编程框架
5.1.1.1 操作者框架概述
- “操作者框架”由操作者和消息构成。消息在消息队列中传输。为减少出错和提高应用程序的可靠性，“操作者框架”限制了能够互相发送消息的操作者。
- 在这儿，我们利用LabVIEW自带示例项目进行解释，该示例项目包括三个操作者：顶层操作者，Alpha操作者和Beta操作者。
5.1.1.2 操作者及消息
操作者是LabVIEW类，代表某个任务的状态。所有操作者类均从LabVIEW中的“操作者”类继承。该类由三个主要部分构成：
- 操作者的核心VI－核心VI是一个特定命名的方法（“操作者核心”），用来定义操作者的连续行为。该方法定义了所有操作者的消息处理行为。该类的子孙类重写方法以显示操作者的用户界面、添加并行循环和启动嵌套操作者。
- 操作者的特定方法－这些VI是LabVIEW类的成员VI，用于定义操作者。通常每个方法对应于操作者能够执行的一个任务。祖先类（“操作者”类）包含几个专门设计用于被子孙类重写的方法。
- 操作者的消息－消息是一个LabVIEW类，定义了操作者能够接收的指令和作出响应的方式。其他操作者将这些消息发送至一个操作者，以便让操作者调用其中的一个方法。在“操作者框架”基础上创建应用程序时，通常需要为操作者的每个方法定义一个消息。所有消息均从LabVIEW中的“消息”类继承。
例如，下图显示的项目库包含一个操作者Alpha（Alpha类）和一个消息(Alpha任务消息类)。
下面介绍各个文件：
- 操作者的核心VI是操作者核心。该方法重写其祖先的“操作者核心”方法，定义了Alpha操作者特有的连续行为。
- 操作者的方法是停止核心和任务。这些方法在下列条件下执行：
- 停止核心在Alpha操作者收到“停止”消息时执行。该方法重写“操作者”类的“停止核心”方法，用于定义Alpha操作者特有的行为。
- 任务在Alpha操作者收到“任务”消息时执行。该方法为Alpha操作者特有，即“操作者”类中未定义该方法。
- 操作者的消息包含在Alpha的消息文件夹中。该操作者仅定义一个消息，即Alpha任务消息，该消息从“消息”类继承，包含下列文件：
- Alpha任务消息控件是该消息携带的数据。
- 发送Alpha任务是其他操作者用来发送“任务”消息至Alpha操作者的VI。该VI将创建消息的一个实例并用一些数据填充消息。
- 执行定义了Alpha收到“任务”消息时执行的动作。本模板中，“执行”VI命令Alpha执行其“任务”方法。
示例项目类间关系图如下所示（需要加上Msg类的表示，需要重新制UML图）
5.1.1.3 操作者之间的通信
在通用Actor Model中，一个Actor能够与任一Actor进行消息通信，但在LabVIEW Actor Framework中，为了减少通信错误，默认情况下，一个操作者只能将消息发送至两种操作者：
- 调用方-启动X的VI（可能是一个操作者）
- 嵌套操作者－X启动的任何操作者
这种被限制的通信顺序称为任务树。这样的优势在于，只有一个通信路径需要管理，因此可以确保某操作在关闭之前其他操作者有机会接收其消息并作出响应。
本模板所定义的任务树如下
该图表明应用程序操作者同时启动Alpha和Beta操作者。因此，应用程序操作者称为顶层操作者，顶层操作者启动所有其他操作者。顶层操作者从一个正常VI启动。
- 在该任务树中，下列通信规则有效：
- 应用程序可将消息发送至Alpha和Beta
- Alpha仅能将消息发送至应用程序
- Beta仅能将消息发送至应用程序
- 这说明Alpha和Beta无法将消息发送至对方。Alpha必须发送一个消息至应用程序，确定Beta是否需要接收该消息并采取相应的动作。同样，限制通信路径有助于写入更多易于管理和正确无误的代码。
消息通过队列发送，每一个操作者维护一个自己的队列，下图显示了两个操作者如何进行通信：
如图所示，X能够将消息发送至自身(1)和Y (2)。Y能够将消息发送至X (3)和自身(4)。尽管有四个消息可进入的方向，但只包含了两个队列。此外，两个操作者都无法释放对方的队列。相反，每个操作者释放自身的队列，作为其关闭程序的一部分。
5.1.2 本项目Actor结构
由于Actor编程模型天然的并发和模块化特性，使得机器人协作系统软件体系结构能够非常容易地转化为LabVIEW中的Actor图，其中：
- 。。。
- 。。。
- 。。。
软件实现的Actor任务树如图所示（这张图要改，风格不对）
Actor结构图见Components-3rd-Refinement-final.pdf
- 最后的类图如下图所示（包括操作者类和消息类，作为两张图）这两张图要放在构件设计中
5.2 基于构件的开发——构件选择与复用
- 基于构件的软件工程（CBSE）强调使用可复用的软件构件来设计和构造软件系统。一方面，我们从一些标准构件库购买构件，对构件进行适应性修改后即可进行组装，另一方面，我们也需要开发新的软件构件，不过需要进行领域分析，按照标准数据结构和接口协议进行设计。本项目软件实现过程充分采用了这种思想，借助LabVIEW自带的丰富构件库进行开发，同时自己也开发出部分构件作后续使用。（component based development）
5.2.1 LabVIEW Tools Network介绍和构件清单
LabVIEW工具网络，被称为工程师的APP商店，提供了经认证的第三方附加组件，以帮助用户扩展LabVIEW系统设计软件功能，提高开发人员的效率。这些由第三方提供的软件组件主要包括以下几类：
- LabVIEW 插件：包括应用程序接口，代码模板，自定义控件，小工具，示例代码等
- 应用程序：LabVIEW环境之外的独立产品
LabVIEW工具网络所提供的组件大多可免费使用（如使用BSD许可协议），在VI Package Manager中进行搜索下载安装即可。
- 下图所示为VI Package Manager及本项目软件所使用的一个组件，XBox手柄控制器的工具介绍页面，下一节将使用这一标准组件，进行适应性修改后制作出本项目需要的手柄操作者。
5.2.2 构件修改及组装举例——手柄操作者的构建
5.2.2.1 手柄操作者功能与通信分析
5.2.2.2 核心函数编写
5.2.2.3 消息函数编写
5.3 构件设计
5.3.1 构件设计举例-协调者构件应用状态设计模式
5.3.2 协调者操作者功能与通信分析
5.3.3 核心函数编写
5.3.4 消息函数编写
5.3.5
5.4 基于LabVIEW的构件（任务）间通信模式的实现
除了操作者相关的都移动到前面去
5.4.1 消息队列——操作者框架提供的若干模式
5.4.2 信号（在LabVIEW中的实现）
5.4.3 共享变量
5.4.4 Socket
6-结论与展望
6.1-结论
6.2-未来工作——一个参考模型（功能扩展+分布式部署）
附录A-ROS系统软件开发概述
A.1
A.2
A.3
参考文献
- Murphy R. Introduction to AI Robotics[M]. MIT Press, 2000.
- Gomaa H. Software Modeling and Design: UML, Use Cases, Patterns, and Software Architectures[M]. Cambridge University Press, 2011.
- Pressman R S. Software Engineering: A Practioner’s Approach[M]. 7 ed. McGraw-Hill Companies, Inc, 2005.
- Andrade H A, Kovner S. Software synthesis from dataflow models for G and LabVIEW/sup TM[C]. IEEE, 1998.
- Bitter R, Mohiuddin T, Nawrocki M. LabView: Advanced Programming Techniques, Second Edition[M]. CRC Press, 2006.
- LabVIEW Graphical Development Platform Part I – An Open Platform for Long-Term Continuity[EB/OL]. National Instruments Corporation. 2005.
- Będkowski J. Mobile Robots - Control Architectures, Bio-Interfacing, Navigation, Multi Robot Motion Planning and Operator Training[M]. InTech, 2011: 402.
- 陈树学，刘萱. LabVIEW宝典[M]. 北京: 电子工业出版社, 2011.
- 徐坤. 搜救机器人人机协作行为控制研究[D]. 山东大学, 2009.
- 王挺，王越超. 人机系统在移动机器人平台的应用[J]. 机器人. 2004(06): 553-557.
- 黄志华，屠大维，赵其杰. 基于人机交互的移动服务机器人导航系统[J]. 机器人. 2009(03): 248-253.
- Goodrich M A, Schultz A C. Human-robot interaction: a survey[J]. Found. Trends Hum.-Comput. Interact. 2007, 1(3): 203-275.
- Wei X, Jiachen M, Mingli Y. Research on Building Mechanism of System for Intelligent Service Mobile Robot[M]. MOBILE ROBOTS – CONTROL ARCHITECTURES, BIO-INTERFACING, NAVIGATION, MULTI ROBOT MOTION PLANNING AND OPERATOR TRAINING, INTECTWEB.ORG, 2011.
- Jones J L, Roth D. Robot programming : a practical guide to behavior-based robotics[M]. McGraw-Hill, 2004: 293.
- Pfeifer R, Iida F, Bongard J. New robotics: Design principles for intelligent systems[J]. Artificial life. 2005, 11(1-2): 99-120.
- Bischoff R, Guhl T, Prassler E, et al. BRICS-Best practice in robotics[C]. VDE, 2010.
- Jang C, Lee S, Jung S, et al. OPRoS: A new component-based robot software platform[J]. ETRI journal. 2010, 32(5): 646-656.
- Domínguez-Brito A C, Santana-Jorge F J, Santana-De-La-Fe S, et al. CoolBOT: An Open Source Distributed Component Based Programming Framework for Robotics[C]. Springer, 2011.
- Mallet A, Pasteur C, Herrb M, et al. GenoM3: Building middleware-independent robotic components[C]. IEEE, 2010.
- Reichardt M, Föhst T, Berns K. Introducing finroc: A convenient real-time framework for robotics based on a systematic design approach[J]. Robotics Research Lab, Department of Computer Science, University of Kaiserslautern, Kaiserslautern, Germany, Technical Report. 2012.
- Brugali D, Scandurra P. Component-based robotic engineering (part i)[tutorial][J]. IEEE Robotics & Automation Magazine. 2009, 16(4): 84-96.
- Brugali D, Shakhimardanov A. Component-based robotic engineering (part ii)[J]. IEEE Robotics & Automation Magazine. 2010, 17(1): 100-112.
