部署方法

关键词：

部署方法（精选七篇）

部署方法 篇1

1 业务构件描述

各个行业的企业总有一些核心业务,长久保持不变,新时期的新业务基本上都是围绕核心业务展开。但是业务的扩展和IT技术的发展始终是一对矛盾的存在,如何重用原有的技术成果去描述常变的业务需求,是当前软件开发行业内所关心的话题。

就企业信息化领域而言,企业和业务包含几个重要要素:业务术语、业务流程、业务活动、业务表单、组织机构等。这些要素相互作用实现企业特定的目标。业务术语代表着领域化数据,是业务的数据来源;业务流程和业务活动代表着用户与系统之间有规律地交互,是业务的语义体现;业务表单代表着用户同数据之间的交互,是业务的交互接口。三者之间互相作用,完成一项特定的业务需求。至于组织机构,可以认为是业务术语的一个子集。

所以提出一套方法:对业务进行抽象分解,抽取出最核心的部分并使用统一的格式去描述,再把他们封装成基础颗粒(构件),定义向外提供的服务,在上述基础工作之上,就可以定义出具有不同功能甚至不同版本的构件,将它们部署在一个架构之上去运作完成指定的业务,从而应对当前企业信息化领域的业务需求挑战。在企业信息化领域对企业业务进行层次化划分为数据模块,流程模块,用户界面3部分。

1.1 业务数据

数据模块是企业信息化领域数据特征的抽象,用于描述一组数据的概念和定义。使用概念建模的方法:现实世界中存在各种概念,本质不同的属性集合,换言之不同的属性,依据一定规律或规则,形成的集合是概念。数据是企业信息内容积累的重点,建立业务数据库对业务概念重用有着重要作用。

业务数据作为业务构件的底层支撑部件,需要提供服务来供构件其他部分或者其他构件去调用。对其进行逻辑封装,将操作封装成业务服务发布出去。另一方面,通过映射逻辑操作,将概念和所属属性映射至持久层中去,这也是数据持久化的途径。

业务数据用于描述企业业务里包含的丰富的概念知识,它是整个业务模型的语义基础,可以规范和约束业务所处理的数据。为数据赋予语义,不仅可以促进企业知识的重用和共享,还可为企业数据交换和集成带来好处。

1.2 业务流程

企业信息化核心职责是企业集成化、协同一体化,关键是实现商务流程系统和商务数据的互相协同。企业信息化领域的施工模块划分,一般以一项完整的流程作为划分的依据,因为它包含最小的独立可执行业务信息。并且在实际开发中,业务数据一般相对稳定,业务流程则是随需求常变的,故将业务流程当作构件中的一部分。

业务流程就是业务页面在不同用户之间流转。业务流程分为:业务活动,业务动作和业务规则,它建立在业务数据承载基础之上。

业务活动是业务流程的一个环节,每一个业务流程是通过处理一个个业务活动来展开的。它是状态的集合,另一方面也是用户访问的基本单位。利用业务活动这个载体,通过其传递、流转体现了企业协同交互功能。

业务功能,也可以理解为业务动作。它被业务活动引用去实现特定的业务操作,换言之它解决了业务流程中做什么和怎么做的问题。在开展业务活动时,参与者根据自己的权限进行受限范围内的操作。

业务规则,表示业务流程与业务活动中的丰富规则,它使流程在业务需求下恰当运行。业务流程有启动规则、流程合并规则。通过启动规则,可以确定流程在什么情况下启动以及如何启动。流程合并规则规定多个流程实例如何并行处理,方便大量流程的共同处理。业务活动之间通过连接弧、逻辑环节、条件环节等连接,这样规定了各项活动之间的先后关系和逻辑关系。最后每个业务活动上可以制定执行规则,转发规则,回退规则,时间规则等。

1.3 用户界面

用户界面和业务两部分之间完全独立的,他们之间通过服务接口交互。用户界面通过技术框架去实现同表单数据、业务流程之间的松耦合。它分为4部分:数据+格式+动作+规则。

数据部分定义了包含在表单中的数据,并规定了用户提交时如何处理数据。数据可以是数据模块中的概念,流程上下文数据,静态数据等;格式指数据如何在表单中布局以及采用什么构件来表现数据等。现在广泛使用的是xbl(界面构件),xforms(界面具体展现)等技术规范;在用户界面中,可以定义各种业务动作,也可以调用数据模块或者流程模块中定义的业务动作,采用事件驱动架构进行业务动作的响应;数据规则的检查,包括计算、约束、必须、只读等;最后还需要胶水层代码以实现一些简单业务逻辑。

2 业务构件拼接组合

类似于对家具的各个零件部分进行组合、拆装来进行家具的搭建。下面对业务构件的组合以及拼接部署进行讨论。

2.1 业务构件封装

能否对软件开发进行更为有效的分工,降低程序员重复单件工作的成本,是衡量软件技术能否在复用性上取得突破的根本准则。因此提出,用户界面、业务流程、业务数据以及彼此之间提供的动作服务的集合,称之为业务宏构件,如图3所示。

业务数据提供数据库表的映射服务;业务流程提供流程服务供流程引擎调用操作;用户界面提供界面服务供用户访问及交互。业务流程为语义执行核心,一方面通过技术框架中的容器同业务数据绑定,另一方面通过REST服务同用户界面发生关联。3部分均支持事件驱动框架提供业务服务供其他宏构件调用导入。最后提供系统管理服务,对宏构件进行部署、注册、注销等管理操作。注意一个业务构件可以由多个业务数据,多个业务流程,多个用户界面组成。

2.2 构件服务接口描述

由图3中可以看出,构件提供出的服务大致分为3类:界面服务,数据逻辑服务,业务动作服务。服务的接口规范基于WSDL(Web Service Description Language),而且也提供Java接口,这样使用业务构件的客户端可以选择使用WSDL接口或Java接口。服务接口类型具体采用哪种调用关系则主要是考虑性能、接口复杂度、耦合性等问题:不同构件之间可以通过 REST 服务进行调用;一个业务构件内部,业务构件和公共模块之间的调用实现 API 调用。

由于涉及到业务构件内外的调用,因此需要制定专门的绑定信息。这些绑定信息包括了目标服务或者源服务的调用方式,位置信息,调用的方法等。常用绑定方法有JMS绑定和Web Service绑定等。

2.3 构件的可配置化部署

文献[4]中提出了一套基于构件的软件配置管理系统模型。使用XML语言进行构件之间的配置描述,需要描述的部分大概有:构件的类库组成;描述构件暴露的服务;构件域描述,描述系统可用节点,互联接信息和桥接信息;逻辑构件映射成物理构件服务过程等。构件调用关系如果想实现自动绑定(Auto-wiring),还需要在标签中加入Autowire属性等标签。

系统架构彻底可配置化,要求框架本身构件也必须像业务构件一样可定制、可配置。这就需要一个微内核配置文件。框架本身构件也是靠配置这个微内核的配置文件达到组合使用或更换个别零件。

2.4 构件架构的实现

依照前述讨论内容,现假设存在多个业务功能不同的构件,为使他们彼此之间协同工作组成一个完整的信息系统,文献[5]提出了一个可拓展的集成式构件描述框架。这里结合CCM(Corba Component Model)标准和企业信息化领域的业务问题,提出一套构件框架模型,如图4所示。

业务服务总线是体系架构的核心,它负责缓存数据,统一数据格式,进行服务的引用调度,启动相应流程引擎,页面引擎等核心功能。

将跟每一个业务构件紧密相关的部分单独作为一个构件,即公共服务构件。业务构件和公共构件使用一个数据库,通过相关标准实现整合。公共服务构件包含组织管理、菜单管理、流程管理、系统管理、报表打印等。业务构件则由用户定制并部署至平台架构中,类似插件一样进行工作。

例如对会议管理部分进行分析。按照流程进行划分,可分为会议通知,会议记录,会议结果处理3个具有独立流程的部分,所以每部分作为一个宏构件进行设计。以会议通知为例分析,要求发起人填写会议信息并分发至参会人员并得到回执。流程包括3个环节:创建会议信息、分发通知、发送回执。业务流程从流程库中选择简单无分支流程类型,对环节进行命名和简单删减以符合流程要求,业务数据从本体库中选取会议本体,可依据企业需求选择所需子集,业务页面选择主表流式布局。接下来进行3部分之间的连接配置以及特色业务服务实现。主要包括:(1)页面技术构件同数据源属性之间的绑定。(2)页面业务服务实现流程各个环节执行者、分派模式等规则设定。(3)同组织机构构件交互的规则设定。(4)部署执行配置。最后通过Osgi技术将3部分资源以及配置信息打包封装,植入构架中运行。

以上为会议通知这一宏构件制造过程,若流程需求发生变化,只需对其流程环节进行轻微修改;若表单需求发生变化,只需对用户界面布局进行改变;若业务需求发生变化,只需对响应业务服务进行修改编码。三者之间彼此耦合度低,影响不大。这样就能将维护局限在宏构件中,甚至还可加入版本机制,增强复用度。

3 结束语

在对当今企业信息化领域分析的基础上,提出宏构件概念,借鉴CCM标准,对构件的拼接部署方法进行了讨论,提出了基于宏构件的业务架构平台,为企业信息化领域构件化开发提供一种可行的解决方法。

参考文献

[1]ZHU S Y,QIAN L Q,SU W M.Software engineering technol-ogy conspectus[M].Beijing:Science Press,2002.

[2]徐玮,尹宝林,李昭原.企业信息系统业务构件设计研究[J].软件学报,2003(7):2-3.

[3]孟凡超,战德臣,徐晓飞.基于领域业务模型的可重用构件设计方法[J].计算机集成制造系统,2006(12):98-101.

[4]张路,谢冰,梅宏,等.基于构件的软件配置管理技术研究[J].电子学报,2001,29(1):267-276.

部署方法 篇2

远程调用 (RPC) 是一种进程间通讯技术, 该技术允许一个程序调用执行处于另一地址空间中 (通常是网络中的另一台计算机) 的函数, 但无须显式编写远程交互代码, 即, 程序员可以编写基本相同的调用代码, 而无须考虑被调的函数处于本地还是远程服务器。当编写面向对象风格的程序时, RPC也常被指代为remote invocation或remote method invocation。

1 系统原理

本系统实现为操作系统中间件的形式。在概念上, 中间件的目的就是为了屏蔽底层操作系统、网络等的异构性, 屏蔽底层实现细节, 为用户提供定义清晰明确的高层API。因此本设计从3个层次来满足这一目的: (1) 底层。网络传输, 使用跨平台的Socket库解决基本通信问题。使用明确定义, 平台无关的接口提供并发服务的能力。本层的实现目的是提供健壮的数据传输和可接受的并发效率; (2) 中间层。完成客户端的请求和函数调用的中间逻辑互换, 以及动态函数组织, 分发的功能。本层的实现目标是提供灵活、可配置、可扩展的函数查询、组织和分发; (3) 上层。将对远程函数的调用封装为本地调用形式, 屏蔽掉底层实现细节以及跨主机通信的事实。本层的实现目标是提供与本地过程调用语义最大程度相同的远程过程调用接口。

同时本系统与传统的RPC系统也存在以下的创新点: (1) 轻量级的实现。传统的RPC实现往往需要支持多语言调用和多传输层协议, 而本系统是为MapGix7.x专门定制的, 只需要支持C/C++语言以及TCP/UDP协议。在实现上参考了RFC10145、1050, 简明扼要, 具有很好的可维护性; (2) 跨平台的实现。在系统设计之初, 便遵循一套代码处处编译的跨平台目标, 先封装了跨平台的SOCKET6库, 再在该库的基础上实现系统, 凡涉及到平台相关的系统调用之处都使用条件编译做了处理; (3) 基于原始接口编译的实现。这是本系统与传统实现的最大不同处, 也是本文的主要创新点所在。传统系统主要是提供一套运行时库以及接口编译器, 开发人员使用系统定义的IDL语言进行接口描述, 然后使用SUN RPC RPCGEN一类的编译器以IDL接口定义文件为输入输出proxy/stub源文件, 然后开发人员再在这些模板文件的基础上实现具体的业务代码, 最终编译为客户端与服务器。而本实现考虑到MapGis7.x空间数据引擎已存在的巨量功能接口, 使用传统RPC对其进行重写的代价是非常巨大甚至不能接受的, 从而创造性的提出了基于原始接口编译的实现方式, 具体来说, 本系统实现了一个专用的接口编译器而不需要定义或设计新的IDL, 该编译器直接以已存在的功能库的头文件作为接口描述文件直接编译生成proxy/stub源代码。该源代码使用底层运行时提供的API接口完成上面已提出的上层设计所需要的功能。这样, 远程化每个已存在的功能库就变成了很简单的任务, 只需对头文件稍加规范 (接口编译器目前的词法解析能力尚不完备) , 使用接口编译器产生proxy/stub源文件, 编译。将stub库与原动态库存放于服务器端指定目录, 运行服务器, 便可以使用proxy库通过本地过程调用的语法风格调用远程动态库中的函数了。

2 系统实现

系统本身提供运行时以及接口编译器两个部件, 程序员使用它们将自己的动态库远程化, 并实现远程调用的应用程序。

2.1 接口编译器

接口编译器是一个简单的编译原理应用, 它包含了一个词法分析/语法分析前端, 分析待远程化的动态库的头文件, 将头文件定义的接口转换为中间形式。它包含了代码生成后端, 根据接口的中间形式生成proxy/stub/serializer代码。基本架构如图1所示:

下面以一个简单的动态库 (MapSde.dll) 为例演示接口编译器的功能:

图2所示为理想情况下的应用, 通常一个任意的接口头文件会引RPC运行时所无法识别的新的复杂类型 (结构体) , 这种情况下编译器会查询运行时及时发现新类型的引入, 在控制台输出中给出提示, 并自动生成与proxy/stub库相匹配的序列化库源文件。该库中包含了接口头文件所引入的所有新复杂类型的序列化函数的框架, 程序员必须添加自己的实现代码。作为一种可选的方式, 运行时本身含有一个默认的序列化库, 其中已经实现了大多数需要使用的MapGis7.x定义的复杂类型的序列化函数。程序员可以选择实现自己的序列化函数或者预先告知库维护者在运行时默认库中实现其涉及到的新复杂类型。

2.2 RPC运行时

RPC运行时实现为一个动态库, 它提供了如下的API。

2.2.1 应用层协议CMsg类

因为套接字之间发送接收的是无类型字节流数据, 为了客户与服务器能理解相互之间的请求与回复, 我们定义了一个简单的服务请求/回复应用层协议:每一个C/S之间传递的调用与回复数据包都必须封装为一个CMsg对象。它维护了如下的重要状态: (1) GUID:本次函数调用过程的全局标识符。用于客户端匹配服务端回复消息; (2) MsgType:本消息的类型, 请求/回复。在网络传输发生异常时用于除错; (3) CmdNo:请求的函数标识号。该标识号是全局标识号, 每个函数一个标识, 不能重复。该信息一般存放于C/S共享的全局配置文件或头文件里; (4) SrvState:枚举值, 存放服务器运行时返回码 (成功或各种具体错误) ; (5) CmdRtn:函数返回值 (不是通常意义的返回值, 而是服务的状态返回值, 成功或各种具体错误) 。由MapGis7.x定义; (6) m_ParamStream, m_ParamStrmLen:存放已打包的调用参数; (7) m_DataStream, m_DataStrmLen:存放本CMsg对象打包后的字节流数据。

2.2.2 客户端运行时接口CGisClient类

并提供了TCP/UDP两种实现。该类主要实现了以下的方法:

(1) RemoteCall:这是客户端运行时的主要方法, 它完成以下功能: (1) 生成本次函数调用请求的CMsg对象; (2) 发送序列化后的CMsg对象; (3) 阻塞等待服务器的回复; (4) 将回复字节流恢复为CMsg对象, 验证消息身份以及调用结果, 提取返回参数字节流; (5) 返回。

(2) Connect:连接地址为SrvIP的服务器, 该地址以及服务器端口都应保存于配置文件中。通过配置工具修改。

(3) Disconnect:断开与服务器的连接。

(4) SetSelectTimeOut:内部使用, 设置轮询接口时的超时, 通过配置工具调用修改。

(5) SetCallTimeOut:内部使用, 设置远程调用的超时, 通过配置工具调用修改。

2.2.3 服务器套接字CGisSvcSock

因为服务器通常都处在并发状态, 在同一时刻维护多个连接以及监听端口, 所以我们为服务器设计了专用的套接字类, 提供了更安全的数据传输和I/O缓存管理功能。

2.2.4 服务器管理对象CGisSrvManager

该对象实现服务器除数据传输以外的主要业务逻辑。服务器管理与组织本地服务有两种简单的思路:第一种将服务与服务器代码编译成一个单独的exe, 这样做的好处是转发服务调用非常简单, 就是一个本地函数的调用。但缺点也是明显的, 不灵活, 每次添加删除服务都需要重新编译exe, 而且无法对服务器进行远程配置, 动态加载或删除服务。第二种思路为将服务器与服务分为不同的模块, 服务器为一个单独的exe, 它自身并不实现任何服务。而服务按照不同的功能分类编译为一个个单独的动态库, 然后存放于一个指定目录, 服务器在启动时加载全部动态库, 或仅在第一次调用服务时加载服务所在的动态库。我们采用第二种思路。

该类提供了如下接口: (1) 构造函数, 根据参数创建TCP或UDP监听套接字, 并将其加入监听套接字集合; (2) ListenerRegister:注册监听端口, 用户可以注册自己的监听端口; (3) ListenerUnregister:注销监听端口; (4) SvcRegister:注册一个服务; (5) SvcUnregister:注销一个服务; (6) ReadMapFromConfig:从配置文件初始化服务映射图。未实现, 待扩展; (7) CreateSvcMap:在指定目录中加载服务动态库并创建服务映射图。该目录由配置文件维护; (8) Start:根据参数采取TCP或UDP方式进入服务器主循环。之所以要分开TCP和UDP是因为两种协议的监听策略和并发策略是完全不同的; (9) Stop:服务器停止服务。

内部实现函数包括: (1) MainDispatch:中央转发函数。完成服务请求到服务调用; (2) UdpMainLoop:UDP主循环; (3) TcpMainLoop:TCP主循环; (4) UdpServeRequest:UDP服务调用响应函数, 调用MainDispatch; (5) TcpServeRequest:TCP服务调用响应函数, 调用MainDispatch。

结合了接口编译器所产生的proxy/stub库, 模块间的调用关系如下:

3 系统流程图

作为总结, 本文将以启动服务器、启动客户端并进行一次远程函数调用的完整流程来说明整个系统的运行流程。

摘要：基于ONC SUN RPC协议 (RFC1014、1050) 及其linux2.6实现, 提出了一种全新的基于原始接口编译的远程调用部署方法, 使得本地动态库的远程化过程变得清晰明了, 并显著地减少了代理以及桩库的编写工作量, 在MapGis7.x分布式网格地理信息系统应用服务器的开发以及部署工作中初见成效。

关键词：远程调用,接口,分布式系统,代理,桩

参考文献

[1]RFC707A High-Level Framework for Network-Based Resource Sharing.

[2]RFC1050RPC:Remote Procedure Call Protocol Specification.

[3]RFC1094NFS:Network File System Protocol specification.

[4]ONC+Developer’s Guide, Sun Microsystems, Inc, May2002.

[5]RFC1014XDR:External Data Representation Standard.

部署方法 篇3

关键词：移动多媒体广播电视,部署,监测,单频网

0 引言

目前移动多媒体广播电视 (CMMB) 已经部署超过300个地级以上城市, 覆盖人口已过5亿, 根据广电总局办公厅广办发技字 (2009) 220号《广电总局办公厅关于将移动多媒体广播电视纳入安全播出管理的通知》精神要求, CMMB已经纳入安全播出体系, 怎样对CMMB进行有效监测已经成为迫在眉睫的问题。CMMB作为新媒体既有同传统媒体的相通性又存在一定的特殊性, 作为CMMB监测网, 除前端监测设备及监测系统等软硬件支持外, 怎样合理地部署前端监测设备对监测效果的好坏有着至关重要的影响。本文将对CMMB前端监测设备部署展开研究。

1 CMMB监测需求分析

1.1 CMMB监测内容

监测内容决定监测形式, 监测设备的部署要以监测内容为准绳。作为CMMB的监测应从两方面考虑。第一, 播出质量监测。播出质量监测主要监测对象为发射机, 可以通过监测设备收测效果体现发射机基本运行状态。监测主要指标为信道功率、误块率和载噪比。第二, 播出视音频内容监测, 播出视音频内容监测既要对正常节目内容进行实时监看和录制也要对非正常播出内容及时发现。

1.2 CMMB覆盖方式

CMMB通过分发信道卫星将中央节目平台节目内容转发至各地市播出前端, 地市播出前端加入自己节目后通过U波段进行覆盖发射, CMMB覆盖方式如图1所示。300个地级以上城市已经进行CMMB播出覆盖, 根据城市具体情况不同, 发射机数量也不一致, 以北京为例, 现在共有13台1k W发射机对北京五环以内地区进行覆盖发射。除此之外, 市内部分接收效果不够理想的位置还存在5W～500W的补点发射装置。1.3监测需求

1.发射机监测可以通过监测前端设备对CMMB信号的采集实现, 采集的各项指标参数要能够基本体现所监测发射机覆盖区的服务质量, 如果发射机发射参数有所调整, 监测设备可以对发射机的调整及时响应, 当发射机出现异常时监测设备可以通过对指标的监测进行实时报警。

2.内容监测主要分为两个方面:

第一:对正常内容做到实时监看、监听、录制, 可以对黑长、无伴音和图像静止等异态情况进行及时报警;

第二:及时根据指标及内容的异常进行报警, 然后进行人工干预。

2 CMMB部署方法

由1.3中监测需求而知, CMMB监测设备部署既要考虑到对发射机的点对点监测又要考虑到对整网的全面监测, 这样就需要有数量庞大的CMMB监测前端设备进行支撑, 但考虑到工程实施问题建议进行分批部署, 即实现对CMMB发射机的一对一监测再进行对CMMB发射网的补点监测。

2.1设备安装位置要求

设备安装位置的合理选取对收测效果的好坏影响很大, 在设备安装之前需要对发射机的服务区进行了解, 在设备可能的安装位置进行长时间定点收测, 对收测数据进行统计分析, 保证大部分数据分布在合理范围之内。

根据实地收测发现如果发射机运转正常, 在接收点接收电平变化将保证在±2d B以内, 但在短时间内会有部分值会分布在±4d B之间。

监测设备安装位置满足以上接收效果要求, 即认为安装位置理想, 可进行安装。但如果由于安装位置条件所限, 无法达到以上接收效果就必须通过选取合理天线对接收信号进行补偿。

2.2监测信号的回传方式分析

由于CMMB采用多点发射, 如果对发射机进行监测仅凭一台监测设备是远远不够的, 需要多台监测设备进行一对一监测。

由于安装条件所限, 完全使用广电自身的有线链路将造成工程实施难度大、网络租用维护费用高昂等诸多问题。同时为了考虑信号接收问题, 选择更为灵活的传输方式尤为重要。在保障传输稳定、灵活的前提下, 参考现有各种形态的传输方式, 个人认为采用有线与无线3G联合组网的方式切实可行。

1.CMMB采用H.264编码技术, 视频码率384k Bps, 音频码率42k Bps, 总速率在500k Bps以内, 就比较成熟的CDMA2000而言, 上行速率最高到1.8Mbps, 只要不发生同时多链接的情况完全可以满足CMMB监测内容传输的需求。

2.由于信号接收的好坏决定着监测效果的优劣, 所以在设备选址时应优先考虑位置对接收效果的影响。这样, 3G这种无线连接方式就为按信号优劣选址提供了最大的可能。

虽然无线传输方式具备设备安装灵活, 费用低廉等优势, 但由于这种方式本身的特性所限, 相比广电的有线方式, 传输不够稳定是其最大的弊病, 综合有线及无线的各方面优势, 在组网时建议采用有线与无线相结合的联合组网方式, 即在所监测城市安装一台有线设备, 其它发射机使用无线设备监测, 这样既能保证信号的稳定回传, 又能保证发射机的一对一监测。

如采用联合组网方式应注意以下问题:

1.采用无线专网方式, 各监测设备应具备独立的固定IP地址;

2.采用VPDN方式对传输内容进行保护;

3.3G传输速度主要取决于无线基站出口带宽, 由于出口带宽为4M, 所以在人员稠密地区可能会出现视频流卡、顿等现象, 所以在布点时应进行实地传输测试。

2.3部署步骤

由于采用发射机一对一监测, 所以设备部署量较大, 在短时间内很难将设备完全部署到位, 应合理安排设备安装顺序。建议采用先主后补、分批安装的原则进行工程实施, 首先保障每个城市可以有一台利用有线传输方式的监测设备可以进行有效的、稳定的CMMB监测, 其次再进行补点安装, 实现对发射机的一对一监测。最后, 对于人员集中区域及敏感区域可以安装适当数量的补点监测设备, 保障对非法插播信号的及时发现, 最大限度地避免不良影响的对外扩散。

2.4部署中应注意问题

2.4.1发射机一对一监测问题

由于需要对发射机进行一对一监测, 所以监测设备对发射机的识别问题尤为重要, 虽然在GY/T220.1-2006《移动多媒体广播第1部分:广播信道帧结构、信道编码和调制》中规定了发射机标识序列, 但是实际发射中这个序列并未启用, 所以从广播信道帧中无法对发射机进行识别。在设备部署过程中应严格保证安装位置远离多台发射机的相干区, 监测设备仅能唯一接收其所监测发射机的信号。

2.4.2组网安全问题

如果采用联合组网方式则安全问题尤为明显。无线网应选用专网、VPDN等安全技术。如果需要更高的安全级别, 建议有线、无线均单独组网, 使用单独的控制系统, 无线网数据可以单向推送至有线网, 严格避免双向连接。

2.4.3接收天线问题

如果监测设备在发射天线附近, 使用大增益天线进行接收, 发射机在降功率时监测设备监测到的功率变化并不明显, 根据实地收测结果而知, 发射机满功率发射仅比半功率发射的监测值大1d B左右, 基本无法对发射机功率变化进行识别。

3 结束语

移动多媒体广播电视监测是一个新兴课题, 与以往的传统媒体监测存在不同之处, 本文从设备安装、监测数据传输方式及组网方式等部署问题进行了阐述, 对CMMB监测提供了一些参考, 不妥之处, 敬请指正。

参考文献

部署方法 篇4

传统的制造企业正在从单一生产车间向多功能的生产中心过渡。由于竞争环境日趋激烈,制造企业仅有充足的生产能力是远远不能够适应市场快速变化的需求。在某种意义上,制造企业应该能够预测不断变化的市场,生产制造的概念正在从强调生产到强调过程控制转变[1];生产制造概念的提出,就是找到一种方法,从过去的企业强调生产能力的充足到现在的注重生产过程控制。作为一种成熟的解决方案,MES已经得到广泛应用。目前已经开展了很多旨在挖掘对MES部署具有影响因素的研究工作。减轻文档工作的负载是MES带给工业领域的显著的优势之一。因此,影响 MES部署和实施的因素成为许多研究人员一直以来努力研究的热点话题。

有关如何生成用于描述MES部署所需文档是非常重要的关键因素 。目前,IEM概念能够很好地描述MES的部署,而且有些公司已经采用了这个概念,并已在其业务中使用相应的软件IEM/MO2GO。然而,使用当前版本的IEM/MO2GO并不能对一个相对复杂的MES部署模型作很好的描述。由于对图形文件格式(目前只支持JPEG格式)的支持有限,文档中的一些关于MES部署过程视图可读性不强。通常情况下,在信息流中定义的元素已经具备了更多更细致的信息,但却没有有效的方法来获取这些信息,并把它生成到文档中。

为了处理上述情况,本文将阐述如何通过生成SVG格式的视图,并将它们链接在一起用于展示整个MES部署过程。

1 研究现状

在制造企业之间的竞争日趋激烈的今天,制造企业更希望他们的生产线与市场同步,需要有一种方法或工具来实现这一要求。制造执行系统(MES)是能够辅助管理工厂制造流程,实现生产线与市场同步的信息技术系统,它能够提高企业的市场竞争力和生产效率,现已得到广泛应用。因此,有很多的建模方法用于模拟制造执行系统的实施部署过程,集成化企业建模(IEM)就是其中之一。集成化企业建模是由弗劳恩霍夫研究所(IPK)开发,该研究所主要从事生产系统和设计技术的研究。

1992年,总部位于波士顿的AMR研究所,对制造应用企业的执行层提出了制造执行系统的概念。这个概念存在于企业与控制系统之间,是为了提供可视性和控制功能[2]。 后来的定义来自于1997年MESA(制造执行解决方案协会),其中指出“制造执行系统提供从订单到成品的优化生产的活动信息。使用现有准确的数据,制造执行系统能够指导,启动,响应以及生成工厂活动的报告。这样的结果能够反映不断变化的条件,有助于减少非增值活动,有效地推动工厂运营和管理。制造执行系统提高了经营性资产的回报,准时交货率,存货周转率,毛利率和现金流量。制造执行系统提供有关企业和供应链通过双向通信活动的关键信息。” MESA国际标准对制造执行系统功能有11种描述[3] :资源分配和状态、操作和详细调度、调度生产单位、文档控制、数据收集和采集、劳动管理、质量管理、过程管理、维修管理、产品跟踪和谱系以及性能分析。

ISA-95标准将企业应用程序定义分成三个识别层:实验室信息管理系统(LIMS)、仓库管理系统(WMS)和计算机化维护管理系统(CMMS)。另一种关于制造执行系统解释更为自然,能够贴近于部署制造执行系统的过程。这个定义也将企业应用功能分成三个层次[4]:“顶层被称为商业规划和物流”,“底层的功能适用于有关具体过程中的批次,连续和离散控制活动”和“位于上述两个功能层之间生产经营管理层,相当于现代的制造执行系统”。

生成制造业使用制造执行系统来帮助企业设计他们的生产线已有十多年的历史了。鉴于制造执行系统解决方案覆盖范围之广泛,一些技术已在不同的领域发生了变化[5]。虽然制造执行系统概念的主要内容仍然存在,但是上述变化将带来对未来的制造执行系统解决方案的影响。这些领域包括:精益生产(LEAN)、过程分析技术(PAT)、移动设备、企业应用集成(EAI)、生物识别、射频识别。

集成化企业建模的概念是用多视图模型的方法来描述制造企业的信息流和产品流[6,7]。 此外,这个概念还支持不依赖现有的组织结构的业务流程分析。

集成化企业建模(IEM)分析了“面向对象的方法”并将其用于企业建模这一概念。IEM概念定义了业务流程中的四个基本要素。使用这四个基本要素,IEM可以描述 “通用模型”[8]的基本结构。IEM/MO2GO 系统可以模拟应用集成化企业建模(IEM)这一概念的建模过程,同时提供多种方法分析模型。例如在某些行业信息系统的规划或实施。

基于IT系统实施部署的调查,IT实施的文档作为影响IT项目管理的重要因素之一已经被多次直接或间接地指出,对IT项目的最终实施有重大影响。 MES部署作为IT系统实施部署的特例尤其需要文档支持。因此,一个有特色的文档生成工具将对MES实施部署具有很大的帮助。

2 图形生成

2.1 MES部署过程

图形生成模块将实现,以矢量图和位图的视图来描述MES部署过程模型。

位图格式文件如JPEG、 GIF和PNG常用于当前的办公软件中。位图文件十分便于存储、压缩和作为图表形式插入其他文件中。虽然位图格式文件容易处理,如 Java 能够很容易地生成JPEG文件, 但是位图文件的一些缺点并不适合本项目,如对图像放大或是缩小都会破坏文件的质量。这样将不适合本项目,因为多数情况下,生成图像将被数倍放大于原尺寸。

因此,基于以上分析,向量图形文件将更适合。矢量图形,如点、线、曲线和形状,或多边形,它们都是基于数学方程,代表在计算机图形图像的几何图元。这些特性恰好适合该项目的需求,但这种文件格式的兼容性不太好,像通常用户需要插入图形到Microsoft Office办公软件,由于SVG和EMF自身的限制,有时图形不能正确显示。因此位图格式的图形仍然是这个项目的备份计划。

图形生成模块提供两种方式用以生成描述MES部署过程的图形文档:位图和矢量图。对各功能模块描述具体如下:对于使用IEM/MO2GO客户端编辑过的MES部署过程模型,此系统将提供如下功能:生成选择元素视图,若视图文件为JPEG,系统提供在内存中拷贝功能;生成若干视图描述整个MES部署过程,如果视图中存在逻辑关系,需将其关联。如上功能详细描述如下:

(1) 生成选择元素视图

生成选择元素视图实现如下功能:对于在IEM/MO2GO客户端编辑过的MES部署过程模型,本系统可以输出位于同一层的含有被选定元素的最小矩形视图。视图文件格式支持SVG,EMF,JPEG。

(2) 生成若干视图描述整个MES部署过程

生成若干视图描述整个MES部署过程实现如下功能:对于在IEM/MO2GO客户端编辑过的MES部署过程模型,如果MES模型包括若干层,即模型中的Action存在细化描述,则本系统可以以SVG的格式输出所有层。并且使用SVG中链接的特性,将子层与父层链接。可以在支持SVG的浏览器中通过单击Action的图形区域实现对子层的浏览。

每个模块的要求简要介绍如表1所示。

2.2 SVG矢量图

矢量图文件格式如SVG是一种以可扩展标记语言(XML)为基础的文件格式,它可以十分方便地转化成其他图像格式。由于SVG是基于XML的文件格式[9],所以SVG可能嵌入到超文本标记语言(HTML)中,成为在线文档生成的一部分。 “SVG格式图形可以在任何文本编辑器中创建和编辑”[10]。

SVG是一个相对新的矢量图形文件格式。它是一种基于XML的文件格式的,用于描述二维静态或是动态矢量图形一个语言族群。今天,SVG仍然是一个无专利的、公开的和正在进行的项目。坦率地说,SVG是这样一种通用的文件格式:“SVG难以归类在一个简单的定义中”[11]。最重要的是,SVG是看被作一个绘图解决方案,正因为如此,SVG是囊括了所有基本的矢量图形通用的绘图方法的系统[12]。

所有当今主流Web浏览器至少在一定程度上支持SVG矢量图形,其中包括Microsoft Internet Explorer 9,Mozilla Firefox,Google Chrome和Apple Safari。然而,没有更早期版本的如Microsoft Internet Explorer(IE)支持的SVG矢量图。 “2010年8月31日,谷歌宣布索引SVG内容的Web,SVG的文件无论在独立的文件或嵌入在HTML中都将会被索引。用户开始看到SVG内容在其搜索结果中列出”[13]。“2010年12月8日,谷歌图片搜索也开始索引SVG文件”[14]。2011年1月28日,“谷歌开始允许仅限于SVG图片文件搜索结果。[26]”此功能于2011年2月11日正式公布。

如上所述,batik是用于Java应用程序中绘制SVG图形的开发工具。 它可以被看作是一个Graphics2D的Java解决方案,以DOM树结构组织所有绘画元素。SVG图形可以很容易地显示在Web浏览器和嵌入HTML中,有很多鼠标动作在SVG图形中得到支持,链接就是其中之一。

2.3 SVG视图生成

SVG的模块包含两个子模块:Selected Elements子模块和All Layers子模块。

SVG视图生成子模块(Selected Elements子模)块将为这个系统中的大部分功能模块提供非常基本的服务。它以一个Action实例作为输入,输出只包含选定的元素图形视图。图1显示了这个模块的结构。Selected Elements子模块的核心是LayerSVG,它聚合zeichenflaeche类和SVGGraphics2D类; 它依赖于PaintFNS接口关联与MComponent类。Linie类和Rechteck类是PaintFNS接口的实现。

Selected Elements子模块的算法

实现生成选定的元素的SVG格式视图文件的逻辑十分自然。由于IEM/MO2GO客户端已定义了元素的颜色,形状,默认的字体风格,和元素尺寸,根据用户喜欢显示比例,该功能模块将元素的绝对位置转换成显示位置,该功能模块中有一个标志位,指示元素是否选中(高亮)。所有这些信息都是密封在MComponent类中。因此,整个绘画过程将开展如下:

S1 找到所有选定的MComponents,并将它们保存在一个列表中。

S2 因为每一个MComponent有一个新的显示位置和显示比例,这样不难找到的包含所有选定MComponent的最小面积。

S3 设置背景颜色。

S4 设置新的原始点(通常在左上角),显示比例(缩放因子),把所有MComponents位置转换到新位置。

S5 生成每MComponent的图形。这里MComponent需要分解成基本部分来绘制。例如它可以分解成线、矩形和非图形(如一个元素的名称),然后用各自的方法来绘制它们。

2.4 MES部署过程模型视图生成

MES部署过程模型视图生成子模块(All Layers子模)块将产生MES部署过程的所有layers的SVG格式视图。这一模块将采用输出文件路径和存有MComponent的数组作为输入,并生成一个文件夹,其中包括描述MES部署模型的所有Layers的SVG格式的视图文件。 LayerSVGAll类聚合zeichenflaeche类和SVGGraphics2D类; 它依赖于ActionElementsAll类和MComponent类; 它有一个PaintFNS类的接口。

(1) All Layers子模块的算法

由于IEM/MO2GO客户端框架限制,实现这一模块不能直接使用Selected Elements子模块。因为只有在当前操作窗口的元素才能被系统初始化,那些没有在当前操作窗口中显示的元素没有被初始化(如定义的颜色,形状,例如,设置新的坐标)。但是因为当IEM/MO2GO客户端打开任何文件时,它总是可以显示一个root下面的一个Layer (层) ,而所有的层之间的关系是Action联系起来的。任何IEM定义下得模型都服从服这个概念,可以找到所有带有子层的Action,放在其一个列表中。考虑所有带有子层的Action可以在上级层预览,如图2所示。因此,应用这个逻辑于所有子层。(用户预览子层时,IEM/MO2GO客户端会初始化在这个子层的元素,但坐标是负值)所有子层可以在这种方式生成。之后,此系统需要将它们连接在一起。除顶层外,所有图层命名其Action的GUID。当这个系统生成一个层的视图文件时,它会找到在这一层内有子层的所有Action。根据它们的坐标,该系统将新生成SVG格式文件根据其Action的坐标把他们链接起来并保存在一个新的文件夹中。 IEM模型中的所有元素都可视为根的子节点。IEM模型中每层元素也可视为存储在相应深度树的某节点。如一个Action的子层,则该子层内的元素可视为Action的子节点。 图3显示的IEM模型的数据结构。

我们使用基于 DFS 算法遍历IEM数据来得到所有Actions,流程图见图4,具体算法的伪代码如下:

4 系统测试

对于SVG的模块,由于Office Word中不支持SVG格式,因此测试结果不能显示在Office Word。鉴于在对系统功能测试的同时考虑到系统应用的一般性,故所选是示例为IPK提供的描述MES部署过程的模型。该模型中含有108个Actions,其中13个Actions有子层。

图5是SVG模块中“All Layers”功能模块在生成结果截图。从这个截图中,可以看出,pic0.svg过程模型的顶层,如果用户把鼠标浮在Action“Acquisition”之上,将会有如图6所示信息,这个图形将链接到文件“pic{6E0D4F44-18E0-4E86- A6B6-57988003918B}.SVG”对应与图5。这是使用SVG的一个特性来展现完整MES部署过程模型。

系统的功能测试基本遵循黑盒测试,鉴于部分测试结果无法在Office Word展示,所以功能测试章节没有展示全部测试结果。本系统不仅在系统功能层面完全满足系统设计需求,而且其提供的功能能够描述当前MES部署过程模型。

5 结 语

本文提出了图形化的方法来展示MES部署过程。借用SVG模块,用户可以自动生成MES部署过程中的任何视图,并且可以利用生成一系列链接在一起的视图文件描述完整的MES部署过程。本方法的优点之一就是降低了MES部署模型的文档生成时间。通常来说,当制造公司部署MES系统的期间,往往需要花费6周到8周的时间来部署一个新系统,本文提出的方法可以缩短这个时间。而本文提出的标准适合于当前的MES部署。对于将来的MES系统,随着IT和制造业的发展,描述MES部署过程将会出现不同于现在的观点。

部署方法 篇5

资源预留指在实际使用资源之前对其将来需要的一段时间进行预留,确保资源使用者在使用过程中获得所需要的资源能力[1]。作为实现任务间时间隔离的主要手段,资源预留一直是实时系统研究的主要方向之一。近年来,资源预留在多核/多处理器平台上的研究获得大量的关注,其中一种较常用的方法是将实时程序划分为多个执行流,每个执行流可以使用单核上资源预留技术进行分析和设计[2]。 然而该方法并未考虑如何将各执行流实际部署到多核处理器上。本文将该部署问题映射为装箱问题, 并提出了基于首次适应算法(FF)的FF—SA算法来解决部署执行流所需处理器核数量的最小化问题。该算法在保证程序实时性的同时有效减少资源浪费, 提高了系统运行效率。

1问题描述

本文考虑多个实时程序以资源预留的方式在处理器核上运行,利用文献[2]提出的划分算法将实时程序划分得到的执行流集 ,使其满足实时性要求。现要将执行流集部署到处理器核集上,建立各个执行流与处理器核的映射关系,且使得所占用的处理器核数最少。假定处理器核之间的通讯开销不计,每个执行流只能在一个处理器核上完成,一个处理器核可以处理多个执行流。

2执行流部署问题映射

上述问题可以映射为一维装箱问题。该问题可以描述为:设有多个具有同样结构和负载的箱子B1,B2.... 其数量不设上限。每个箱子的负载(可为长度、重量等)为C,现有m个负载为wj,的物品J1,...,Jm需要装入箱内。现在需要寻找一种有效方法,使得能以最小数量的箱子数将J1,...,Jm全部装入箱内。

由于执行流以资源预留的形式执行,且假定处理器核之间的通讯开销不计,因此执行流之间可视为相互独立。此时,多核处理器上执行流部署问题近似于一维装箱问题,即将不同“尺寸”的执行流“装” 到空间大小固定的n个处理器核中(n不设上限)。其中,执行流fj的“尺寸”定义为该执行流的CPU利用率(所占的带宽)Uj=Cj/Tj,其中Cj表示执行流中所有任务的执行时间之和,Tj表示执行流的周期,任意处理器核Pi的最大空间为1。因此,该部署问题的数学模型可表示如下:

设

则执行流部署问题的整数线性规划模型为:

3执行流部署FF—SA算法

由上节可知,该问题可以映射为一维装箱问题, FF算法是经典的解决一维装箱问题的启发式算法, 但该算法受执行流顺序影响且容易陷入局部最优, 为此本文提出了FF—SA算法。该算法可分为两步:

(1)用FF得到执行流部署的初始解。FF算法思想如下:对每个执行流来说,总是从第一个处理器核开始,如果第一个处理器核剩余的资源能够满足这个执行流的需求则将此执行流部署在该处理器核上,如果没有则判断第二个处理器核,以此类推。 当已用的处理器核不能容纳当前执行流时则使用一个新的处理器核。伪代码如下:

( 2 ) 将FF得到的初始解作为SA的初始解,利用SA进行优化,得到最终解。SA算法核心思想是: 由初始解和初始设定的控制参数T(初始控制温度) 开始,算法持续进行“产生新解判断接受或舍弃”的迭代过程,当控制参数T逐渐减少并趋于温度下限时,系统亦趋于平衡状态,算法停止,此时得到的解即为近似最优解。伪代码如下:

其中C(S)表示解为S时的评价函数,本算法中的评价函数是指当解为S时执行流集占用的处理器核数。 每个T值的迭代次数为L(处理器核数),内循环终止条件是连续拒绝的次数等于给定值时停止迭代Generate产生新解的过程如下:若是第k次产生新解,则取出处理器核Pk的所有执行流,将Pk+1到Pn的编号改成Pk,...Pn-1。按照执行流占带宽从大到小排序,将执行流依次部署到利用率最低的处理器核中,从而得到一组新解。

4实验评估

本文将通过仿真实验来评估FF算法和FF—SA算法在不同情况下的性能。仿真平台主机配置为: Intel Core i5 CPU,2.00GB内存,Windows7操作系统。所有程序代码都采用python语言实现的。利用随机程序生成方法,将依据如下多个可调参数随机生成测试程序:

执行流数m:程序划分后得到的执行流数量

处理器核数n: 执行流最终占用的处理器核数

带宽Ui: 执行流fi的CPU利用率,即所占的带宽

总带宽U: 各个执行流的带宽Ui总和

对任何一组上述参数的设置,随机生成50个测试程序并取结果的均值。对每一个程序,分别使用FF算法和FF—SA算法计算该程序运行所需占用的处理器核的数量,并对其进行比较。

首先比较不同的执行流数对算法的影响,测试程序包含的执行流数m为100~200个,带宽Ui在0到1之间随机分配。由图1所示结果可见,两种算法得出的处理器核个数都随着执行流数目的增加而变多。 同时还发现,当m相同时FF—SA算法比FF占用的处理器核个数要少,且当m变大时两者的差距也在变大大。。这这说说明明FFFF——SSAA算算法法能能够够节节省省处处理理器器资资源源。。

图1 执行流数m对FF和FF—SA算法的影响比较

接着比较总带宽U对算法的影响,将执行流数m固定为100,而评估U在[10~50]区间内变化时,测试程序所需占用的核数。对于每一个U的取值,使用UUni Fast-Discard算法[4]生成一组执行流。为分析在总带宽U相同的情况下Ui的取值对算法的影响,在第一组实验中执行流集中的每个Ui在[0~1],结果如图2所示。而在第二组实验中执行流集前50个Ui在 [0~0.5],后50个Ui在[0~1],结果如图3所示。图2,3结果表明:FF—SA占用的处理器核比FF少。随着U变大,FF—SA与FF占用的处理器核数的差距也变大。 同时还可以发现:在U相同的情况下,图3得出的处理器核数比图2少。这是因为当Ui较小时,单个处理器核上可以容纳更多的执行流。

图2 U对FF和FF—SA算法影响比较(m=100,在[0~1])

图3 U对FF和FF—SA算法的影响比较 (m=100,前50个Ui在[0~0.5],后50个Ui在[0~1]) (参见右栏)

5结论

本文将执行流集部署到处理器核集上的问题映射为一维装箱问题,并对比了FF算法和FF—SA算法对执行流在多核处理器核上部署的影响。实验结果表明,相对于FF算法,FF—SA算法更能减少处理器核的个数。

图2 U对FF和FF—SA算法影响比较(m=100, 在[0~1])

部署方法 篇6

装备部署性是指装备从某区域到另一区域之间连续不断的调动、展开、使用、撤收的能力[1]。装备部署性与其运用铁路、公路、水上、航空等方式运输性、整体装卸搬运性、装备自身机动性、展开撤收方便性以及装备在不同地区的环境适应性有关。野战卫生装备主要在作战、演习、抗震救灾等紧急事件的特殊野外环境中使用,需要满足边集结、边展开、边抢救、边后送、紧跟部队伴随保障的装备部署性需要。快速部署性作为野战卫生装备的主要性能之一,对野战卫生装备使用性能发挥具有极为重要的影响,也是野战医疗装备与普通医院医疗设备的最大不同。因此,对野战卫生装备部署性进行合理性评价具有重要意义。

实际装备部署性评价涉及影响因素较多,各因素之间并非都有确定的数量关系。有些部分信息不全,具有很强的灰色性。要想在信息不全的条件下,评价医疗卫生装备的优劣,传统数学方法较为困难。灰色系统理论采用关联度模型来量化研究系统内各因素之间相互作用,根据发展态势相似或相异程度来衡量因素之间的关联度。当在选取参考序列后,其他参数序列为比较序列,参数序列构成的空间几何曲线越接近,则关联度越大。根据关联度可求出与参考序列在空间几何曲线上最接近的比较序列,从而达到对装备部署性评价的目的[2,3,4]。

2 多层灰色关联综合评价模型

2.1 评价指标集与指标系数矩阵确定

设野战卫生装备部署性评价由L层不同结构的指标体系组成。第l(l=1,2,…,L)层评价目标值为Bl,权重为;Bl目标下指标为Pi(i=1,2,…,m),权重为,n种野战卫生装备是被评价对象(方案)Si(j=1,2,…,n);以x*lij表示在目标Bl下评价对象Sj的第i个指标Pi量化后的指标值,则n种方案m个指标的原始数据形成指标系数矩阵Dl*如式(1)所示。

2.2 参考数据列与指标权重确定

根据指标的不同类型,从Dl*中按下列式(2)确定参考数据列x*l0=(x*l10,x*l20,…,x*lm0)T中各元素值。设,采用客观赋权熵值法[4]按下列式(3)确定目标Bl下各指标的权重Wli。

2.3 数据规范化处理

为便于分析,保证数据类型一致化、无量纲化、量级无差别化,需要对原数据进行规范化处理。一般采用数据区间值变换进行规范化处理。不同指标类型有不同的规范化方法,对极大或极小型指标采用下列式(4)的规范化方法不影响评价对象的保序性,综合评价结果相同[3]。经对Dl*、X*l0规范化处理,参考数据列元素x*li0变为xli0,Dl*变为规范化矩阵,如下列式(5)所示。

2.4 灰色关联综合评价模型

设Rl=(rl1,rl2,…,rln)为n个对象的评价结果关联度矩阵,其中rlj表示第j个评价对象的关联度;Wl=(wl1,wl2,…,wlm)为指标权重矩阵。则可建立下列式(6)所示的灰色关联综合评价模型。其中,El为关联系数矩阵,矩阵元素ξli(i)表示目标Bl下第j个评价对象Sj第i个指标Pj与参考对象S0中第i个指标的关联系数。根据矩阵的特点,令序列差Δlij=xli0-xlij,最大、最小极差分别为:mjaxmiaxΔlij=1,mjinmiinΔlij=0,则ξli(i)及rli如下列式(7)、(8)所示[4]。在计算各评价目标n个评价对象底层关联度的基础上,把n个评价对象底层关联度作为上一层指标的原数据。通过确定参考对象、数据规范化处理,确定上一层指标的权重λl,即可求得上层指标的关联度,直到求得整个系统的部署性关联度为至。

3 综合评价实例

本文利用灰色关联综合评价模型对我国S01-40野战手术车(S1)、法国VLRA厢式卫生车(S2)、前苏联ΠΜл型医疗化验车(S3)及ΑΠ-3型细菌化验车(S4)、德国LA911B化验车(S5)[5,6]等5种野战卫生装备部署性进行综合评价。

3.1 影响因素与评价指标体系

影响野战卫生装备部署性的因素可分为装备自身机动性、装备运输性[7]、装备展开撤收方便性、装备部署方式转换性能及装备环境适应性等5个方面,各层次又受不同因素影响,如图1所示[7,8,9]。

根据图中所示部署性影响因素及定量参数,考虑数据来源难易程度、参数间的相关性及评价目标,可以确定装备部署性评价的指标体系。就本实例中,被评价的5种装备的部署方式转换性、展开撤收方便性及装备环境适应性均按建造标准设计制造,各指标参数在评估范围内可认为无差别。即该3项指标对5种卫生装备部署性的最终排序贡献相同,剔除这3项指标对综合评价结果无影响[10],装备部署性评价指标、按指标原数据由式(2)与(3)确定的参考数据列S0及指标权重Wli如表1所示。

3.2 数据规范化

对获取原数据及参考列数据进行规范化处理后结果见表1。

3.4 关联系数矩阵

根据表1中的规范化数据,计算装备部署性综合评价指标与参考数据列对应数值的差,形成差序列矩阵。根据差序列矩阵,按式(7)求得第l层评价对象j的第i个指标与参考数据列对应指标的关联系数,得到关联系数矩阵El,求得的底层关联系数矩阵如E1～E8所示。

3.5 各层关联度

由表1中第l层各指标权重,按式(8)求各个单层关联度,底目标层(l=1～8)关联度如R1～R8所示。

3.6 计算最终关联度

把底层各个装备部署性综合评价指标关联度与上一层部署性指标原始数据相结合,重复上述步骤计算上一目标层(l=1∶2)中第j个评价对象的第i个指标与参考数据列对应指标的灰色关联系数。由此得到该层关联系数矩阵为E1′、E2′,关联度为R1′、R2′。

把该层关联度作为装备部署性次底目标层数据,重复上述步骤计算得到目标层的灰色关联系数矩阵E及关联度。

根据装备部署性目标层关联度可知,5种野战卫生装备部署性由高到低的排序为:S2>S5>S4>S1>S3,即法国VLRA厢式卫生车的部署性最好,前苏联ΠΜл型医疗化验车的部署性最差,其他排在中间位。

4结论

本文针对医疗卫生装备部署性影响因素多、信息贫乏不确定造成综合评价复杂的特点,展开分析研究。根据评价装备的特点,在建立医疗卫生装备部署性层次化评价指标体系的基础上,对评价指标进行规范化,解决装备评价指标数据的公度性问题。通过建立部署性灰色关联矩阵,以灰色关联度作为评判不同医疗卫生装备部署性优劣的准则。实例表明,该评价方法对样本量多少、分布规律没有要求,适应了装备部署性多因素、多目标的综合评价问题。该评价方法简单易行,结果可信。

参考文献

[1]Military Traffic Management Command.Transportability for Better Deployability[PAM70-1][EB/OL].[2004-12-08][2008-08-30]http://www.tea.army.mil/pubs/descriptions/70-1.html.

[2]Li Yongping,Tang Yanzhao,Chen Rongqiu.The grey comprehen-sive evaluation method on investment item[J].The Journal of Grey System,2006,12[4]:383-390.

[3]郭亚军.综合评价理论与方法[M].北京:科学出版社,2002.

[4]肖新平,宋中民,李峰.灰技术基础及其应用[M].北京:科学出版社,2005.

[5]刘训勤,王运斗.外军野战卫生装备发展研究[R].北京:解放军总后勤部卫生部,1997.

[6]肖南,李曙光.俄军野战卫生装备现状及发展方向[J].医疗卫生装备,2007,28[7]:26-28.

[7]刘士通,鲍平鑫,钱润华.加强武器装备运输性研究[J].装备,2002[12]:43-44.

[8]代汝泉.汽车运行性能[M].北京:国防工业出版社,2003.

[9]Qian Runhua,Shi Qixin,Wang Zhimin.Predicting the truck speed based on four factors of transportation engineering:A curvilinear regression model[A].ICTE2007,International Conference on Trans-portation Engineering2007,Virginia:ASCE,2007,1572-1577.

部署方法 篇7

由于电脑技术发展非常快且各行各业电脑使用的范围越来越广泛, 必然面对的是电脑硬件和软件的种类和数量使用越来越多, 电脑硬件和软件更新的速度也越来越快, 目前多数单位使用的系统软件和应用软件是5年至10几年前的旧版本, 功能少、速度慢, 只要电脑能够使用就行无人关心这些问题;部分单位使用的软件较新, 但由于更新、升级工作量大, 因此有心解决此问题, 但因为没有好的快速布署软件工具, 因此无力真正着手解决此问题。

相关的技术管理水平或技术维护水平远远滞后, 导致安装、部署、更新电脑软件、提高电脑整体使用效率成为一项费力、耗时的繁重工作。因此绝大多数单位要么无人尽心尽力管理维护, 要么有心无力去跟上软件升级和布署, 结果造成大量硬件、软件资源浪费, 使用效率低下。如何高效地完成这项工作从而提高整体工作效率的问题应该引起单位主要领导、相关部门领导和从事计算机软硬件系统维护人员高度关注。究竟应该如何快速安装、部署、更新电脑软件从而提高电脑整体使用效率呢?

1 快速布置软件工具选择

首先选择好的多机快速布署软件工具, 目前主要广泛使用的是各种版本的GHOST。虽然简单易用, 但存在许多严重问题。不能支新较高速接口技术, 如:ESATA接口, USB3.0, SATA2, SATA3, 部分较新的主板集成的网卡等, 不支持异机还原、多镜像网络克隆且运行的系统环境落后速度很慢, 多机克隆GHOST对于部分新的电脑无法正常工作。

由于上述原因, 我们一直在寻找一个好的好的快速布署软件工具, 经过多方寻找、摸索、验证, 最终确定使用:Acronis Snap Deploy5繁体中文版, 它可以很好地解决上述所有问题。

2 方法

2.1 方法一:在windows 2008 server r2环境安装并运行Acro-nis Snap Deploy 5

(1) 事先选择好在即将布署的电脑有代表性的一台或几台电脑, 同时确定已经分别作好硬盘逻辑分区, 安装好最新的系统软件和各种应用软件, 应包括各种升级补丁、激活软件、端口保护软件、还原精灵等必备的常用软件, 必须确认运行一键还原精灵解冻保护操作系统。最后使用Acronis Snap Deploy 5或Acronis Backup&Recovery 11.5来制作具有代表性电脑的一个或多个镜像文件的备份。

(2) 然后在局域网络中另外选择一台电脑, 它是为布署多台电脑提供镜像服务的服务器同时也是为其它电脑提供自动分配IP的DHCP服务器。

在这台电脑上安装好windows 2008 server r2和Acronis Snap Deploy 5并可使用批量导入购买的授权码, 在server版的操作系统上, 设置好本机的固定IP地址、添加“DHCP服务器角色”服务, 根据即将布署的电脑的数量预设置好固定的IP范围等。运行Acronis Snap Deploy 5。

(3) 将需要布署的电脑都设置成网卡引导模式, 2.中创建的DHCP服务器根据2.中设置好的等待布署的电脑IP地址范围, 按照打开等待安装布署电脑电源的先后先后顺序, 从小到大自动分别分配赋予不同的IP地址。在已经引导成功且等待安装布署的每台电脑上分别设置好存放有镜像的一台或多台电脑的固定IP地址。

(4) 在DHCP服务器上运行Acronis Snap Deploy 5中发送布署1.中做好的那些镜像。假设一个镜像大小50G左右, 布署27台电脑大约需要十小时左右。

(5) 完成布署后, 对操作系统和应用程序进行激活, 最后运行一键还原精灵冻结保护操作系统。完成全部布置。

用此方法可以完成多镜像多台电脑的布署工作, 但是若只需要布署一台或少量几台电脑时, 所用的时间和布署多台电脑几乎是一样的, 即依然要十小时左右。

2.2 方法二

首先软件使用说明中的方法创建移动媒体。然后手动设置镜像服务器电脑和待布署的电脑的IP, 使用移动媒体来引导开机布署一台或多台电脑。从而可以完成多镜像多台电脑的布署工作, 用这种方法, 需要布署的电脑越少速度越快, 越多速度越慢。

3 结束语

经过对几种不同但具有相似功能的软件比较验证, 通过实际使用证明, 用Acronis Snap Deploy 5软件工具用方法一或方法二来进行多镜像多机布署电脑是目前最完美的布署办法。

参考文献

[1]ADS5用使用手册[S].2002-2014.Acronis International Gmb H.