面向任务（共7篇）
面向任务 篇1
弹药调度系统是保障武器装备作战效能发挥重要组成部分, 快速、安全、可靠的弹药调度是现代作战保障的重要内容。调度任务具有流程复杂、批次量大[1]等特点, 正确评估调度系统完成任务的能力, 对战时指挥决策及保障资源的安排具有重要意义。
任务成功概率是装备在规定任务剖面内能完成任务的概率, 是任务成功性的度量指标, 也是重要的装备保障性评估指标。当前任务成功概率评估模型多是针对单系统开展研究, 系统组成结构串联或是并联, 根据系统部件的可修复情况和修复时间分布给出任务成功概率计算公式[2—4]。文献[5, 6]给出了多种任务特点及要求情况下可修系统的任务成功概率评估模型。对多阶段任务则是研究备件保障水平对任务成功概率的影响[7—10]。网络计划技术非常适用于复杂系统的分析, 其中主要的PERT技术主要考虑工序的时间取值对任务工期的影响[11,12], 没有考虑工序单元故障及修复情况;GERT模型根据概率有多个不同的引出端[13,14], 能够很好地描述流程中活动之间的关系及状态转移, 但不适用于逻辑关系要求严格的系统可靠性问题。多数方法研究保障系统本身的可靠性及维修策略问题, 而对保障任务组成及复杂度关注不够。
鉴于此, 本文基于流水网络计划技术提出一种较为通用的任务成功概率评估仿真方法, 面向多任务要求, 在考虑系统故障及维修资源的基础上, 处理诸如弹药调度系统等此类复杂系统的任务可靠性评估问题。
1 面向多任务的调度系统分析
弹药调度系统具有显著的网络计划性质, 多任务调度过程可理解为流水网络计划的任务分段处理, 但时距关系要求严格。分析其特征如下。
(1) 调度系统由多个相互独立的分系统组成, 分系统之间工作不交叉, 都可独自进行调度任务, 只是在管理系统的统一布置下并行工作。
(2) 分系统具有相同的工序组成, 逻辑关系相同并且要求严格, 分系统按照工序关系组成调度网络计划图, 流水网络计划以此为基础。
(3) 根据资源人员等限制, 确定某些分系统参与调度工作, 最后一个分系统完成任务后才算所要求调度任务的结束。
(4) 根据任务批次量及参与调度的分系统数量, 合理分配调度任务, 工作过程中可根据状态实时调整任务分配。
(5) 分系统中工序单元故障服从一定的分布, 可通过更换件等维修工作进行完全修复, 即故障后恢复为初始完整的功能状态。
(6) 暂不考虑修复失败的情况。
通常的解析方法针对的是串 (并) 联系统的单任务成功性, 或是单部件中多任务的成功性。而弹药调度系统由于其网络结构复杂, 且任务批次量多, 尤其是工序自由时差的存在导致工序单元故障率分布函数取值范围各相不同, 系统的故障率分布函数几乎不可整合, 特别是当工序单元分布函数不同的情况下更是如此。故而采用Monte Carlo仿真方法进行任务成功概率评估, 根据各工序单元分布产生随机数, 以此计算所需数据进行统计分析。
2 基于流水网络计划的任务总工期
2.1 分系统时间参数计算
一般流水网络计划是将一个任务计划分解为多个阶段实施, 以利于工程任务连续紧凑地进行。其区别于网络计划技术的特点是工序间存在时距关系, 即某工序只需其紧前工序开始一段时间后即可实施, 而不需要其完全结束, 如图1所示。
满足时距方程的网络计划才具有流水关系, 方程如下:
式 (1) 中, Ki, i+1为开始时距 (Ki, i+1>0) ;Ji, i+1为结束时距 (Ji, i+1>0) ;ti为活动的持续时间 (ti>0) ;i为活动的代号 (i≥0) 。
而调度任务本身具有多阶段性质, 单个调度分系统任务计划的实施由多个相同的任务流程组成, 每个任务流程都具有相同逻辑顺序关系的网络图, 依照约束条件多个任务流程顺次展开, 最后一个任务流程完成时整个任务计划才算结束。只是其时距关系相对较为严格, 同一流程的工序只有在紧前工序完成后方可开始, 需要对一般流水网络计划的时距方程加上Ki, i+1≥ti条件, 关系如图2所示。此时的工序显然也满足时距关系, 这里仍称作流水网络计划技术。
在此时距关系基础上计算流水网络计划的时间参数, 这里仍以网络计划通常使用的参数作为对象;但需做出调整。假设参与调度任务的分系统共计M个, 第m个调度分系统负责Qm个批次量的任务。双代号网络计划图有n个工作节点组成, 第q个任务流程的工序i-j的时间参数以此表示为:工序持续时间Dm, qi-j、工序最早开始时间Em, qS, i-j、工序最早完成时间Em, qF, i-j、网络计划工期Tm, qp、工序最迟完成时间Lm, qF, i-j、工序最迟开始时间Lm, qS, i-j、工序总时差Tm, qF, i-j等。由于约束条件的变化, 对多任务流程的流水网络计划时间参数的通用计算公式进行修正。
2.1.1 工序最早开始 (完成) 时间
此参数不仅受同一任务流程下其紧前工序的约束, 也受限于前一任务流程的同一工序的完成时间。
(1) 网络计划起始工序:
(2) 其他工序:
式 (3) 中, Em, qS, h-i为工序i-j的各项紧前工序h-i的最早开始时间;Dm, qh-i为工序i-j的紧前工序h-i的持续时间;Em, q-1F, i-j为工序i-j的前一流程的最早完成时间。
计算从网络计划的起节点开始, 各任务流程顺着箭线方向依次逐项计算。
多任务流程的工序最早完成时间计算方法与单流程的网络计划相同, 公式为
2.1.2 网络计划工期
单个调度分系统的任务完成工期为最后一个任务流程的最后一道工序的完成时间, 本文流水网络计划中属于无规定工期情况, 各任务流程的计划工期即等于计算工期Tm, qc=max{Em, qF, i-n}, 其中Em, qF, i-n为第q个流程以终节点为完成节点的工序i-n的最早完成时间。显然此调度分系统的网络计划工期为Tmp=Tm, Qmc。则各任务流程的计划工期为不耽误下一流程完工的完成时间:
2.1.3 工序最迟完成 (开始) 时间
与最早开始时间类似, 受到其紧后工序和下一任务流程中同一工序的最迟开始时间约束。
(1) 以终节点为完成节点的工序:
(2) 其他工序:
多任务流程的工序最迟开始时间计算方法与单流程相同, 公式为
2.1.4 工序总时差
工序总时差表示该工序可以利用的机动时间, 这里仍用单流程计算公式
需要说明的是, 多任务流程工序总时差不仅对其本流程紧前紧后工序有影响, 而且影响到了其他流程工序的可利用时间。正是此参数的存在导致了不同工序相同的故障恢复时间对本分系统任务总工期的影响不同。流水网络计划中, 以各工序最迟开始时间为实际执行时间, 此时可充分利用总时差进行准备工作及任务间的休整。
2.2 总工期确定
基于单个调度分系统流水网络计划时间参数的计算, 确定整个调度任务的总工期。由2.1节可知, 只要确定了调度分系统各任务流程的工序持续时间Dm, qi-j, 就可计算出此系统的任务工期, 因此可将其表示为工序持续时间集合的函数形式:
式 (10) 中, 所有流程工序持续时间集合, 而各任务流程工序时间参数集合
整个调度任务中所有调度分系统全部完成工作后任务才算完成, 亦即是任务总工期由最后完成任务的分系统工期决定, 表示为
2.3 任务分配调整方法
由于各调度分系统组成结构相同, 对每批次调度任务的相同工序持续时间可认为是无差别的, 在任务进展顺利 (即系统各阶段无故障现象发生) 时, 分系统工期与任务批次量有关。此种情况下调度系统可靠性达到100%, 依据对式 (11) 的最小化原则即可确定各分系统的任务批次量。然而, 调度任务风险就是由系统不可预测的故障所造成的, 分析任务成功性则是考虑可能出现的系统故障对任务总工期的影响。
可以设定各分系统的同一工序i-j的故障修复时间为Ri-j。为方便计算操作, 调度任务进行时若分系统m的第q批次任务流程中某工序i-j发生故障, 可任务此时的工序持续时间增加了修复时间的增量, 表示为
考虑修复时间的分系统可形成新的工序持续时间集合, 若任务批次量不作调整, 则其工期表示为。发生故障的情况下, 分系统工期可能显著延长, 必要的情况下则需要向其他分系统转移尚未开始的任务, 其工期又与调度任务量有关, 修正分系统工期表示函数为
设定各分系统的任务量为Q=[Q1…Qm…QM], 依据式 (10) 得到的工期值, 各分系统任务量调整方法如图3所示。
在这种情况下, 以整个调度任务总工期最小化为目标, 以动态调整各分系统的任务批次量为手段来调整调度过程中个别工序故障造成的影响, 在实际可操作情况下获得了任务总工期及各分系统任务量。
3 任务成功概率计算模型
3.1 任务成功率模型
弹药调度的任务成功性表现为调度系统设定保障资源的情况下按时完成规定任务的可能性, 对应的任务成功概率是指其规定任务剖面中成功完成的概率。则可定义弹药调度系统任务成功概率为其任务成功完成总次数与任务执行总次数的比值, 应用蒙特卡罗仿真方法可以简化任务成功概率的计算, 即任务成功概率PMCS=成功完成任务的总次数/仿真总次数。
由第2节的计算可知, 调度任务成功性与上级下达的调度时间有直接关系, 这里要求的调度时间表示为TR, 第w次仿真的任务完成工期为T (w) 。显然, 当T (w) ≤TR时任务成功, 否则失败。统计得出在共计W次仿真中, 按升序关系出现的任务完工期有T=[T1T2…Tc…], 对应出现的频数为N=[N1N2…Nc…], 即有∑Nc=W, 表示其出现概率为P=[P1P2…Pc…]。以要求调度时间TR确定截断位置c', 即当c≤c'时Tc≤TR, 当c>c'时Tc>TR。根据以上描述, 则可得到仿真方法下与TR有关的任务成功概率模型:
式 (14) 表示了任务成功概率与任务要求调度时间的关系, 在加上第2节中考虑到的计划工期与流水网络计划中工序持续时间及故障修复时间的关系, 任务成功概率仿真方法如实反映了调度系统结构组成及可靠性对调度任务的影响。
3.2 仿真操作方法
3.2.1 随机数产生方法
蒙特卡洛仿真的基础工作即是产生合理的随机数, 就本文而言需要产生调度各分系统所有任务流程下的工序持续时间, 以及在此基础上根据工序单元的可靠性分布产生故障点, 进一步修复时间也可随机产生。
设总的调度任务批次量为Q, 各分系统的任务量为Q=[Q1…Qm…QM], 由于调度过程中不可预测故障的出现, Q是动态调整的。而对于每一次仿真过程而言, 各分系统工序的持续时间一旦产生之后就是固定的, 不可随任务量的增减而改变。这里为保证操作方便, 在第w次仿真过程中, 对每个分系统m的工序i-j持续时间都产生Q个, 即, 任务工期计算过程中, 根据分系统的任务量取其前Qm个进行运算, 可保证Qm≤Q。具体的数值根据工序的持续时间分布随机产生。
随机产生的时刻点落在范围内, 表示该工序单元此阶段任务过程中出现故障, 则应用公式 (12) 处理其持续时间。需要说明的是, 由于故障均可通过更换备件等措施予以排除, 可认为单元“修复如新”, 即其累计工作时间需要从0重新开始算起。
以上的相关随机数产生方法确定了各调度分系统的时间参数, 只是的维数全为总任务批次量Q, 通过任务工期的计算及任务量的调整, 可最终确定此次仿真过程中的任务总工期及各分系统的任务量。
3.2.2 仿真流程
根据随机数产生方法及通用Monte Carlo方法, 基于仿真过程的多任务调度系统任务成功概率评估流程如下。
步骤1:设定仿真次数W、调度批次量Q、参与调度的分系统数量M, w=1;
步骤2:产生各分系统工序的Q维持续时间集合, 以此为基础产生随机故障点, 修正持续时间集合为
步骤3:确定各分系统任务量Q=[Q1…Qm…QM];
步骤5:如果需要根据2.3节方法调整Q, 转步骤3, 否则转步骤6;
步骤6:若w<W, w=w+1转步骤2, 否则转步骤7;
步骤7:统计总工期为Tc的次数Nc, 获取各总工期值出现的频率P=[P1P2…Pc…];
步骤8:根据式 (14) 得到任务成功概率与要求调度时间的关系PMCS (TR) ;
步骤9:结束。
3.3 几类情况考虑
考虑到调度系统工序持续时间分布、故障概率分布、修复时间分布以及保障资源配置对任务成功性的影响, 将调度任务可能遇到的情况分为以下几类。
3.3.1 Ⅰ类情况
此类情况属于无故障条件下的任务调度, 调度系统各设施设备可靠性极高, 或设定任务下故障现象不可能发生。则仿真过程中只需确定工序持续时间, 根据均衡化原则确定调度任务分配方案, 以任务总工期最小化为目标静态确定调度时间。
3.3.2 Ⅱ类情况
通常情况下需要考虑工序可能的故障情况。工序单元的可靠性函数与其累计工作时间有关, 实际情况中必须考虑发生故障情况下的调度任务风险。由于故障发生的不可预测性, 工序故障修复时间显然影响了此分系统的任务工期, 进而可能影响调度任务总工期。若分系统的任务工期由于故障而显著延长, 则需随时调整任务分配方案, 仿真过程中这是个动态过程。进一步可讨论工序故障修复持续时间的取值, 通过其分布函数同样随机产生式 (12) 中的Ri-j。
3.3.3 Ⅲ类情况
以上两种情况下没有考虑维修资源的限制, 而有些情况下维修小组数量级备件数量会限制到故障的即是修复。此类情况下可能会出现两种结果: (1) 维修小组的限制, 倘若某工序故障时所有的维修小组已经处于忙的状态, 则修复时间Ri-j还需加上等待时间; (2) 备件数量的限制, 如果某工序故障时缺乏相应备件, 则其处于不可修复状态, 此分系统只能完成本工序之后业已开始的任务, 之前的乔杜批次量需要调整给其他分系统。
4 算例
某调度系统包括6个工序逻辑关系相同的分系统, 网络计划关系如图5所示。系统中各工序执行小组兼有维修职责, 故可不考虑维修资源对任务进度的影响, 显然属于Ⅱ类情况。下面对调度任务批次量为Q=20的任务成功概率进行仿真分析。
工序持续时间采用三时估计法确定, 其概率分布可认为是正态分布, 分布形状可由乐观时间a、最可能时间m和悲观时间b确定, 计算公式:期望、方差。工序单元故障率服从指数分布F (t) =1-e-t/λ, 故障修复时间认为是固定的。相关时间参数见表1, 时间单位为同一量纲。
仿真次数设置为W=10 000, 图6所示为当参与调度任务的分系统数量为3时的一次仿真结果, 进度条中间的数字表示此分系统的第几批次任务, 3个分系统的任务批次量依次为7、7、6, 调度时间由分系统1决定, 进度条中浅颜色为故障修复时间。调度任务成功概率随要求调度时间的变化情况如图7所示。
当参与调度的分系统数量不同时, 对应的任务成功概率及要求任务工期显然不同, 图8所示为任务成功概率分别为99.9%、99.0%和90.0%时不同分系统数量对应的要求任务工期大小。参与调度的分系统数量要求越多, 需要的资源及人员也就越多, 此参数的意义在于可供指挥决策人员综合任务工期、可靠性要求以及调度资源来确定调度方案。
5 总结
从弹药调度系统执行多任务情况出发, 分析提取了此类复杂系统的特征。应用流水网络计划技术确定了分系统固定任务下的进度时间参数, 在确定任务总工期的基础上建立了任务成功概率仿真模型。此模型具有广泛的通用性, 工序单元可服从不同的可靠性函数, 甚至只需知道工序持续时间及故障时间的取值规则和范围便可进行仿真分析, 系统结构越复杂越能体现其优越性。此方法给出了几类不同保障情形下的应用形式, 正确评估了复杂多任务下的任务成功概率, 为弹药调度方案的制定及保障资源的优化配置提供决策依据。
摘要：正确评估弹药调度系统的任务成功概率, 作为装备可靠性分析的重要内容, 是制定装备保障方案和优化配置保障资源的重要依据。针对多任务调度系统的复杂性, 以流水网络计划为框架, 计算分系统调度进度时间参数。考虑工序单元故障及修复时间的情况下动态调整分系统的任务量, 最终确定任务总工期。以此将任务总工期作为任务成功概率的比较数据, 根据工序持续时间及故障时间分布产生随机数据, 应用蒙特卡洛方法对仿真结果进行统计分析, 建立了任务成功概率评估模型。并且分析了几类维修资源配置情形下的仿真操作方法, 提高了评估方法的实际应用能力。最后, 通过一个算例验证评估方法的有效性和实用性。
关键词：多任务,任务成功概率,流水网络计划,工期,蒙特卡罗法
面向任务的知识支持系统研究 篇2
在企业中实施知识管理是赢得竞争优势的一项重要手段,因此知识管理系统应最大化知识资产的效率,进而为企业增加收益和产量。企业的工作和管理活动都是面向任务并且是知识密集的,因此在实施知识管理时一项重要的工作就是提供任务相关的知识,以满足在执行任务时设计者的知识需要[1]。从先前工作中萃取的知识可以给正在实施的任务提供有价值的知识,同时也是构建一个满足用户任务需求的任务模型的有价值的来源。而目前企业的各种设计活动主要是面向设计任务的,本文构建了面向设计任务的知识提供方法,提供任务相关的知识,以满足设计者在执行任务时的知识需求,以机械加工工艺为实例建立的知识支持系统。
1 面向任务知识模型描述
构建一个满足用户任务需求的任务模型是设计知识提供的首要目标[2]。根据任务特征构建面向任务的知识模型。任务是根据具体领域工作流程确定的一个相对独立的、有明确目的的、以人为执行主体的工作单元。通过对这些任务的求解,实现提供满足用户个性化需求的知识和案例。
面向任务的知识模型的结构如图1所示。在任务求解过程中,用户根据自己的需求输入参数,通过匹配领域知识中的相关推导规则,确定任务求解所需要的知识范围、知识类型、知识结构。此外,不同的用户由于受本身经验、技能、教育程度、知识水平等影响,其思维和检索行为存在差异,因此还可以通过测试用户的知识水平、记录、分析用户的操作行为等来获取任务求解过程中用户对知识的需求。面向任务的知识模型包括任务知识结构、用户知识结构、用户行为特征信息等,系统根据这些信息向用户推送他最需要的知识。
2 知识支持系统
2.1 知识获取、知识表示
知识获取就是从人类专家获取领域知识并将知识转化为计算机可利用的形式送入广义知识库[3]。该系统采用的知识获取方式主要有以下两种:1)从设计标准、手册、规范和专家经验中获得;2)询问专家。
知识表示主要研究用什么样的方法将解决问题所需的知识存储在计算机中,并便于计算机处理[4]。该系统的后台知识库总体结构采用多文件形式的层级树形等级结构。从理论上讲,多文件结构是多个等级结构的集合。等级结构的最底层是知识单元,这些知识单元是最小的在知识利用时可操作的符号集合。知识单元包括名称、知识本体和所属知识结构层三部分。知识单元的定义如下:
知识库中存储的内容包括知识单元、分类结构、测题、设计经验、技术数据等。其中知识单元是对书本、设计参考书之类的整理和归纳,包括工艺设计的各个方面,如加工方法、机床设备、金属热处理、工艺规程的制定等内容,为用户提供翔实的设计资料参考。设计经验是对零散的专家经验等的整理。技术数据对应于工艺设计手册和已规范化的工艺规程等,由加工材料数据、加工数据、机床数据、刀具数据、量夹具数据、标准工艺规程数据、成组分类特征数据等组成。
工艺设计中的知识包括金属切削加工、加工工艺规程、典型零件加工工艺、典型表面加工工艺等围绕工艺设计的各方面。按照之前所述的知识树状结构对加工工艺领域内的知识进行组织。机械加工工艺知识结构树如图2所示。
2.2 知识支持实现机制
根据设计过程中的任务确定的任务知识需求与个体无关,而设计者个体之间差异的客观存在导致了在完成同一任务时对知识的需求不同,用户知识需求是知识支持系统的驱动因素,知识支持系统实现机制是利用一些测试题对用户进行测试,并根据用户的反应情况来估测其能力以及领域知识的掌握程度,它是系统对检索和知识补充进行动态组织的重要依据。通过它能够了解用户的原有知识水平、认知水平,并给出相应的知识评价和补充建议,从而系统根据用户知识需求进行知识查询,将查询结果主动提供给用户。用户待补充的知识根据用户自身特点和业务过程中用户所承担的任务和充当的角色等因素来确定。
知识检测应具有极高效率,尽可能以最少的测试内容诊断出用户的真实能力,而且在不同环境、不同时间内所诊断的结论是一致的。测题参考人类认知和教育测量理论制定[5]。测题方式采用计算机易于识别的单选题、多选题、判断等形式。根据任务知识模型产生任务测题库,从任务测题库中随机抽取一定量的试题构成试卷。测题包括理论知识的客观测试题和用户主观测试题。测题的产生应经过知识评测,本文运用灰色聚类评价方法进行知识评测[6],检测过程如图3所示。
3 知识支持系统应用
本系统以Windows XP服务器操作系统和Apache tomcat服务器为平台,采用浏览器/服务器模式(Browser/Server,B/S模式)的体系结构,SQL Server 2000数据库管理系统作为后台知识库的存储工具,人机交互界面利用jsp语言在通用工具平台Eclipse环境下开发,实现系统的在线服务,图4为系统一运行界面。整个系统涉及多个界面的显示与操作,主要有以下3个模块:
1)系统管理:主要提供用户注册信息显示与更改,审核用户注册信息和修改用户所具有的权限等功能;
2)知识管理:主要实现对知识信息的管理,包括知识审核、添加知识、修改知识、删除知识等功能;
3)知识支持:系统的核心模块。主要根据设计任务的描述来提供用户所需的领域知识和经验实例,使用户能够快速的利用和学习知识,以便为用户提供设计参考和解决思路。
4 结语
本文构建面向任务的知识提供方法,可提供任务的相关知识,以满足设计者在执行任务时的知识需求,并以机械加工工艺为实例建立了知识支持系统。其主要目标是实现设计知识继承和共享,从而解决海量知识利用问题,为企业设计人员提供更强有力的设计支持。
参考文献
[1]Duen-Ren Liu.Collaborative relevance assessment for task-based knowledge support[J].Decision Support Systems,2008(44):524-543.
[2]Simon Szykman,Ram D.Sriram.The role of knowledge in next-generation product development systems[J].ASME Journal of Computer and Information Science in Engineering,2001,1(1):16-21.
[3]杨炳儒.知识工程与知识发现[M].北京:冶金工业出版社,2000.
[4]Chen Y M,Chen Y J,Wang C B,et al.Knowledge refinement for engineering knowledge management[J].Concurrent Engineering,Research and Applications,2005,13(1):43-56.
[5]余胜泉,何克抗.基于Internet网络的适应性学习系统的研究[C].第三届全球化人计算机教育应用会议,1999.
面向任务 篇3
1 面向任务的作战系统模型及结构
作战系统模型由作战需求视图和UML子图组成。作战需求视图中包含使命和任务两种建模元素。使命确定系统的设计目的和范围,需要多个不同的任务协同完成。任务的动态需求用活动图建模,静态需求用类图建模,功能需求用自然语言对事件的前置和后置条件进行建模。由于自然语言无法形式化,文中提出用对象图来描述功能需求,把动态需求和静态需求结合。对象图中对象是静态需求中类的实例。
以作战系统中护航使命模型为例,潜艇为完成护航使命需要不断侦察是否有敌方目标出现;如果出现敌方潜艇,需要发射鱼雷攻击,所以把护航使命分解成侦察和雷攻击两个任务。
静态需求模型:图1是护航使命的类图。一个潜艇(Submarine)有多部声纳设备(Sonar),同时装载了多个鱼雷(Torpedo),需要一个鱼雷发控装置(Torpedo Fire Control)来控制鱼雷。声纳(Sonar)可以同时探测多匹目标,假定目标为敌方潜艇(Enemy Submarine),检测到目标后发射鱼雷攻击目标。由于在需求阶段,图1中的类没有添加方法,图2是类图的一个实例图。
动态需求模型:图3是护航的作战需求视图以及任务的活动图。潜艇用声纳来侦察,侦察任务首先需要声纳开机(start Up Sonar),然后探测目标(detect),如果目标有威胁,攻击目标(attack)。鱼雷攻击任务活动图包括鱼雷发控装置开机(Startup Torpedo Fire Control)、发射鱼雷(shoot)和设置目标位置(set Target)。
功能需求模型:功能需求用对象图对事件前置和后置条件进行建模。在任务模型中,事件指动态需求中的活动(actions)。侦察任务和鱼雷攻击任务的活动图中事件的前置后置条件分别如图4和图5所示,对象图中每个对象都是静态需求UML类图的实例,例如:在图4声纳开机(startUpSonar)功能需求中对象Submarine是图1中类Submarine的实例。
由于多个需求分析人员分析不同的任务需求,导致模型中存在语义上的重叠,在多个任务协作完成使命的过程中产生错误。需求模型不一致将导致设计中的错误,事后修改代价非常高;如果错误未被发现则会影响系统的可靠性和健壮性。上例中侦察任务和鱼雷攻击任务的功能需求之间存在语义上的重叠,攻击目标(attack)和发射鱼雷(shoot)都删除了Torpedo。由于两个任务协同完成护航使命,所有任务的活动必须依次执行。但由于语义上的重叠导致攻击目标(attack)和发射鱼雷(shoot)无法依次执行,所以功能模型之间存在冲突。
2 作战系统模型一致性检测方法
属性图文法[4]既有直观的图形符号又有较成熟的形式化理论,基于规则的图转换可以有效地描述任务的功能需求,所以把作战系统模型的UML子图转换成属性图文法并形式化检测功能需求之间的冲突和依赖。
2.1 UML子图转换成属性图文法
2.1.1 UML类图转换成类型图
定义1 一个类图模型是一个五元组C=(Cn,Cp,Co,Cr,Cm),其中,Cn表示类名;Cp表示类属性;Co表示类的操作;Cr表示类之间的关系;Cm多重性。文中讨论的类图是处于需求阶段,只考虑类图的静态特性,由于类的操作属于动态性的知识,不予考虑。
定义2 一个类型图模型是一个四元组TG=(TGn,TGp,TGr,TGm),其中TGn表示图的名称,TGp表示图的属性,TGr表示图的关系,TGm表示多重性。
显然,很容易把类图转换成属性图,由于不考虑类的操作,类图中的Cn,Cp,Cr,Cm可以直接转换成类型图中的TGn,TGp,TGr,TGm。类之间的关系Cr有联系(Association)和泛化(Generalization)等。类型图之间的关系TGr有边(Edge)和继承(Extend)两种。类图中的泛化关系可以之间转换成类型图中的继承。
在大多数情况下,类图中两个类之间的联系是二元的,而且,聚集和复合总是二元联系。因此,文中只考虑二元联系。二元联系有一个联系名和两个联系端。每个联系端有一个角色名和一个多重性约束,一个描述导航性的属性和一个描述关系类型的属性。多重性约束描述的非负整数的范围表示该位置上可以有多少个对象,并且限制了一端的一个对象可以和另一端的多少个对象有联系。类型图中的边也是用来表示两个类型图之间的两个类型图可以相互拥有的对象的数目,所以类图中的联系可以直接转换成类型图中的边。
2.1.2 UML对象图转换成规则
定义3 UML对象图是一个二元组G={N,E}。N 为节点n的有限集;E为边e的有限集;节点n及边e都用对象表示。
在上文中已经介绍了,活动图的前置后置条件用UML对象图来描述,且UML对象图中的对象都是UML类图中类的实例。在属性图文法中,规则的前置后置条件中的属性图都是类型图的实例,可以直接把UML对象图中的对象转换成规则前置或者后置条件中的实例。UML对象图中的边可以转换成规则前置或者后置条件中的边,所以UML对象图可以转换成规则的条件后置条件。
利用上述转换方法,静态需求中UML类图对应属性图文法中的类型图。UML类图的实例图作为属性图文法的开始图,开始图代表图转换的起点。功能需求转换成属性图文法中的图转换规则集,功能需求前置条件对象图对应规则的左部图,后置条件对象图对应规则的右部图。由于模型中没有对功能需求限制执行条件,所以属性图文法中约束集为空。本文用AGG工具来分析任务模型转化的属性图文法,得到功能需求之间的冲突和依赖。
两个图转换规则之间有依赖关系是指一个规则的执行必须以另一个规则的执行为前提条件,AGG工具检测出所有功能需求之间的依赖关系,但没有进行详细分析。循环依赖是指依赖关系中出现环,错误依赖表示功能需求之间依赖关系与动态需求中活动图的执行流程不一致。循环依赖或错误依赖一般是设计中的错误,所以需要对依赖关系进行验证。
2.2 循环依赖检测算法
该算法对使命中功能需求之间的依赖关系深度搜索,同时加入栈来记录搜索路径,如果在搜索中出现栈中已经存在的功能需求,说明找到环,同时输出环中所有元素。假设有3个功能需求A、B、C,A依赖B,B依赖C,C依赖A,三者的依赖关系形成一个环。首先对A的依赖关系进行深度搜索,通过A的依赖关系找到B,再对B进行搜索,找到C,这时栈中保存的是A、B、C,在对C进行搜索的过程中找到A,因为A已经存在栈中,所以找到一个环,输出环中元素A、B、C、A。相关定义如下:(1)功能需求FunctionRequirement=<name,dependencs>,name是名称,dependeces是该功能需求依赖关系数组。(2)任务Task=<name,functionRequirements>,name表示任务的名称,functionRequirements是任务的功能需求数组。(3)使命Mission=<name,tasks>,name表示使命的名称,tasks是完成使命的所有任务。(4)frs数组记录使命中所有功能需求,用visited数组来表示功能需求是否被遍历过,初始化为false。(5)栈stack用来记录遍历路径,算法调用之前栈为空;top表示栈顶的位置,初始化为-1。(6)count用来记录环的个数,初始化为0。
2.3 错误依赖检测算法
假设活动action1的功能需求依赖活动action2的功能需求,且action1和action2在同个活动图中,那么action2必须在action1之前执行,即活动图中必须存在action2→action1或者action2→…→action1执行流程,否则该依赖关系是一个错误依赖。UML活动图中主要的建模元素是活动(Action)、判断(Decision)和转换(Transition),因此判断活动图的执行流程时节点只考虑这3个元素。首先需要遍历活动图中的所有模型元素,找到所有的活动和判断节点。然后从action2开始对活动图进行深度搜索通过单步转换(Transition)到达的活动或判断节点,如果在搜索的过程中发现action1,说明活动图中有该活动流,否则继续至结束。相关定义如下:(1)功能需求FunctionRequirement=<name,dependencs>,name表示名称,dependeces是该功能需求依赖关系数组。(2)任务Task=<name,functionRequirements>,name表示任务的名称,functionRequirements是任务功能需求数组。(3)actions数组记录活动图中所有的活动,decisions记录活动图中所有的判断。(4)isActionVisited数组用于记录活动图中所有的活动是否被搜索过,与actions数组对应;isDecisionVisited数组用来记录活动图中所有的判断是否被搜索过,与decisions数组对应。
3 一致性检测系统的实现及验证
作战系统需求工具中用AGGCT一致性检测方法来保证建模的正确性。基于AGGCT一致性检测系统的输入是有领域模型和UML模型组成的作战系统模型,检测结果会输出所有的冲突依赖关系、错误依赖和循环依赖。检测系统的类图如图8所示,其主要职责如表1所示。
用该系统检测第一章中的护航使命模型,图8是AGG检测出shoot和attack都删除了torpedo引起的冲突。由于协同完成护航使命,只能由其中一个执行删除操作。所以修改了attack活动的功能需求,删除torpedo操作只由shoot活动来执行,消除了冲突。
AGG工具把所有任务的功能需求之间的依赖关系用矩阵显示,如图10所示,记每个功能需求为pi,如果pi依赖pj,则表格第j行第i列的数字>0,如果没有依赖关系,则等于0。例如:attack依赖于detect,那么第2行第3列上的数字约为0。功能需求不能依赖本身,所以矩阵对角线的位置并没有计算。
一致性检测系统对图10中所有的依赖关系进行检测,发现依赖关系中没有循环依赖,shoot对setTarget的依赖关系是错误依赖。在图3中,鱼雷攻击任务的活动图中发射鱼雷(shoot)发生在设置目标位置(setTarget)之前,而功能需求中shoot对setTarget的依赖则要求设置目标位置(setTarget)必须在发射鱼雷(shoot)之前执行。所以,修改鱼雷攻击任务的活动图,把设置目标位置活动(setTarget)放在发射鱼雷活动(shoot)之前,活动的执行流程与依赖关系一致,消除了错误依赖。
4 结束语
模型一致性以及验证一直是软件工程领域内研究的热点,本文考虑作战系统中不同需求分析人员针对不同的任务进行分析的特点,提出一种基于图文法形式化检测任务模型一致性的方法,把作战系统模型转换成属性图文法并检测功能需求间的冲突和依赖,同时验证了依赖关系中是否存在循环依赖和错误依赖。提出了相应的检测算法,循环依赖检测算法通过深度优先搜索找到依赖关系中的环,同时输出环中的所有依赖关系;错误依赖检测算法对活动图进行深度优先搜索,检测功能模型的依赖关系与动态模型的执行流程是否一致。任务可能还含有子任务,子任务是否可以继承父任务的约束关系,以及如何检测子任务间的冲突和依赖,可以作为下一步的研究方向。
参考文献
[1]陈卉,窦万峰.UML顺序图与状态图的一致性检查[J].计算机工程,2008,34(18):62-64.
[2]张自强.基于自动机理论的UML模型一致性研究[D].兰州:兰州大学,2009.
[3]JAN H H,REIKO H,GABI T.Detection of conflicting fuc-tional requirements in a use case-driven approach[J].SoftWare Enginneering,2002:105-115.
[4]邢阳,谢德平,马晓星,等.一种图文法制导的软件体系结构开发环境Artemis-GADE[J].计算机研究与发展,2010,47(7):1166-1173.
[5]韩秀清,曾晓勤,邹阳,等.图文法综述[J].计算机科学,2008,35(8):10-16.
面向任务 篇4
在网络技术支持下的网络化协同开发技术改变了传统的合作方式。不同设计师、设计机构、人员之间可以实现资源共享, 实时互动协作参与、合作设计, 避免了重复工作, 提高一起工作人们的整体效率, 从而提高产品设计的质量, 产品设计和开发, 降低成本, 缩短产品的设计开发周期, 提高产品服务, 实现提升企业核心竞争力的目的。
产品设计存在着大量复杂的、有依赖关系的设计活动, 产品的设计过程就是按照一定的顺序来进行这些设计活动的过程。因此, 产品协同设计的前提是任务分解, 任务分解需要依据一定的原则, 将总设计任务分解为多个子任务, 确立各子任务之间的关系, 便于设计人员进行协同设计。
1 协同设计概述
网络化协同设计是指在计算机技术、通信技术及多媒体技术的支持下, 将在地理位置上分散的各设计人员, 通过协同设计系统平台合作协同、充分利用各种设计资源, 实现协同产品的设计开发的过程。
在网络环境中, 处在异地的开发人员进行产品信息的资源共享和数据通信、进行设计方案的讨论、设计协同、设计结果的审核和修订。协同设计结合了网络技术与先进制造技术, 包含了行为学、社会学等多方面的研究, 深化了并行工程、敏捷制造等先进制造模式在设计领域中的应用。根据现有研究发现网络化协同设计具有以下特点:
(1) 多主体性:协同设计过程中协同人员构成较为复杂, 来自不同专业、不同知识背景, 在设计之初就需要整体考虑整个设计过程各个阶段可能出现的各种问题, 因此协同设计具有多主体性的特点。
(2) 协同性:在整个协同过程中, 信息的交互方包括领域内也包括跨领域信息交互, 其信息交互方式也存在同步和异步交互, 协同设计产品开发过程的实施有多个工作组, 根据设计的需求采用不同的交互方式来组织和完成设计任务。
(3) 灵活性:协同工作的过程会因为个体的不同而不同, 协同工作的结果也可能会因为协同工具的增强或者个体的增长而改善, 整体比较灵活没有固定的模式。
(4) 时效性:在协同设计工作中, 多个用户组成一个小组围绕着同一个产品任务来完成, 任务完成后, 协同小组也就解散。
(5) 共享性:协同的基本特点就是实现资源的共享, 信息在知识源之间可以交流互补, 以完善协同任务的效果。
(6) 异地性:参与协同设计的成员分布在不同地域。
(7) 互补性:参与协同的成员可以是来自不同专业, 互补之间的知识。
(8) 并发性和一致性:在同一时刻协同设计系统中分布在各地的协同人员有可能进行并发操作, 所以系统需要保证资源数据的一致性, 避免数据遭到破坏。
(9) 冲突性:产品开发过程存在约束及资源冲突。另外, 在产品的开发过程中设计需求的多样性及设计人员的学科背景差异, 造成合作必然存在冲突。
2 任务规划及其任务分解
在设计过程中, 设计人员以任务作为工作和调度的基本操作, 任务的产生有几种情况:可以是设计人员创建产生任务、协作小组中其他协作人员发送的任务和上级下发产生的任务。任务产生后生成任务完成计划存放于任务队列中, 任务完成计划的产生要考虑相关任务的时间、优先级、调度原则等参数进行指定。整个设计任务按照一定的划分规则及原理进行任务分解, 将任务分解为若干个子任务。
进行任务规划的复杂性在于:子任务之间具有串行和并行的时间约束关系;子任务之间具有依赖性, 某个子任务的修改会影响到和它关联的其他子任务, 导致关联子任务的修改。
任务分解是按照一定的划分原理和规则, 将任务分解为几个子任务, 同时确定子任务之间的相互关系。分解粒度较粗, 子任务个数太少, 会导致任务的复杂度太高, 影响子任务的完成, 不利于协同设计;反过来, 分解粒度较细, 产生的子任务个数较多, 任务复杂度会降低, 但对子任务之间的控制和管理会提高难度。因此, 任务分解是否合理, 会影响整个协同设计的顺利进行。
3 任务分解的原则
产品协同设计任务分解应遵循以下原则:
(1) 设计人员对于分解后的子任务是否满意。
(2) 分解的任务应具有一定的相对独立性, 减少子任务之间的相互依赖关系, 减少设计人员之间的信息交互。
(3) 分解后的子任务要便于控制与管理。
(4) 分解后的子任务完成后应易于组合装配。
(5) 子任务分解粒度要适中。
4 任务分解的方法
定义1满意度Sij为设计组j对任务Ti的满意程度。
满意度分别以数值{O, O.25, 0.5, 0.75, 1}来量化, 通过模糊变量集{很不满意, 不满意, 一般, 满意, 很满意) 来表示。
定义2平均满意度
式中m为设计小组的个数。
通过分析产品设计任务的功能和结构, 将整个设计看成总任务, 对其进行按层次分解, 当分解的子任务不能再继续分解, 判定为最小子任务不再进行分解, 否则, 对子任务进行满意度测评, 如果子任务的平均满意度达到阀值λ (0<λ
具体的分解步骤如下:
(1) 按功能与结构相结合的方式将任务T分解成子任务Ti (i=1, 2, …, n) 。
(2) 若Ti是最小子任务, 则不必再分解, 否则对其进行满意度测评。
(3) 若Si’>λ, 则不必再分解, 否则继续对Ti进行分解。
分解后的任务是一种树状的层次结构, 如图1所示任务结构树描述设计任务。在任务结构树中, 用符号T表示设计任务; 符号T1, T2……, Tn表示其子任务;符号Ti1, Ti2, ……, Tin 表示Ti的子任务。总任务为树的根节点, 然后分解成多个子任务, 叶子节点为最小子任务。
5 结束语
产品协同开发中的设计任务分解与分配是一个复杂的过程;其中涉及的影响因素和需要处理的信息较多, 需要与企业其他信息系统协调配合, 本文在分析协同设计过程特点的基础上, 提出了任务分解的原则及任务分配的数学模型, 实现了整个设计任务按照一定的划分规则及原理进行任务分解, 将任务分解为若干个子任务, 将合适的任务分配给合适的人的目的, 对协同设计实施产生了有效驱动。
参考文献
[1]高曙明.分布式协同设计技术综述[J]计算机辅助设计与图形学学, 2004 (16) 149-157
[2]贺东京.基于云服务的复杂产品协同设计方法[J], 计算机集成制造系统, 2011 (17) 533-539
[3]彭可.网络化控制系统的协同设计与形式化建模[J], 计算机集成制造系统, 2011 (17) 433-441
[4]王生发.产品协同设计过程中关键技术的研究与实现, 重庆大学学报, 2008 (30) 1899-1903
[5]徐路宁.基于网格的协同设计平台关键技术研究, 浙江大学学报, 2008 (39) 122-126
面向任务 篇5
装备保障训练资源是制约装备保障训练顺利、有效进行的关键性因素之一。在训练过程当中,由于参训人员种类多、训练科目多、训练资源需求大,各类参训人员的训练科目、训练资源需求交叉,使装备保障训练资源需求确定问题变得十分困难。本文力图在对训练资源使用进行优化的基础上,分析装备保障训练资源的需求,从而提高装备保障训练资源的使用效率,降低训练成本。
1 训练资源分析
1.1 训练资源定义及分类出于研究需要,本文采用多标准结合、分层次划分的分类方法,得到如图1所示的训练资源类型结构。
1.2 训练资源的属性参照表1,对于不同的训练资源有选择性地对其下述几种属性进行描述。
2 问题描述
将一个专业、一个等级人员的训练看为一个训练任务,则总的装备保障训练任务由多个不同的训练任务组成。对某一承训单位而言,其装备保障训练资源需求预测问题可描述如下:
总装备保障训练任务要在时间T内完成;共有n个训练任务,训练任务i的参训人数为Ni,i=1,2,…,n。求:承训单位在T时间内完成所有个训练任务所需的资源种类、数量,及总费用。
3 问题求解
3.1 现有装备保障训练资源使用优化
设承训单位允许的同时在训人员数量为C。按各训练任务总人员数量比例计算同一批次中各类人员的数量:
B—训练批次;N—训练人员总数;Nie—每批次参训的第i种人员数量。
完成训练任务共需m类主要循环使用资源,第j类的现有数量为Mj,其允许cj个人同时使用。根据开设的训练课程及其所需主要资源的类型,设置课程单元,使每一课程单元对应一种主要资源,以确定训练任务i对第j类主要循环使用资源占用的标准课时tij。同一批次训练任务i对第j类主要循环使用资源的总占用时间pij为:
训练任务/主要循环使用资源的时间占用矩阵P:
所需求解的问题即为求解:最短训练任务完成时间T*及各批次最短训练时间Te。
结合问题特点,作如下假设:(1)各项训练任务对主要资源的占用无先后顺序;(2)同一项训练任务对主要资源的使用无先后顺序;(3)各项训练任务对循环使用型资源的使用是可中断的。
根据以上假设,即可将上述问题转化为排序问题:
可参考文献[4]中所提供的方法对该排序模型进行求解。
3.2 装备保障训练资源需求计算具体求解步骤如下:
(1)计算T*。
(2)若T*燮T,转步骤六。
(3)若T*>T,转入下一步。
(4)计算追加的主要资源数量。
Mjd—实际所需第j种主要资源数量;Mj′—所需追加第j种主要资源数量。
(5)步骤五:计算追加的主要资源的费用。
Sa—追加主要资源的费用;Cj—追加的主要资源的单位成本。(6)计算所需追加的各类附属资源费用:
Sap—追加附属资源的费用;Mip—所需追加第j种附属资源数量;Cjp—第j种附属资源单位成本。
(7)按照各门课程同时所进行的最多班数,计算教员的需求数量。
(8)计算各类消耗型资源的需求和费用:
Msi—第i项训练任务各批次的第s种消耗型资源需求数量;Uji,s—训练任务i占用第j类主要循环使用资源时,单位时间内消耗第s种消耗型资源的数量;Ms—第s种消耗型资源的总需求数量;Cs—第s类消耗型资源的单位费用;Ss—消耗型资源总费用。
(9)计算各类循环使用资源的更新费用:
Su—资源更新费用;tjr—第j类资源的平均剩余寿命;tjl—第j类资源的寿命周期;Cju—第j类资源的单位更新成本。
(10)计算各类费用,及总费用。
St—教育训练费;Crti—第i类参训人员标准保障费;Nt—教员数量;Crtt—教员标准保障费;Mt—教学设施设备数量;Crtm—标准维护管理费;Sq—装备费;Mq—各类装备数量;Crq—各类装备标准维护管理费;S—总费用。
4 结束语
本文结合装备保障训练资源的特点,提出了一种新的训练资源分类方法。针对装备保障训练中出现的不同情况和各种装备保障训练资源的不同特征,采取不同的预测方法,建立了相应的数学模型。同时,根据本训练资源使用优化的结果,可对训练课程进行安排,在保证训练进度的前提下,提高训练资源使用效。
参考文献
[1]吴铨叙.军事训练学.军事科学出版社,2003.
[2]胡利民等.总装部队军事训练概论.国防科技大学出版社,2005.
[3]胡利民.装备训练学.国防工业出版社,2004.
面向任务 篇6
服务组合优化是云制造中构造松耦合敏捷制造方案、实现资源优化配置的关键技术[1,2,3]。传统服务组合优化研究主要围绕着计算资源、Web服务、网格制造资源等服务类型展开[3,4]，并在面向服务计算（service-oriented computing,SOC)[5,6,7,8,9]及面向服务制造（service-oriented manufacturing,SOM)[10,11,12,13]等应用领域取得了一定研究成果。与传统研究相比，云制造领域服务组合优化问题的特殊性在于其任务请求的复杂性，主要表现在：(1)普遍存在的“多资源需求型”任务[10]并行请求服务的情形；(2)无法避免的强服务质量（quality of service,QoS）约束[7]情形；(3)可能存在任务请求相对于可用资源过量的情形。对于任务请求的上述复杂性因素，传统SOC领域及SOM领域尚无法有效应对[14]。因此，如何解决因多任务、强QoS约束及任务过量等复杂性因素导致的云制造系统组合效果不佳的问题，本文通过分析研究提出了面向复杂任务请求的服务组合优化全局策略（global optimal strategy for complex task oriented services composition,GOS-CTOSC）框架，并介绍了上述策略框架在云制造原型系统服务组合优化引擎中的实现及验证。
1 云制造典型的任务请求场景
本研究首先选取一个典型的云制造案例即摩托车的生产过程（图1）来阐述问题场景：摩托车生产包括从“车架生产”到“包装发运”的6个生产环节（子任务），每环节须在相应服务候选集（candidate service set,CSS）中选取一个构件服务（component service,CS）来执行相应的子任务，如成车总装可选取宗申或隆鑫装配线来完成。整体制造任务则由这些构件服务所构成的组合服务来完成。
假定每个服务候选集均给定3个可用的构件服务，每个构件服务的QoS指标值（以时间指标为例）给定在图2中。
场景1（多任务）：本场景假定制造任务T1和T2同时请求服务，均需从候选集CSS1到候选集CSS6中选取构件服务，并构造两个组合服务来响应制造任务T1和T2。其中，给定T1和T2的QoS约束分别为QoS-time1<523,QoS-time2<498。
场景2（强QoS约束）：本场景在场景1的基础上，进一步假定制造任务T2为强QoS约束（对完成时间要求极高），即给定T2的QoS约束为QoS-time2<350,T1的QoS约束仍为QoS-time1<523。
场景3（任务过量）：假设出现了同时请求的制造任务（不含强QoS约束的任务）多于可用服务的情况，即假定制造任务T1、T2、T3、T4同时请求服务，其QoS约束分别为QoS-time1<550,QoS-time2<1200,QoS-time3<1800,QoS-time4<1600。
2 传统服务组合优化策略概述与应用分析
2.1 传统服务组合优化策略概述
传统服务组合优化方法在实施组合优化时主要基于以下四种策略：(1)局部策略[6]。局部策略从每个子任务对应的构件服务候选集中选择QoS最优的构件服务，构造整体QoS较优的组合服务。(2)全局策略[6,7,10,14,15]。传统全局策略以单一“多资源需求型”任务请求为基本假设条件，依据构件服务对组合服务整体QoS水平提升的贡献大小来实施优选，寻求面向整体任务QoS最优的服务组合方案。(3)混合策略[16,17,18]。混合策略的基本思路是将整体任务的全局QoS约束分解为各子任务的局部QoS约束，进而实施分布式的优选过程。(4)改进全局策略[7,19]。由于全局策略可能无法找到可行组合服务，故改进全局策略加入了服务等级协议（service level agreement,SLA）协商机制。发生可行组合失败时，该机制松弛QoS约束直至最佳可行方案出现，以最大限度地保证SLA被满足。
2.2 传统服务组合优化策略应用分析
2.2.1 多任务场景下的组合优化
针对场景1，直接运用局部策略，即同时到达的制造任务T1和T2在局部策略的作用下将分别从各个云服务候选集中挑选出最佳的基础云服务，如图3所示。由图3可知，在多任务场景下，基于相同的评估指标体系、优选模型、优化算法，同一批优秀的候选服务易被多个复杂任务中相同类型的子任务同时选中，进而造成选择冲突。
再就场景1，考虑直接运用传统全局策略的情况：在全局策略的作用下，系统将逐一面向复杂任务T1和T2构造全局最佳的组合服务，如图4所示。
由图4分析可知：将复杂多任务请求转化为多次单任务请求后，可能出现先序任务用尽较优候选服务而后序任务难以保障SLA的现象，即次序冲突。
2.2.2 强QoS约束场景下的组合优化
针对场景2，当强QoS约束任务请求时，传统全局策略存在无法找到可行组合服务的可能[7]（图5）。局部策略、混合策略不可能构造成比传统全局策略QoS更优的组合服务，也无法克服强QoS约束下难以找到可行组合服务的缺陷。改进全局策略虽可通过协商SLA来降低某些QoS约束条件以最大限度保证SLA的满足，但不能避免因松弛QoS约束引发的组合服务QoS水平不足；即使形成最优组合服务，也是通过降低用户某些方面的QoS期望得到的结果，无疑是一种迫不得已的折中方案。
传统组合优化策略的局限性在于任务与组合服务之间存在双射限定。而单个组合服务所能提供的QoS存在上限，一旦任务的QoS约束增强到所有组合服务的能力上限之外时，即发生可行组合失败。
2.2.3 任务过量场景下的组合优化
在场景3的实例中，由于各候选集中均只有3个候选服务，故只可产生3个组合服务。依据传统策略，3个组合服务仅能响应3个制造任务请求，因而总有一个任务请求会发生服务响应失败（图6）。
实际上，从场景3的给定条件来看，3个组合服务的QoS较高，而4个任务给定的QoS约束偏低，因此存在完全响应4个任务请求的可能性。但传统组合优化策略限定组合与任务间“一一映射”关系，特别是任意组合服务只可为单个任务请求提供服务（独占性条件），使得某些任务享有的服务能力有余，而另一些任务的组合需求却无法得到满足。
3 云制造中面向复杂任务请求的服务组合优化全局策略
基于对传统组合优化策略的应用分析，本文认为云制造中的服务组合优化策略需考虑以下三大原则：(1)多任务全局优化，即构造面向复杂多任务的、整体全局策略；(2)组合服务捆绑，即突破任务请求只允许由一个组合服务来执行的基本假设；(3)组合服务共享，即破除加诸组合服务上的独占性条件。
根据上述原则，本文设计了云制造中面向复杂任务请求的GOS-CTOSC框架。GOS-CTOSC框架包含了由简至繁的三类组合模式定义。
3.1 单组合执行每任务组合模式
定义1单组合执行每任务（each composition for each task,ECET）组合模式，即针对每个任务请求只构造一个组合服务予以执行。
ECET组合模式适用于解决不含强QoS约束和任务过量的复杂多任务服务组合优化问题（场景1）。它是GOS-CTOSC框架中最简单的多任务服务组合优化全局策略，包含两个特征：(1)面向所有任务请求实施整体决策（区别于传统全局策略）。(2)任务请求与组合服务之间仍沿用“一一映射”假设条件。
根据定义1，其问题模型建立过程如下。
(1）设定决策变量x(i,j,k）。x(i,j,k)=1，即候选服务集CSSj中的第k个构件服务CS(j,k）被选取到组合服务Si中，用于执行任务Ti；反之，则x(i,j,k)=0。
(2）输入参数。qm(CS(j,k))(m=1,2，…，M）表示任意构件服务CS(j,k）所能提供的某种维度的QoS水平，例如q1(CS(j,k））可代表CS(j,k）时间维度的QoS水平，q2(CS(j,k））可代表CS(j,k）成本维度的QoS水平，q3(CS(j,k））可代表CS(j,k）可靠性维度的QoS水平。CS(j,k）所能提供的整体QoS水平，可用全维度的向量Q(CS(j,k))=(q1(CS(j,k)),q2(CS(j,k）），…，qM(CS(j,k）））来表示。qm(Ti）表示任意复杂任务请求Ti给定的某种维度的QoS约束。Ti给定的整体QoS约束可用向量Q(Ti)=(q1(Ti),q2(Ti），…，qM(Ti））表示。
(3）问题模型：
问题模型中，式（1）为目标函数，即用于执行I个任务的I个组合服务总体QoS最佳。式（1）使用标定后的QoS评估值，原因在于标定过程可消除不同QoS指标值之间的差异性，以利于比较[6?7]。式（2）表示任意组合服务的QoS需要至少满足对应任务的QoS约束。式（3）、式（5）代表基于简单加权法（simple additive weighting,SAW）的QoS值标定[6]。式（4）代表基于内部组合结构模式及其表达式计算得到的组合服务QoS值[5]，其中，fin代表内部组合结构模式的QoS计算函数。
针对场景1的求解，由图7可知，尽管ECET组合模式针对单个任务构造的组合服务QoS未必是最优（执行T1的组合服务QoS只有520，小于它所能达到的最优结果490），却能在多个任务间做到统筹规划，最终获得满足所有任务请求QoS约束的全局最优QoS值。
3.2 多组合执行每任务组合模式
定义2多组合执行每任务（multi-composition for each task,MCET）组合模式，即针对每个任务请求，由多个组合服务捆绑后形成一个组合服务组予以执行。
MCET组合模式适用于解决含强QoS约束的复杂多任务服务组合优化问题（场景2）。它包含两部分的整体决策：(1)利用可用的构件服务决策组合服务的构造、优选过程；(2)利用构造好的组合服务，决策组合服务组的形成过程。该模式破解强QoS约束任务请求的关键在于：以面向所有任务请求的整体决策为基础，通过将能力不足的若干组合服务捆绑来响应强QoS约束的任务请求，即允许组合服务与任务请求之间多对一的关系。
根据定义2，其问题模型建立过程如下。
(1）设定决策变量x(l,j,k）与y(l,i）。其中，x(l,j,k)=1表示第k个构件服务CS(j,k）自第j个候选服务集CSSj被选取到第l个组合服务Sl中；反之则x(l,j,k)=0。当y(l,i)=1时，表示第l个组合服务Sl被捆绑到第i个组合服务组SGi中，为任务Ti服务；反之则y(l,i)=0。
(2）输入参数。qm(CS(j,k））表示任意构件服务CS(j,k）所能提供的某种维度的QoS水平。CS(j,k）所能提供的整体QoS水平用向量Q(CS(j,k))=(q1(CS(j,k)),q2(CS(j,k）），…，qM(CS(j,k）））来表示。qm(Ti）表示任意复杂任务请求Ti给定的某种维度的QoS约束。Ti给定的整体QoS约束可用向量Q(Ti)=(q1(Ti),q2(Ti），…，qM(Ti））表示。
(3）问题模型：
式（6）～式（10）的意义与ECET的问题模型类似。MCET问题模型特殊在于：(1)目标函数（式（6））及约束条件（式（7）、式（8））的构成元素由组合服务替换成了组合服务组，以反映MCET下组合服务与任务请求之间的“多对一”关系以及“合众为一”的组合服务捆绑策略；(2)式（9）代表了如何从构件服务的QoS计算得出组合服务QoS，再得到组合服务组QoS的过程，该过程需运用内部组合结构模式及其表达式计算得到组合服务QoS[5]，以此为基础，再运用外部组合结构模式及其表达式得出组合服务组QoS[14]，其中，函数fin＿out代表运用内部及外部组合结构模式的计算表达式实施运算。
针对场景2的求解，由图8可知，基于MCET模式，当T1的强QoS约束导致单个组合服务无法满足时，可将多个组合服务再次聚集到一起，捆绑成一个组合服务组，共同响应强QoS约束的任务请求。
3.3 多组合执行多任务组合模式
定义3多组合执行多任务（multi-composition for multi-task,MCMT）组合模式。即若干任务可组成一个任务组，若干组合服务可组成一个组合服务组；一个任务组中的多个任务可共享使用一个组合服务组中的多个组合服务。
MCMT组合模式适用于有任务过量的复杂多任务服务组合优化问题（场景3），其整体决策包含三个部分：(1)合理的任务组划分；(2)组合服务的构造、优选决策；(3)合理的组合服务组构造。MCMT模式破解任务过量问题的关键在于：它同时满足多任务全局优化、组合服务捆绑、组合服务共享三个原则，允许组合服务与任务请求之间最一般的多对多关系，以最大限度地挖掘现有资源的潜力。
根据定义3，其问题模型建立过程如下。
(1）设定决策变量z(i,n）、x(l,j,k）、y(l,n）。z(i,n)=1代表第i个任务请求Ti被配属到第n个任务组TGn；反之则z(i,n)=0。
x(l,j,k)=1代表第k个构件服务CS(j,k）自第j个候选服务集CSSj被选取组合到第l个组合服务Sl中；反之则x(l,j,k)=0。y(l,n)=1代表第l个组合服务Sl被捆绑到第i个组合服务组SGi中，共享给第n个任务组TGn中的所有任务使用；反之则y(l,n)=0。
(2）输入参数。输入参数与多组合执行每任务组合模式输入参数相同。
(3）问题模型：
式（11）～式（15）的意义与ECET及MCET问题模型类似，MCMT问题模型的特殊之处在于：它新增了任务请求的分组过程（式（15）），并利用任务组对应组合服务组（式（12）），构成了GOS-CTOSC框架中最一般的“多对多”映射关系，形成了该框架中最一般的问题模型。但正因它的一般性，使之具有了极高的问题复杂度，也更依赖高效算法的设计与实现。
需要说明的是，组合服务组和任务组规模不会无限膨胀，且组合服务组也不会被无限划分。原因在于：(1)组合服务捆绑规模的增长会自然受到QoS指标体系的约束，例如：实施捆绑策略固然可利于QoS时间指标优化（更多资源执行任务使工期缩短），但同时也导致QoS成本、可靠性等指标恶化（租用更多资源需支付更多租金，协同更多服务环节使风险增加），故一定捆绑规模下会形成Max-min问题下的平衡态；(2)由于构件服务的QoS有限，则组合服务组必然存在QoS上限，故任务组规模扩张也将受到遏制；(3)由于资源共享将导致管理、物流、协同等额外开销，故组合服务组被无限划分共享的情况也会受到遏制。
基于上述问题模型，求解场景3如图9所示。针对场景3的求解，由图9可知，当组合服务相对任务请求发生数量上的紧缺时，可依据MCMT模式：一方面按照最适宜的分组数量对任务请求进行分组，另一方面按相同分组数量将构造的组合服务捆绑成若干组合服务组，并将组合服务组配置给各任务请求组共享使用，以此来化解组合服务紧缺的矛盾。
4 GOS-CTOSC框架的实现与验证
4.1 GOS?CTOSC框架在云制造原型系统服务组合优化引擎中的实现
GOS-CTOSC框架实现了三类组合模式：ECET、MCET及MCMT。其特性如表1所示。从表1可知，GOS-CTOSC框架中，三类组合模式的优势和局限均十分突出，没有一种组合模式可将其他模式完全代替。故在云制造应用中，可根据实际在适用范围、复杂度、难度间进行权衡和抉择。
注：A．单/多个“单资源需求型”任务或单个“多资源需求型”任务请求情形；B．不含强QoS约束和任务过量情形。
我们在前期研发的云制造原型系统[20]的服务组合优化引擎中设计实现了任务请求探测模块。该模块在调用GOS-CTOSC框架中不同的组合模式之前，会检测任务请求的类型，以便组合执行模块调用最适宜的组合模式执行服务组合优化过程。
GOS-CTOSC框架采用Java语言编程实现；同时，利用MATLAB实现了ECET、MCET及MCMT三种组合模式，并封装成可供调用的．jar文件。其中，ECET、MCET及MCMT实现模块均选取了时间、成本、可靠性三个维度的QoS指标，并分别基于3种组合模式的问题模型实现了对应的求解算法；求解算法采用了基于混合算子的矩阵编码遗传算法（hybrid-operator based matrix coded genetic algorithm,HO-MCGA）予以实现。在笔者的前期研究中，该算法对较复杂的组合优化问题具有良好的求解性能[14]。
GOS-CTOSC中实现多任务请求与组合模式的执行逻辑如图10所示。
4.2 模拟实验
基于4.1节的GOS-CTOSC框架实现，我们在云制造原型系统中分别模拟了多任务、强QoS约束、任务过量的情形。原型系统模拟生成上述三类情形的步骤如下：
(1）随机生成各候选构件服务的QoS指标值。
(2）从各个构件服务候选集中找到时间、成本、可靠性三种维度的最大、最小指标值；利用这些值计算组合服务的绝对最小、最大QoS评估值[6]（用Qmin、Qmax表示）。
(3）分别生成三类情形：(1)多任务情形。在[Qmin,Qmax）内随机生成若干任务请求的QoS约束，且任务数量少于给定的构件服务所能组成的组合服务的规模。(2)强QoS约束情形。在[Qmin,Qmax]内靠近Qmax一侧，随机生成若干任务请求的QoS约束，当其值接近Qmax时，即出现强QoS约束。(3)任务过量的情形。在[Qmin,Qmax）内随机生成若干任务请求的QoS约束，且任务数量可多于给定的构件服务所能组成的组合服务的规模。
从服务组合优化引擎的运行状况来看，GOS-CTOSC框架能高效高质量地求解多任务或强QoS约束场景下的服务组合问题（表2及图11）；传统全局策略因出现了无法满足某些任务QoS约束的情况，以致组合结果的QoS受惩罚而下降（表2）。此外，当任务过量时，GOS-CTOSC也能以显著高于传统策略的QoS响应所有任务请求（表2）。但在该场景下，GOS-CTOSC仅适合处理较小的问题规模，当问题规模逐渐增大时，其时间性能渐成瓶颈（见图11）。
5 结论
(1）指出了云制造系统任务请求的特殊性及传统服务组合优化策略应用于云制造典型场景存在的选择冲突、次序冲突、可行组合失败、服务响应失败等局限与原因，并提出了服务组合优化策略设计的原则。
(2）设计了面向复杂任务请求的服务组合优化全局策略框架，突破了传统策略面向单任务及加诸于任务请求和组合服务之上的“一一映射”基本假设，建立了以多任务全局优化、组合服务捆绑、组合服务共享为原则，适宜于云制造环境的ECET、MCET及MCMT组合模式。
(3）提出了以面向复杂任务请求的服务组合优化全局策略框架为基础的服务组合优化引擎实现方案，并在云制造原型系统中初步验证了其可用性。
面向任务 篇7
信息系统是由计算机硬件、网络和通信设备、计算机软件、信息资源、信息用户和规章制度组成的以处理信息流为目的的人机一体化系统[1]。信息系统应用于各个行业, 种类繁多。在军事应用领域, 仅从其载荷平台上划分, 就可分为陆基信息系统、海基信息系统、天基信息系统、空基信息系统。简言之, 空基信息系统就是运行于空中平台的信息系统。空中平台可包括飞行器、浮空器等, 可搭载信息系统包括预警探测系统、电子侦察系统、电子对抗系统、通信干扰系统、红外侦察系统等[2]。
空基信息系统的特点是信息获取、加工、存储、应用、分发等一系列过程都受限于其所依赖的空中平台。空中平台的机器性能、电讯性能、舱室空间、载荷能力、飞行高度、续航能力等都约束着空基信息系统的功能性能。因此, 空基信息系统除具有一般信息系统软硬件模块较多、功能复杂的特点之外, 还具有小型化、自动化、实时性、低功耗等特殊要求[3]。
目前, 软件数字界面已经越来越多地取代了传统的人-机 (器) 硬件界面而成为当今人机交互的主要载体, 操作者主要通过数字界面完成交互信息监控、决策分析和突发问题的解决[4]。空基信息系统人机交互设计不同于普通信息系统, 对系统操作流程、界面功能布局、操作席位设置等都有着特殊要求。以上因素既是系统硬件布局以及载机配重的重要依据, 又是影响空基信息系统整体效能发挥的重要因素。如何构建简单合理的人机交互方案, 在日趋庞大的空基信息系统中最大限度发挥人机工效是本文所要研究的问题。
1 技术现状分析
20世纪90年代后, 随着世界上先进军用航空电子系统技术的发展, 机载雷达、识别、侦察、通信和任务计算与人机界面等电子系统的综合性集成性高度依赖于软件架构, 并采用开放式网络体系架构融合了原来任务系统中各电子分系统的功能界面, 在软硬件配置规模上都产生了量与质的飞跃, 体现了大型信息化装备一体化发展特征[5]。目前, 国内外大型空基信息系统基本上都是采用多席位分工合作的方式来完成空中任务。通常情况下, 系统硬件数量较多, 分布于载机机舱及机身的各个部位, 机舱内分为设备区和工作区。设备区主要排布大型计算设备、通信设备和电源设备;工作区安装操作员工作台。以国外某型空基信息系统为例, 其任务舱设置13个操作台, 分别用于执行设备控制操作和信息处理操作。空基信息系统由于其所依附的空中平台研制难度以及其自身电子系统的高度复杂性, 在国外主要被欧美几个大型公司垄断。在国内, 空基信息系统研究领域较新, 目前处于快速成长时期, 某些系统正处于突破创新阶段, 难免遇到诸多问题。一个普遍的现象是, 重系统能力指标而轻人机交互, 重硬件技术攻关而轻软件流程设计。在解决军事装备或民用系统从无到有的阶段, 这种现象具有一定合理性, 但是, 一旦有无问题解决后, 就应该从实际应用中深层次探究系统运行效能问题。包括空基信息系统在内, 所有信息系统都是人机一体化系统, 系统效能能否充分发挥, 很大程度上取决于人机交互效率。就是说如何划分操作员席位职责、如何使操作员协同工作是提升系统运行效能的关键所在。
在空基信息系统研制初期, 通常迫于资料短缺和进度压力, 在实战业务研究上投入较少, 往往将关注点放在核心设备的操作使用上, 试图从专业设备的应用中找出解决业务需求的各方面问题。起初, 这种按照专业分类和硬件特性将全系统功能细化分解的方法, 有以下几个优点:
(1) 分类简单, 便于操作。空基信息系统由多组功能独立的专业设备组成, 每组设备本身构成一个完整的功能集合, 将每设备的全部或部分功能分配给一个操作员负责, 简单明了, 有利于系统的快速开发。
(2) 专业性强, 易于明确职责。空基信息系统中, 每组设备的专业性非常强、结构复杂。此划分方法有效化解了系统的复杂度, 使每个操作员只需掌握某个单一领域知识, 便于划分任务、明确职责。
虽然这种职责划分方法有着种种优点, 但是很难适应空基信息系统的发展要求。空基信息系统自诞生以来, 不仅在性能和威力方面改进需求不断, 而且在小型化、多用途方面也有着较多的改进需求。一方面, 为了满足更多任务需要, 空基信息系统功能越来越庞大, 需要配置更多的操作员;另一方面, 为了适应特殊战场环境, 载机体积不宜过大。因此, 在有限的载机空间中部署更多功能, 并且可以通过简洁合理的方式调用这些功能, 是系统人机交互设计的基本要求。按照专业分类和硬件特性的席位职责划分方法, 显然不能适应这些需求变化, 暴露出以下缺点:
(1) 操作人员需求量较大。以空基探测系统为例, 由导航、雷达、通信、情报处理等几大模块组成, 如果按照专业和硬件特性划分操作员席位职责, 一个完整的作战任务执行起来, 需要配备多名不同专业的操作员, 因专业差异较大, 操作员之间无法理解和胜任对方工作, 给用户培训和任务执行带来较大人员风险。
(2) 任务执行效率较差。一个任务流程要达到高效执行, 需要其中每个系统操作步骤都进行的恰到好处, 不烦不简, 整个操作流程衔接准确、合理有序。专业间的功能差异制约了操作员之间的协同合作。另外, 空间上的分散布局, 也是影响操作员交流效率的一大因素。因此, 这种分工方式, 使得操作员在任务执行过程中, 很难达到理想的交流状态, 任务执行效率难以得到保证。
(3) 系统冗余大, 不利于信息融合。空基信息系统数据庞大、结构复杂, 模块众多, 如果众多数据和模块不能合理划分、有效整合, 则会严重影响系统的整体运行效率。按照分系统专业归类的方法开发空基信息系统可以降低开发难度, 快速实现整个系统功能, 但是各个分系统之间的消息互通, 资源共享很难实现, 这就制约了系统效率。另外各个分系统之间的功能冗余和定义冲突则给系统开发带来了很大难度, 甚至是错误隐患。
2 面向任务的用户化方法
空基信息系统功能复杂, 操作项繁多, 但是对于某个具体任务来说, 通常不会覆盖全部操作功能。比如一个探测任务, 其任务目标可能仅仅是将探测目标航迹下传给地面指挥所。可以发现, 完成该任务所需要的系统操作并不多, 但是这个简单的任务所涉及的专业较多, 包括导航、雷达、通信等, 如果每个专业都派出一名操作员, 各司其职, 显然浪费了人力资源, 并且, 在某些体积较小的机型上根本容纳不下这么多操作员。
按照任务来定制系统操作界面可以很好地解决以上问题。依然以上述任务为例, 在任务执行前, 对系统进行配置, 使之启动后展现在操作员面前的只有与任务有关的操作菜单项, 其他功能都将被屏蔽。对于操作员来说, 这个操作流程并没有涉及专业性很强的领域知识, 也不需要精通任何一个分系统的操作流程, 只需要简单的理解任务即可胜任。系统画面简单明了, 系统操作清晰便捷。另外, 空基信息系统所执行的任务往往是重复的, 长期应用会发现某几种任务会被反复执行, 比如探测系统中的探测任务。对于这些日常执行的任务, 通过一定方式保存起来, 以备下次执行同样的任务时使用[6]。保存配置信息的方法很多, 本文采用用户化设计方法来解决这个问题。
一个任务的菜单项集合对应一个系统功能子集, 将这个系统功能子集保存起来并用某个代号表示, 再次执行该任务时, 根据代号调出该任务所对应的系统功能子集即可。这个代号本身维护起来比较困难, 也缺乏灵活性。为此, 提出系统用户概念, 将用户和任务进行绑定。使用户不仅包含访问系统的身份信息, 还包括职责信息。当系统为执行某个任务创建一个新用户时, 将执行任务所需要的功能菜单项赋予该用户。这样就使得每个用户对应一个系统功能子集, 如图1所示。
系统启动后, 选择用户进行登录。对于某个用户来说, 系统操作的目的简单明了, 系统所能调用的功能也仅限于为该用户所定义的任务要求。
3 基于信息生命周期模型的系统模块划分
实现面向任务的用户化方法, 必须有个前提条件, 就是系统功能模块化, 不仅如此, 还应该尽力使每个模块能够独立实现某项功能。系统模块划分方法较多, 但对于信息系统而言, 基于信息生命周期模型的系统模块划分方法更有利于提高操作员操作效率和系统运行效率。信息生命周期模型示意见图2。
根据信息生命周期模型划分系统模块, 首先需定义本系统所处理的核心信息, 然后根据核心信息的获取、加工、存储、应用、分发过程[7]逐条分解系统模块。然后, 根据功能类别及信息处理流程将整个系统划分为多个独立的操作单元, 在此称之为系统操作单元。每个系统操作单元对应一个系统功能, 在界面上表现就是一个菜单项。通过将菜单项添加给用户的方式, 将系统功能分配给用户[8], 如图3所示。
对于某个用户而言, 其所能够访问的系统功能由其所配置的菜单项决定, 如果在创建该用户时, 为其配置了雷达操作相关的菜单项, 则其主要面对的任务就是雷达探测任务, 如果在创建时, 为其配置了情报综合相关的菜单项, 则其主要面对的任务就是情报综合任务。
4 面向任务的用户化人机交互设计
根据任务定义用户的方法, 前提是系统操作模块化。以下分别通过对已有系统改造和采用全新设计的方式来实现本方法。
4.1 已有系统改造
通过对已有系统的界面进行改造, 来实现面向任务的用户化界面控制。一般情况下, 已有的空基信息系统中, 各个专业功能独立, 并且都已经历了多年的发展完善, 其内部结构已经相对成熟, 模块划分趋于合理。因此, 不需对系统实现部分进行改动, 只要将系统功能重新整合, 进行系统操作功能的模块化改进, 重新设计可配置的系统菜单, 建立用户机制即可。但是这种改造方式回避了系统内部信息处理流程改造, 实施效果有一定局限性。
4.2 基于MVC模式的综合显控一体化设计
通过对已有系统的改造来实现面向任务的用户化界面, 只是从界面操作上提高了系统使用效率, 并不能提高系统的运行效率。要想更好的发挥系统功能, 必须对系统进行重新设计。
一个系统运行效率的高低, 主要取决于系统架构的合理性。一个好的系统设计应该能从整体上把握系统各部分的功能划分及模块构成, 使系统功能均衡分布, 信息交互通畅。设计性能优异的人机交互界面, 离不开对全系统的精确构造。空基信息系统作为特殊的电子系统, 其人机界面有如下几个特点:
(1) 界面操作繁多。空基信息系统是集各种系统于一体的大型系统, 系统模块较多, 因此, 相应的界面操作单元也会比较多。
(2) 界面对象特殊。空基信息系统大多数作为武器系统的组成部分, 所面向的操作人群为部队战勤人员, 这些人员一般习惯于现役装备系统, 所以针对这些使用者的界面设计有一定的特殊性。
(3) 更新需求大。空基信息系统在国内发展时间并不长, 各项功能正在逐步完善, 并且人们对界面操作的理解和习惯不尽相同, 所以界面设计不可能做到一次到位, 需要与客户进行不断的沟通, 通过系统实际运行来验证界面设计的合理性。所以, 界面程序难免频繁改动。
(4) 实时要求严格。作为空中平台系统, 尤其是空基武器平台, 空基信息系统执行的实时性必须得到保证, 其执行速度必须满足用户的基本操作要求, 如果执行过程延迟较大, 则会降低系统的可用性。
基于以上特点, 为了更好的发挥人机功效, 系统设计必须考虑以下几个方面:
(1) 保证系统风格一致, 各个界面模块应该具备统一的格式和一致的操作流程。
(2) 界面程序必须符合使用者的操作习惯。界面程序的模块化界定必须符合部队操作人员的一贯理解。
(3) 为了不影响整个系统的开发进度, 且不增加系统的维护难度, 界面程序应该相对独立。
(4) 模块划分必须合理, 系统其他模块能够迅速处理来自界面的调用, 并将处理结果及时反馈给界面。
模型-视图-控制器 (Model View Controller, MVC) 是一种软件设计模式, 它强制性的使应用程序的输入、处理、输出分开。根据MVC模式, 可以将系统模块划分为三大类:界面模块, 负责接收来自用户的输入数据和命令;业务处理模块, 这种模块没有界面, 负责数据运算处理;控制模块, 在界面模块和业务处理模块之间构建动态对应关系, 支撑系统正常运转。
通常, 数据处理模块被用来支撑界面操作, 接受一个或多个界面模块的调用。如果这些模块与界面模块相绑定, 将使系统很难灵活配置, 而且容易造成代码冗余, 甚至导致系统数据不一致错误。比如设报告区操作和报告区编辑操作使用的数据处理代码相同, 如果各自编写这部分代码显然多余, 即使不会产生上述问题, 也会带来维护上的麻烦。通过将数据处理代码单独封装为一个模块并提供公用的调用接口, 可以很好地解决以上问题, 既可以实现数据处理的共享, 又使系统简化, 大大提高了系统开发效率, 如图4所示。
上述结构, 采用数据共享、模块共享、统一控制的方式开发整个系统。从全系统高度, 以执行任务为目的划分系统模块, 使每个模块能够独立完整的执行一项系统功能, 达到系统模块之间低耦合、高内聚, 各层次模块都遵循统一规范, 为实现可配置的功能布局创造了条件。此结构实现了业务处理、控制与界面显示独立布局, 从面向任务的角度, 对功能菜单排列、显示方式进行统一设计, 降低了系统复杂度, 便于开发和维护[9]。
5 用户定义及管理
在本系统中, 一个系统用户对应一个系统操作集合。按照操作种类和任务流程将全系统功能划分为多个系统操作集合。全权用户特指有权使用全系统内任何系统操作的用户, 即该用户对应系统操作全集。
5.1 已有方法兼容性
对于目前已经使用的空基信息系统, 用户习惯于按照专业划分, 将系统功能划分为若干特定职责。面向任务的用户人机界面设计同样可以适应用户的这些习惯。根据系统功能所属的专业类别将某类系统操作单元归为一个系统操作集合, 建立与之对应的系统用户。这种用户与已有系统中的操作员职责一一对应。从而可以使习惯于已有系统的用户毫无障碍地使用新系统。
5.2 面向任务的用户定义
根据任务要求, 选择特定的系统操作集合构建系统用户。比如, 一个任务包括雷达航迹探测、情报信息综合、态势数据下传。在执行任务前, 只需建立一个涵盖以上三种功能的系统用户即可。使用该用户登录系统, 其所能访问的操作足以覆盖本次任务所需的所有功能, 而且把没用用到的其他功能屏蔽在外, 从而使一个复杂的大系统变为简单易用的小系统。
5.3 用户管理
系统管理员可以全权访问系统的全部功能, 并负责建立用户。设置用户名、密码及主要职责, 为用户配置一个或多个系统功能, 完成一个普通用户的建立。系统管理员可以对已经建立的用户进行修改, 如对密码、功能配置等属性的更改。另外, 系统管理员可以删除用户。用户登录系统后, 可以对本用户密码进行更改。
6 结语
面向任务的用户化人机界面设计方法可以有效提高系统操作效率, 满足空基信息系统小型化和多用途化的需要。本方法可以兼容用户对现有系统的操作习惯要求。通过对现有系统改造或者采用层次化统一设计框架全新设计来实现本方法。层次化统一设计方法可以更好地实现系统功能颗粒化, 不仅可以提高系统操作效率, 而且可以大大改进系统运行效率。面向任务的用户化人机交互设计方法重在系统功能的灵活配置, 而如何划分系统功能颗粒, 如何优化系统功能组合是需要不断探讨和研究的方向。
参考文献
[1]卢莉莉.面向任务的人机交互模型研究及应用[D].重庆:重庆大学, 2005.
[2]刘波, 沈齐, 李文清.空基预警探测系统[M].北京:国防工业出版社, 2012.
[3]童志鹏, 刘兴.综合电子信息系统[M].2版.北京:国防工业出版社, 2008.
[4]汪海波, 薛澄歧, 黄剑伟, 等.基于认知负荷的人机交互数字界面设计和评价[J].电子机械工程, 2013 (10) :57-60.
[5]宁静辉.任务电子系统构架浅析[J].中国电子科学研究院学报, 2009 (4) :172-176.
[6]张耀鸿, 叶培春.面向任务的作战数据保障能力评估方法与工具[J].火控与指挥控制, 2012 (3) :136-138.
[7]陈正捷, 裴宏, 吴迪, 等.基于信息流程分级的指控信息处理机制设计初探[J].计算机工程与应用, 2009 (z1) :318-322.
[8]李晓卉.面向角色的工作流模型及其应用研究[D].武汉:华中科技大学, 2004.