系统任务论文范文

系统任务论文范文（精选12篇）

系统任务论文 第1篇

在烟草行业物流项目中,产生任务的因素较多、条件复杂,通常采用全部或大部分的硬编码来实现。我们对烟草行业配方、辅料、成品等物流系统的任务产生模式进行分析,以期得到一个稳定、可扩展的任务驱动系统。

一、常见任务产生场景分析

任务驱动过程中,既要保证任务能自动连续产生,又不能使之过于集中,造成公用搬运设备的不合理占用或堵塞,从而影响其他物流业务。这是任务驱动系统的基本设计原则。

通常情况下,任务驱动系统的执行依据包括单据和下位信号。结合物流单据类型,可分为人库任务驱动、出库任务驱动和移库任务驱动。

1. 入库任务驱动的分析

入库任务是指把装载物料的容器,通过自动化物料搬运设备搬运到指定的货位进行存储,信息系统记录装载有物料A的容器B存储在目标货位Y上。

入库任务中的容器通常是由外部系统进入物流系统,并在入库起始站台就位后,发起下位信号(即入库申请信号)。而产生任务前,物流系统需要知道正在申请入库的物料、容器等相关信息,这些信息来源于入库单和入库申请信息。其中入库申请信息包括容器信息和部分物料信息(例如:称重重量、化学指标检测值等)。

以辅料配盘入库为例,现场操作人员在PC终端上编制配盘入库单;配盘完成后,在源站台X发起申请入库;信息系统结合入库单、入库申请信息,获取完整的物料A和容器B信息;然后,分配目标区域(例如:高架库)的空货位Y,产生入库任务,如图1所示。

因此,入库任务驱动是产生一条将装有物料A的实容器B (或空容器B),从入库站台X移动到货位Y上的任务。入库任务驱动的充分条件是存在可执行的入库单(仅实容器)、容器在入库站台X上的就位信号;必要条件包括线路的在执行任务上限、目标货区是否有存储空间等。

2. 出库任务的驱动分析

出库任务是指根据出库单,通过自动化物料搬运设备从源存储区域(例如:高架库)搬运到投料点(或指定站台)。

出库任务是由出库单发起。根据出库要求,由源存储区域向生产投料口输送指定要求的物料。确定出库的源货位X后,从源货位的货位帐确定装有物料A的容器B信息。当容器到达生产投料口后,清除容器信息。

以烟叶库的生产投料为例,物流线路的结束点一般在翻箱喂料区的前面,可视作上位系统的控制边界(即非存储类型的站台)。操作人员在现场终端上编制投料出库单,并执行。信息系统根据出库单,从源货区分配满足要求的源货位X(货位帐存有物料A和容器B信息),并产生出库任务,如图2所示。

因此,出库任务驱动是产生一条将装有物料A的实容器B (或空足条件的容器、目标货区有可容纳空间等。

3.移库务的驱动分析

移库任务是指结合在库管理需要(例如抽检、货位优化或空容器调运等),调整空实容器的存储位置。如,立库间货位移动、立库至缓存区的移动等。

移库任务主要由移库单驱动执行。根据移库单要求分配了源货位、目标货位后,也就确认了装有物料A的容器B,将其由源货位X转移到目标货位Y上。搬运任务的物料及容器信息来源于源货位帐。

以从高架库向缓存区补充空容器为例。由操作人员编制空容器的移库单,移库单包括从源区域到目标区域。任务驱动模块根据移库单信息,分配满足条件的源货位X,确定可用的目标空货位,从而产生到达目标货位Y的任务。如图3所示。

因此,移库任务驱动是产生一条将装有物料A的容器B(或空容器B),从源货位(站台)X搬运到目标货位(站台)Y上的任务。移库任务驱动的充分条件是有可执行的移库单、下位要料信号(可选);必要条件包括线路的任务数量上限、源货区有满足条件的容器、目标货区有可容纳空间等。

二、任务驱动的处理

结合上述分析,任务驱动要解决两个问题。即:

一是何时产生任务?

二是产生什么任务?也就是产生将装有物料A的实容器B (或空容器B),从源货位X搬运到目标货位Y上的任务。确定了A、B、X、Y的信息,即可产生任务。

以下结合烟草行业常见的几种出入库业务进行分析。

1.何时产生任务

(1)实容器的入库业务

在实容器入库业务中,主要由“容器到达入库申请站台”的信号触发产生入库任务。而入库的物料信息主要由入库单明细信息确定。在该业务中,产生任务的条件包括:一是入库点有确认执行的入库单;二是有实容器到达入库申请站台的信号。

另外,实容器入库前,有些项目会有容器(包括物料)信息从下位采集。这些信息通过入库申请上传。例如:成品库入库托盘的所有件烟条码、复烤配方库的重量与烟碱值等。这里应考虑提供一个允许项目扩展的机制。

(2)空容器的入库业务

空容器入库常见于容器初始化、投料后返库等业务。在该业务中,空容器不需要物料信息,只要有空容器入库申请信号即可产生入库任务,产生任务的条件包括:容器入库申请。

(3)空容器的移库业务

空容器移库就是将空容器从货位X搬运到货位Y,例如:将托盘组从高架库搬至缓存区。在该业务中,产生任务的条件包括:一是有可执行的空容器移库单;二是下位的要料信号(可选)。下位要料信号可用于控制下位要料时机,以保证供料的节奏。针对需要下位主动要料的触发方式,我们定义为拉式供料;反之(即只要线路允许就产生)为推式供料。

(4)实容器的出库业务

实容器出库常见于生产投料出库。在该业务中,产生任务的条件包括:一是可执行的出库单;二是下位要料信号(可选)。下位要料信号的使用与空容器移库一样,可用于控制下位要料时机,以保证供料的节奏。同样可分为拉式和推式供料。

(5)实容器的移库业务

实容器移库是将源货位X上的实容器B (装载物料A)搬运至目标货位Y,典型的包括辅料配盘送至卷包机组站台。该业务中,产生任务的条件包括:一是可执行的移库单;二是下位要料信号(可选)。下位要料信号可用于控制下位要料时机,以保证供料的节奏。与上述相同。

综合上述业务分析,总结如表1所示。

2.产生什么任务

不论是入库、出库,还是移库业务,搬运任务都是把装有物料A的实容器B (或空容器B),从源货位X搬运到目标货位Y上。

也就是说,能确定物料A、容器B、源货位X和目标货位Y后,就可以产生确定的任务。

对实容器入库而言,容器B信息来源于入库申请,物料A信息来源于入库单(部分来源于入库申请),源货位X即是入库申请站台,而目标货位Y即为入库的目标存储货位(通常为高架库)。

对空容器入库而言,容器B信息来源于入库请求,源货位X为入库申请站台,而目标货位Y为入库的目标存储货位。

对空实容器出(移)库而言,容器B、物料A、源货位X等信息来源于货位帐。目标货位Y如果是存储类型的货位,则记录货位帐。

综合上述业务分析,总结如表2所示。

三、驱动策略的实现

从上述业务分析中,我们提炼出四个驱动策略,即实容器入库、空容器入库、推式出(移)库、拉式出(移)库策略。

上述策略在满足充分条件的同时,要考虑以下必要条件,包括:源货位有满足条件的物料(入库不考虑)、目标货区有可容纳的位置、在执行任务数未达到线路控制的上限。

1. 策略实现

(1)实容器入库策略

①策略描述

当装载物料A的实容器B到达入库申请站台X时,产生一个入库申请。

任务驱动模块检测到入库站台X有未处理的入库申请后,结合入库申请、入库单信息,构造容器B和物料A信息。分配目标存储货位Y,产生入库任务。

②.Net代码示意(仅列出核心代码,省略变量定义等。)

③业务流程(如图4)

(2)空容器入库策略

①策略描述

当空容器B到达入库站台X时,产生一个入库申请。信息系统产生X到Y的搬运任务。

任务驱动模块检测到入库站台X有未处理的入库申请后,结合入库申请信息,构造空容器B(例如空箱、托盘组等)信息。分配目标存储货位Y,产生入库任务。

②.Net代码示意(仅列出核心代码,省略变量定义等。)

③业务流程(如图5)

(3)拉式出(移)库策略

①策略描述

当容器离开某个物流业务的出库申请站台M时,产生一条出库申请。信息系统驱动产生出库任务。

任务驱动模块检测到某物流业务有未处理的出库申请后,根据出(移)库单获取需求物料,从而分配源货位X。从源货位帐上获取物料A和容器B信息。通过目标货位分配策略确定目标货位Y。

拉式出库提供了一种灵活调整出库节奏的方式。

②.Net代码示意(仅列出核心代码,省略变量定义等。)

③业务流程(如图6)

(4)推式出(移)库策略

①策略描述

任务驱动模块检测到某物流业务线路完成一个任务后,即未完成的任务数小于线路可容纳任务总量后启动策略。根据出(移)库单获取新的需求物料,分配源货位X。从源货位帐上获取物料A和容器B信息。通过目标货位分配策略确定目标货位Y。

②.Net代码示意(仅列出核心代码,省略变量定义等。)

③业务流程(如图7)

2. 策略调用

驱动策略采用策略模式实现,支持按需扩充。但结合烟草行业应用场景和实际应用,上述四种策略基本满足。

对策略的调用需增加一个服务层。结合实际项目定义任务驱动规则。驱动规则包括:在某个物流业务线路上,用什么任务驱动策略;选择的源货位、目标货位分配策略是什么;线路上最大可容纳数量是多少。

对策略的调用机制有两种,包括消息和定时处理。

方式一:采用消息机制。当执行单据、任务完成、收到出入库申请时,向队列发送消息。消息内容包括:哪个物流业务有产生任务的需求。收到消息后,针对该物流业务及业务的驱动规则来处理。

方式二:采用定时处理。综合检查出入库单据、出入库申请,判断和产生任务。

四、总结

通过对常见物流业务的分析,我们总结了四种物流驱动策略,包括实容器入库策略、空容器入库策略、拉式策略和推式策略。前两种策略针对从外部系统进入本系统的入库需求。此时需要从单据、申请信息中提取完整的物料、容器信息,以动态产生入库站台的货位账。

后两种策略针对从系统内的源货位X产生搬运任务的出库或移库需求。此时需要从源货位帐上获取物料、容器信息。

拉式和推式出库的触发差异在于是目标要料还是源头推送;在实际应用效果中,两者的差异在于控制搬运任务的节奏。当拉式出库站台设置在任务结束点时,两者无应用效果的差异。

以上四种自动化物流系统的任务的驱动策略,可以有效解决出入(移)库单的任务顺序产生,使在保障生产能力要求的同时,又能实现物流设备效率的有效利用。

任务书 电力系统 第2篇

一． 了解电网调度自动化系统的作用。

二． 了解国、内外电网调度自动化系统的发展状况。

三． 分析电网分层调度的作用。

四． 电网调度自动化远动系统的构成1． 分析电网调度自动化远动主站结构。

2.分析远动主站结构中各部分的结构、功能和配置。

3．分析信息传输系统的功能。

① 分析常用的信息传输信道的工作过程。

② 分析常用的信息传输规约的工作过程。（CDT、POLLING）

4．分析远动子站结构中各部分的结构、功能和配置。

① RTU的构成。

② RTU的作用。

5．以“四遥”为例，分析信息传输、处理的功能。

五． 分析数据采集和监控系统（SCADA系统）的功能。

六． 分析能量管理系统（EMS系统）的功能。（分析各部分的作用）

七． 写出一份论文。

1． 要求报告分析过程详细、准确。

2． 附必要的计算过程。

任务督办管理系统设计与实现 第3篇

【摘 要】随着企业的发展以及各级管理层的决策落实，督办事项时效性、实效性要求越来越高，各项重点工作管理也越來越重要，如何借助信息化手段，实现工作任务的督办管理成为一项实际应用课题。该文结合任务督办管理系统的建设实践，简要阐述了如何通过建立便捷、畅通、协同、高效的任务督办管理系统，实现工作任务闭环管控的信息化管理。

【关键字】任务督办，管理系统，信息化

一、建设背景

随着企业的发展，协同办公等信息系统逐步建立，信息化在企业安全生产、经营管理模式创新等方面发挥了重要的作用。然而，已经广泛应用的协同办公OA，还是侧重流程管理，对于“任务督办”这样需要跨部门、跨班组、跨岗位的协同业务管理，在现有协同办公OA上的应用还不够贴合实际操作。在日常工作中，任务事项越来越多，时效性、实效性要求也越来越高，传统的督办方式、运作机制和工作手段已难以为继。一些重要的工作缺少督办机制，工作的跟踪、落实和评价管理有待规范。督办事项如何保证落实、贯彻执行、跟踪反馈，提高重点工作的督办执行效率，实现信息化的督办管理，促进工作任务的有力执行成为一个急需解决的实际应用课题。

二、业务需求分析

任务督办是一项重要而复杂的工作，要做好这项工作必须遵循一套科学的工作程序，分为立项发布、接收办理、跟踪督办、办理反馈、核查考评和办结环节。为促进工作任务管理规范化、流程化，保证各项重要工作部署的具体落实，通过开发建立便捷、协同、高效的任务督办管理系统，明确责任、落实措施，形成自上而下、PDCA闭环管理的任务督办管控机制。任务督办管理系统对整个工作任务流程的发布走向、分支、实时办理状态进行全程的监控和管理，解决执行过程中任务口头化、难以记录、难以考核的弊端；及时发现问题及时解决，以减少工作批漏，强化工作执行力，提高办公效率，同时加强上级与属下的沟通交流。

如果单纯依靠人工方式进行工作任务过程管理和督办，不仅管理过程复杂，管控能力也相对较弱，往往会出现任务不清晰、督办效率低、职责不匹配、效果评价难等问题和现象。如何在督办工作越来越多、任务要求越来越高的情况下规范流程、简化操作、增强手段，减少此项工作的复杂度、提高工作效率效果，利用信息化手段显然是一种必然选择。

任务督办管理系统建设要能够帮助简化任务立项发布、办理、督办、反馈、核查考评和办结的过程管理，提升执行效率效果，改善工作的执行过程控制，加强跟踪反馈深化协作沟通。同时能够向管理层提供事项执行情况跟踪监控；向任务执行者提供便捷的沟通反馈的平台。运用信息化手段固化任务督办管理的管控要求，解决人工催督办工作难题，提升工作效率，保证工作质量，进而提升执行力。督办任务可逐级分解，对子任务的管理权可逐级下放；精细化的任务日程、工作记录、工作日、周、月报机制；对每个任务进行办理回顾和评价和完成情况统计。

三、技术选型

根据系统设计需要，采用C#语言，实现系统分层的开发，选用了B/S模式体系结构设计的方案，通过ASP.NET技术实现系统功能，采用Microsoft SQL Server 2005数据库进行后台数据库管理，对任务督办信息处理进行技术方面设计。

四、系统设计方案及实现

任务督办管理系统主要由任务发起、任务承办、任务办理、任务复核、任务办结及统计查询等模块组成，实现对任务事项的逐级分解下达、任务承办、任务办理、报告反馈、核查考评、查询统计等具体功能。实现对督办事项进行“红、黄、绿”灯预警监控，从而简化工作流程提升工作效率。通过采用任务流程控制，结合企业管理现状和需要，将现代管理思想和信息技术进行有机集成，以沟通、协调、控制为原则，建立起督办有力、落实及时、考核明确的任务督办体系，从而提高督办事项的管理执行效率，加强沟通与协作，减少工作纰漏。

系统功能架构图如下：

图1 系统功能架构

系统用户角色分为任务发起人、任务负责人、任务承办人以及任务复核人。任务发起人发布任务，将任务导入系统，对发起的任务进行跟踪监督及办结。任务负责人对负责的任务进行跟踪监督。负责人接收任务后可承办任务或将任务交办，每项任务可以交办给多个承办人。任务承办人接收到任务后，进行确认接收办理，在系统中记录任务进展情况、完成情况，提交至复核人进行审核。任务复核人对任务的工作完成情况进行评价。

（一）工作任务发起及确认分派

任务发起人将各种需要进行督办的工作事项导入系统，系统会自动将任务下发至负责人进行确认分派。在任务分解下达过程中为保护相应事项的信息安全，系统能够对督办事项的查看权限进行统一的控制。

（二）任务办理及反馈

承办人确认督办事项后，在承办人的界面显示该办理的督办任务。承办人在系统填报工作进展情况。涉及多个协办人的事项，由承办人负责沟通、督促，并在系统统一填报协办人工作进展情况。

当有新的承办任务时，系统将通过企业内部邮件向承办人发出提醒，交办人可以实时查看承办人是否对承办事项进行相应的响应。承办人可在系统待办事项中查看，操作简便。承办人可通过系统直接提交督办交办事项的阶段及最终完成标示交付物、执行进度情况等信息。通过任务执行情况反馈功能大大简化反馈繁琐度，规范了督办事项的执行跟踪和监控，提高了任务管理的精细化程度，保障了各项任务有效的执行。

在办理、监控环节，系统增设了“红、黄、绿”灯预警监控功能，逾期未办理的事项显示红灯，即将逾期的事项显示黄灯，已按期办理的事项则显绿灯。

（三）任务复核及办结

复核人可在系统中查询督办事项填报情况，可按照承办人、办复期限、完成情况等信息查询督办事项。复核人对办理结果进行审核认可，按照工作量和完成质量维度进行评价。办理结果审核通过后，由发起人在系统中办结督办事项。对逾期未完成的任务，可由发起人调整办复时限，转入下一阶段进行督办。

（四）任务办理情况查询统计

任务督办系统能够提供目前及历史督办事项的办理情况查询统计。同时，系统能提供自定义的查询、导出功能，方便用户使用。

五、应用价值

通过任务督办管理系统的建设，对督办事项的管理进行规范，优化管理流程、健全运行机制、强化结果应用，推动各项工作的规范开展。任务督办管理系统的使用，确保了被督办的工作能及时反馈和通报，推动了事事有落实有反馈，各项工作的执行质量和效率得到提高，形成了良好的工作机制，营造了“求创新、重实效、抓落实”的工作氛围。通过将被督办事项的统计结果应用于绩效考核，强化了工作任务的执行效率和效果。

六、结束语

任务督办管理系统实现了督办工作的规范化、标准化、程序化，保证了各项工作任务的具体落实。该系统运用信息化手段实现工作任务的督办管理，实现工作任务闭环管控的信息化管理，也是企业管理创新的具体体现。

参考文献：

[1] 李丹， 赵占坤， 丁宏伟， 等. SQL Server2005数据库管理与开发实用教程[M]. 北京：机械工业出版社， 2010.

[2] 郎登何. ASP.NET（C#2008）项目开发案例教程[M]. 北京：机械工业出版社， 2010.

[3] 曹晖.基于.NET的B/S三层结构物流管理系统[J]. 湘南学院学报， 2010年02期.

作者简介：

任务管理系统的开发 第4篇

关键词：任务进度,eclipse,Java,Spring,Hibernate,Struts2,Mysql

日常工作中,经常面对多个任务穿插进行的情况,为了了解任务的进度情况,只有去和每个负责人员交流才能获取相关情况,但是这种方式导致效率低下、进度不准确,并且没有进展情况、任务转发流程的记录。针对这个情况,开发了任务管理系统,其主要功能包含任务创建、分配、转发、进度更新以及用户管理、组管理等功能。

开发环境使用了eclipse、jetty,系统采用了B/S架构,使用java语言开发,使用的技术均为成熟的开源方案,使用广泛,便于学习使用。

MVC框架使用了Struts2,该框架包含了拦截器、OGNL表达式语言、堆栈等技术(系统架构如图1所示)。整个框架结构清晰,开发过程一目了然,可以很好的掌握开发的过程。模块化的结构便于功能扩展。

Spring控制翻转(Inversion of Control,Io C)的应用及面向接口编程使得在开发的过程中解耦,所有类的初始化由Spring完成,减少人为干预。不必再为单实例模式类、属性文件解析等这些很底层的需求编写代码,可以更专注于上层的应用。声明式的事务方式可以很灵活的进行事务管理,提高开发效率和质量。同时Spring对很多开源框架具有良好的支持,如Hibernate、Struts等,简化开发过程。

数据库采用了Mysql并使用Hibernate作为持久层方案,由于Mysql是一种关系型数据库,在面向对象的开发过程中,需要一个对象关系的映射,hibernate是这方面比较优秀的解决方案。Hibernate是轻量级对象封装,是一个独立的对象持久层框架,不仅负责从Java类到数据库表的映射(还包括从Java数据类型到SQL数据类型的映射),还提供了面向对象的数据查询检索机制,从而极大地缩短了手动处理SQL和JDBC上的开发时间。同时系统采用了Dao、Service分层,Dao层仅处理对象的简单操作,Service层主要处理业务。

1 权限设计

系统共包含了新建任务、任务列表、我的任务、用户管理、用户组管理功能。系统定义了三种角色:系统管理员,组长,用户。不同的角色对应了不同的菜单项,系统管理员可以使用所有功能,组长功能包含新建任务、任务列表、我的任务。用户功能包含新建任务、我的任务。为了保证系统安全,防止没有相应角色的用户通过url直接访问相关功能,使用了webwork拦截器(代码1)进行权限检查,所有请求均会经过该拦截器处理,各请求会通过自定义的Annotation(代码2)声明获得相应操作需要的权限,level表示操作所需要的权限级别,只有当登陆用户的权限级别大于等于所要求的级别才可以进行相应的操作(权限声明代码3),如果没有相应的权限,则直接跳转到提示页面。

代码段1

代码段2

代码段3

2 新建任务

所有用户均可以新建任务,包含了任务名称、优先级任务描述、相关文档上传,如果该任务不在自己的处理范围,可以将任务指派给其他人员,系统会记录任务的指派流程,便于跟踪。新建任务界面如图2所示。

3 数据过滤

系统管理员和组长均有任务列表功能,但是所能查看的数据是不同的,系统管理员可以查看所有数据,而组长仅能查看自身及组员的任务数据,数据会根据组用户进行过滤。列表中通过图示简单明了的显示任务的进度、优先级信息。任务列表界面如图3所示。

用户管理功能是用于维护用户基本信息以及用户所拥有的角色。用户组管理维护用户组信息以及用户所属组内容,组长可以查看组内用户的任务。

通过该系统的使用,提高了人员的工作效率,并且可以查看用户所分配的任务,可以统计人员的工作量,便于对任务进行跟踪及进度检查。

参考文献

[1]Struts官方网站[EB/OL].http://struts.apache.org/development/2.x/.

[2]Spring官方网站[EB/OL].http://www.springsource.org/.

[3]Hibernate官方网站[EB/OL].http://hibernate.org/.

[4]Mysql官方网站[EB/OL].http://www.mysql.com/.

网上售票系统任务书 第5篇

网上售票系统

（1）能够熟练应用Mysql数据库对数据进行管理。（2）前台部分主要用于为客户服务、包括余票查询、车票详细信息展示、客户信息修改、车票退定、关于网站的最新动态、其他站车的风采展示、网上购票用户注册/登录、票价查询、列车时刻表查询、起售时间查询、客票代售点查询、铁路客服中心电话展示、网上购票常见问题、客户信箱等。

（3）后台部分主要用于修改车票信息、添加车票信息、车票分类、对客户信息的管理、订单管理、管理员密码的修改等。

（4）采用JSP+Mysql、Servlet、JavaScript等技术实现。

时间： 2013 年 10 月 21 日 至 2013 年 12 月 13 日 共 8 周 所属系部：

学生姓名： 学 号： 专业： 指导单位或教研室： 指导教师：

一种分区操作系统实时任务调度方法 第6篇

摘 要：本文以提高在综合化航空电子系统混合任务场景中的实时任务响应性能和解决遗产代码重用问题为目标，提出一种具备虚拟化支持能力的分区操作系统实时任务调度方法。该方法通过建立全局调度队列，并对任务状态进行合理控制，相比已有分区操作系统两级调度模型更为灵活，并且保证了虚拟化分区中客户操作系统自身的调度策略不被破坏，能够满足分区操作系统对任务调度实时性和虚拟化支持能力的需求。

关键词：分区操作系统；任务调度；全局调度队列；虚拟化支持

中图分类号：TP316.2

随着航空电子技术的发展，机载电子系统综合化模块化（Integrated Modular Avionics，简称IMA）成为必然发展趋势，一个物理平台可能承担来自多个系统的不同类型的任务，这些任务对基础平台的处理特性有着极为不同的需求。例如，机电应用可能需要快速处理多个外部事件，飞控应用可能需要根据当前传感器数据及时进行舵面控制，而航电应用可能需要进行复杂计算以完成某种功能，这些应用综合在一起，提出了强实时任务与一般任务共存的需求。如图1所示的操作系统（简称OS）架构所示[1]，目前为了解决综合化带来的故障隔离和信息安全问题，现有的高安全机载操作系统都采用了分区机制，提供分区间隔离与分区间通信能力。现有的典型分区操作系统，如VxWorks653等采用两级任务调度策略，分区调度凌驾于分区内的任务调度之上，任务响应难以逾越分区时间窗口的限制，虽然能够确保任务的确定性实时响应，但是无法对任务从全局层面提供以任务为单位的统一调度，需要进行大量的前期任务规划，缺乏灵活性。

另一方面，机载软件的开发和验证成本相对较高，业界一直在探索降低机载软件成本的途径。系统综合中重用遗产代码可以有效降低成本，提高系统的安全性。虚拟化能够为代码重用提供有效支持[2]，支持虚拟化也成为机载操作系统发展的一个新的方向。如何在不破坏虚拟化分区中客户OS自身调度策略的前提下进行全局统一调度，也是综合化调度算法亟待解决的问题。

面对上述问题，需要通过在软件架构层面优化，提出新的综合化任务调度方法[3]，使含有虚拟化分区的混合任务环境下的强实时任务调度成为可能。

1 强实时全局统一调度算法

如图2所示，为了从根本上提高系统混合任务场景中实时任务的响应性能，必须减少调度层次，给分区操作系统所有分区内的每个任务赋予全局统一优先级，在分区管理程序中维护一个全局优先级调度队列，进行全局统一调度。具体来说就是将所有任务的当前优先级都映射为全局的统一优先级，然后在时间片耗尽和实时事件触发时，由分区管理程序的调度器进行统一调度。

在图2中，以分区中分别运行包含大量非实时应用的普通OS（例如Linux）和实时OS（简称RTOS，例如μC/OS）为例，虽然运行在RTOS上的实时任务通常具有最高的调度优先级，然而每个RTOS中也有低优先级的后台活动，它们不应该抢占运行在普通OS之下的用户前台任务。同样的，普通OS也会运行一些软实时活动（比如媒体播放器），而这些软实时活动可能会抢占RTOS中别的实时活动。很明显，使用现有分区操作系统那种分散的、层次性的调用模型，需要进行大量的前期任务规划来应对这种复杂的混合任务场景。

本文中分区管理程序中的调度器提供的综合化调度算法是一种抢占式、严格优先级、在最高优先级任务之间进行时间片轮转的调度算法。如图2所示，调度器维护一个包含255个优先级的全局就绪任务队列，调度器总是选择队列中具有最高优先级的任务获得处理器，如果处于最高优先级的有多个任务，则进行时间片轮转（RR，Round-Robin）调度。

本调度方法也提供了足够的用户可控支持[4]。用户可以通过系统服务动态的改变任何一个任务的以下3个基本调度参数：（1）优先级，0-255；（2）时间片长度；（3）处理器的编号。从而，任务的时间片通过在调度前对优先级的进行计算由系统缺省配置，也可以由用户通过系统服务进行修改。

出于调度开销和效率的考虑，本方法通过分析各种调度时机，可以在确认不会有更高优先级任务就绪的情况下不触发调度器而直接进行切换。

其中触发调度器调度的时机如下：（1）当前线程的时间片耗尽；（2）当前线程主动放弃时间片；（3）分区间通信（IPC，Inter-Partition Communication）操作阻塞当前线程或激活另一个线程。

不激活调度器，直接触发任务切换将减少系统开销，增加执行效率[5]。任务直接切换的时机如下：（1）中断发生时，通过全局优先级决定获取执行权的是当前线程或用户级中断服务线程；（2）IPC机制触发多个接受线程就绪，则在发送方和多个接受方之间选择一个优先级高的任务直接切换，此时可以不考虑优先级，而选用其他策略。

相比现有的两级调度算法，依据上述调度策略，借助合理的优先级部署，可以有效提高关键任务的实时响应性能，但是单级的综合化调度如何保证在虚拟化条件下分区中客户OS原有的调度策略不被破坏，是一个必须要解决的问题。

2 维护客户OS的自有调度策略

对于图2所示的全局调度策略，对于同一类型的任务全部给定相同的全局优先级，相同优先级的任务在全局实时调度中是以轮转Round-Robin方式进行调度。这种优先级配置策略在系统存在虚拟化分区的情况下将破坏客户OS原本的调度策略（比如Linux的普通用户级任务使用CFS调度策略），违反虚拟化的原则[6]。因此，分区管理程序和客户OS必须采取必要的措施，在无其它分区更高优先级任务抢占时采取合理的配合机制，保留客户OS自身的调度策略。

本文提出的调度方法解决此问题的基本原理是：首先，限制单个客户OS上应用级任务在全局调度队列中同时出现，从而使全局调度策略无法影响到客户OS内部的任务调度；其次，在触发调度的时机，全局调度器优先调度，如果没有当前运行客户OS之外的更高优先级的任务就绪，则将调度控制权交给当前客户OS的客户级调度器，此时激活客户级调度策略。

如图3所示，如果能够保证在每一时刻所有的客户OS应用级任务只有一个处于全局就绪队列中，就可以避免多个同等全局优先级的用户级线程按照全局调度策略进行轮转调度。在创建客户OS的任务时通过分区管理器系统服务修改任务在分区管理器中的系统状态，使其一经创建就处于未激活状态，不进入全局调度队列。在客户OS分区中创建一个高优先级的定时器处理线程timer_thread[7]，这个线程处理所有的客户级时间中断（真实时间中断在分区管理器的预处理中已经判断了在全局队列中是否有其他更高优先级线程就绪的情况，有则调用分区管理器的全局调度器进行调度），否则唤醒客户OS的调度器，依据客户OS的调度策略进行调度，启动获取CPU的新任务，将其加入全局队列，更改被剥夺CPU的上一个任务的状态（将其屏蔽出全局队列），从而保证了同一时刻所有的客户OS用户级线程只有一个处于就绪状态。

通过上述机制，可以在确保实时性和坚持虚拟化原则的基础上，完成分区管理器和客户OS的调度配合，达到在虚拟化分区内维护客户OS自有调度策略的目标。

3 结论

本文针对航空电子系统综合化产生的实时任务和非实时任务共存的混合调度需求，以及遗产代码继承产生的虚拟化需求，能够在不破坏虚拟化原则的前提下，对实时任务和非实时任务进行全局统一的单级调度，改进实时任务的响应性能，解决全局调度策略破坏客户OS自有调度策略的问题，突破现有两级调度策略的瓶颈。

参考文献：

[1]Alves-Foss J，Oman P W，Taylor C，et al.The MILS Architecture for High-assurance Embedded System.International Journal of Embedded Systems，2006，2（3/4）：239-247.

[2]Gernot Heiser，PhD.Virtualization for Embedded Systems.

[3]Sergio Ruocco，Real-Time Programming and L4 Microkernels.

[4]J. Kamada， M.Yuhara， and E.Ono.User-level real-time scheduler exploiting kernel-level fixed priority scheduler.In Multimedia Japan，Mar，1996.

[5]M. Hohmuth and H.H¨artig.Pragmatic nonblocking synchronization for real-time systems.In 2001 USENIX Techn.Conf.，Boston，MA，USA，2001.

[6]U.A.Steinberg.Quality assuring scheduling.Diploma thesis，Dresden University of Technology，Mar，2004.

机载任务电子系统总体布局优化设计 第7篇

机载任务电子系统是安装在飞机平台上执行某种任务的综合电子信息系统, 涵盖预警机、反潜机、巡逻机、电子战飞机等特种飞机, 任务电子系统在飞机上的安装设计的好坏直接影响着任务电子系统的作战使用效率。任务电子系统结构总体设计的主要工作包括系统构型设计、布局设计、结构安装设计以及环境适应性设计等方面。大系统总体设计的方法主要包括系统遗传-进化法、系统工程程序法、系统分析法、系统分解-集成法、黑箱辨识法、经验法、反馈协调法、系统优化法、模型验证法等[1]。本文重点论证系统优化法在机载任务电子系统结构总体设计中的应用。

特种飞机主要由载机和任务电子系统两部分组成, 任务电子系统根据需求可包括雷达、敌我识别、通信、电子侦察、通信侦察、指控、信息综合显示和监控等组成。

任务电子系统在飞机上的安装设计, 关键是要解决在飞机上安装任务电子系统设备所引起的一系列问题:一是任务电子系统设备在飞机上的安装问题, 即“机械接口”的问题。这些设备的安装涉及飞机的气动外形 (天线) 、内部布置、安装部位的结构强度等。二是电学方面的问题。一方面是供电问题, 任务电子系统设备既需要增加更大的电源供应, 又需要新的电源品种;另一方面是复杂的电磁兼容问题, 即“电接口”。三是热力学方面的问题。新增的设备用电带来发热量增加以及传热、散热问题, 需要采取多种散热冷却方式。

总之, 在一架成熟的基本飞机上安装任务电子系统设备, 破坏了基本飞机原有的设计平衡。改装的目的就是要在安装任务电子系统设备、改变飞机用途的条件下, 寻求新的设计平衡。任务电子系统结构总体优化设计就是采用多学科多目标优化的设计思路来满足新的设计平衡。

1 结构总体布局优化设计

机载任务电子系统设备在载机上的布置安装主要分为机舱内和机舱外两部分[2]。结构总体布局优化内容主要针对舱外天线布局优化和舱室系统布局优化设计。

1.1 舱外天线布局优化

任务电子系统对载机气动影响最大的是在机身外安装的大型天线以及天线罩, 无论哪种天线安装方式都会对飞机的气动性能产生影响, 而不同的天线布局形式会有不同的天线探测性能, 在舱外天线布局优化时需要同时考虑气动特性和天线电磁场特性, 这是一个典型的多学科优化问题[3], 场耦合关系如图1所示。

以气动特性和电磁特性为设计目标, 以预警任务系统布局参数为设计变量, 进行多目标优化设计, 得到舱外天线最佳布局方案。

以雷达天线布局优化为例, 设计变量x, y为雷达天线安装位置坐标, h, Φ为雷达天线尺寸参数, 设计目标f1为气动特性, f2为电磁特性, 雷达天线设计参数如图2所示, 优化设计流程如图3所示。

式中:xmin, xmax为雷达天线前后位置范围;ymin, ymax为雷达天线高度范围;hmin, hmax为雷达天线罩短轴范围;Φmin, Φmax为雷达天线罩直径范围。

此方法可扩展到全机天线布局优化设计。

运用流体仿真软件分析雷达天线罩尺寸、位置、支架形式对气动的影响, 同时运用电磁分析软件分析全机电磁特性, 经过优化, 提出最佳天线布局方案。

以天线布局位置参数为优化变量, 以方向图的畸变最小和飞机操稳性变化最小两个目标作为优化目标, 优化算法采用多目标优化算法 (MDO) 进行优化。

1.2 舱室系统布局优化

任务电子系统的舱内布局应充分考虑载机平台的舱内空间特性和全机重量重心、任务电子系统使用维护、人机工效特性分布等情况, 通过先进的优化算法, 优化任务电子系统在舱内的布置, 提高任务电子系统设备的维护性, 方便战勤人员的操作, 使战勤人员能在尽可能舒适的环境中高效地工作。

舱室布局优化流程如下:

(1) 系统功能使用布局设计要求和系统人机工效布局设计要求

规划系统使用功能和系统人机工效特性设计初始布局, 作为布局优化的起始值和约束范围。

(2) 进行系统舱室布局优化设计

近年来, 全局随机最优化方法如退火演化算法[4]和改进的遗传算法[5]等得到了广泛的研究和应用。它们在求解传统的基于梯度优化方法难以解决的复杂优化问题中显示了优良的求解特性。本文利用改进的遗传算法来求解特种飞机舱室优化布置设计问题。

图4为舱室布局优化设计流程图。图5为某特种飞机舱室布局三维示意图, 根据系统功能要求将舱室分为三个区域, 即前设备区 (分为左前机柜区和右前机柜区) 、中操作员区 (分为左操作员区和右操作员区) 、后设备区 (分为左后机柜区和右后机柜区) 。

图6为人员操作空间要求示意图, 图7为图5的简化模型示意图, 将各个设备区简化为一个固定的空间区域, 并假设各个设备区重量重心在形心, 对各个设备区域的相对位置进行优化调整。左前机柜区长a1, 宽b1, 重m1;右前机柜区长a4, 宽b4, 重m4;左操作员区长a2, 宽b2, 重m2;右操作员区长a5, 宽b5, 重m5;左后机柜区长a3, 宽b3, 重m3;右后机柜区长a6, 宽b6, 重m6。以设备区间隔距离xi为设计变量, 以布局重心xm与要求重心xd之间的距离最小、人员操作空间xi之和平均值最大为设计目标进行布局优化, 公式 (2) 为该舱室布局优化模型。

该多目标优化数学模型采用基于Pareto前沿的改进的遗传算法 (NSGA-Ⅱ) 来解决。NSGA-Ⅱ算法的基本思想为[6]:首先, 随机产生规模为N的初始种群, 非劣 (Pareto) 前沿分级后通过遗传算法的选择、交叉、变异3个基本操作得到第一代子代种群;其次, 从第二代开始, 将父代种群与子代种群合并, 进行快速Pareto前沿分级, 同时对每个Pareto前沿分级层中的个体进行小生境密度计算, 根据Pareto前沿关系以及个体的小生境密度选择合适的个体组成新的父代种群;最后, 通过遗传算法的基本操作产生新的子代种群, 以此类推, 直到满足程序结束的条件。

图8为布局优化迭代图, 从图中可得出最优结果集, 即人员操作空间优化结果为890~920 mm, 重心距离优化结果为0~60 mm。证明该方法可以使得两个目标同时相对最优。

2 结论

本文针对机载任务电子系统提出布局优化设计方法作为总体设计的一个重要内容, 舱外天线布局采用气动电磁多学科优化策略, 舱内设备布局采用人机工效、重量重心等多目标优化策略, 通过这些设计能够得出各方面指标相对最优的结果。

参考文献

[1]彭成荣.航天器总体设计[M].北京:中国科学技术出版社, 2010.

[2]王红.机载电子设备总体布局设计探讨[J].电子机械工程, 2007 (4) :6-9.

[3]段宝岩.电子装备机电耦合理论、方法及应用[M].北京:科学出版社, 2011.

[4]李俊华, 陈宾康, 应文烨, 等.退火演化算法在舰艇舱室优化布置设计中的应用[J].武汉交通科技大学学报, 2000 (4) :360-362.

[5]李云, 龚昌奇.改进的遗传算法在游艇舱室布局优化设计中的应用[J].船海工程, 2010 (1) :34-37.

机载任务系统软件性能架构设计 第8篇

关键词：软件架构,非功能需求,性能,任务

0 引言

在系统工程和需求工程中, 非功能需求 (Non-functionalRequirement, NFR) 确定了衡量的尺度, 用于对系统运行的判断, 而不是具体的系统行为。

可以这样理解, 非功能需求是指软件产品为满足用户业务需求 (即功能需求) 而必须具有且除功能需求以外的特性。

功能需求描述要开发的软件系统应该做什么, 它可以包括为用户提供哪些服务, 也可以包括本系统为其它系统提供哪些服务。

非功能需求分为质量属性和约束。约束需求规定了开发软件系统时必须遵守的限制条件。例如, 要采用什么操作系统, 要采用哪种开发技术, 是否需要与遗留的老系统进行互操作等等。当然, 还要考虑软件用户所在的行业中必须遵守的法律法规、政策方针和行业标准、企业标准。

质量属性作为非功能需求的一个分支, 同样包含众多内容。例如性能、安全性、易用性、可靠性等等。

功能需求是重要的, 它们包含了几乎所有用户所要求实现的业务逻辑。当然, 非功能需求也同样是决定架构成功与否的关键因素。

事实上, 非功能需求中的质量属性与约束是一个复杂的问题。而且, 在非功能需求中的某一条或几条可能就将左右架构风格的选择。

(1) 功能需求影响架构, 架构必须要适应功能需求。但是功能需求不会决定架构, 是否基于接口编程还是硬编码实现功能, 是否要分层等等问题都不是功能需求所能单独确定的。

(2) 质量属性会从根本上影响架构。例如, 非常强调性能的系统软件会在算法、任务实现上下足功夫, 而在架构设计中是否避免了性能的损失。

(3) 至于约束, 它或作为架构设计的限制条件, 或转变为功能需求, 或转换为质量属性。

1 软件性能相关因素

性能指实现预期功能能力的特性。软件性能是软件的一种非功能特性, 它关注的不是软件是否能完成特定的功能, 而是在完成该功能时展示出来的及时性。它包括对系统速度和空间的要求, 如下是常见的性能指标:①任务的响应时间:请求响应的时间;②任务的吞吐量:单位时间内, 可以处理的数量;③任务处理的存储容量:处理的空间和数据量。性能相关因素见表1。

2 性能设计过程

软件性能设计流程可参考图1。

以下各节基于某机载任务系统软件分析流程中的各个设计阶段。

2.1 确定系统边界

识别待分析系统或者子系统的外部Actor:和系统直接交互的人, 软件系统或者硬件系统。

与综合任务处理系统交互的的人和外部设备包括操作员、目标探测系统、惯性导航系统、显示控制系统、大气处理系统和外挂物管理系统。示例见图2。

2.2 确定应用场景

从Actor的角度识别可能存在的应用场景。示例见图3。

2.3 识别接口事件

接口事件就是:请求与响应的交互事件。示例见图4。

2.4 分析性能约束

分析和场景相关的请求响应要求、事件速率。示例见表2、表3。

2.5 活动分析

创建活动分析图见图5。

2.6 并发性能

考虑任务的并发:①一个任务的多个实例执行;②一个任务实例和其它任务的实例并发。

在各种并发数情况下:①测试确定关键活动时间;②定义性能约束;③调整任务, 实现性能约束。

2.7 识别关键任务

关键任务识别示例见图6。

2.8 为关键设计建立多个备选方案

如示例, IO与综合任务处理应用程序之间传递装订与修改的数据, 如何保证数据正确采集, 同时真实的反应操作员的操作。示例见表4, 表5、表6。

2.9 通过对方案的验证, 选择最适合的方案

综合对备选的方案进行验证, 由于对综合任务处理系统软件的处理速度要求是首要的, 因此在容忍确定的基础上优先选择备选方案中响应最快的一种方案, 即共享内存的方案。

2.10 确定任务周期、时序同步和资源同步关系

①分析每个任务的触发机制、执行周期;②任务之间的时序同步;③任务之间的资源同步。

示例见表8。

2.11 使用技术手段提升关键性能

可以使用如下的技术手段提升关键性能:①缓存:经常处理的东西复制一份在手边, 方便下次使用, 注意不要过时;②连接池:资源创建麻烦, 使用后释放, 其他人获取后可以使用;③优化算法:采用最快算法;④分页:只提取当前需要的数据, 避免存取浪费;⑤采用合适的搜索算法:在尽可能小的空间中, 通过尽可能匹配的条件;⑥尽可能减少费时的操作次数;⑦分布计算:把请求多的任务建立更多的任务实例, 保持响应;⑧负载均衡:把负载尽力均匀分布。

2.12 提升关键任务性能

为了保持对操作员动作的正确解析, 在综合任务处理系统中采用优化算法机制提升性能:对于装订和修改的数据, 进行滤波算法过滤掉操作员操作时的抖动。示例见图7。

3 性能有关的设计模式

嵌入式软件性能设计的典型模式如下:①使用command模式解耦任务的执行时机;②使用Observer模式实现数据重复利用;③使用缓存模式实现数据重复利用;④使用共享缓存模式实现异步任务通信。

这些设计模式都有很多书籍专门介绍, 因此本文不再赘述。

4 对已有系统的性能优化

对已有系统的性能优化可以采用如下的过程, 如图8所示。①确定关键任务;②确定性能监测指标;③性能测试与分析; (4) 性能重构。

5 结语

将软件架构理念, 尤其是非功能需求架构设计引入到机载软件的开发, 需要大量的验证仿真工作, 更需要结合机载软件的特点进行合理有效的设计。本文基于性能属性研究了机载综合任务系统软件的软件架构, 并给出了性能设计的过程和方法。实践表明, 采用合理的过程和方法开展机载软件的性能设计可以明显提高软件的质量和开发效率。

参考文献

[1]谢新华.软件架构设计的思想与模式[Z].中科院计算所培训中心, 2010.

[2]张仁良.软件架构中的非功能需求[J].微型电脑应用, 2009 (2) .

系统任务论文 第9篇

住房和城乡建设部部长姜伟新在会上提出，当前住房和城乡建设部门的主要任务是：

一、加大廉租住房和经济适用住房建设规模

一是加快廉租住房建设。各地建设(住房保障)部门要与当地有关部门密切配合，按照规定条件，尽快做好项目组织和落实工作。各地区已经开工的廉租住房建设项目，要加快工程进度。原计划于2009年开工的项目，凡具备开工条件的，要在今年开工。同时要抓紧组织一批新的廉租住房项目，落实建设用地和资金来源，为2009年做好项目准备。二是增加经济适用住房供应。要加快实施本地区经济适用住房建设年度计划。有条件的地区，要按照适当超前的原则，调整经济适用住房年度计划，加大近期建设的规模;鼓励已具备开工条件的项目尽快开工建设。三是加快城市棚户区改造步伐。坚持政府主导、群众参与、市场运作的原则，多渠道筹措改造资金。对不具有商业开发价值的城市集中成片棚户区改造项目，可以按照项目中的廉租住房对象数量给予补助。

二、加快市政基础设施和公用设施建设

一是加快城镇污水处理设施建设。36个大中城市要力争明年底前实现污水全收集和处理;在“十一五”规划基础上扩大全国县城污水处理设施覆盖面，使全国90%以上县城建设污水处理设施。二是加快城镇垃圾处理设施建设，在确保垃圾处理设施建设进度的同时，加快垃圾收运体系建设。以上两项，今年中央追加投资补助资金50亿元，住房城乡建设部将会同有关部门抓紧进行任务分解和计划下达工作。同时，各地要加强供水、供气、供热动态监测和应急能力建设，保障供应质量和运行安全。

三、积极配合有关部门做好林区棚户区、农垦危旧房和农村危房改造及重点流域水污染防治工作

各地住房城乡建设部门要积极配合林业、农垦部门做好林业棚户区和农垦危旧房改造规划和项目选择，尽快启动试点工作。积极配合民政、财政等部门做好农村危房改造工作。组织开展农村危房鉴定，摸清农村危房底数，制定改造计划。要组织专业队伍向农民提供住房安全知识和危房改造技术服务，确保危房改造质量。积极配合环保部门做好重点流域水污染防治的有关工作。

四、加快推进建筑节能工作

要在严格执行新建建筑节能标准的同时，加大资金支持，组织实施好一批重点建筑节能项目。要优先支持新建经济适用房、廉租房建设中规模化应用可再生能源的项目，地震灾区按照重建规划进行建设，规模化应用可再生能源的居住建筑和公共建筑项目，以及符合低能耗建筑和绿色建筑标准的项目。支持节能改造项目、可再生能源建筑应用示范项目和公共绿色照明项目。

五、稳定房地产市场和规范市场秩序

装备保障任务规划系统体系结构研究 第10篇

装备保障任务规划系统, 指在从保障任务目标确定到保障任务完成的整个过程中, 安排装备保障力量执行何种保障任务以及如何实施保障, 使装备保障力量生存概率和整体保障效能达到最佳。整个规划系统由威胁建模、威胁评估、任务分配、路径规划、战术决策以及指控中心等子系统组成, 并在指控中心系统的指挥控制下, 实现对装备保障任务的规划与实时重新规划。规划系统最后所给出的具体规划结果包括装备保障力量分配、保障任务分配和保障路径。

1 系统需求分析

装备保障是为满足部队遂行各项任务的需要, 对装备保障采取的一系列保证性措施以及进行的相应活动的统称。装备保障力量是实施装备保障的主体, 装备保障的对象是装备保障任务, 装备保障的过程即装备保障力量完成装备保障任务的过程。装备保障力量与装备保障任务, 在正常情况下, 二者是一一对应关系, 即有多少的保障任务就有多少对应的装备保障力量。但实际上, 通常情况下实际的装备保障力量是少于装备保障任务所需的装备保障力量的, 战时这种差距更大。信息化战争条件下, 战场环境复杂、作战样式多变, 首先直接导致了装备保障任务的多样、多变及不确定性, 难以准确预测装备保障任务类型、数量、发生地点等;其次也导致装备保障力量的战损、补充的动态变化。二者关系如图1所示。二者的这种不确定性与动态性, 最终导致装备保障复杂性、不确定性甚至是低下的装备保障效率。这就需要对装备保障任务与装备保障力量进行规划, 减少二者之间对应的不确定性, 增强装备保障效益。

由于战时装备保障任务主要是由敌方攻击导致装备的战损而产生装备保障任务, 这导致装备保障任务的不确定性远远高于装备保障力量, 因此上述规划应以装备保障力量为基础。未来装备保障力量模块化编组是装备保障力量发展的趋势, 加之战时装备保障力量是按照群队组的形式区分编组装备保障力量的, 因此, 该规划系统中将装备保障力量划分为装备保障力量单元, 并以装备保障力量单元为基本研究对象。

2 系统基本功能

对装备保障而言, 装备保障任务规划系统的基本功能是根据装备保障能力和装备保障任务地域地理环境、威胁环境等因素, 为装备保障任务目标规划出满足要求的保障力量与保障路径, 并可以根据需要进行局部重新规划。为确保装备保障过程中装备保障力量的有效利用和任务的完成, 一般需要多种装备保障力量单元进行协同, 因此对于装备保障任务规划系统而言, 协同功能尤为重要。其主要功能包括:

2.1 系统内的多装备保障力量单元保障任务规划与分配

将保障任务按重要性、紧迫性进行区分, 按照保障任装备保障力量单元在保障地域的分布, 调配相应的装备保障力量单元。例如:有M个装备保障力量单元要对N个保障任务目标进行保障, 如何对这些装备保障任务进行分配要根据保障效能以及目标的重要程度进行合理分配。首先任务规划系统按照重要性与紧迫性选取任务目标进行保障, 并确定任务目标的保障顺序及任务路径。

2.2 装备保障力量单元间共享资源的协调

为完成所分配的任务, 合理地将系统中的共享资源 (如通用工具子系统、技术人员、通信、控制系统以及各种信息等) 分配给各个装备保障力量单元。这要求装备保障力量单元具有较强的数据通信能力以及数据融合的能力, 以便装备保障力量单元之间要进行最低限度的通信, 既能实现相互协同, 又能保证隐蔽性, 不容易被敌方侦察和干扰。

2.3 多装备保障力量单元之间的协同任务路径规划

在装备保障过程中, 当某个装备保障力量单元被指派去完成某个确定的装备保障任务, 二者之间的能力与需求关系是确定的, 那么装备保障力量单元如何到达装备保障任务地点即选择机动路径就十分重要。规划系统根据保障任务地域环境, 综合评估战场威胁、通行条件、任务时间、通信条件等, 规划装备保障任务路径。同时, 在任务路径规划过程中, 需要做好装备保障力量单元之间的协同, 避免多个装备保障力量单元进行同一个保障任务等造成的保障力量局部过剩、重要保障任务目标装备保障力量稀缺的现象。

2.4 多装备保障力量单元之间的协同控制

主要指多装备保障力量单元在机动途中的协调控制, 避免装备保障局部过度集中造成目标过大, 及共同完成某项任务时力量单元之间的协调操纵及其控制。

3 多保障力量单元协同任务规划系统的体系结构

在复杂多变的战场环境中, 装备保障任务规划系统的体系结构在很大程度上决定着系统作战的效率和灵活性, 体系结构的选择应能使系统满足良好的伸缩性、高鲁棒性、高可靠性、快速反应能力、动态重构能力以及容错能力等要求。

多装备保障协同任务规划系统的体系结构主要分为集中式控制和分布式控制两类系统。

如图2所示, 集中式控制系统的特点是由唯一的任务指控中心对整个系统进行控制。在集中式控制系统中, 任务规划功能集中在任务指控中心, 装备保障力量单元仅具有底层控制功能。但集中式控制可靠性低、通信延迟、计算量大、消耗时间长、缺乏鲁棒性。

如图3所示, 分布式控制系统的特点是各装备保障力量单元具有完全的控制功能, 能够独立的规划任务与底层控制, 并可通过各装备保障单元之间的通信来实现任务协同规划。但在现有技术水平上, 装备保障平台在态势评估和决策能力上还远远不能与人的能动性相提并论, 人依然是整个系统中的关键决策因素。因此, 分布式控制系统很难实现系统真正的协同和获得最大整体效能。

为了更有效地实现多装备保障单元协同保障, 一种新型的分布/集中混合式体系结构被提出, 如图4所示。分布/集中混合式体系结构综合分布式控制系统和集中式控制系统的优点, 能够更好地发挥装备保障单元自主与集中指挥的互补优势以及保障人员的主观能动性。在分布/集中混合式体系结构中, 装备保障力量单元在执行任务之前, 先由任务指控中心通过预先规划为装备保障力量单元提供一个初始任务计划;在装备保障执行任务中, 装备保障力量单元在系统控制下按计划执行任务;当战场态势发生变化时, 装备保障力量单元自主决策, 各装备保障单元之间通过相互间通信实现保障任务协同, 并将协同结果传送给任务指控中心, 任务指控中心将对装备保障自主决策的结果进行评估, 决定是否对其进行干预。

在分布/集中混合式体系结构中, 任务指控中心可以是陆基、舰基, 也可以综合到空中指控中心。它的主要任务是对多个装备保障单元进行初始任务规划, 并负责在任务执行过程中对装备保障单元进行监控, 任务指控中心具有对装备保障控制的最高优先权, 可随时与每个装备保障单元进行通信, 并能随时调整每个装备保障单元的任务规划。各装备保障力量单元之间具备完全对等的独立分析、规划及协调能力, 能根据分配到的任务目标进行数据收集、数据分析和任务规划。

4 装备保障力量单元任务规划系统

装备保障力量单元任务规划系统主要组成和逻辑结构如图5所示, 其核心组成和主要功能包括信息融合、威胁建模、态势评估、路径规划等子系统。

4.1 信息融合子系统

所谓信息融合, 就是利用计算机技术对获得的若干传感子系统数据在一定准则下加以自动分析、综合, 以获取决策与任务规划所需的信息而进行的信息处理过程。多传感子系统是信息融合技术的基础, 多源信息是信息融合的加工对象, 协调、优化是信息融合的核心。

装备保障力量单元为了获得“全方位”的测量信息, 一般载有高度表、温度计、GPS、激光测距仪等多种传感子系统, 所测量的信息不仅包括机动平台本身的位置、速度、运行状态, 还包括机动平台所处的外部环境信息, 如地形地物、气象等, 并且将这些参数反馈至机动平台计算机, 规划并控制平台的任务路径。要使这些传感子系统协同起来为实现这一目标共同工作, 就必须对多传感子系统信息进行融合。目前, 比较成熟的多传感子系统信息融合方法有卡尔曼滤波、加权平均、贝叶斯估计、统计决策等。

4.2 威胁建模子系统

该系统主要根据已知威胁系统信息, 参照威胁数据库和地形数据库, 对反映威胁状态的空间分布进行描述, 即生成威胁空间, 主要是由分布于地面上的障碍、敌步兵和武器子系统形成的、对保障单元具有威胁性的攻击或杀伤区等。广义地讲, 威胁空间不仅包括障碍与地面高炮的火力障碍, 而且还包括敌方空中拦截力量、预警机雷达、各种气象因素和人工障碍等造成的对保障安全具有威胁性的空间区域;尔后结合装备保障力量单元的特性与能力, 对威胁空间的每一点进行威胁级别的判定处理, 以满足威胁评估、路径规划的要求。

4.3 态势评估子系统

为了正确、可靠、高效地完成复杂的保障任务, 就必须首先对战场的态势进行评估。态势评估以军事知识和军事经验为基础, 自适应地对急剧动态变化的战场场景进行监控, 按照军事专家的思维方式和经验, 自动对多源数据进行分析、推理和判断, 做出对当前战场情境合理的解构, 为军事指挥员提供较为完整准确的当前态势分析报告。态势威胁评估是一个涉及不确定性的信息融合的推理和决策过程, 可采用的方法一般有基于统计理论的经典推理、贝叶斯推理和D-S证据推理;有基于知识的专家系统、黑板模型等方法;还有近年来发展很快的模糊集合理论、神经网络、遗传算法等。

4.4 任务路径规划子系统

任务路径规划是指在特定约束条件下, 寻找从初始点到目标点, 并且满足某种性能指标最优的运动轨迹。装备保障路径规划是以实现地形跟随、地形回避和威胁回避为手段, 利用地形和敌情等信息, 规划出生存率较高的任务路径。装备保障力量单元路径规划系统是保障任务规划系统的核心, 主要实现装备保障力量单元路径规划、冲突检测与消解以及选择性管理等, 其主要难点在于如何在不确定性战场环境下出现突发威胁源或突发事件时, 规划系统能够根据态势评估结果对任务路径作出实时重新规划, 并实现冲突检测与消解。

5 多装备保障力量单元协同任务规划系统的逻辑结构

根据多装备保障协同任务规划系统的层次特性, 多装备保障协同任务规划系统如图6所示, 其组成部分包括信息融合、威胁建模、态势评估、任务目标分配、任务协调、任务路径规划等子系统, 其中目标分配、任务协调及任务路径规划子系统为其核心部分。与单装备保障力量单元任务规划系统相比, 信息融合、威胁建模、态势评估3部分功能基本相同, 主要增加了目标分配和任务协调两部分, 并且在保障路径规划部分更加注重新规划的协同性。主要介绍一下目标分配子系统、任务协调及保障路径规划等3个子系统。

5.1 保障任务分配子系统

在多装备保障力量单元协同保障过程中, 不可避免地要面临多保障力量单元协同的多任务分配和编队配置问题。多装备保障力量单元协同保障的任务分配问题就是确定哪些装备保障力量单元完成哪些保障任务, 并对装备保障单元编队、设计其路径, 使得整个装备保障系统的保障效能最高, 保障代价最小等。任务分配子系统从路径规划子系统获得各装备保障单元对各个保障任务的预估路径代价和需要耗费的时间范围, 按照保障任务要求确定协调分配方案, 将保障目标分配给各保障力量单元。

5.2 任务协调子系统

任务协调子系统的主要协调管理多个装备保障力量单元协同完成任务, 使多个装备保障力量单元达到时域和地域上的协同, 协调的关键是所有装备保障单元在时间上同时达到目标点。

当战场环境发生变化时, 导致某些装备保障力量单元无法继续按原定规划完成任务时, 应当实时调用保障路径规划子系统, 协调各装备保障力量单元的任务路径, 协调管理装备保障力量单元, 确保规划的有效执行。

在多装备保障单元协同任务规划系统的逻辑结构中, 虽然任务分配子系统和任务协调子系统都需要任务路径规划子系统进行有关的保障路径规划, 但它们对任务路径规划的要求和针对的环境是不同的。任务分配子系统需要了解所有装备保障力量单元对保障任务目标的路径代价, 而非具体的环境细节与装备保障力量单元的机动性能, 主要要求快速获得装备保障力量单元的任务路径代价和耗费时间。而任务协调子系统只需要得到需要协调的与重新规划的任务路径的路径代价, 需要比较细致和较具体的环境信息, 要求考虑各种约束条件 (机动性能、通行条件等) , 其要求规划的粒度比较细, 并获得对装备保障来说顺畅可行的保障路径代价和相应的运行时间。

5.3 任务路径规划子系统

任务路径规划子系统是任务规划系统的核心, 主要实现多装备保障力量单元的协同任务路径规划、冲突检测与消解等。根据装备保障任务的约束条件、装备保障力量单元能力以及战场环境等因素, 同时为多个装备保障力量单元设计完成保障任务的多条保障路径, 并实现保障力量单元在空间和时间上的协调一致。

6 结语

装备保障任务规划是充分发挥多装备保障力量单元协同保障优势、保持任务复杂性与装备保障能力之间良好协调性的关键问题, 是一个复杂的多约束、多目标优化与决策问题。首先对装备保障任务规划系统的本质进行了深入分析;接着在分析未来装备保障任务的基础上, 构建了分布/集中混合式多装备保障力量单元协同任务规划系统体系结构;最后研究了单装备保障力量单元任务规划系统和多装备保障单元协同任务规划系统的逻辑结构。

参考文献

[1]李舜志, 吴明曦.军事装备保障学[M].北京:军事科学出版社, 2009.

[2]程路尧, 朱建冲, 蔡纪伟.航空装备保障任务规划系统体系结构研究[J].兵工自动化, 2008 (11) :26-28.

工作任务管理系统中的软件模式应用 第11篇

摘要:设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。文中对MVC模式、单例模式和页面控制器的概念进行了探讨，并在工作任务管理系统进行了实现。

关键词:设计模式 MVC 单例模式 页面控制器

0 引言

软件项目开发的一个难点是用户需求的变化导致后期功能代码的扩展和维护，软件项目管理的一个难点是团队成员间的协作和沟通。设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编写的、代码设计经验的总结。遵循设计模式的解决方案，有助于功能的扩展和代码的维护。设计模式是面向对象程序设计的精华，让对象和对象的关系清晰了起来，使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。设计模式是按场景进行分类，便于团队间的沟通。本文以工作任务管理系统为例，讨论几种常用软件模式在信息管理系统开发中的应用。

1 设计模式分析

1.1 MVC模式 MVC是个将一个应用的实现分成三个组件角色的框架技术：模型，视图和控制器。①在基于MVC的应用里，Model(模型)是负责保持状态的应用组件。这个状态通常都持久于数据库之中（譬如，我们也许会有一个Product（产品）类用来代表SQL中的Products数据表中的订单数据)。②在基于MVC的应用里，View(视图)是负责显示用户界面的组件。这个UI通常是使用模型数据来创建的（譬如，我们也许会生成一个Product“编辑”视图，根据当前Product对象的状态，显示文本框，下拉框和复选框等)。③在基于MVC的应用里，Controller(控制器)是处理用户交互，操作模型和最终选择用哪个视图来显示UI的组件。在MVC应用中，视图只是用来显示信息而已，是控制器来处理和回应用户的输入和交互的。使用MVC方法的一个好处是，它有助于促进应用中模型，视图，控制器间的关注的清晰分离。保持关注的清晰分离使得对应用的测试极其容易，因为不同应用组件间的契约的定义和表达是更明确的。

1.2 页面控制器 使用页面控制器模式接受来自页面请求的输入、调用请求对模型执行的操作以及确定应用于结果页面的正确视图。分隔调度逻辑和所有视图相关代码。如果合适，创建用于所有页面控制器的公用基类，以避免代码重复并提高一致性和可测试性。页面控制器可接收页面请求、提取所有相关数据、调用对模型的所有更新以及向视图转发请求。而视图又将根据该模型检索要显示的数据。定义独立页面控制器将分隔模型与Web请求细节（例如会话管理，或使用查询字符串或隐藏表单域向页面传递参数）。

1.3 单例模式 单例模式的特点：①单例类只能有一个实例；②单例类必须自己创建自己的唯一实例；③单例类必须给所有其它对象提供这一实例。

Singleton模式包含的角色只有一个，就是Singleton。Singleton拥有一个私有构造函数，确保用户无法通过new直接实例它。除此之外，该模式中包含一个静态私有成员变量instance与静态公有方法Instance()。Instance方法负责检验并实例化自己，然后存储在静态成员变量中，以确保只有一个实例被创建。

2 工作任务管理系统的设计模式应用

2.1 工作任务管理系统体系结构 工作任务管理系统的体系结构如图1所示，图中的箭头表明了信赖关系。在物理上，DAL是公共的数据访问入口层，BLL用来封闭业务实体对象，BIN是经过编译后的逻辑控制代码，Web文件夹下是按功能划分的视图文件。用户与《View》下的视图文件进行交互，控制数据的显示和接受用户的输入；《View》中的数据来源于《Controller》，《Controller》负责维护《View》的状态和数据的呈现，以及将《View》传递过来的数据对象化，并调用对象方法实现相应的业务逻辑获得数据；《Model》中包含实体的集合，对应于业务规则，是数据库表数据和数据增、删、改、查操作的抽象，实体以类的形式存在，业务以类方法的形式进行实现，《Model》从业务规则的层面处理数据，它是《Controller》数据的供应商。

工作任务管理系统中使用了MVC结构后，在开发时，项目组成员间职责明确，美工和网页设计师只需要关注《View》的设计和HTML实现；数据库设计人员只需要关心数据库的设计以及数据的转换规则；模型人员只需要从业务的角度关注业务规则的实现和从数据库到实现对象的转换工作；而程序只需要关注利用模型的业务规则控制处理《View》的数据显示和输入就可以了。这样做，非常有利于项目的管理和分工协作。

另外，到了开发的后期，需求分析的变化，导致业务规则的重整，只需要在现在代码基础上增加一些实体类就可以了，便于系统的扩展。

2.2 页面控制器 在工作任务管理系统中，《View》分为两种，一种是无需授权任何人都可以访问的页面，称之为通用页；一种是需要用户登录，特定用户才有权访问的页面，称之授权页。《View》只是简单的以HTML的方式显示，由浏览器解析，否能访问由页面控制器来控制的，即《View》对应的后台代码。在默认情况下，所有的布面控制器都继承于System.Web.UI.Page类，要实现权限控制必须在所有的页面控制添加控制代码，这用做非常的麻烦，而且不利于代码的后期修改和扩展。针对于这种需求，页面控制器设计模式提供了一种非常好的解决方案，如图2所示。

定义一个基类BasePage，继承于System.Web.UI.Page，是系统中所有页面控制器的基础；从BasePage下派生出GenPage和AuthPage两个类，分别用作于通用页和授权页的父类。在授权页的构造函数中，实现OnLoad事件的订阅，在OnLoad的事件处理程序中添加权限控制代码，所有的授权页都从AuthPage派生出来，这样在派生页控制器中，就无需写权限控制代码了。在后期代码的扩展过程中，只需有修改父类的代码就可以，而不是每个页控制器的代码。

2.3 单例的数据连接对象 数据连接是系统中非常宝贵的资源，如果一个数据库系统中存在着多个连接对象，并且这些对象没有及时释放，系统的性能将会急剧下降。一个好的设计是，在一个系统中数据连接应该是唯一的，单例的，如图3所示。Cnn是DBAccess的一个静态成员，并在静态构造函数实例化。这样，不论DBAccess有多少个对象，数据连接对象便只有一个了。

3 结论

设计模式是设计经验的总结，在系统设计过程中合理地使用一些经典的设计模式，是十分有利于系统功能的扩展和代码复用的。在工作任务管理系统中，MVC模式使得系统的结构清晰，有利团队的分工合作；页面控制器模式降低了代码的冗余度，提高了代码的重用性，方便了功能的扩展；单例模式实现了数据连接的唯一性，提高了系统的性能。

参考文献：

[1]钟金琴，辜丽川.一种面向对象的软件设计模式库的设计.计算机技术与发展[J]，2008.(9):22.

系统任务论文 第12篇

军事地形学作为一门实践性比较强的军事共同课程,有其鲜明的学科特点——理论与实践结合的非常紧密。提高理论教学环节的授课质量,必将对野外实践环节带来积极的影响。结合该课程的具体情况与授课对象的特点,在教学活动中,围绕特定教学内容,教员可以设计出具体的、可操作的任务,开发并运用相应的教学训练系统,使学生通过表达、沟通、操作、解释、询问等各种语言活动形式来完成任务,以达到学习和掌握相关技能的目的。

1 需求性/可行性分析

1.1 需求性分析

在军事地形学的教学过程中,一直存在师资力量不足与授课对象过多的矛盾、教学内容冗多与课时量短缺的矛盾、教学资源丰富与训练质量不高的矛盾等。整合教学资源、精简授课内容、加大课堂交互等已成为教学改革的核心工作,于是,为实现教学模式转型,设计并开发出一套简单、实用、高效的任务型、交互式教学训练系统已成为军事地形学教学以及课程建设的一项迫切任务。

1.2 可行性分析

作为一门军事基础课程,军事地形学所涉及的相关技能应用很广泛。军事地形学有其独特的应用优势,即可以将相关技能通过完成想定作业的方式转化为任务目标,并藉此规范教员的教学过程,并引导学员自觉、自发培养个人的军事素养。以军事应用案例为任务目标,以理论学习为先导,通过课堂交互(操作、询问、交流)以实现培养技能的目的。通过以往的教学活动,我们发现案例教学在引导学员思考、讨论等方面一直是非常高效的和可行的。

2 任务型教学训练系统设计

2.1 工作原理

任务型教学训练系统,是基于地理地形信息系统,以室内教学为背景,从而实现野外训练课堂化、生动化,特别是要通过整合教学资源,提高学员在理论学习环节的效果。

教员在应用该系统时,主要是通过任务组织教学,在任务的履行过程中,以参与、体验、互动、交流、合作的学习方式,充分发挥学习者自身的认知能力,整合他们已有的学习成果,在实践中感知、认识、提高,在“干”中学,“用”中学,体现了较为先进的教学理念。

2.2 原则设计

2.2.1 真实性原则

此原则是指在任务目标设计中,任务目标应来源于真实案例,同时,履行任务的情景以及具体活动应尽量贴近真实(战场社会)环境。

2.2.2 交互性原则

此原则是指在完成任务目标的过程中,应考虑到它在课堂环境中的可操作性问题,应尽量避免那些环节过多、程序过于复杂的课堂任务。必要时,要为学生提供任务履行或操作的模式。

2.2.3 连贯性原则

任务型教学训练系统所设计的任务目标应是相互关联、具有统一的教学目的或目标指向,同时在内容上相互衔接。这一原则涉及任务与任务之间的关系,以及任务在课堂上的实施步骤和程序,即怎样使设计的任务在实施过程中达到教学上和逻辑上的连贯与流畅。

2.2.4 趣味性原则

该系统的优点之一便是通过有趣的课堂交互活动有效地激发学习者的学习动机,使他们主动参与学习。机械的、反复重复的任务目标可使学生失去参与任务的兴趣,因而任务的形式应多样化,任务的趣味性除了来自任务本身之外,还可来自多个方面,如多人的参与、多向的交流和互动,解决问题或完成任务后的兴奋感、成就感等。

2.2.5 实用性原则

该系统要尽可能为学生的集体活动创造条件,利用有限的时间和空间,最大限度地为学生提供互动和交流的机会,达到预期的教学目的。

2.3 功能设计

2.3.1 自主学习功能

该系统设计有学习项目模块,将军事地形学理论学习部分进行的高度整合,并根据学员的学习习惯、知识储备以及学习能力规划出了不同难度、强度的序列组合,能充分地满足学员的自主学习需求。

2.3.2 模拟作业功能

该系统是基于军事地理/地形信息系统开发出来的,并且充分考虑到军事地形学课堂教学的客观情况,特别是能实现战场环境(三维地貌)显示,能满足学员野外作业室内完成的需求。

2.3.3 观摩评比功能

该系统可以对学员的学习情况进行实时检查,即满足整建制学员的观摩需求,并且现场就可以对检查结果进行评比验收。

结论,任务型教学训练系统有着相当广阔的应用前景,不仅仅能应用于军事地形学教学,更能推广到军事基础教学领域。完成该系统的设计仅仅是工作的开始。

摘要：军事地形学是任职院校学员的必修课程之一。本文以“任务型”教学训练系统设计为主要研究内容,目的是为了更好地衔接课堂理论学习与野外实践操作这两个教学训练环节。

关键词：任务型,教学训练系统

参考文献

[1]程晓堂.任务型语言教学[M].北京:高等教育出版社,2004.

[2]余胜泉.教学软件设计指导手册[M].北京:清华大学出版社,2011.