第5期 张鸿皓，等：水下机器人任务流程建模与管理 ·435· 图3中的例子与图1中的流程大体相似s.尽 态之一，2种状态可分别指向不同的后继任务： 管保留了库所、标记等元素，但它并不使用复杂的路 4)任务间的依赖关系F可分为2类：发起一个 径、资源的冲突等技巧来表达逻辑上的意义，而是用 尚未执行的任务，或终止一个正在执行的任务 固有的逻辑组件来构造路由，将Petri网构造的逻辑 模型中只存在任务极其依赖的关系，虽然没有 结构隐藏在逻辑组件之下. 库所和标记这样的元素，但类似的功能已被整合到 任务中默认情况下任何任务必须等到所有前驱任 开始 结束 务全部结束才能执行，相当于AND_join型：任务结 航行到目标区 紧急 束后其对应的所有后继流程也都会被执行，相当于 上浮 回收 AND_split型.其他的逻辑关系，如OR_split和OR_ 到达目标区 长时间 join,将由特殊的任务来实现.不同之处在于区分出 未到达 AND_split未反应 了“成功”和“失败”2种互斥的结束状态，且流关系 目标区 也包括“发起”和“终止”2种.对任务首尾逻辑结构 返航 的处理不像Petri网那样显式地建模表示，而是用一 开始 采集 个“工作流管理程序”来进行管理，这在编程实现时 作业 数据 更加方便， 任务工作流有自己的图形语言，如图4所示，所 OR join 有任务采用相同的图形样式.任务图形的头部可接 作业 作业 纳多个前驱任务：图形的尾部分成2个区域，空白的 完成 ☑AND join 一半表示执行成功，带叉的一半表示执行失败，从2 个区域流出的箭头分别代表了2种状态下任务工作 流网不同的路径.水下机器人任务流程中最为常见 的成功或失败的分支流程在这里成为任务的内置属 图3任务示例（工作流模型） 性实箭头表示发起一个尚未运行的任务，虚箭头表 Fig.3 Example of AUV task flow workflow) 示终止一个正在运行的任务.网络中的每个任务都 虽然Petri网能够构造出一些精妙而准确的逻 有惟一的名称（称之为标号，以“#”开头），同类型的 辑结构，但在多数时候，这种极其苛求洞察力和智力 不同任务的名称也必须不重复.每个任务都有内置 的建模方式并不适合面向普通人的、需要迅速作出 的超时值，默认情况下其值为无穷大，超时后任务会 灵活更改的任务建模.与经典的Petri网相比，工作 被判定为失败，网路流程转向其失败后的路由. 流模型更灵活，更接近人类语言和人抽象的思维方 式.但同时，由于缺乏标准、精确和成熟的理论基础， 虽然市面上的工作流模型及基于工作流的应用软件 任务采用 实线箭头 统一的图 表示发起 种类繁多，但每种模型都或多或少存在明显的缺陷， 形样式 一个任务 例如OR_join任务同步时出现的逻辑问题等，尚 虚线箭头 成功 失败 表示终止 未见到理论上完美的解决方案[).然而总的说来，在 一个任务 适当的改进和处理之后，工作流模型能够更好地服 务于机器人抽象任务建模。 终止一个任 3任务工作流 务，指向任 发起一个任 务中部 务，指向任 任务工作流由工作流模型改进而来.定义任务 务头部 工作流网为有向网N=(T,F),其中T为任务，F为 流关系，且需满足： 图4任务工作流图形描述方式 Fig.4 Graphic description of task workflow 1)存在惟一的起始任务T∈T作为网路的起 始点，其前驱为空： 每个任务都是不可分割的原子任务，要扩展某 2)每个任务t∈T都位于连接到T的一条通 一任务，只能在相应的流程处插入子网.任务的具体 路上，不存在孤立的任务： 内容由高级编程语言编写，任务获取环境信息、判断 3)每一任务结束时必处于成功或失败2种状 任务成功执行或失败的代码都在其实现代码中.任图 ３ 中的例子与图 １ 中的流程大体相似[５￣６] .尽 管保留了库所、标记等元素ꎬ但它并不使用复杂的路 径、资源的冲突等技巧来表达逻辑上的意义ꎬ而是用 固有的逻辑组件来构造路由ꎬ将 Ｐｅｔｒｉ 网构造的逻辑 结构隐藏在逻辑组件之下. 图 ３ 任务示例(工作流模型) Ｆｉｇ.３ Ｅｘａｍｐｌｅ ｏｆ ＡＵＶ ｔａｓｋ ｆｌｏｗ (ｗｏｒｋｆｌｏｗ) 虽然 Ｐｅｔｒｉ 网能够构造出一些精妙而准确的逻 辑结构ꎬ但在多数时候ꎬ这种极其苛求洞察力和智力 的建模方式并不适合面向普通人的、需要迅速作出 灵活更改的任务建模.与经典的 Ｐｅｔｒｉ 网相比ꎬ工作 流模型更灵活ꎬ更接近人类语言和人抽象的思维方 式.但同时ꎬ由于缺乏标准、精确和成熟的理论基础ꎬ 虽然市面上的工作流模型及基于工作流的应用软件 种类繁多ꎬ但每种模型都或多或少存在明显的缺陷ꎬ 例如 ＯＲ＿ｊｏｉｎ 任务同步时出现的逻辑问题[１] 等ꎬ尚 未见到理论上完美的解决方案[７] .然而总的说来ꎬ在 适当的改进和处理之后ꎬ工作流模型能够更好地服 务于机器人抽象任务建模. ３ 任务工作流 任务工作流由工作流模型改进而来.定义任务 工作流网为有向网 Ｎ ＝ (ＴꎬＦ)ꎬ其中 Ｔ 为任务ꎬＦ 为 流关系ꎬ且需满足: １)存在惟一的起始任务 Ｔｓｔａｒｔ∈Ｔ 作为网路的起 始点ꎬ其前驱为空ꎻ ２)每个任务 ｔ∈Ｔ 都位于连接到 Ｔｓｔａｒｔ的一条通 路上ꎬ不存在孤立的任务ꎻ ３)每一任务结束时必处于成功或失败 ２ 种状 态之一ꎬ２ 种状态可分别指向不同的后继任务ꎻ ４)任务间的依赖关系 Ｆ 可分为 ２ 类:发起一个 尚未执行的任务ꎬ或终止一个正在执行的任务. 模型中只存在任务极其依赖的关系ꎬ虽然没有 库所和标记这样的元素ꎬ但类似的功能已被整合到 任务中.默认情况下任何任务必须等到所有前驱任 务全部结束才能执行ꎬ相当于 ＡＮＤ＿ｊｏｉｎ 型ꎻ任务结 束后其对应的所有后继流程也都会被执行ꎬ相当于 ＡＮＤ＿ｓｐｌｉｔ 型.其他的逻辑关系ꎬ如 ＯＲ＿ｓｐｌｉｔ 和 ＯＲ＿ ｊｏｉｎꎬ将由特殊的任务来实现.不同之处在于区分出 了“成功”和“失败”２ 种互斥的结束状态ꎬ且流关系 也包括“发起”和“终止”２ 种.对任务首尾逻辑结构 的处理不像 Ｐｅｔｒｉ 网那样显式地建模表示ꎬ而是用一 个“工作流管理程序”来进行管理ꎬ这在编程实现时 更加方便. 任务工作流有自己的图形语言ꎬ如图 ４ 所示ꎬ所 有任务采用相同的图形样式.任务图形的头部可接 纳多个前驱任务ꎻ图形的尾部分成 ２ 个区域ꎬ空白的 一半表示执行成功ꎬ带叉的一半表示执行失败ꎬ从 ２ 个区域流出的箭头分别代表了 ２ 种状态下任务工作 流网不同的路径.水下机器人任务流程中最为常见 的成功或失败的分支流程在这里成为任务的内置属 性.实箭头表示发起一个尚未运行的任务ꎬ虚箭头表 示终止一个正在运行的任务.网络中的每个任务都 有惟一的名称(称之为标号ꎬ以“＃”开头)ꎬ同类型的 不同任务的名称也必须不重复.每个任务都有内置 的超时值ꎬ默认情况下其值为无穷大ꎬ超时后任务会 被判定为失败ꎬ网路流程转向其失败后的路由. 图 ４ 任务工作流图形描述方式 Ｆｉｇ.４ Ｇｒａｐｈｉｃ ｄｅｓｃｒｉｐｔｉｏｎ ｏｆ ｔａｓｋ ｗｏｒｋｆｌｏｗ 每个任务都是不可分割的原子任务ꎬ要扩展某 一任务ꎬ只能在相应的流程处插入子网.任务的具体 内容由高级编程语言编写ꎬ任务获取环境信息、判断 任务成功执行或失败的代码都在其实现代码中.任 第 ５ 期 张鸿皓ꎬ等:水下机器人任务流程建模与管理 􀅰４３５􀅰