面向服务建模

面向服务建模（精选8篇）

面向服务建模 篇1

知识资源正在逐渐成为企业的主要财富之一,知识被认为是保持企业竞争优势和创造价值的重要来源[1]。实现知识在项目团队中的有效共享,及时传递,使团队成员能够快速获取完成业务所需知识是实现业务目标的重要保证。因此,如何将知识资源以“正确的方法”分配到“正确的业务活动”,并落实给“正确的人”执行(即知识配置)对实现业务目标具有重要的意义。许多学者在这方面进行了研究。文献[2]构造了大型常识知识库系统CYC,用于人类智能活动的机理研究。文献[3]建立了知识主动推送的控制模型,通过相似度计算对设计人员匹配适当的知识。文献[4]针对产品协同设计环境下设计人员获取知识效率低的问题,提出基于粗糙集的产品协同设计知识推送方法。文献[5]基于业务流程提出知识节点的相关度以及知识网络的模块度,提出了知识的模块化指数并以此来度量知识的模块化程度,为知识配置提供依据。文献[6]提出的视图模型把知识分成who、when、what、where、why和how的5W1H视图,用于知识的抽取。但目前的建模方法还存在不足:(1)知识和业务过程还相对独立,缺乏面向知识配置的有效建模手段;(2)现有的知识配置方法多为单纯知识分配算法,缺乏与业务过程模型的联系。

上述问题产生的本质原因在于知识配置的基本元素及其关系没有在更高的层面上得到全面的抽象。因而底层的知识很难与业务过程模型相匹配,并且知识对象间相关的逻辑关系也难以表达。特定领域建模(Domain Specific Modeling,DSM)[7]是通过对特定领域的分析和抽象,得到该领域的共性和变化特征,建立该领域的元模型,通过模型转换及验证和代码生成实现领域应用。本文采用DSM方法,构建面向知识配置的领域模型(K-DSM),全面描述企业知识资源配置的领域概念和规则,增强领域概念的一致性与规范性。

1 面向知识资源配置服务的特定领域建模模型

知识配置服务是从业务案例和知识资源的解析开始的。本文通过案例和知识的解析建立了如图1所示的面向知识资源配置服务的领域模型(K-DSM)。K-DSM由四部分组成:领域纲要(domain schema)、领域模板(domain template)、应用模型(application model)和应用平台(application platform)。

领域纲要包括业务领域纲要、知识领域纲要和业务与知识相匹配的桥接关系集。领域纲要描述的是知识配置领域中构造系统模型的基本元素,包括业务单元集和知识单元集,单元集描述的是业务和知识中的对象、关系及逻辑。桥接关系集描述业务和知识之间的黏合关系。领域模板是对领域纲要的格式化描述,精确定义领域概念所包含的特定内容和格式。领域模板包括业务过程模型和知识需求接口,是知识配置系统实现的设计纲领。通过对领域概念的抽象描述,领域纲要和领域模板就构成了K-DSM系统中的元模型(meta-model)。对元模型进行实例化应用就形成应用模型,应用模型用于表示面向特定业务案例的具体模型。应用模型包括业务实例化规则和知识载体匹配,保证将知识资源以“正确的方法”配置到“正确的业务活动”后,并由“正确的人”来执行。应用模型形成后,由应用平台执行具体业务过程,应用平台由工作流系统和知识需求模型构成,在传统工作流引擎中增加知识需求,进行知识流的跟踪与管理,以实现与活动执行同步的知识服务。业务活动结束后,运行的结果将能够反应到业务案例库中,实现领域纲要的持续更新,使知识资源配置服务成为可持续改进的过程。

2 面向知识资源配置服务的领域建模过程

2.1 领域纲要

知识单元集是企业知识单元的集合。知识单元由一个或多个知识构成,知识描述两类信息:知识内容信息、知识载体。知识内容信息是知识所包含内容简单、概要的描述,可通过关键词和概要来表达知识主要的核心内容。知识载体是知识所依赖的和存在的宿主,包括人、文档、计算机程序和产品等。

知识单元所包含的知识之间具有逻辑关系,它们是相互关联的。知识之间可能存在内容上的关联关系,或者他们为同一个业务目标(或业务能力)所需求。知识之间的协作网络构成了一个知识单元,如图2所示,图中圆圈表示知识节点,连线表示知识节点间的内容关联或协作关联。

业务单元集是企业业务活动单元的集合。业务过程可以用事件驱动的业务过程(Event-driven Process Chain,EPC)链来表示,EPC模型以业务过程视图为中心,将企业事件、功能、数据、资源集成起来,用于描述企业业务过程。事件视图用六边形表示,描述当前的业务活动状态;功能视图用圆角四边形表示,描述实际运作的业务活动;功能与事件的逻辑关系用圆圈表示,分为3种:与、或、异或。建立EPC业务单元的基本图例如图3所示。EPC业务过程链由这些元素按一定的逻辑关系组合而成,而高层次的业务单元可分解为了多个较细化的业务单元过程链,如图4所示。

桥接关系集是表示业务对知识的利用信息的集合。桥接关系是连接业务单元和知识单元的枢纽,是知识应用到业务活动中的具体背景和环境。桥接关系描述3部分内容:(1)询问业务活动需要什么知识来执行一个功能,一个功能可能对应多个知识,一个知识也可能应用到多个功能中;(2)对知识的精准描述,以功能“绘制零件图”为例,此功能需要“电脑制图”知识,细化到“Auto CAD软件制图”知识,熟练程度为“精通”;(3)描述知识应用中的情境(Context)信息,包括业务目标、任务、事件、时间、地点等要素。以上这些关系构成了桥接关系,如图2.5中桥接关系框所示。桥接关系不仅确定业务所需求的知识,还确定对需求知识的情境信息的描述。

当桥接关系确定以后,业务中所涉及的知识就确定了,所以桥接关系在业务和知识之间扮演桥梁的角色。由业务提出知识需求,桥接关系确定需求内容和对内容的精确描述,从知识单元集中找到合适的知识单元,用于匹配某一项业务活动,保证业务的顺利开展。加入知识单元和桥接关系的EPC模型如图5所示。

2.2 领域模板

领域模板主要包括业务过程模型和知识需求接口。EPC业务过程模板是一系列制造企业模式化流程逻辑的描述,主要保存通用的和企业已经建立起来的EPC业务过程模型。知识需求接口是业务单元对知识单元的需求信息,一端连接业务活动,另一端连接知识单元,并包含了桥接关系所具有的内容,如图6所示。知识需求接口根据不同的业务单元提供不同的知识单元,保证业务的顺利进行。

进行知识配置首先面向要求解的问题,业务案例根据上述业务模板采用EPC方法建立其业务过程模型。因为业务单元集和知识单元集之间存在相互依附关系,当某一业务单元被选中时,相当于与其对应的一组知识单元集也被选中。这里的知识单元是相当于对该业务单元所需知识资源的描述。当整个多层次的业务过程模型建立后,该业务过程模型对知识资源的需求也就确定了。之后形成知识需求接口,提出知识资源配置服务的请求,业务建模层面的任务完成,即要求进行资源配置的对象已经准备完毕。图7为完整的某零件加工业务过程模型。

为了达到满足业务过程与企业知识需求的要求,在构建和维护模板库的过程中有以下一些基本要求:

(1)模板库数据适时性。要保证模板库数据对业务过程管理系统的模板库数据的适时响应。如果业务过程管理系统的模板库数据更新或修改,需求建模系统的模板库应该及时保持相应更新或修改。

(2)自动清除无用模板。有些业务过程模板已经不在使用,模板库应该及时清除。

(3)良好的兼容性。模板库应该能保存异构的业务过程模型。

2.3 应用模型

领域纲要和领域模板准备完毕后,相当于系统元模型已经确立,应用模型是元模型的实例化数据。应用模型包括业务实例化规则和知识映射,业务实例化规则是指业务过程模板在实际应用中的转化指示和规则;知识载体匹配是根据领域模板中的知识需求接口,找到具备所需知识,并能够完成特定任务的知识载体。

基于EPC业务案例的解析建立业务过程模板,并形成知识资源配置方案后,把业务过程模型分解成逻辑相连且不可分割的业务活动链(如图8所示)后,即开始进行真实的知识资源实例化过程。因为所形成的知识配置方案中,只是描述知识需求,并未落实到真实的具备知识的业务执行者,因此需要为每个业务活动找出该活动所需的一些相互协作的知识载体(完成业务活动的人、一个团队或一个工具)。实例资源载体的映射完成,并被预加载(验证资源载体的可用性)后,真正的资源配置服务完成。这样就建立了业务活动与知识载体的映射关系,实现了业务活动对知识载体的绑定。

2.4 应用平台

业务实例化形成应用模型后,实际操作由应用平台完成。应用平台由工作流系统和知识需求模型构成。图9所示为经过扩展后的工作流过程元模型。该模型引入一个新的元素:知识需求。知识需求是指角色为完成特定活动而对有关知识的需求。知识属性中的时间约束与业务活动执行中的时间约束相关联,以实现与活动执行相同步的知识服务。

扩展后的工作流过程元模型为业务过程控制和知识配置的结合提供了基础。该元模型能够描述参与人员在执行活动过程中的知识需求和知识配置机制,以提供完成活动所需要的知识及帮助。同时,业务活动信息为知识需求和知识配置提供了可利用的情境信息,保证知识服务的质量。图10为工作流模型的具体执行过程。

业务过程在工作流系统执行过程中,可能还会提出计划外的知识请求,这时可返回到领域模板中进行知识资源的追加。业务过程执行完成后,该业务案例被提交到业务案例库,实现业务领域纲要、知识领域纲要和桥接关系的动态更新。同时,专家组会对案例执行情况进行评价,修改和完善资源配置规则或业务过程模板,为下次的资源配置服务做准备。

3 实例与结论

根据上文提出面向知识配置的特定建模方法,笔者设计了如图11所示的面向知识配置的K-DSM系统原模型。包括:单元集解析层、业务建模层、知识配置层和业务运作层。其中,单元集解析层主要负责单元集合桥接关系集的构造;业务建模层主要实现业务过程建模并加载知识需求接口;知识配置层主要确定知识配置方案;业务运作层负责业务活动的执行。

知识建模子系统与业务过程建模子系统中的业务过程建模工具可形成知识单元集合和业务单元集,对应特定领域建模框架中的领域纲要。业务过程建模子系统中的业务过程模板工具形成了框架中的领域模型,经过知识需求接口加载,待知识网络建模子系统和知识配置子系统对知识进行评价和配置之后,形成了框架中应用模型。最后工作流子系统执行知识配置完毕后的业务过程,新的业务案例提交到企业案例库中,实现知识配置的反馈。

本文通过深入分析面向知识配置的领域概念,基于DSM方法论,提出了K-DSM框架。并从领域纲要,领域模板,应用模型,工作流模型4个方面详细阐述了面向知识配置的领域建模过程,最后提出了基于K-DSM的系统原模型。

不仅实现了对业务和知识全面、统一的描述和管理,也通过知识配置的反馈作用,实现了企业案例库和知识库的动态更新,满足企业案例库和知识库日益膨胀和复杂化的管理需求。

参考文献

[1]KINGAW,ZEITHALMCP.Measuringorganizational knowledge:a Conceptual and Methodological framework[J].StrategicManagement Journal,2003,24(8):763-772.

[2]LENAT D B,GUHA R V,PITTMAN.Cyc:to-ward programs withcommonsense[J].Communications of the ACM,1990,33(8):30-49.

[3]王生发,顾新建,郭剑锋,等.面向产品设计的知识主动推送研究[J].计算机集成制造系统,2007,13(2):234-239.

[4]杨洁,杨育,王伟立,等.基于粗糙集的产品协同设计知识推送方法研究[J].中国机械工程,2009(20):2452-2456.

[5]杨剑军,战洪飞,黄利民,等.基于业务流程的知识模块化分析[J].科技与管理,2009(6):36-38.

[6]KINGSTON J,MACINTOSH A.Knowledge management throughmulti-perspective modeling:representing and distributingorganizational memory[J].Knowledge Based Systems,2000,13(2):121-131.

[7]耿俊浩,张振明,田锡天,等.面向产品生命周期管理的特定领域建模方法[J].计算机集成制造系统,2008(2):262-267,288.

面向服务建模 篇2

随着计算机网络与嵌入式系统的发展， 将组态软件应用到计算机控制中已成为最新的研究动向。组态软件是一种数据采集与过程控制相结合的专用软件， 在自动控制系统监控层一级的软件平台和开发环境中，用户可采用灵活的组态方式，快速构建工业自动控制系统。组态软件的出现，解决了之前要通过编写程序来实现某一任务的目的。目前计算机控制系统的设计与实现主要采用组态软件的方法。但是现有的组态软件在结构设计和数据结构设计上还存在着若干不足，如面向过程分析面向功能设计、解问题空间和实际系统脱离、数据和算法分离，不便于数据实现和操作。针对这些问题，本文利用面向对象方法进行组态的思想，对于计算机控制系统进行了面向对象分析和设计，并建立相关模型。

一、计算机控制系统的面向对象分析与设计

计算机控制系统有其自己的显著特点，可以采用面向对象方法的思想进行分析和设计。

1、系统的总体结构设计。通过系统需求分析，我们知道该系统软件是利用面向对象的思想来进行计算机控制系统的硬件和软件组态，并实现对计算机控制系统的现场监控。因此，该系统分为两个子系统：设计子系统和监控子系统。设计子系统需要数据库接口、图形用户接口完成计算机控制系统的设计和保存；监控子系统需要通讯接口、数据库接口和图形用户接口完成计算机控制系统的软件和硬件通讯、数据的存储和运行信息的查看等功能。计算机控制系统的设计子系统和监控子系统是通过对象列表实现信息的共享，把软件中表示硬件的控件和现场硬件联系起来，并加以控制。

2、任务管理设计。任务是进程的别称，任务管理部分用来管理任务的运行、交互等。任务管理部分的设计可采用如下的策略：识别事件驱动任务；识别时钟驱动任务；识别优先任务和关键任务；识别协调者；定义每个任务。

该系统中任务管理应根据系统所实现的功能为两部分：设计部和控制部分。设计部分中任务管理主要完成的任务是绘图以及控件信息的数据存储；控制部分的任务则比较复杂，有事件的并发驱动，时钟驱动，优先任务等。 因此，我们将主要分析计算计控制系统的运行任务管理。

3、人机交互界面的理想设计。人机交互部分突出人如何命令系统及系统如何向用户提交信息，其目的是设计出方便、友好的用户界面，这一部分的设计可使用如下策略：对人分类，因为不同的人对于系统的要求是不同的，他们利用系统完成的工作往往也不同；描述人和他们的任务脚本；设计命令层次；设计详细的交互；继续做原型；设计人机接口类；根据图形用户界面 GUI进行设计。

该系统用户就分为设计人员和操作人员两类，设计人员完成计算机控制系统的设计工作，即利用系统使表示硬件的控件和现场的设备进行通讯；操作人员完成计算机控制系统运行中的监控工作，即运行系统，并可查看运行信息，如曲线图、报表及报警信息。

4、数据管理设计。数据管理部分提供了在数据管理系统中存储和检索对象的基本结构。该系统中的数据管理主要是针对设计过程中的控件信息数据管理和控制过程中物理量的数据管理两个部分。

控件信息的数据管理。在设计过程中，针对世面上广泛应用的和已存在的硬件设备，建立与其对应的数据库，实现控件对象的具体化，当创建某一具体型号的设备时，可直接调用数据库信息，提取属性值。如果要创建数据库中未存在的控件，不再实时保存控件的信息到数据库，采用对象列表动态存取各个控件对象的属性。在退出系统和关闭设计窗口时，要保存设计图。

物理量的数据管理。根据设计过程中对历史信息设计，生成相应的表格， 在控制过程中按照设置好的历史信息的时间间隔直接进行存储。如果没有要求保存物理量，则不需要实时保存到数据库中去。系统提供的物理量类是数据的实时显示和实时传递的中转站，使关于实时数据的每次操作都与数据库无关，直接从物理量对象中提取其当前值即可，节省了数据库连接、存储的时间，提高了系统的运行效率。

二、系统部分功能实现

依据建立的静态模型和动态模型，结合系统架构设计和人机交互界面设计，我们利用面向对象程序设计语言Visual C++6.0初步实现了该系统的基本功能。

1、系统设计功能的初步实现。系统的设计功能的初步实现分为实体控件类的实现、控件关联的实现、实体控件和现场设备通信的实现三个部分。

实体控件类是计算机控制系统设计中不可缺少的部分，系统提供的实体控件类的种类直接反映了该系统的全面性和通用性。由于是初步实现，只要求可以完成最简单的单回路输入输出单机控制的系统设计，因此只实现了较为常用的实体控件类。

控件关联的初步实现。控件之间的关联有两种情况：一种是在同一部分设

计中，控件与控件之间通过智能折线相关联，进行数据的传递；另一种则是在不同部分设计中，控件与控件之间的关联。

实体控件与现场设备通信的初步实现。实体控件与现场设备通信的实现也就是计算机和现场设备的通信实现。 根据类的分析，计算机和现场设备的通信方式有三种：串行接口通信、并行接口通信和网络通信方式。

2、系统控制功能实现。系统运行过程中，控制由控制设备实现，即首先在设计窗口的对象列表中查找到控制设备类对象，调用其控制程序，在控制程序中依次调用采集数据、计算数据、输出数据三个操作。在采集数据操作中，即查找控制设备对象列表中的A/D转换器类对象，调用A/D转换器对象的转换程序，当数据已经传递给被控量后，则由与被控量相连的减法器对象（比较器）进行偏差量计算；然后控制设备对象的计算数据操作将查找对象列表中的控制算法PID类对象，调用其控制算法程序，控制程序操作中调用选择好的算法函数，进行计算，然后查找与控制算法对象相连接的控制量类对象，并把计算结果赋给控制量的当前值；这时，控制设备对象的输出数据操作将查找对象列表中的D/A转换器类对象，调用其转换程序，D/A转换器对象在对象列表中查找与其对应的被控量对象，获得其当前值，完成数据的输出。

3、系统人机交互界面的初步实现。在体系结构设计界面中，用户点击控件工具栏中的按钮，添加新的控件。当用户点击计窗口中的控件，控件被选中，将出现黑色线框，并且在属性/格式列表栏中出现，与该控件类的属性单和格式单。用户可以直接设置该控件的属性和格式，点击其它地方后，属性/格式列表栏自动提交并保存。

在控制回路和控制算法設计界面中，控件的连接构成控制回路，直观地表示出了计算机控制系统的控制回路和采用的控制算法。

对计算机控制系统进行全面分析，找出所有的有用对象，并对其属性和操作进行定义；运用UML面向对象分析与设计建模工具，建立计算机控制系统统一的对象模型，为研制面向对象的智能化设计与控制平台打下坚实基础。基于上述所建立的各种模型，初步实现了该开发系统的一些基本功能，系统可以设计出简单的单回路PID控制系统。

参考文献

[1]江杰.乔莉.安世奇.工控组态软件在过程控制系统中的应用[J].微计算机信息，2007.11.

[2]贾洞.面向对象建模技术的实践与体会[J].计算机应用，1999.06.

面向服务建模 篇3

制造执行系统 (Manufacturing Execution System, MES) 位于企业上层的计划管理系统和底层的工业控制系统之间, 是制造企业上层计划系统与下层控制系统的信息桥梁。

市场需求、业务规则及制造流程的经常性变化要求制造执行系统能够快速根据需求进行调整和重构, 面向服务架构[1] (service-oriented architecture, SOA) 的制造执行系统基于开放的工业标准, 具有语言独立性、松散耦合、跨平台、良好的封装性、位置透明等特点, 使得面向服务的MES能够快速地按需应变以满足制造管理的需求, 已成为未来MES发展的趋势之一。

面向服务的架构[2]是在面向对象、面向组件的基础上发展起来的架构模型。而系统建模作为实现系统架构的关键技术之一, 由此产生了面向服务的建模方法。目前国内外所研究的建模方法主要有:基于服务的概念模型和面向服务体系结构层次模型的分析, 自顶向下, 业务驱动和自底向上相结合的服务建模方法;基于模型驱动架构的SOA系统建模和设计方法;基于服务组件的概念和标准统一建模语言建模方法的基础上, 应用MDA (model-drive architecture) 的建模方法;应用UML技术, 基于多代理的建模方法等。

UML (Unified Modeling Language, 统一建模语言) , 是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。UML支持从需求分析到软件开发全过程。通过三类图形建立系统模型:用例图、静态结构图 (对象类图、对象图、组件图、配置图) 和动态行为图 (顺序图、协同他、状态图、活动图) , 从不同的角度实现系统可视化。

本文结合纺织制造执行系统的实际情况及需求, 设计了一种面向服务的制造执行系统架构模型, 在此基础上利用UML进行系统框架的分析设计, 选择Rational rose2003建模工具实现。最后通过系统平台开发验证其可行性。

1 纺织制造执行系统分析

制造执行系统是对整个生产过程的管理和优化的信息系统, 它应具有对从订单下达到产品完成的整个生产过程进行优化管理的功能。纺织机械制造是典型的机电一体化制造, 生产工艺复杂, 且制造模式为多品种小批量。上层计划管理层对计划的制定和执行受市场和实际作业执行状况影响较大, 因此需要能够与底层控制系统实时地交互以满足市场及业务需求变化。而纺织制造执行系统作为上下层沟通的桥梁, 需在上层计划管理层接到市场订单后, 将具体的产品要求下达给MES, MES将控制参数和操作指示下达给底层的控制层。由底层控制层将现场设备、人员的操作及状态反馈给MES, MES根据反馈信息进行各项管理活动, 并将相应信息上传给上层管理层, 以帮助决策。

本文以纺织机械制造的龙头企业——中国纺织机械有限公司为研究对象。通过调研得到该企业现有19台加工中心, 一条机加工生产线及一条钣金加工柔性生产线以及100多台计算机, 具备较好的硬件设施基础。但企业内部的信息化集成程度低, 虽有相关的软件应用系统, 但基本没有实现信息共享功能, 因此形成了信息孤岛。整个制造系统的信息流比较混乱, 且信息反馈滞后, 信息传递的准确性也较低。因此建立一个功能完善的制造执行系统, 既能较好地利用企业现有的资源, 让各种独立的应用更好的集成以实现信息实时共享, 且能在原有基础上扩展新的应用, 以满足生产管理需求。

根据MESA对制造执行系统的功能模块定义, 结合本企业的实际情况, 本文将该企业制造执行系统分为以下几个功能模块[3]:

工艺管理模块:利用CAPP (计算机辅助工艺设计) 设计图纸, 根据资源管理提供的工具, 库存管理提供的物料的规格、状态、库存情况, 设备、人力的能力、状态、利用情况, 确定合理的工艺流程。为车间、计划部门提供工艺图纸、技术参数等信息。CAPP同时根据质量反馈意见, 计划管理审核, 修正工艺方案。

计划调度:根据公司的年度计划、季度、月度计划, 库存信息及销售订单来制定生产计划, 此计划作为车间领料依据。审核并反馈工艺图纸, 并根据工艺管理处提供的产品工艺路线表, 库存情况, 设备、人员的状态制定详细的作业计划。调度员根据作业计划指导生产准备, 根据设备人员的状况安排生产;当生产部下达计划变动指令或紧急加工单, 或出现到件不准时, 正在装配的零部件由于质量问题影响总装时, 调度员综合考虑自身加工能力情况和产品的优先级下达变动指令到操作层。该模块具有生产任务管理, 计划编制, 生产调度, 生产监督等功能。

过程控制:采用工单的方式跟踪生产进度信息、废品信息、批次信息和配套信息, 实现生产各环节的反馈和过程管理, 增强计划的指导性, 提升物料、工具、备件等库存管理的合理性。利用电子工单的方式, 实现无纸化和实时数据传输。工单包含工艺、材料等方面信息。工单数据实时采集, 能得到在制品的流转情况, 及加工过程中的详细记录, 包括质检信息。每道工序负责人在接收上一道工序完工产品后在电子工单上输入相应信息 (如工序加工、质检、工序完工、交付等信息) , 在本道工序完成后再输入完工状况反馈信息;对于数控车床, 则可以通过PLC实施数据采集。

质量管理:从原材料到产品, 加工工序到用户反馈, 整个生产过程中实施全面质量管理。质检员通过在电子工单相应位置填写质检结果或在专门的质检组件上输入信息, 将信息反馈到计划等相应部门, 或者提供SPC统计信息, 以便做出决策和安排后续生产任务。

资源管理:订单的分解细化后, 计划部门需要了解原材料、工具、人员、设备的状态、能力, 从而制定详细的生产计划。资源管理负责人员、设备、工具等资料的数据管理。

成本核算:通过收集车间工时、生产费用、产值等信息, 对车间内生产业务进行事前的成本预算和事后的成本核算, 为成本控制和经营决策提供数据支持。

库存管理:反映原材料、零组件、标准件等物料的库存水平和在制品信息, 为计划和工艺管理提供相关的物料库存信息。

系统管理:用户角色权限管理;系统信息维护, 为整个系统提供安全保障。

2 面向对象的MES架构

根据制造执行系统的需求分析及功能模块, 建立基于SOA的MES系统架构[4], 如图1所示:

面向服务的MES架构主要包括表示层、业务流程层、服务层、组件层和数据层。其中表示层是用户与MES系统交互的接口。用来提供用户接口服务, 为用户在界面上提供一个统一的信息服务功能入口, 通过将内部和外部各种相对分散独立的信息组成一个统一的整体, 保证用户既能够从统一的渠道访问其所需的信息, 也可以依据用户的需求来制定个性化的服务。用户可以是技术员、调度员、工艺员、质检员、外协件客户、企业级领导等。访问方式也可以是windows客户端, WEB浏览器, 无线访问界面等各种方式。业务流程层是通过业务流程定义和整合服务, 把已经注册的应用服务在一定的规则下组成相应的业务流程链。将各功能设计成粗粒度组件, 使外部系统可以通过获得组件接口完成业务逻辑工作。当业务需求变化时, 可以调整服务的组合方式来快速响应业务变化。服务层提供多种企业服务总线所需要的必要服务支持。在这一层上可提供服务总线需要的基本服务, 如消息分发、订阅, 队列, 目录服务, 数据转换、映射服务等。组件层是对服务的细粒度划分, 实现制造执行系统的基本功能和技术构件;数据层包括企业现有的数据库、数据文件, MES的系统软件等各种形式的数据实体。该架构还实现MES与其他系统的集成。

3 面向服务的模型开发

3.1 建模过程

UML建模首先要进行领域分析, 收集需求, 并利用用例图建立需求模型。然后将分析阶段的模型扩展和转化为可行的技术实现方案, 再通过代码转换、软硬件配置, 实现系统功能。最后进入系统测试并投入应用。从而实现面向服务建模全过程。

纺织机械制造执行系统是基于上层经营管理和底层系统控制之间的面向车间的管理信息系统, 主要是通过对底层数据的收集、处理、反馈, 实现系统内外部信息集成, 以满足管理和生产的需要。系统中所涉及到的主要角色有:工艺员、计划调度员、质检员, 操作工人, 库管员等, 以及这些角色所担任的工作的用例图模型如图2所示。

系统业务流程为MES从上层ERP得到制造订单后, 工艺部门制定详细工艺信息, 计划部门根据工艺信息制定详细的工作计划, 考虑库存、设备及人员的状态, 进行具体计划调度, 然后下达加工单;加工人员根据加工任务单, 下载相应的设计图纸、工艺路线等技术资料, 去相应部门领取加工所需物品, 开始加工。加工过程中, 及时更新加工信息反馈给计划管理人员。根据业务流程利用时序图建立的业务交互模型如图3所示。

在系统建模的详细设计阶段, 根据SOA的不同架构层次, 采用不同UML图建立相应的模型。如业务对象建模, 根据制造执行系统的业务特点, 用UML建立的业务对象模型, 如产品、设备、工艺路线、产品结构清单、质量、工单等。对应组件建模, 利用UML组件模型, 根据服务的特点进行组件划分。如在资源管理服务中, 有人员管理、工具管理、设备管理等功能组件。可以根据实际需要, 对组件进行合并成粗粒度组件或拆分为更细粒度组件。服务是按业务对象归类的功能组件, 封装成具有一定粒度、完成特定功能的业务服务, 并通过服务契约对服务的接口和实现分别进行描述, 发布到服务注册中心, 供其他服务和应用进行绑定和应用。因此服务模型也可用组件图建立。根据实际需要, 本文建立了工艺管理服务、计划调度服务、质量管理服务等8个服务模型。

3.2 方法验证

在建立模型的基础上, 应用Web服务技术, 利用J2EE软件开发架构设计开发了制造执行系统平台[5], 图4为制造执行系统主界面及功能模块界面图。该系统可以与上层ERP进行信息交互, 从ERP接收生产计划, 并反馈生产计划执行状况;该系统还可以实现车间作业计划管理, 进行详细的作业计划制定, 工艺流程制定, 作业分派执行及跟踪, 同时包括库存管理、设备管理、工具管理、质量跟踪管理、综合信息查询;此外, 该系统通过现场人工交互以及自动化OPC技术, 能进行现场数据采集 (数控机床的运行参数、设备状态, 班组的生产进度情况, 质检情况) , 实现车间作业进程监控以及设备状态和加工信息反馈。

4 结论

本文结合纺织制造实体企业, 提出了基于SOA的制造执行系统架构, 并利用UML对架构不同层次建立软件架构模型。最后利用J2EE开发框架在系统平台开发设计中验证其可行性, 从而为纺织制造企业信息化系统建设提供了一种新的架构及建模方法。

摘要：结合纺织机械制造企业, 提出面向服务的制造执行系统架构;根据架构提出基于UML的制造执行系统建模方法, 建立系统的业务对象模型、服务交互模型等, 实现了面向服务的制造执行系统的分析和设计。最后通过模型在系统平台开发中的应用验证了其可行性。

关键词：纺织制造执行系统,面向服务架构,UML建模

参考文献

[1]Michael N.Huhns, Munindar P.Singh.Service-Oriented Com-puting:Key Concepts and Principles[J].Journal of IEEE Internet Computing, 2005.

[2]刘瑜, 王立福, 等.软件框架开发过程研究[J].计算机工程与应用, 2004, 26 (2) :26-28.

[3]蔡宗琰, 王宁生, 王志胜, 等.制造执行系统的功能模型[J].计算机工程与应用, 2004.12.

[4]Cheng Fantien, Shen Eric, Deng Junyan, et a1.Development of a Distributed Object—Oriented System Framework for the Computer Integrated Manufacturing Execution System[C].Proceedings of the 1998 IEEE International Co-nference on Robotics&Automation Leuven, Belgium, May1998:2116-212.

面向服务建模 篇4

面向服务的体系结构 (Service-Oriented Architecture, SOA) 是一种 IT 体系结构风格, 通过构建服务能够建立一个业务逻辑抽象和技术抽象, 把业务逻辑与具体实现技术分离开来, 可系统减少异构性、满足服务互操作性和不断变化的业务要求, 可以良好的实现群决策支持平台的需求。目前SOA架构已经得到广泛的认可, 但如何构建面向服务的应用软件模型, 即如何进行面向服务的建模 (Service Oriented Modeling, SOM) 仍然是构建SOA系统的一大挑战。

广义上的服务建模指整个面向服务的分析和设计过程, 狭义上的服务建模被作为面向服务分析过程的子过程。目前针对面向服务系统广义的服务建模方法包括IBM提出的面向服务分析和设计方法, Thomas Erl提出的主流SOA方法论和Micheal Bell提出的面向服务建模框架。针对狭义的服务建模方法的研究大体可分为基于服务应用系统开发方法、面向目标的建模方法和面向最终用户建模方法三类。

2面向业务的模型驱动敏捷服务建模方法

服务建模的目标是建立企业的服务模型, 服务模型作为业务与IT之间的桥梁, 是实现SOA对业务随需应变灵活性支持的关键因素。面向业务的模型驱动敏捷服务建模方法首先需要对系统进行面向服务的分析, 在总结了SOMA, MSOAM和SOMF的面向服务的分析过程基础之上, 结合业务组件分析和面向服务的思想, 采用业务流程建模, 建立服务模型。

第一步:分解业务流程。这步将业务流程分解成一系列的细粒度流程, 把流程的工作流逻辑分解到最小粒度的处理步骤, 以便于识别细粒度的业务服务。

第二步:识别候选业务服务。在服务建模阶段, 并不一定所有服务都会成为最终设计实现的一部分, 故而称为候选服务。首先应该剔除那些不属于被候选服务封装的逻辑, 例如不能被自动化的手工流程步骤或对遗留逻辑的流程步骤而言。

第三步:创建候选业务服务。在细粒度的业务流程中, 将能够聚合的业务逻辑建立成一个候选业务服务。

第四步:应用面向服务原则。在这个步骤中, 需要为候选业务服务应用面向服务的原则, 以支持服务的复用和自治。

第五步:识别候选服务操作。这个步骤将应用逻辑处理需求分解, 识别它们所执行的功能。

第六步:创建候选服务操作。在这个步骤中, 创建识别出的候选服务操作, 考察消费者对服务的使用, 合并或拆分服务操作。

3实例

3.1 业务建模

在问题管理子系统中, 包括问题录入与修改、问题查询、问题语言分词、问题属性识别、问题类型识别、问题求解方法匹配、子问题识别、问题求解管理和问题求解方案评价等9个主要业务功能。本节将对问题管理子系统进行业务建模, 首先将业务流程分解为细粒度的流程。从细粒度的管理流程分解中, 可以得到问题语言分词服务、问题属性识别服务、问题类型识别服务, 问题求解方法匹配服务, 检查是否产生子问题服务和问题求解服务。经过应用面向服务原则步骤, 发现问题语言分词, 问题属性识别, 问题类型识别相互互为前提, 可以将其组合封装为粗粒度的问题分析服务, 以便于高层次的服务请求的调用。

3.2 模型驱动开发

(1) UML建模。

本节以上文分析所得的问题分析服务为例。问题分析服务可以进行问题分词, 问题属性识别和问题类型识别。问题分析服务是复合服务, 而问题分词, 问题属性识别和问题类型识别提供构件服务。业务分析师可以利用UML类图建立问题分析服务平台无关结构模型。

(2) 转换规则及WSDL服务描述。

模型驱动开发将UML转换为WSDL, 可支持对服务进行详细的建模和设计。作为计算无关模型CIM的UML模型可以转化为平台无关模型PIM的WSDL模型。使用UML 扩展机制, UML模型可以图形化的直观方式, 表达WSDL的语义。

本文引入了构造型<>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>。

4结语

面向业务的模型驱动敏捷服务建模方法具有广泛复用、灵活匹配、松散耦合的特点。一方面, 以业务为核心且可迭代的快速建模过程使服务模型随需求快速敏捷地变化。另一方面, 服务模型是业务架构的底层, 技术架构的顶层, 承上启下, 是灵活的业务流程和IT之间的桥梁, 保证二者之间的可追溯性。

摘要：面向服务的体系结构 (Service-Oriented Architecture, SOA) 日渐成为主流, 因而与之对应的面向服务的建模方法成为迫切的需求。在总结了服务建模的现状基础上, 提出了面向业务的模型驱动敏捷服务建模方法。

关键词：模型驱动,面向服务的构架,群决策支持平台

参考文献

[1]刘勇, 李朋, 薛华成.Intranet环境下群体决策支持系统的研究[J].系统工程, 1997, (6) .

[2]Micheal Bell.Service-Oriented Modeling:Service Analysis, Design and Architecture[M].Wiley, 2008.

面向方面建模的研究 篇5

面向对象程序设计(OOP)提出了对象级别的抽象,每个类分工明晰,极大地提高了软件的可读性、可维护性和可复用性,但由于OOP难以模块化处理软件系统的横切关注点,以至于业务逻辑代码和其它代码(如日志记录、安全验证等)相互“纠缠”(tangling)在一起,使得程序难以维护和复用。为了解决上述现象,人们提出了一种新的软件设计方法——面向方面编程[1]AOP(Aspect-Oriented Programming),它很好地弥补了OOP的不足。AOP方法通过引入关注点的抽象,将系统的关注点分离为横切关注点和核心关注点,分别对这两类关注点进行模块化,提高了模块的内聚性,降低了模块间的耦合度,使系统易于维护与复用,并具有较好的体系结构。然而由于在软件开发的早期阶段缺少面向方面AO(Aspect-Oriented)模型的支持,AOP方法仅体现在软件生命周期的编码阶段。为了促使开发者在软件开发的早期使用面向方面思想,将关注点的分离提前到设计阶段,本文给出了设计阶段面向方面的静态模型,并提出了一种面向方面动态模型—协作图的生成算法。

UML已成为软件工程标准的建模语言,它还提供了一种扩展机制以适应特别的领域。我们的模型是在没有改变UML模型规格说明前提下,通过对UML进行扩展获得的。这有助于熟悉OO和UML的开发者对面向方面模型的理解和接收,并且可以继续使用已有支持UML的工具,保证用面向方面模型进行的设计可在现有各种工具之间交互使用。

1 AspectJ语言

AspectJ是第一种实现AOP的语言,它是对Java语言的一种无缝扩展。AspectJ是在Java语言基础上,增加了joinpoint、pointcut、advice、inter-type declaration和aspect这样一些概念和结构。joinpoint是aspect中的一个关键概念,它定义了执行程序时,在核心关注点逻辑中某个明确的“点”,在此“点”处需要引入横切行为,这些点可以是一个方法调用、一个构造器的执行或者是对特定类的一个属性访问等。pointcut是joinpoint定义的集合,多个pointcut可以通过逻辑运算组成新的pointcut。advice是用来定义在joinpoint处需要引入的横切行为,其结构类似于方法,AspectJ中定义了三种advice,分别是before、after和around advice。inter-type declaration是在aspect中给类添加新的方法、属性和接口的实现。aspect是用来封装pointcut、advice、inter-type declaration实现横切的单元,其定义格式同类。

AspectJ编译器在编译时将每个aspect编译成标准的Java class,称为aspect class,在aspect中声明的advice被编译成public non-static method,其参数和aspect中声明的一样,也可能增加一些如thisJoinPoint这样的参数,方法体通常也和aspect中声明的一样。然后AspectJ的weaver根据pointcut的定义在被影响的class中,插入对before和after advice的调用,当然对于around advice的处理复杂一些。对于inter-type declaration则直接编译成对应类的方法或属性。通过以上编译处理就生成了纯Java的bytecode,最终将bytecode输入到JVM中执行。

2 相关工作比较

AOP与OOP是有区别的,UML用于OO设计的元素不能直接用于描述面向方面的概念和结构,因此迫切需要有新的UML元素来描述面向方面的概念和结构。Suzuki和Yamamoto[7],Clarke et al.[9],Groher et al.[8]和Stein et al.[6]等分别对UML进行了不同的扩展,以描述面向方面的概念和结构。现分别介绍如下:Suzuki和Yamamoto是第一个提出扩展UML用于面向方面软件的设计阶段,在它们的方法中,提出了一个新的命名为“aspect”元模型,aspect和class的关系用<<realize>>构造型表示。这种方法仅仅给出了一个用于设计指导的符号,没有给出AspectJ的pointcut、advice等概念的表示,也没有给出aspect行为是如何影响基类的;用<<realize>>构造型表示aspect和class的关系也不能准确地反映AspectJ的语义。关键的问题是该方法修改了元模型的规格说明,使原来支持UML的工具不支持该模型。Clarke等用“组件模式”的概念对UML进行扩展。“组件模式”包含的是introduction的语义而不是advice的语义,因此仅可用于静态横切,不能表示动态横切。Stein等通过对链、类、模板和协作等元模型的扩展来表示AspectJ的jointpoint、pointcut、advice、introduction和aspect;通过对操作的分解来织入advice。该方法比较烦锁,不便于开发人员理解与使用。Groher等提出在软件需求分析和体系结构设计阶段进行关注点的分离,给出了包级的面向方面模型,将系统分为三个包,分别是Base package、Aspect package和Connector。该方法抽象级别很高,开发者难以理解,并且Aspect package和Connector在功能上有很多的重复,同样对于AspectJ具体的概念表示不清楚。

以上这些方法是从不同的角度对UML进行扩展来描述面向方面的概念和结构。Suzuki和Yamamoto方法需要修改UML元模型的规格说明,不能和已有的支持UML的工具兼容;Clarke等的方法没有完全描述出AspectJ的概念和结构,不够全面;Stein等的方法过于烦琐,不便于使用;Groher等的方法抽象级别太高,开发者的理解和使用都有困难。本文利用原型扩展机制对UML进行扩展,获得了描述AspectJ相关概念和结构的模型符号,从而建立面向方面的静态模型;在静态模型和OO协作图的基础上,通过本文提供的算法,能够自动获得面向方面的动态模型,便于开发者的理解与接收,因而使面向方面思想在更广的范围被使用。

3 扩展UML用于AspectJ的静态和动态建模

本节首先详细介绍了如何扩展UML描述AspectJ的概念和结构,并建立系统的静态模型;然后根据静态模型和OO的协作图,通过我们给出的算法获得AspectJ的动态模型。

3.1 静态模型

通常在软件工程中,静态模型包含整个问题域和系统上下文两方面的信息,问题域的静态模型是以类图来表示。面向方面的静态模型就是描述AspectJ中aspect,以及aspect和类的关系。根据UML扩展机制和class类元模型的定义,我们通过对class类元模型进行扩展来表示aspect,见图1。图中,用UML的class 元模型加 <<aspect>>构造型表示aspect,这样扩展的合理性在于:(1)aspect是一个和class相似的独立单元;(2)aspect是方法、域、构造函数以及pointcut、advice、intertype declaration等元素的容器;(3)aspect在编译时被编译成标准的Java class。对于aspect中的pointcut和advice,把它们看成是aspect的“方法”,在他们的定义处分别加构造型<<pointcut>>和<<advice>>以示和真正class方法相区别,这样扩展的合理性在于:(1)他们的定义形式和方法相似;(2)advice在编译时是被编译成aspect class的方法。inter-type declaration是一种静态横切机制,它允许aspect从外部添加类的属性、方法及构造函数。inter-type declaration可理解为对已存在类进行的扩展,因此可在inter-type declaration定义处添加原型<<extension>>来描述,如图2中Logging aspect为类Employee添加boolean类型的属性dirty和返回值类型为void不带参数的方法store。在面向方面的建模中,根据aspect和基类的关系特征(图3示),选择关联关系来描述aspect和基类的关系。对于aspect和基类关联关系的每个内容定义如下:

· 关联的名称 关联的名称表达了关系的内在内容,使得其他人更容易理解。aspect和基类的关联通常表示方面单元需要捕获基类的join point,因此关联名称用<<capture>>进行描述,关联的方向是从aspect指向基类。

· 关联的角色 角色是关联中靠近它一端的类对另外一端类呈现的职责。在aspect和基类的关联中,我们把角色定义为基类的join point和aspect advice的对应关系。其中r1表示aspect中的advice;r2代表join point的类型,包括方法调用(method call)、构造函数调用(constructor call)、方法执行(method execution)、构造函数执行(constructor execution)、字段获取(field get)、字段设置(field set)、异常处理程序执行(exception handler execution)、类化(class initialization)及对象初始化(object initialization)。

· 多重性 多重性其实是UML的一种约束机制,关联的多重性说明aspect和基类间存在多少个相互连接。c1代表aspect的数量,c2代表基类的数目。

通过对UML的class元模型及关联关系做上述扩展,就获得了描述aspect中概念和结构的模型符号。这样扩展没有修改UML中class元模型的规格说明,使熟悉UML和OO的开发者易于理解与使用,并且使支持UML的工具可继续用于面向方面的建模。图4是一个面向方面静态模型的示例,简化股票交易系统的类图[5]。

3.2 动态模型

动态模型描绘了参与用例的所有对象之间的交互,通过对象间交互实现系统的行为。OOP中通常使用UML顺序图和协作图来描绘满足某个用例需要的对象之间的消息通信序列。面向方面软件设计阶段需要重点关注的是动态模型的建立,面向方面软件进行动态建模时,关键是要解决aspect和被影响class之间交互的表示。UML协作图表示了一组通过交互来实现某些行为的对象,它描述了特定行为参与对象的静态结构和动态的交互。动态交互部分是一个消息集合,用协作实现过程中的消息流定义系统行为方面的内容[3,4]。因此本文使用协作图描述面向方面系统的动态行为,进行动态建模。

根据面向方面系统的静态模型及AspectJ的语义,用协作图描述aspect和class交互的,就是将advice按照poincut所定义的join point插入到面向对象协作图的消息序列中,并给advice消息添加相应pointcut作为条件,从而获得面向方面系统的协作图。在此,我们将advice理解为消息,并将消息的类型标记为<<advice>>,advice消息的接收者就是aspect的一个实例,消息的发送者就是触发advice消息的实例。对于around advice消息及被其代替的消息,在协作图上表示为两个互斥的消息,给被替代的消息添加[not pointcut]条件。根据以上的规则,以一个简化的股票交易系统为例,建立面向方面系统的动态建模型。

面向方面系统的开发是在面向对象系统开发的基础上进行的,对于动态模型的建立,同样也是在面向对象动态模型的基础上建立的。为了便于开发者在熟悉UML和已有OO动态模型的情况下,建立面向方面系统的动态建模,本文提供了一个AOP_collaboration_generation算法,通过该算法用户可以从OO的协作图及面向方面系统的静态模型获得面向方面系统的动态模型。AOP_collaboration_generation算法的输入是静态模型中aspect所定义的pointcut、advice及OO协作图中所描述的消息,算法分别对这三个输入信息定义相应的存储结构如下:

算法主要思路是这样的:对每一个pointcut判断是否有消息所包含的信息和此pointcut的定义相符,如相符,则根据此pointcut找到相应的advice,如果是before advice则在该消息的前面添加此before advice消息,如是after advice,则在该消息的后面添加此after advice消息,如是around advice,则添加一个和该消息互斥的around advice消息,并且给该消息添加一个[not pointcut]条件(注:所有的advice消息都要增加[pointcut]条件,以完全体现动态交互时根据上下文来判断advice消息是否发送),不断重复直到所有的pointcut都处理过了,则该算法结束。算法的输出是一个带有advice消息的新消息序列。根据所获得的新消息序列就可得到面向方面系统的动态模型,即面向方面系统的协作图,算法描述如下。

图5描述了一个简单的OO买卖股协作,由客户发出makeTransaction()消息,调用Broker类对象的方法makeTransaction(x,x,x,x),Broker类对象发出消息getAccount()消息调用自身的方法getAccount(x),获得客户的帐户信息,然后Broker类对象根据条件决定发出的是tradeStock()还是buyStock()消息,从而调用Account类对象的tradeStock(x,x)或buyStock(x,x)方法,以实现股票的买卖功能。通过AOP_collaboration_generation算法,输入图5的消息序列(共计4条消息),和图4中所有aspect中的poincut(共2个)及advice(共2个),就可获得新的消息序列。具体算法执行过程如下:

首先对第一个pointcut即logAllMethod,依次判断协作图中的四个消息是否有满足定义,根据日志记录要求可知,对Broker及Account类对象的方法调用都要进行日志记录,因此图中消息都满足logAllMethod定义,也即在所有消息之前都需要插入logAllMethod所对应before advice。其次对txCut pointcut进行同样的过程,只有第一个makeTransaction()消息满足定义,由于其对应的是around advice,因此需要添加一条和makeTransaction()消息互斥的消息即around advice消息,同时添加条件为[pointcut],并且给makeTransaction()消息添加[not pointcut]条件。由于仅有两个pointcut,因此算法执行完毕,从而获得面向方面系统协作图的消息序列,再将此消息序列转换成协作图,见图6。

4 小 结

面向方面编程(AOP)是在OOP基础上提出的,并被用来解决OOP代码纠缠问题,通过引入方面单元来封装pointcut、advice和inter-type declaration,实现横切行为模块化。在软件设计阶段描述aspect以及aspect-class之间的关系,需要有相应的动态和静态模型。本文首先分析了已有的,用于描述面向方面概念和结构的方法,指出了各自的不足。然后通过对UML类元模型进行扩展,获得面向方面的静态模型;在静态模型和OO协作图的基础上,通过我们给出的算法,就可自动得到面向方面的动态模型。我们的模型易于理解,容易接受,更重要的是促使了AOP在更广泛的范围内被使用,特别是在软件开发的早期阶段,从而有效地提高了所开发软件的可重用性、可维护性等,并为将要研究的面向方面程序的测试提供了测试模型。

摘要：为了解决OOP中横切关注点与业务逻辑代码纠缠的现象,人们提出了面向方面编程(AOP)方法,以弥补OOP的不足。然而目前在软件开发的早期阶段缺少面向方面(AO)模型的支持,AOP方法仅体现在软件生命周期的编码阶段。在不改变UML规格说明的前提下,通过对UML进行扩展,给出了在软件生命周期中设计阶段AO的静态模型,并提出了一种面向方面动态模型—协作图的生成算法,使开发者在设计阶段更易识别和描述软件的横切关注点,使所设计的软件易于维护与复用。

关键词：模型,AOP,UML

参考文献

[1]Ramnivas Laddad.AspectJ IN ACTION[M].Manning Publications,2004.

[2]Tom Pender.UML宝典[M].耿国桐,等译.电子工业出版社,2004.

[3]Grade Booch,James Rumbaugh,Ivar Jacobson.The Unifield Modeling Language User Guide[M].Addison-Wesley,2001.

[4]Grade Booch,James Rumbaugh,Ivar Jacobson.The Unifield Modeling Language User Manual[M].Addison-Wesley,2001.

[5]王砚霖,王世耆.面向方面编程和AspectJ.电脑编程技巧与维护,2004,12:47-51.

[6]Dominik Stein,Stefan Hanenberg,Rainer Unland.An UML-based As-pect-Oriented Design Notation For AspectJ.AOSD2002:106-112.

[7]Junichi Suzuki,Yoshikazu Yamamoto.Extending UML with Aspects:Aspect Support in the Design Phase.in Proc.of AOP Workshop at ECOOP99,Lisbon,Portugal,Jun.1999:299-300.

[8]Groher I,Baumgarth T.Aspect-Orientation from Design to code.1123:62-68.

[9]Siobhán Clarke,Robert J.Walker.Composition Patterns:AApproach to Designing Reusable Aspects.in Proc.of ICSE′01(Toronto,Canada,May2001),ACM,5-14.

面向对象的本体建模应用研究 篇6

关键词：本体,统一建模语言,映射,元模型

本体理论自20世纪90年代逐渐形成,作为一种知识组织体系,在知识表示时,有独特的优势。但同时在本体建模方面也存在以下缺陷:(1)目前可用的本体描述语言有十几种,多种语言共存使得使用者相互交流很困难;(2)这些语言都比较抽象,难以为人理解和掌握;(3)本体构建工具存在差异性,这导致它们缺乏互操作性;(4)建模过程大多需要手工参与,开发效率较低。这些限制使得本体建模缺乏统一的标准,进而无法满足实际的工程化本体建模需要。面向对象的思想和方法极大地推动了计算机技术的发展,尤其在软件开发的各个阶段都有成功的应用。在本体建模中引入面向对象的思想和方法,可以有效地革新现有的本体开发过程。UML是面向对象建模领域公认的工业标准,与之相关的技术和开发工具都很成熟。将UML引入本体建模,是实现面向对象的本体建模的有效途径。

如何将UML应用于本体建模,成为国内外相关领域学者的研究课题,文献[1]、文献[2]和文献[3]从不同角度,提出了用UML建模元素表达本体建模元语的不同方法,例如彭祖林[8],王翀[9]等研究了UML映射为OWL的可行性及实现方法,试图使UML能够严格的表达特定本体描述语言的建模元素的语义。文献[4]、文献[5]、文献[6]和文献[7]尝试在实际的工程应用中将UML引入本体建模,较为典型的像金芝[4],殷磊[5]等将需求分析与面向对象的本体建模结合起来。这种面向应用的研究主要围绕领域本体展开。这些研究已经取得了一定的成果。本文阐述了将UML应用于本体建模的理论依据,提出针对应用本体的不同领域,采用不同的映射方法。根据实际需要,提出了不同的扩展UML的方法,从而实现将UML建模元素到本体建模元语的映射。

1 本体建模研究

本体最早是一个哲学上的概念,表示客观存在的一个系统的解释或说明,关心的是客观现实的抽象本质[8]。而在人工智能界,引入这个概念是为了更准确地描述知识[2]。1993年,Gruber提出本体最为流行的定义[9] ,即“本体是概念模型的明确的规范说明”。

Perez等[11]认为本体可以按分类法来组织,他归纳出本体包含5个基本的建模元语(Modeling Primitive)。这些元语分别为:类(classes),关系(relations),函数(functions),公理(axioms)和实例(instances)。通常也把classes写成concepts。目前比较成熟的本体建模语言都包含了这五个基本的元语。本体构建方法的研究对于本体的应用有关键的作用。由于不同的学科领域有各自不同的实际要求,所以构建本体的方法也各不相同。目前尚没有一套标准的构建方法。一般认为,Gruber在1995年提出的5条规则是比较有影响的:(1)明确性和客观性、(2)完整性、(3)一致性、(4)最大单向可扩展性、(5)最少约束。常见的本体建模方法有Uschold方法、Grüninger&Fox方法、METHONTOLOGY方法、以及SENSUS方法等。其中斯坦福大学医学院开发的七步法相对比较成熟,主要用于领域本体的构建。七个步骤分别是:(1)确定本体的专业领域和范畴、(2)考查复用现有本体的可能性、(3)列出本体中的重要术语、(4)定义类(Class)和类的等级体系(Hierarchy)、(5)定义类的属性、(6)定义属性的分面(Faces)、(7)创建实例。本体构建工具能完成对本体的解析、创建、存储和重用等工作,好的工具可以帮助本体快速而有效地建立。目前较为有效的构建本体的工具主要有:OntoEdit、Ontolingua with Chimaera、Ontosaurus、OpenCyc Knowledge Server(简称OpenCyc或Cyc)、Protégé-2000和WebOnto等。其中Protégé-2000拥有大型的用户团体。与其他系统相比,其优点在于:(1)具有图形化的用户界面、(2)支持Unicode字符集输入、(3)可以免费下载系统安装软件和插件、(4)支持目前几乎所有的可用于构建语义网络的本体描述语言。

2 UML基本概念

UML (Unified Modeling Language) 是软件工程中的标准建模语言,采用面向对象的分析与设计(OOA&D)方法,具有图形化的建模手段。

作为一种建模语言,UML的定义包括UML语义和UML表示法两个部分。UML语义描述基于UML的精确元模型定义。UML还支持对元模型的扩展定义。UML表示法定义UML符号的表示法,为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达的是应用级的模型,在语义上它是UML元模型的实例。标准建模语言UML的重要内容可以由五类图来定义。例如用例图、静态图(Static diagram,包括类图、对象图和包图)、行为图(Behavior diagram):描述系统的动态模型和组成对象间的交互关系、交互图(Interactive diagram):描述对象间的交互关系、实现图( Implementation diagram ) 等等。

UML在信息和概念的工程化建模方面取得了很好的应用效果,成为软件开发的工业标准,拥有强大的数据库和成熟的开发环境支持。同时,存在大量熟悉UML语言和UML建模工具的软件开发人员。UML应用于本体建模,优势在于:第一,熟悉UML的用户可以利用现有的大量UML模型、模式和UML工具熟练地进行本体建模。第二,可以为本体开发的整个生命周期(分析、设计、实现、测试及配置)提供工程化支持,从而保证本体存储和访问的一致性,有利于本体之间的交互。第三,UML对本体进行建模不仅能支持现有的OWL、KIF这些知识表示语言,而且还能支持将来有可能出现的其他知识表示语言[12]。

3 面向对象的本体建模

现有本体表示语言无法满足实际的工程化本体建模需要,欠缺工程化的本体开发工具也是阻碍本体建模发展的一个重要的原因。为解决这一问题,人们提出面向对象的本体建模思想,将UML应用于本体建模是实现面向对象的本体建模的有效途径。目前,这个领域的研究的首要问题是,完成从本体到UML建模语言的映射。

3.1 UML用于本体建模

比较两种建模手段的异同是建立映射的基础,这两种建模手段的不同点在于:

第一,两者的建模目的不同,O-O模型是抽象的,用于消除和简化不必要的概念与关系,只遴选必要的知识来解决某个特定的问题。本体模型在于知识表达,往往需要囊括一个领域中所有的知识,强调知识的完备性。第二,O-O模型用于在软件系统开发时,创建精确、具体的实例。本体模型关注的是概念层的问题,虽然能说明某个事实,但是却不具体指导软件开发中元素的建立[12]。

本体模型和O-O模型之间的相同点在于:两者都是表达现实世界中可以用来处理的概念;两者都建立在类/概念和关系之上;两者都是为了得到在某个领域上的可重用的模型。

同一个领域的本体模型和O-O模型的相似性是UML有效开发本体的基础,但本体模型和O-O模型的差异导致UML在一些方面不适于进行本体建模,比如本体中的属性是第一级的建模元素,而在UML中属性和关联都不是第一级的,因此即使是OMG 即将发布的UML2.0规范也不能够解决本体建模需要解决的所有问题。为了解决这些问题,就必须扩展UML以实现面向对象的本体建模。OMG发布的MDA(模型驱动框架)定义了一个四层元模型框架。根据对每个层次的功能的定义,可以在OMG 模型驱动框架中的M2层上扩展原有的UML元模型,这样从“元级”这个层次保证了新的UML元模型可以用来指导开展本体建模工作,并且为这个元模型可以保证描述的处于M1层的本体模型之间的互操作性[12]。在一定条件下,也可以将UML建模元素直接映射为语义相似的本体建模元语,并且运用stereotype扩展机制和对象约束语言对语义加以约束,从而实现基于UML的本体建模。

3.2 UML映射为特定本体建模语言

3.2.1 比较分析两种建模手段的异同点

随着语义网络的发展,一些基于XML语法的语言出现,用以对本体进行表述,并可以将本体纳入语义网络的层次结构中。这些语言主要有DAML+OIL、OWL等。

为了将UML用于描述用这类特定语言表示的本体,首先要分析两种建模手段的异同点。也就是比较相应的建模元素。

将本体建模元素在OWL中的概念与UML中相同或相近的概念罗列出来,加以对照。可以看出:OWL中构造算子(交、并、补、限制、枚举)在UML中无直接对应。OWL中版本信息、版本管理机制等概念无直接对应。OWL中数据类型(XMLSchema 数据类型、枚举类型)在UML中无直接对应。除此之外,主要的OWL 模型元素在UML 模型元素中都能找到对应或相近的概念[1]。对OWL的概念及相应关键词加以分析归类,详细对照OWL与UML的具体关键词,也可以找出对应关系[2]。

找到对应关系之后进行异同点的比较,主要是两者之间差异的比较,也就是对应的概念或对应的关键字之间在语义方面存在的差异的分析。OWL底层的语法基于XML,在此基础上的语义扩展基于RDF(S),DAML+OIL也是如此,而且两种语言都可用于构建语义网络,所以两种语言本身有相似点。两种相似的语言都同UML作比较,能得出以下一些大致相同的结论:(ⅰ)泛化是UML中从已知类构造新类的唯一方法,而OWL或DAML+OIL却包含多种类构造算子,如交、补等,用于从已有类构造出新类。(ⅱ)本体描述语言中属性(性质)可作为一级对象独立存在,而UML中对应的术语描述的对象必须依附于某个类或某两个类。(ⅲ)UML 具有清晰、严格的元建模体系结构,而本体描述语言的层次并不这么严格。

3.2.2 构建元模型

通过比较两种建模方法的异同点,确定从那些方面扩展UML建模元素,以完整的表达本体建模元语的语义,完成从特定本体描述语言到UML的映射。

本体描述语言比较简单。只有实例、类、性质、子类、子性质等几种模型元素,目前只支持对概念及概念间静态关系的建模。因此只需要实现UML 的静态建模元素中的一部分如类、属性、继承关系等与本体模型元素之间的映射即可。所用的静态建模元素主要是类图、对象图。构建用UML类图描述的基于本体建模语言的元模型,是完成从特定语言描述的本体到UML描述的本体的映射的关键步骤。UML的元建模体系结构从具体到抽象分别是用户对象层、模型层、元模型层、元元模型层。如果基于上述的MDA四层模型构建元模型,则扩展的元模型处在元模型层。可通过扩展的元模型定义模型层元素描述具体的本体对象。构建的元模型不涉及具体的对象,不存在语义的映射空间。

具体的扩展内容取决于对两种描述语言的比较分析。有多种实现扩展的方法。(ⅰ)通过继承UML已有的元模型元素,引入了适合本体语义的元模型元素,例如本体、特性类、属性类、本体类等。经过扩展的元模型用来描述本体中最基本的类、属性、关系等概念[1]。(ⅱ)用UML profile扩展机制扩展UML的基本建模元素, 定义OWL 的UML 表示集,用类图描述同OWL中描述类概念和属性概念相关的主要关键字,从而建立OWL 的UML Profile 元模型[3]。这种扩展不存在具体的语义映射空间。(ⅲ)前人为了解决用UML表示本体的问题,已经提出了UML 元模型的扩展模型。可以基于自身研究分析的结果,结合对前人工作的分析,针对自身研究工作的需要,提出不同于前人结果的扩展模型。新的扩展模型并不基于前人的扩展模型,但可以基于前人的基本思路[3]。以上的方法在应用研究中都取得了有效的成果。

3.3 领域本体刻画及其应用

将UML用于领域本体建模具有实际应用的意义。例如,领域需求分析中所谓的“通信鸿沟”问题。针对这个问题提出了基于本体的需求工程。其主要思想是:在领域本体的制导下抽取现实世界的概念,产生应用描述,构造应用系统模型;映射应用系统模型中的可实现部分为应用软件概念模型;对应用软件概念模型进行规格说明,产生应用软件需求模型和软件需求文档[4]。也可以利用本体在知识表示方面形式化、规范化的优势,解决领域内知识共享的问题[5]。对面向agent的软件开发的研究近年来逐渐兴起,其基本原理是:在agent抽象层次上设Multi-agent系统需要对agent所处的世界(或应用领域)模型进行定义,agent 通过这个模型和其他的agent 进行交互。应用领域的描述通常是通过本体模型来表示领域中的实体以及实体之间的关系[6]。在标准化的建模过程中建立企业级的标准数据模型可采用本体建模的方法。葛世伦等人[7]采用了多种本体,利用面向对象的本体建模方法描述与企业生产过程和控制,制造等特定领域相关的知识。

用本体描述这些特定领域的知识,并将其用于实际应用,例如软件设计开发,在一定的条件下有其特殊的优势。但在接下来的工程实践中,这些数据要能被有效的处理,本体描述的知识就不理想了。需要将这些知识转化为其他形式。实际上,由于UML在软件开发过程中的作用,将用领域本体描述的知识转化成用UML类图描述的知识后,可以直接将他们用于软件开发。在工程开发的不同阶段,针对不同的实际需要,采用不同的建模工具,可以发挥各自的最大效力。

描述领域本体并不一定要扩展UML元模型或者构建某种基于UML的元模型,本体的概念可以映射为类或对象,由UML语言中的类图和对象图来表示,本体概念之间的关系映射为类之间或者类与对象之间的关系。为了达到对类实体更精确的表示(比如对属性之间依赖关系的描述),采用OCL(Object Constraint Language,对象约束语言)对实体加以约束。OCL是一种指定约束和查询的语境有关语言。刘炜[6]与殷磊[5]等人都采用了这种方法,有效地完成了映射。

用领域本体准确表达特定领域的概念,必须体现特定领域的概念的特点,一般的数学模型往往达不到这个要求,需要针对领域知识的特点,定义合适的数学模型。例如用一个三元组<ConTypeS,ConAssS,ConTypeH>描述企业本体。其中,ConTypeS为企业概念类集,ConAssS为企业概念类关联集,ConTypeH为企业概念类抽象层次结构[4]。要描述企业领域中的行为活动,可借助于人工智能领域中的形式化工具“情景演算”(Situation Calculus)定义情景演算模型[7]。“情景演算”是表达动作和变化基于情景概念的一阶理论。

由于要满足实际需要,在这个方向往往要设计完整的软件设计或数据建模的算法。为了将需求转换为一种通用的数据共享交换格式,可以设计算法将用本体建模的需求描述转化为UML,再转化为XML文档[4]。将本体用于领域需求分析时,可分为四个阶段:业务流程分析、逻辑分析、对象行为分析以及对象活动分析。在此基础上构造算法,最后输出领域需求分析的结果。同时,采用UML的活动图、对象图、对象状态图、对象活动图和用例图分别表示各个阶段的分析结果和应用本体构建的领域需求模型[6]。

因为具体应用不同,在这一方向实现映射的方法也不相同。但有以下共同点:不一定需要在元模型层扩展UML或构建元模型;一般使用领域本体描述相关知识;为了完成整个领域需求分析过程或数据建模,往往要使用多种UML视图;UML到本体的映射只是算法的一部分。

4 结语

目前,UML用于本体建模的研究还处于探索阶段。具体的扩展UML的方法和实现映射的机制应该根据相关研究领域的实际情况来决定。具有实际意义的工作往往将UML用于本体建模作为系统的一个模块来实现。相关的理论研究还有很大空间,还有不少有意义且极具挑战性的应用领域。将UML用于本体建模后,实现基于UML本体模型的推理成为必然要求,基于图形变换的推理是一种解决方法。也有人提出引入描述逻辑,将其作为推理的工具[15]。这一方面探索将是有益的,而且也一定会产生更加有效的结果。

参考文献

[1]彭祖林,林永动,杜彦辉.UBOM:基于UML的本体建模工具.Transactions of Beijing Institute of Technology,2006;26(11):1014—1018

[2]王翀,何克清,刘进.基于OWL元模型的本体建模研究.武汉大学学报(理学版),2004;50(5):581—585

[3]王洪伟,段永瑞,蒋馥.基于UML扩展机制的本体模型的可视化研究.管理工程学报,2006;20(3):67—73

[4]李娜,金芝.基于知识的UML图形文档自动生成.计算机工程与应用,2004;(33):50—55

[5]殷磊,王润孝,姜晓鹏.基于本体的领域需求分析方法与模型研究.计算机工程与应用,2005;(7):82—83,223

[6]刘炜,刘宗田.Multi-Agent系统中基于UML的领域本体建模.计算机工程与应用,2004;(5):22—25

[7]苗虹,葛世伦.本体支持下的企业数据模型构建.清华大学学报(自然科学版)2006;46(S1):40—48

[8]邓志鸿,唐世渭,张铭.Ontology研究综述.北京大学学报(自然科学版),2002;38(5):730—738

[9]Guarino N.Formal ontology,conceptual analysis and knowledge repre-sentation.Human-Computer Studies,1995;43(5):625—640

[10]Gruber T.ATranslation approach to portable ontology specifications.Knowledge Acquisition,1993;5(2):199—220

[11]Perez A G,Benjamins V R.Overview of Knowledge sharing and re-use components:ontologies and problem solving methods.In:Stock-holm V R,Benjamins B,Chandrasekaran A,eds.Proceedings of the IJCAI99workshop on Ontologies and Problem2Solving Methods(KRR5)1999;1—15

面向智能电网的建模研究展望 篇7

关键词：智能电网,建模,随机性,参数辨识

0 引言

仿真计算已经成为电力系统设计、运行与控制中不可缺少的手段[1,2,3], 人们对仿真计算的精度要求越来越高, 而这是以电力系统模型为基础的。电力系统模型对电力系统的计算结果影响很大[4,5], 在临界情况下还有可能改变定性结论, 掩盖一些重要现象, 构成系统潜在危险, 造成不必要的浪费。在过去的几十年间, 电力系统建模方面已经取得相当多的成果, 中国电力科技工作者做出了重要贡献[6], 主要内容包括:电力系统建模基本理论与技术[7,8]、同步发电机组建模[9,10]、电力负荷建模[11,12,13,14,15,16]、输配电网络建模、动态等值建模等。国内外许多电网纷纷开展应用研究[17,18], 取得良好成效。

另一方面, 国内外有关智能电网的研究如火如荼[19,20], 一些电网开展了试验性示范工程。这些研究工作同样离不开模型, 而智能电网的特性对建模研究提出了新的需求。所以, 面向智能电网新需求开展建模研究是重要而迫切的任务, 为电力系统建模研究注入了新的动力。

本文分析智能电网对建模的新需求, 提出智能电网建模的新思路和新内容。本文试图展望未来一段时期电力系统建模研究框架, 旨在抛砖引玉, 促进学术交流。

1 面向智能电网建模的新需求

与传统电网相比, 智能电网在电源、负荷和网络方面都具有新的特性, 相应地对建模研究带来了新的挑战。

1.1 可再生能源新电源

未来的智能电网需要聚纳较大比例的可再生能源电力。与传统的火电、水电、核电相比, 最大区别在于: (1) 可再生能源发电具有间歇性或随机波动性, 例如风速变化; (2) 可再生能源电源并不完全可控, 例如太阳能要遵循白昼夜晚的自然规律。

可再生能源发电有2种方式。一种是大规模集中式, 中国西部地区具有丰富的可再生能源, 而负荷中心却在东部地区, 所以在西部建立一系列大规模可再生能源发电场, 通过西电东送工程, 输送到东部负荷中心。在这种情况下, 建模研究面对的是一个大规模的互联电网。另一种是小规模分布式, 微电网中就有一系列这样的可再生能源发电方式。在这种情况下, 建模研究面对的是一个很小容量的微型电网。

1.2 电动汽车等新负荷

未来智能电网需要容纳较大比例的主动负荷, 例如电动汽车。与传统负荷相比, 最大区别在于: (1) 主动负荷具有双向性, 例如电动汽车既可以充电表现为负荷, 也可以放电表现为电源; (2) 主动负荷具有不确定性, 这既表现在时间上又表现在空间上, 因为电动汽车充放电时间不确定、充放电地点也不确定; (3) 从某种意义上来说, 传统负荷是不可控的, 而主动负荷则具有一定可控性。在这种情况下, 对于大量而且是随机的电动汽车, 不可能对每一辆电动汽车都加以描述, 建模研究面对的是如何从变电站角度描述负荷的总体特性。

1.3 网络自愈等新结构

未来智能电网需要网络具有自愈功能。与传统网络相比, 最大区别在于: (1) 网络经常需要重构, 尤其是系统中出现故障或者某个区域出现电力紧缺的情况下; (2) 网络中具有较多控制设备, 例如柔性交流输电系统 (FACTS) 。在这种情况下, 建模研究面对的是如何处理网络结构变化带来的模型变化。

综上所述, 智能电网对建模提出了一系列新的挑战: (1) 不确定性。既包括电源不确定性, 也包括负荷不确定性。不确定性包括随机性、模糊性等, 研究最多的是随机性, 下面所述不确定性主要指随机性。 (2) 不连续性。既包括电源跳机, 也包括网络重构。 (3) 时变性。既包括状态参数的时变性, 也包括元件参数的时变性。 (4) 控制复杂性。控制设备多种多样, 可再生电源不完全可控, 主动负荷不再完全不可控。

2 面向智能电网建模的新思路

2.1 建模策略

在传统电网中, 建模策略是以元件建模为基础, 然后一个一个积木式地连接成为系统模型。面向智能电网建模时, 由于元件的多样性、不确定性甚至移动性, 建模的总体策略可能是混合形式。对于能够基于元件建模的情况还是尽量基于元件的建模策略, 例如发电机、线路等;对于不能够基于元件建模的情况则要采用整体等效的建模策略, 例如主动负荷。整体等效建模策略与基于元件的建模策略不同之处在于, 整体等效建模不拘泥于建模对象的具体形式, 主要考虑等效描述其外部整体特性。

2.2 建模方式

在传统电网中, 建模一般都是离线方式, 即离线采集数据然后离线建模, 或者在线采集数据然后离线建模。面向智能电网建模时, 由于系统状态和参数存在时变性, 应该采用在线建模方式, 即在线采集数据然后在线建模。

在传统电网中, 建模一般都是集中方式, 例如省、网调度中心统一建立全省、网的模型。面向智能电网建模时, 由于系统的复杂性, 可能需要采用分层次建模方式。对于某个层级的电网, 一方面要建立适用于自身需要的详细模型, 另一方面要建立适用于上层电网需要的等效模型。上层电网根据下层电网上传的模型, 需要进行模型协调拼接, 一方面需要连接网络模型, 另一方面需要进行潮流匹配。近年来, 一些学者在这方面开展了有关研究工作[21,22,23]。

在传统电网中, 建模一般都是全系统方式。面向智能电网建模时, 由于系统规模巨大, 可能需要采用分区域建模方式。对于某个区域, 其边界节点通过广域测量系统 (WAMS) 获得动态数据, 以此作为这个区域的已知注入。这样就将需要建模的系统规模缩小, 有利于提高速度并隔离不同区域模型不准确的交互影响, 也有利于充分利用中小扰动。

需要说明的是, 分区域建模与分层次建模是有区别的。分层次建模一般按照电压等级来划分, 例如220kV电压等级作为主网建模层次, 110kV作为配电网建模层次。而分区域建模则是针对同一层次的系统按照建模需要来划分, 然后逐个区域进行建模。

2.3 模型结构

在传统电网中, 无论是元件模型还是系统模型, 大多数采用的是机理模型。面向智能电网建模时, 由于不确定性、不连续性、时变性和控制复杂性, 许多情况下不一定能够采用机理模型加以描述。所以, 模型结构可能是混合形式。即对于能够采用机理模型描述的情况还是尽量采用机理模型, 对于不能够采用机理模型描述的情况则要采用非机理模型。

传统电网模型基本上都是连续模型, 面向智能电网建模时有可能需要在连续模型中嵌入离散模型, 用于描述不连续性和离散事件。

2.4 不确定性的描述

不确定性是智能电网建模面对的一个重要问题, 其主要表现形式是随机性。对于集中参数模型, 可以将随机性概括为如下形式:

式中:X为状态向量;U为输入向量;Y为输出向量;θ为参数向量;F和G为非线性函数向量;X0为初值向量;ε为外部激励向量。

在上述方程中, 随机性主要表现为3个方面: (1) 外部激励ε的随机性, 这有可能是负荷随机性引起, 也可能是电源随机性引起; (2) 初值X0的随机性, 需要说明的是这个初值是指最后一次操作后的自治系统的初值, 并不是干扰刚开始时刻的初值, 所以这个初值的随机性有可能是干扰之前的潮流随机性引起, 也可能是干扰的随机性引起; (3) 参数的随机性, 这可能是网络结构变化引起, 也可能是设备参数随运行状态变化引起, 还可能是等效模型代表的区域 (例如负荷) 内部结构变化引起。

3 面向智能电网建模的新内容

传统电网建模对象最主要是确定“四大参数”, 即励磁系统及其调节器参数、原动机及其调节器参数、同步发电机参数、电力负荷参数。除此之外, 电力系统建模还包括动态等值建模、输电线路建模、动力系统建模等。面向智能电网建模的对象大大扩展。首先, 可再生能源发电研究广泛开展, 其建模研究非常紧迫;其次, 分布式电源和微电网的研究逐步深入, 微电网建模研究也被提上议事日程;再次, 电动汽车等主动负荷研究方兴未艾, 包含主动负荷的混合负荷建模研究需要起步。下面重点讨论上述3个方面的内容。

3.1 可再生能源发电系统的建模

可再生能源发电包括风力发电、光伏发电、海洋能发电、生物能发电等形式, 其中接入电网的主要有风力发电和光伏发电, 需要重点加以研究。

目前, 有关单个发电单元模型的研究较多, 相对比较清楚[24,25,26,27], 例如一台风力发电机组的模型由发电机电气动态、机械动态、变换器、控制系统等组成。但是, 发电单元的参数仍然是一个问题, 很多情况下生产厂家无法或不愿提供全部参数, 研究中只能引用先前文献中使用的参数值或采用经验值, 部分参数不一定符合实际。所以, 对于单个发电单元重点需要研究参数实测方法与技术。具体研究内容可能有: (1) 研究单个电源中各种模拟、数字和非电量信号的同步测量技术以及实测数据的预处理方法; (2) 研究电源各元件参数的现场试验方法; (3) 分析在快慢扰动下可以分别辨识的参数, 研究如何利用各种随机输入、输出信号辨识模型参数; (4) 开发电源基础数据库以及电源参数辨识软件。

目前, 有关可再生能源电场聚合建模的研究刚刚起步[28,29,30,31,32,33], 建模方案基本上是2个极端。一种方案是采用单元等效模型来描述一个电场, 而且对于电场网络采用简化处理, 这在许多情况下可能会带来较大误差。另一种方案是采用详细模型, 即每个发电单元都采用单元模型描述, 这种方案可以提供精确结果用于对比参考, 但对于电力系统仿真计算会产生维数灾, 也是不必要的。所以, 可再生能源电场的等效建模是今后的研究重点和难点。

由于可再生能源的随机波动性和时空分布性, 电场中各个发电单元的运行状态各异并且随机波动, 给电场的模型等效和状态等效带来了困难。但另一方面, 随机波动可能分布在较广的时域和频域上, 也可能给模型参数辨识带来新的数据来源。以大规模风电场为例, 具体研究内容可能有: (1) 风电机组的分群判据。针对风电系统具有较强的随机性和分布性, 以及模型中快慢动态耦合的特点, 通过微分几何下的相似性等方法实现分群。 (2) 大规模风电场网络的变换化简。以往的一些处理方法过于粗糙, 可以借鉴以往电力系统动态等值中的网络化简方法, 其中需要注意无功功率补偿问题。 (3) 风电场等效模型参数的在线测辨方法。根据输入信号的时间尺度 (频谱范围) , 应用摄动方法区分待辨识对象中与快、慢变过程强相关的参数, 确定等效模型中可以通过理论聚合获得的参数以及需要重点辨识的参数, 进而研究在线辨识方法。 (4) 大规模风电场的动态聚合建模。针对大规模风电场机组多、地域广的情况, 首先需要构建风电场的动态聚合模型结构, 包括风力、风机、发电机、变换器与控制器、场内网络等部分。然后, 分别研究其参数确定策略和方法。 (5) 大规模风电场的稳态聚合建模。通过分析风电场稳态条件下整体的电压、频率特性、短路特性, 以及风电机组运行状态的随机性对风电场稳态特性的影响, 研究风电场稳态降阶聚合建模方法;结合空气动力学建立用于风电场稳态降阶模型的等效风速模型, 研究通过稳态试验、风力慢变过程、小扰动快变过程的实测数据确定稳态模型的参数。

需要指出的是, 可再生能源电场等效建模研究中的难点可能有3个。一是一次能源的等效和预测, 例如风电场等效机组上的等效风速等;二是电力电子接入装置的处理, 电力电子装置在某种程度上具有隔离作用, 导致从电网侧看电场与内部特性不一致;三是风电场有多种类型时的聚合, 尤其是发电机组控制器的聚合。

需要注意的是, 等效运行状态参数随一次能源的随机波动而随机变化, 而等效发电单元参数的标幺值则基本不变, 因为发电单元参数的标幺值是基于对应的容量, 即使在掉机情况下, 基于剩余单元总容量的参数标幺值也基本上不变。

3.2 微电网的建模

有关微电网仿真、分析与控制的研究比较多[34,35,36], 但微电网建模方面的研究比较少[37,38,39]。作为独立的系统, 微电网能够独立稳定运行。这时, 需要基于元件建模策略, 建立微电网的详细模型, 用于微电网自身的分析计算和控制。另一方面, 微电网可以和配电网联网运行。从配电网的角度来看, 微电网可以作为一个简化的节点。如果要详细分析微电网内部的特性, 则需要对每个元件都详细描述。从这个角度来说, 可以理解为分层次建模。

联网运行时, 微电网与配电网之间的功率流动是双向的, 即功率可以从配电网流向微电网, 也可以从微电网流向配电网。功率流动受到各种因素的影响, 例如微电源容量、负荷容量、运行经济性等。联网运行时, 微电网可以理解为广义的负荷。当微电网接入的数量比较多时, 对配电网潮流及稳定性势必带来影响。为了分析微电网接入配电网后的特性, 如果要对微电网中成千上万个元件都详细描述, 既不可能, 也不必要。电力系统分析所需要的只是从系统侧向微电网侧看进去的总体特性, 并不关注微电网内部元件个体的特性。所以, 可以借鉴电力负荷总体建模的思路。但微电网建模与电力负荷建模所不同的是, 电力负荷只吸收功率, 而微电网比电力负荷多了大量的电源元件, 所以既可能吸收功率, 也可能输出功率。

一般来说, 微电网中的元件大体上可以分为两大类。一类是静态元件, 既包括静态负荷元件, 也包括燃料电池、太阳能光伏电池、储能设备等分布式电源。有可能将这些分布式电源连同静态负荷等效为静态部分, 其模型为静态的代数方程, 描述有功功率、无功功率与电压、频率的关系。另一类是动态元件, 主要包括异步发电机 (例如风力发电机) 、同步发电机 (例如微型燃气轮机) 和异步电动机、同步电动机。需要特别指出的是, 不管是发电机还是电动机, 同步和异步只是在稳态时的概念。而在动态过程中, 同步电机并不是真正同步的, 其转子和定子之间也有一定的转速差, 体现出异步特性。为此, 有可能等效为统一电机模型。微电网的等效机理模型结构如图1所示, 等效静态部分与等效电机部分并联接在母线上, 总的功率为两者之和, 然后通过公共连接点 (PCC) 接入配电网。

如果微电网内部元件和控制比较复杂, 有时难以采用图1所示的机理模型描述。需要研究等效非机理模型, 例如输入、输出模型。其中的参数需要根据PCC处的测量数据, 采用辨识方法确定。

3.3 混合负荷的建模

对于传统常规负荷的建模, 通常采用机理模型描述, 模型的随机性主要表现为参数的变化, 例如电动机比例。常规负荷表现出“被动性”, 即由于系统侧干扰, 引起负荷母线电压波动, 进一步引起功率波动。需要注意的是, 在短时间内常规负荷模型的内部结构被认为是不变的, 例如恒定阻抗、恒定电流或者电动机并联静态负荷。

除了常规负荷以外, 将来电网中还可能包括一些新的负荷。一种不妨称为“主动负荷”, 主要指电动汽车等, 这种负荷既可以消耗电能, 也可以释放电能, 而且部分可控[40,41,42];另一种不妨称为“冲击负荷”, 主要指冶炼、电气化铁路等。这些负荷区别于常规负荷之处就在于其“自变性”, 即负荷内部会自主变化, 例如冶金的出铁、电动汽车充电、电力机车启停等。所以, 不妨将上述2种负荷都称之为“自变负荷”。

“自变负荷”在自变期间, 实质上是负荷内部特性发生变化, 引起外在表现出的阻抗、电流或者功率的变化。而负荷节点电压的变化, 则是由于负荷与系统侧联立求解确定的, 而且一般来说较小, 电压变化大小取决于系统侧阻抗、负荷阻抗及其变化量, 如图2所示。

所以, 对于常规负荷, 主动变量即输入量是电压, 因变量即输出变量是功率或者电流。而对于“自变负荷”在自主变化期间的特性, 主动变量即输入量不应该是电压, 而应该是反映其内部特性变化的变量, 例如阻抗、电流等;电压则是需要通过负荷侧与系统侧联立求解的中间变量。也就是说, 负荷采用某种模型描述, 然后接入系统, 负荷节点电压等其他中间变量可以计算获得。有的文献仍然像常规负荷那样, 以电压作为模型的输入量、功率作为模型的输出变量, 笔者认为是不妥的。

单个“自变负荷”在其自变期间, 具有自变性、时变性和随机性, 其电气特性可以采用时变电流源等机理模型, 也可以采用非机理模型。但是, 对于一个220kV变电站, 下面可能接有上百个“自变负荷”单元, 所以在自变期间总体表现出来的是一种随机波动的功率特性。在相对较长时间框架上, 需要进一步研究其统计学模型。

无论是对于单个“自变负荷”, 还是一群“自变负荷”, 在其正常运行期间, 即内部没有发生自变情况, 表现出来的是一种与常规负荷相似的电气特性, 一般来说可以采用常规负荷模型。

4 结语

面向虚拟装配的公差信息建模研究 篇8

随着计算能力的显著提高以及软件在设计和制造过程中的广泛应用,CAD/CAM/CAE系统已经成为产品集成开发平台的代名词,其功能在不断地扩展,逐渐覆盖了产品的整个生命周期,服务于产品开发的全过程,包括产品的设计、产品的数字化校核与验证、产品的生命周期管理,成为了提高企业市场反应速度和产品竞争力的有力保障。在现代制造技术中,虚拟装配技术在产品全寿命周期设计过程中的作用日益凸现。但是对装配公差的研究远落后于对其他方面的研究,多数局限于公称尺寸的零部件的装配,虽近年来对公差约束的影响的研究日渐深入,但与工程实际应用的要求相比仍有较大差距,特别是公差信息建模以及公差优化设计的建模研究。

1 装配公差信息模型的研究

公差信息数学模型即为一组能刻划公差语义的模型变量及限制这些模型变量的不等式。公差语义主要表示为公差域如何形成和标识,变动后的要素如何形成及表示。建立完整的、正式的公差语义表示的数学模型对自动公差分析、公差分配等后续工作十分重要。

人们自计算机辅助公差设计研究以来,从不同的方向对公差信息模型进行了研究,出现了以下几种数学模型:1)漂移模型。Requicha最早对公差数学定义进行了研究,他针对几何造型的需求,以变动族为基础于1983年提出了实体漂移模型。模型用点集的形式来表述,实体是欧氏空间的一个正则子集,用点集定义了其上的特征。漂移模型易于实现,没有二义性,但与公差标准不相适应,所确定的公差带偏严,只能用来表示公差域的边界等。2)基于公差函数与矢量方程的数学模型。Hoffman在三维欧氏空间中发展了一种模型,把几何图形视为由一些点矢量组成,公差被解释为一系列的以点矢量为参数的公差函数。Turner在变动实体造型的基础上也提出了基于公差可行域的公差模型。目前这种方法主要用于确定公差域的边界,对满足公差变动后要素如何表示未作深入的研究。3)基于几何约束变动的参数矢量化数学模型。Hillyard和Braid把几何实体视为物理框架,尺寸信息是一些使框架受到约束从而得到固定的固件,公差信息是尺寸信息所允许的微小变动。该模型较好的表示尺寸公差信息,但不能处理形位公差信息。4)基于数学定义和自由度变动的数学模型。Shah等人提出建模的关键是能对满足公差的要素的变动作出准确的解释,在此模型中,设自由度为模型变量,由公差的数学定义导出基于自由度变动的公差域边界标识和变动后要素的表示统一的方法。刘玉生等针对多面体提出了机遇数学定义和自由度的建模方法,较好的解决数学模型的两个问题。该模型以一个点集统一地表示出所有的公差域边界及变动要素,并且还能实现不同公差类型的组合,作用对象已应用到圆形、矩形截面和直线等。可以看出,数学定义与其他方法的结合的模型具有独特的优点,有较好的应用前景。

按与实体造型的关系,表示模型可分为依赖于实体模型和独立于实体模型内的表示模型。前者可进一步分为基于CSG、基于B-Rep及基于CSG/Rep混合模型等;后者可分为基于TTRS、基于公差元及基于特征等类型。

公差信息表示模型是公差分析、公差综合等后续工作的基础,是产品信息建模的基础。但现有的CAD软件尚不能有效地处理公差信息,缺少公差信息表示模块。但是在产品信息系统中必须包括公差信息,因此需寻找一种合适的公差信息表示模型,使之能与产品信息系统有机的结合起来。

2 装配公差建模的实现

现有的CAD系统的核心是实体造型器,其中的公差信息只是符号的表示,缺少有效的工程语义表示,所以CAD,CAPP和CAM难以实现真正的有机集成。虽然有些软件(如CATIA)集成了公差信息模块,但是存在许多问题,无法有效地对公差信息进行评价,对公差信息的综合有所欠缺,进行公差分析时,需手工完成大量的前期工作,所以需要设计合适的公差表示模型和公差语义定义,并须考虑公差原则,使之与CAD系统有机集成,通过一定的方法对公差进行评价,最终使公差满足设计要求。公差评价的一般步骤如图1所示:

3 公差优化建模研究

3.1 动态公差设计

装配公差优化设计是一种辅助设计手段,可以合理地解决设计与生产中公差分配上的矛盾,降低生产过程中的设计修改返工率。传统的方法是根据预定的加工顺序,在零件加工前计算出工序尺寸和公差。这种方法具有局限性,为了克服传统方法不能在加工过程中修改尺寸和公差的缺点,发展了一种根据实际获得的尺寸来重新动态设计后续尺寸和公差的方法,称为动态公差设计方法。有关研究已对低维尺寸公差设计进行了研究,但对较复杂多维零件的尺寸公差、角度公差等混合设计较少涉及。

动态公差设计的实质是根据工序公差可行域中的实际可行点,构造新的降维公差可行域,确定后续的工序尺寸和公差。动态公差设计的步骤如下:1)在第i道工序前,确定公差分配算法;2)对部件进行测量,如果产生的公差域不在规定的范围内,则此算法失效,重新对公差进行再分配,进行第i+1道工序。

3.2 公差优化设计

3.2.1 基于M-C方法的优化设计

优化设计问题的数学模型包括设计变量、约束条件和目标函数。在有约束优化设计问题中,其数学模型为:

装配过程中产生的公差大多数是服从正态分布或矩形分布,常用Monte Carlo方法(简称M-C方法)进行实验仿真,模拟装配公差统计分布,分析误差原因,修改公差指标或装配过程,对结果进行优化处理。M-C方法的基本原理是,当所求解的问题是某个事件出现的概率时,可以通过抽样试验的方法得到这一事件出现的概率,把它作为问题的解;当所求的问题是某个随机变量的期望值时,通过抽样试验求出随机变量的样本平均值,并作为问题的解。这里以公差样本服从正态分布为例,通过线性变换可以转化为标准正态分布。正态分布的一个重要规则即“3σ规则”,正态随机变量分布由它的数学期望和方差决定,它的值在区间[μ-3σ, μ+3σ]的概率几乎为1。由区间估计, μ的置信度为1-α时置信区间为:undefined, σ2的置信度为1-α时置信区间为:undefined,最后可以得到公差样本参数值和特性。如果样本服从非正态分布,也可通过估计得到它的特征性能。

可以看出虽然在公差分析过程中M-C方法可较好的处理非线性装配函数,但为确保较高的精度,需要大量的样本,多次重复运算,计算量较大;而且如果装配函数中各分量的均值或方差发生改变,需重新计算,因此应该研究更高效的算法。

3.2.2 基于遗传算法的优化设计

近年来,发展了一种模拟生物进化的优化方法,即遗传算法。在遗传算法中,目标函数北转化成对应各个个体的适应度。适应度是根据预定的目标函数对每个个体(染色体),进行评价的一个表述。计算开始时,从随机产生的染色体中选择适应度(性能好)的染色体组成初始的寻优群体(初始可行解),称为“种群”。算法将一组染色体用二进制(或十进制)的字符串进行编码,其中的一位或几位字符的组合称为基因,两个染色体表示二维空间的两个可行解,称为一个寻优的初始点。维数越高,染色体的群体个数越多。而且遗传空间内可行解会有多种组合,它们组成了可行解的空间。改变了染色体的某个基因的位置,可以作为一组新的寻优试探点。这种交换叫“杂交”。为了提高算法搜索全局最优解的能力,还需扩大基因组合,这就是“变异”。可以看出遗传算法是多点搜索,直接利用从目标函数转化成的适应函数,采用编码的方法以概率原则指导搜索。目前,遗传算法还存在一些问题,主要是计算时要求种群规模较大(一般为50～100),在求解过程中有时会过早收敛于局部优化解,对低维、连续、单峰等简单问题不能显示其优越性。遗传算法的基本程序如下:BEGIN/*遗传算法*/生成初始种群,并计算每个个体的适应度

4 结论

装配公差与产品的装配和制造过程以及产品最终的性能密切相关,因此随着计算机辅助设计技术的应用和推广,装配公差已成为产品设计开发阶段的一项重要内容,它的应用前景将十分广阔。由于产品零部件的材料,使用环境的影响,以及装配方式造成的盈余和变形,确定正确的公差分配方案尤为必要。以往的装配公差大体上可分为公差分析和综合,均是基于直观地公差分布通过工程数学方法进行处理,无法考虑实际工况造成的影响,因此,需要在这方面深化研究。

参考文献

[1]顾寄南,等.基于虚拟装配的装配工具与公差的信息建模研究[C].全球化制造高级论坛(21世纪仿真.

[2]姬舒平.虚拟装配环境下公差并行设计方法的研究[D].哈尔滨工业大学,2000.

[3]曹衍龙.基于数学定义的公差建模方法与技术研究[D].浙江大学,2005.