分布系统程序化设计

分布系统程序化设计（精选12篇）

分布系统程序化设计 第1篇

面向服务的体系结构(即SOA,Service-Oriented Architec⁃ture)是一类分布式系统的体系结构,是构造分布式系统中应用程序的方法[1]。SOA作为一个技术架构,决定了不依赖某个特定的技术和平台环境来实现[2]。应用系统SOA架构建设的必要性体现在三个方面:1)解决应用系统信息孤岛问题;2)解决应用系统紧耦合问题;3)解决应用系统资源复用低问题[3]。本文将为面向服务体系结构的分布式系统设计实现一个可以快速搭建服务的框架,从而把更多的经历集中在服务本身的功能上。使基于该框架的服务可以支持通过服务名访问服务、跨程序语言的RPC、服务负载均衡、服务日志记录、服务配置信息自动加载等功能。

2 相关技术简介

2.1 Thrift

Thrift是Facebook实现的一种高效的、支持多种编程语言的远程服务调用的框架[4]。它结合了功能强大的软件堆栈和代码生成引擎,通过定义一个简单的定义文件中的数据类型和服务接口,以作为输入文件,编译器就可以生成代码用来方便地生成RPC客户端和服务器通信的无缝跨编程语言。

2.2 Zookeeper

Zoo Keeper是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等[5]。

2.3 Scala

Scala是一种可伸缩式编程语言。它有以下几个优点[6]:1)与Java无缝兼容;2)支持类型推理;3)良好的并发性和分布式操作机制和性能;4)更灵活的更多样的模式匹配机制;5)完全的面向对象程序设计语言,函数也是对象,可以在程序的任何地方使用函数,甚至把函数传递到任何地方。已经有很多公司在使用Scala语言来开发分布式系统,包括Twitter、Linked In、In⁃tel等等[7]

2.4 Ostrich

Ostrich是Twitter用于监控服务器性能的一个Scala库,主要功能是收集、展示统计信息,同时也提供了关闭服务器、重新加载配置、监测服务器有效性等简易控制功能,以及获取线程、GC以及Profile等调试和性能信息[8]。通过这个框架可以很方便地观测到系统内各个服务的状态及统计信息。

3 需求分析

本框架的主要目的是实现系统内服务启动关闭时的一系列任务管理。这样,使用本框架,开发者就可以很便捷的搭建一个服务器,然后把主要经历放在服务本身的功能上。为了达到这一目的,我们的框架包括以下功能:

1)自动加载Config文件;规定统一文件格式(Scala Class)

2)利用Zookeeper的域名服务功能自动管理系统中的服务。通过服务的名字来访问服务集群,而不是Host+IP的形式访问单个服务.

3)通过指定Thrift文件来自动创建Thrift服务端;并创建基于BS架构管理服务用来记录统计信息和服务的状态。

4)通过指定Thrift文件来自动创建Thrift客户端。

5)支持可选择的服务端负载均衡策略;包括通过服务名字随机访问和通过服务名字访问指定序号的服务。

6)通过代理技术,实现对接口的自动记录日接口访问信息的功能。并且可以配置记录日志的详细程度。

7)通过代理技术,实现对异常的统一处理,并且支持可配置的异常处理策略。

8)支持自动调用以上功能的接口,使用户可以只通过Thrift文件、Config文件即可简单的通过一个方法就可以启动服务。

4 设计与实现

本框架一共设计并实现了11个类。各类的名字功能及关系,见表1。

由于篇幅有限,本文只列出Easy Thrift Service Builder和Eas⁃y Thrift Client Builder中的类的参数表(见代码1)和Easy Thrift Ser⁃vice Builder.build函数的实现方法(代码2)。

代码段1:

代码1 中使用了Scala的类型自动转换和以类型作为参数的技术。通过这两个技术,实现了通过Thrift文件自动获得Ser⁃vice接口类型和客户端类型。这样才为根据Thrift文件和Con⁃fig文件自动创建Thrift服务端和客户端创造了可能。

代码段2:

代码2 是Easy Thrift Service Builder中build函数的实现。Build函数主要做了下面的工作:1)设置Service的代理(ad⁃d Proxy Support);2)根据配置文件创建Thrift Service(TThread⁃Pool Server);3)创建Easy Thrift Service。Easy Thrift Service会自动注册服务名、创建服务监控程序、根据config文件设置负载均衡、根据config文件记录log信息等功能。

5 测试与验证

首先我们定义了简单的Thrift文件test.thrift和Config文件test Config.scala。调用Easy Thrift Service Builder.build函数创建服务端和调用Easy Thrift Client Builder.build函数创建客户端。并测试了客户端和服务端的基于服务名的访问。一切正常,满足需求规格说明。随后将该框架应用于基于Scala语言的面向服务的分布式的系统内的服务上,运行良好,达到预期目标。

6 结论

本文描述了为面向服务的分布系统设计了一种服务框架,并基于Scala语言实现了支持跨语言的该服务框架。利用该框架,用户可以便捷的创建基于服务名访问的Thrift服务器和客户端。并且通过浏览器观测服务的状态和统计信息。

参考文献

[1]Papazoglou M P.Service-Oriented Computing:Concepts,Char-acteristics and Directions[J].Web Information Systems Engi-neering.wise.proceedings of the Fourth International Confer,2003.

[2]中国知网.面向服务的架构[EB/OL].http://epub.cnki.net/kns/brief/default_result.aspx.

[3]黄嘉东,徐兵元,叶向阳.企业级应用系统SOA架构建设研究与实践[J].中国高新技术企业,2016(2).

[4]Apache.Apache Thrift-Home[EB/OL].http://thrift.apache.org/.

[5]Apache.Apache Zookeeper-Home[EB/OL].http://zookeeper.apache.org/.

[6]École Polytechnique Fédérale de Lausanne(EPFL).The ScalaProgramming Language[EB/OL].http://www.scala-lang.org/.

[7]École Polytechnique Fédérale de Lausanne(EPFL).WHAT ISSCALA?[EB/OL].http://www.scala-lang.org/what-is-scala.ht-ml.

分布系统程序化设计 第2篇

在分布式存储系统中，系统可用性是最重要的指标之一，需要保证在机器发生故障时，系统可用性不受影响，为了做到这点，数据就需要保存多个副本，并且 多个副本要分布在不同的机器上，只要多个副本的数据是一致的，在机器故障引起某些副本失效时，其它副本仍然能提供服务。本文主要介绍数据备份的方式，以及 如何保证多个数据副本的一致性，在系统出现机器或网络故障时，如何保持系统的高可用性。数据备份

数据备份是指存储数据的多个副本，备份方式可以分为热备和冷备，热备是指直接提供服务的备副本，或者在主副本失效时能立即提供服务的备副本，冷备是用于恢复数据的副本，一般通过Dump的方式生成。

数据热备按副本的分布方式可分为同构系统和异步系统。同构系统是把存储节点分成若干组，每组节点存储相同的数据，其中一个主节点，其他为备节点;异 构系统是把数据划分成很多分片，每个分片的多个副本分布在不同的存储节点，存储节点之间是异构的，即每个节点存储的数据分片集合都不相同。在同构系统中，只有主节点提供写服务，备节点只提供读服务，每个主节点的备节点数可以不一样，这样在部署上会有更大的灵活性。在异构系统中，所有节点都是可以提供写服务 的，并且在某个节点发生故障时，会有多个节点参与故障节点的数据恢复，但这种方式需要比较多的元数据来确定各个分片的主副本所在的节点，数据同步机制也会 比较复杂。相比较而言，异构系统能提供更好的写性能，但实现比较复杂，而同构系统架构更简单，部署上也更灵活。鉴于互联网大部分业务场景具有写少读多的特 性，我们选择了更易于实现的同构系统的设计。

系统数据备份的架构如下图所示，每个节点代表一台物理机器，所有节点按数据分布划分为多个组，每一组的主备节点存储相同的数据，只有主节点能提供写 服务，主节点负责把数据变更同步到所有的备节点，所有节点都能提供读服务。主节点上会分布全量的数据，所以主节点的数量决定了系统能存储的数据量，在系统 容量不足时，就需要扩容主节点数量。在系统的处理能力上，如果是写能力不足，只能通过扩容主节点数来解决;而在写能力不足时，则可以通过增加备节点来提 升。每个主节点拥有的备节点数量可以不一样，这在各个节点的数据热度不一样时特别有用，可以通过给比较热的节点增加更多的备节点实现用更少的资源来提升系 统的处理能力。

同步机制

在上面的备份架构中，每个分组只有主节点接收写请求，然后由主节点负责把数据同步到所有的备节点，如下图所示，主节点采用一对多的方式进行同步，相 对于级联的方式，这种方式在某个备节点故障时，不会影响其它备节点的同步。在CAP理论中，可用性和一致性是一对矛盾体，在这里主节点执行写操作后会立即 回复客户端，然后再异步同步数据到备节点，这样并不能保证主备节点的数据强一致性，主备数据会有短暂的不一致，通过牺牲一定的一致性来保证系统的可用性。在这种机制下，客户端可能在备节点读到老数据，如果业务要求数据强一致性，则可以在读请求中设置只读主选项，这样读请求就会被接口层转发到主节点，这种情 况下备节点只用于容灾，不提供服务。

为了保证主备节点的数据一致性，需要一种高效可靠的数据同步机制。同步分为增量同步和全量同步，增量同步是主节点把写请求直接转发到备节点执行，全量同步是主节点把本地的数据发到备节点进行覆盖。接下来详细介绍同步机制的实现，同步的整体流程如下图所示。

系统中数据分片的单位是一致性哈希环中的VNode(虚拟节点)，每个VNode有一个自增的同步序列号SyncSeq，VNode中所包含的数据 的每一个写操作都会触发它的SyncSeq进行自增，这样在每个VNode内SyncSeq就标识了每一次写操作，并且SyncSeq的大小也反映了写操 作的执行顺序。数据的每次写操作除了修改数据，还会保存写操作对应的SyncSeq，后面可以看到，SyncSeq是同步机制可靠性的基础。

主节点的写进程收到写请求后，先修改数据，把当前VNode的SyncSeq加1并更新到数据中。接下来会记录Binlog，Binlog是一个三元组

主备节点的数据同步由主节点上的同步进程异步进行，通过扫描上图的同步进度表中主备节点的SyncSeq差异就可知备节点需要同步哪些数据。同步进程通过同步进度表确定需要同步的二元组

接下来介绍一下同步协议如何保证同步的高效和可靠。为了让同步包严格按照主节点的发送顺序到达备节点，采用TCP协议进行同步，在主节点的每个 VNode上到每一个备节点建立一个TCP连接，记为一个同步连接。在每一个同步连接上，主节点会一次性批量发送多个同步包，备节点也会记录已同步的 SyncSeq，对每一个同步包会检查携带的SyncSeq是否符合预期，如果符合预期，则执行同步写操作，执行成功是更新已同步的SyncSeq，在这 种情况写备节点也不需要回应主节点，主节点在未收到备节点的回应时，会认为同步一切正常。只有以下异常情况下，备节点才会回应主节点：

在正常同步后第一次收到错误的SyncSeq，回应主节点自己所期望的SyncSeq，主节点收到回应后，会从备节点所期望的SyncSeq开始同步，需要注意的是，备节点在连续收到错误SyncSeq时，只需对第一个错误回应，否则主节点会出现重复同步的情况;同步连接在断连后重新连接时，备节点告知主节点自己所期望开始同步的SyncSeq，主节点从该SyncSeq开始同步;SyncSeq符合期望但执行出错，一般是增量同步才可能出现，备节点回应主节点同步出错，主节点收到回应后，把出错的同步包改为全量同步。

在增量同步和全量同步交叉进行的情况下，如果某次全量同步已同步了最新的数据，后续的增量同步可能导致写操作重复执行，为了避免这种情况，备节点会 校验同步包中的SyncSeq和数据中的SyncSeq，如果前者不大于后者，说明数据已执行了这次写操作，直接跳过不执行，也不需要回应主节点，这就是 为什么需要在数据中保存SyncSeq的原因。

通过上面介绍和分析，可以看出采用同步连接、批量同步的方法，正常情况下只有单向的同步流量，是非常高效的;而在异常情况下，通过出错回应、SyncSeq校验等机制，保证了同步的可靠性。容灾机制

如果系统需要具有容灾能力，即在机器发生故障时，系统的可用性基本不受影响，那么系统中所有数据至少需要有两个以上的副本，并且系统的处理能力要有 一定的冗余，需要保证在故障机器不能提供服务时，系统不会过载。一般来说，数据的副本数量越多，系统的处理能力越冗余，系统的容灾能力越强。更进一步，还 需要考虑物理部署，通过把数据的不同副本分布在不同机架、不同机房、甚至是不同城市，来把系统的容灾能力提升到不同的级别。

配置运维中心会监控系统存储层所有节点的状态，存储节点会定时上报心跳，如果配置运维中心在一段时间未收到某个存储节点的心跳，则把该节点的状态标 记为故障，并进行故障处理流程。首先需要禁止故障节点继续提供服务，即通知接口层不再把客户端请求转发的故障节点，如果故障节点是主节点，配置运维中心会 查询并对比所有备节点的同步进度，选择数据最新的备节点，将其切换为主节点。由于所有备节点也会记录Binlog，所以在切换为主节点之后，可以直接向其 它备节点进行同步。这里的主备切换可能会导致少量的数据丢失，如果业务不能容忍这样的数据丢失，则需要使用其它强一致性的方案。

在容灾切换之后，还需要进行故障节点的恢复，以便系统恢复到正常的状态。故障机器恢复后，就会进入死机恢复流程，无论故障节点在故障前是主节点还是 备节点，故障恢复后的角色都是备节点。首先待恢复节点需要把机器上所有的数据清空;接着主节点会把当前所有VNode的SyncSeq复制到待恢复节点，并且全量复制所有数据;在全量复制完成之后，开始进行数据同步，由前面的同步机制可知，同步的SyncSeq会从之前复制到待恢复节点的状态开始追赶;在 主节点和待恢复节点之间的SyncSeq差异缩小到正常范围时，待恢复节点的角色就变为备节点，开始提供服务。

配置运维中心会监控主备节点之间的SyncSeq差异，如果某个备节点差异达到一定的阈值，则禁止该备节点提供服务，如果差异在比较长的时间之后仍然无法恢复，则会触发死机恢复流程。数据回档

最后再简单介绍下数据冷备和回档，主要是由备份系统负责。备份任务一般是手动或定时发起，属于业务级别的，备份系统收到一个业务的备份任务后，会远 程备份业务的所有数据，过程比较简单，就是遍历所有的存储节点，把属于该业务的所有数据写入到远程文件系统中，每次备份都需要记录开始时间和结束时间，作 为数据回档的基准。

分布系统程序化设计 第3篇

【关键词】分布覆盖；设计

1.时代广场建设分布覆盖系统的必要性

1.1时代广场的简介和信号覆盖现状

时代广场是新近建成的一座集餐饮、娱乐、商场、写字楼于一体的高级综合性办公楼，建筑面积160000平方米。位于黄金地段。它的西面为艺术中心；南面和五星酒店、博士专家楼、高档市区隔街相对；东面是长途客运中心；北面是高档写字楼等多座高层建筑；东北方向不到1000米就是火车站；时代广场门前是市区东西方向上的三大主要交通干道之一。

根据在时代广场的实地调查和用户投诉的情况可以发现，时代广场室外，信号强、覆盖良好，随时可以进行通话，没有掉话现象，话音质量良好；但在时代广场室内的大部分楼层没有手机信号或者信号微弱，不能进行正常通话，特别是地下建筑和电梯内，全部是盲区；但是时代广场楼层较高的部分手机表现为信号很好、电话振铃，但无法接通，所以时代广场的室内移动通信能力表现为除了个别地方可以通话外，基本不能正常通话。

1.2目前时代广场信号覆盖中存在的问题

时代广场的框架式建筑结构和钢筋水泥的建筑材料决定了它对周围基站信号有较大的屏蔽，室内以轻钢龙骨为主的隔断墙也对电波有较大的衰耗，它们都影响到建筑物内部的绝大部分区域移动通信的效果。业主和入住商户的投诉严重，要求快速解决问题。经过现场测试，发现时代广场的地下室和电梯内由于钢筋水泥的封闭环境，属于完全盲区，建筑底层区域信号较弱，电话接打困难，高层部分则可以接收到相对较好的基站信号，但由于没有主导小区，接受到的几组电平值相差很小，重选切换频繁，通话过程中质量较差，经常发生掉话，通过测试数据可以发现时代广场的室内移动通信困难主要表现为：

（1）建筑中出现信号覆盖的盲区，主要是建筑内部的电梯轿箱、地下停车场、设备楼层和1、2层部分区域。造成盲区的原因主要是由于建筑结构为钢筋水泥浇注而成，穿透损耗极大，或者是由于周围其他高大建筑物对本建筑造成的阴影效应，使得这部分地方根本没有信号覆盖，基站信号到达地下时的电平值小于手机接收的灵敏度，属于信号盲区，所以无法接入网络。

（2）建筑中出现“乒乓效应”区域。它的高层部分基本都能接收到基站信号，不仅数量多，电平值高而且大小十分接近，造成手机在这些地方，没有主导小区，在能够选择的小区间频繁地重选、切换，无法进行正常的发起、维持呼叫。这主要是因为随着建筑物楼层高度的升高，周围有遮挡的建筑物也在逐渐减少，当到达一定的楼层高度后，周围对其有屏蔽作用的建筑物基本不存在了，到达建筑高层的信号主要为周围相邻的基站的直射信号。由于相邻基站站距比较接近，到达时代广场高层的信号在自由空间传播时的损耗基本相同，造成其高层部分信号数量多、场强值大，没有主导小区、手机频繁重选切换的现象。

（3）时代广场外墙体为钢筋水泥浇注而成，室外基站信号在进入室内时，穿透损耗很大，因而建筑的低层部分信号覆盖很弱，而且不均匀，覆盖这些区域的信号主要是周围基站的绕射和反射信号，这些信号经过长距离空中传播后有很大的损耗，到达这些区域时的电平已经十分微弱，基本接近或者超出手机的灵敏度极限，因而发起呼叫十分困难。

2.具体的设计方案和步骤

2.1基站设备的选型

室内分布覆盖系统最为重要是信号源的选取，信号源的性能决定了整个分布覆盖系统的性能，是整个系统的根本。本方案设计中使用宏蜂窝作为信号源，既可以保证有持续稳定的信号输出，又可以在话务量增长的同时，成倍的增加系统容量，是覆盖时代广场室内比较理想的方案。

由于覆盖面积比较大，单纯使用宏蜂窝配合无源系统不可能完全覆盖建筑内的每个地方，因而在关键的部分干线上需要使用放大器。放大器产生的噪声对基站的影响，在系统允许的范围内，不影响系统的正常运行。

2.2基站容量配置分析

时代广场是一座高级综合性写字办公楼，大厦内日常办公约5000多人，每日流动人员数量约为1000人，现以已经开通的同地区同类型的其他高层建筑的室内用户和话务统计平均数对照计算，时代广场的覆盖范围内有70%的手机拥有率，忙时40%的手机拨打率，得知忙时时代广场内移动用户手机共计为（5000+1000）×70%×40%=1680部。按照通常情况：

每移动用户的忙时话务量为0.02Erl；话音信道（TCH）呼损为2%；则大厦内忙时的总话务量为1680×0.02Erl=33.6Erl。由于分布覆盖系统采取分层结构，为使系统资源充分利用，可使两个天线子系统话务量负荷基本相同，那么每个子系统话务量为：33.6/2=16.8 Erl按2%的拥塞率，根据爱尔兰B表计算得话音信道数量为25个；SDCCH信道话务量为：16.8 Erl*28%=4.704 Erl；控制信道（SDCCH）呼损为0.1%。

根据爱尔兰B表计算得SDCCH信道数量为2个（由于下层小区与相邻基站的切换和重选次数较上层小区相对较多，所以在开通时根据实际的话务情况可以适当增加1个SDCCH信道）；每个小区BCCH信道1个。

由以上可以得到覆盖系统中的每个部分需要的信道数量为：25+2+1=28个。

每载频8信道，可得分层小区的每部分需要载频28/8=3.5，约为4载频；整个分布覆盖系统的宏蜂窝配置为上层小区CELL-A为4个载频、下层小区CELL-B为4载频，共计8个载频；使用机柜一个。

2.3基站传输系统的设计

室内分布覆盖系统所需要的传输电路一般可以由以下两种方式实现：

（1）HDSL市话专线是目前实现传输非常经济的方式，以前使用情况比较普遍。它的路由是从BSC端口开始经配线架跳接到光端机，经过光缆到达光缆中心，由光缆中心的HDSL专用设备转换后，通过专用电缆到达测量室，再由市话电缆到达目标建筑物，由于市话电缆几乎遍布城市的每个角落，所以HDSL专线电路可以几乎到达城市的任何一个建筑物。

（2）微波（或者红外线）可以实现光缆不能到达的特殊区域的传输电路，用户可以自行设计路由，而且实现起来方便快捷，能在目标建筑物和相邻基站之间迅速建立传输通道，解决光缆传输的“最后一公里问题”，是目前广泛使用在建筑物间的传输电路的方式之一，性能比较稳定，调整余量也比较多。

3.时代广场项目设计总结与展望

分布式程序设计学生团队实验建设 第4篇

关键词：分布式程序设计,团队实验,教学改革

一、团队实验的意义

长期以来在计算机课程的教学中,重点倾向于把计算机技术作为一门科学来学习,关注诸如算法分析、数据结构等理论知识,强调培养学生的个人素质,发掘学生的个人潜力;而对于团队合作、软件工程方面的素质没有给予充分的重视。分布式程序设计规模很大,不是个人能够完成的,它需要由开发团队分工合作,共同完成。使用软件工程的方法管理软件开发过程,能够保证按时保质地交付产品。

在分布式程序设计教学中,通过选择合适的项目,组成开发小组,按照软件过程来开发,将设计和实现划分开来,从而实现软件工程师中各种角色的划分,产生系统分析师、软件工程师和程序员等多种职责。软件产品是由程序、文档和数据三者共同组成,在软件工程实施过程中,需要自始至终采用软件质量保证计划。在项目计划、需求分析、系统设计、编码实现和测试运行的各个阶段,都会有相应的交付清单。根据设定的里程碑,在每个阶段都会组织相关人员进行评审,根据评审意见对计划和进度进行必要的调整。这样保证最后的产品不仅仅是简单的可执行程序,而应该是一份完整的产品清单。通过以上软件过程的严格培训,使学生能够快速适应工作岗位的需求。

另外,在当今社会的各种活动中,以团队的方式协同工作是一个成功的工作模式,同样许多科学研究也不再是某个人可以独立完成的。(1)团队的定义:团队是指具有共同执行目标,实现共同目的,相互负贵,方法技能互补的一些人组织起来的集体。(2)团队的教学目的:将原来实验的教学目的与新的团队教学目的有机结合起来,即“协作”与“独立”的统一,对部分而言是独立的,对整体而言又是协作的。此外,创新能力或创新精神培养也应是团队教学的目标之一。团队实验本身就是创造天高任鸟飞的条件,让学生从原教材和实验步骤的约束中解放出来。

二、团队实验的实施

我们以计算机二年级2个班级为实施对象,在实验教学中穿插了2次团队实验。在组织团队实验之前,教师必须先向学生介绍团队实验的目的、意义及具体实施方法。在成立团队的过程中,教师要充分信任学生,不干预、不评价任何团队,只给出原则性的指引:(1)团队自由组合,成员人数由教师根据实验需要提出建议、学生自定;(2)团队必须有团队名称、团队目标;(3)每个成员必须有明确的工作岗位并设领队1人;(4)学生经过一段时间的酝酿,成立团队。

团队成立后首先讨论工作流程,制订团队工作计划,让每个成员都能清晰地了解到团队的工作流程和自己在团队中担当的角色。团队以工作计划代替实验预习报告。团队的工作计划经教师审核通过后,队员方可进入实验室做实验。实验过程中,教师要及时检查团队的每个岗位实施情况,如果发现严重错误,则警告领队并责令其及时纠正。在一般情况下,教师不干涉团队的工作过程。实验结束后,团队成员相互交换实验数据,每位成员都进行综合,写出各自的实验报告并提交领队。领队通过筛选和修正,最后完成团队的实验报告并向教师提交。教师组织实验讨论会,评判每个团队的实验过程和实验结果。在讨论会上,每个团队按照论文答辩的要求,宣读实验报告,讲解实验过程,回答教师和其他同学的提问。最后,教师进行问卷调查,师生共同讨论团队实验的改进。

三、团队实验的实例

我们设计的实践环节主要采用两种实验方式:配合本课程核心教学内容的NET Remoting和Web Service部分要求学生采用分组方式,每组六至八人,每一小组设一名正组长,两名副组长,独立完成指定的任务,包括问题分析、总体设计、上机实现、调试与部署、观察并记录结果等步骤。在教学过程中对各课题小组进行考核、检查与指导。各课题小组在讨论问题、分析问题、解决问题的过程中提高了其成员的规范意识,培养了他们独立思考问题的能力,增强了自我学习、自我教育的能力。各课题小组成员在集体创造过程中不断体会到学习的乐趣,在比、学、赶、帮、超中学习热情极度高涨。

而针对面向服务的体系结构、高性能计算等扩展内容则主要由学生按预先制定好的实验步骤上机执行,并观察和记录实验结果,学生自主完成实验的某一环节。每一学生均须参与本课程的实践环节,在实验前充分作好实验准备,在实验过程中认真记录实验情况与结果,在实验后作好总结并提交实验报告。实践环节将根据学生的上机实验结果以及提交的实验报告综合评价学生的实验成绩。

四、团队实验的分析

从实验改革的角度来看,原有的实验过程为:实验预习实验实验报告;团队实验过程为:制订实验计划团队实验实验讨论。从初步实施效果看来,“制订实验计划”、“实验讨论”比“实验预习”、“实验报告”的效果好。学生一般都会认真地组建团队,有些团队从教材和原实验步骤的约束中解放出来,进行实验的创新设计,初步表现出良好的创新精神。在制定团队目标、设置实验角色方面,队员都有优秀的表现。实验计划制订得较合理,实验讨论中涉及的一些问题的深度和广度超出教师预料。从初步的教学实践来看,原以为团队实验可能会冲击教学,学生可能对团队形式出于好奇,忽略实验教学的宗旨。但实际上,学生还是能正确地对待团队实验,通过相互的询问、讨论,全面地了解和掌握实验。又如,原以为团队实验会让某些学生偷赖,实际上团队实验发挥了集体的智慧和力量,使学生看到了个人和集体力量结合的意义。由于我们的实践次数还不够多,认识有限,即便如此,以下的一些问题和思考仍可起到抛砖引玉的作用。

(一)关于责任感

在团队实验中,很容易出现学生缺乏贵任的现象。在单人实验中,无责任感的学生不会影响到他人,不易引起教师和同学的注意,但在团队实验中,不负责任的学生表现出极大的危害性。培养学生的责任感,团队实验可能是一个很好的途径。

(二)关于独立分析问题、解决问题能力

团队概念提出时,有的教师提出疑义,认为这与实验教学中提倡培养学生独立分析问题、解决问题有冲突。实施中发现,它恰恰能促进教学,培养学生这方面的能力。团队中每个实验必须独立完成自己的任务,即使是提交集体讨论,也必须由自己决定结果。出于对团队的责任感,学生必须认真、独立地分析问题、解决问题。换一个角度说,团队实验更能培养学生独立分析问题、解决问题的能力。

(三)关于计算机操作能力

团队实验中,学生表现出对计算机操作的格外重视,即使是不认真的学生,也会自己操作计算机。这是好的现象,但是我们应该让学生知道,计算机操作只是实验中的重要环节之一,实验设计思想、数据分析等工作同样重要。

(四)关于团队人数

团队实验的效果与团队人数有一定的关系,人数少的团队在实验的设计、计划和讨论等方面不积极,表现不出团队实验的优势,同时实验操作也不理想,学生容易分立。人数多虽然在设计和讨论时比较热烈,但计算机操作时容易敷衍了事,学生学不到知识。通过实践我们感到团队的人数以4-6人为宜。因此,认真选择实验项目是十分关键的。团队人数的确定,应以构成母实验的子实验的个数而定。

(五)关于团队实验的次数

在此需要说明的是一人一组的实验仍然是最基本的。在整个实验过程中,安排两次左右的团队实验是比较合适的。

五、团队实验的展望

与一人一组实验相比,团队实验更接近当今社会的活动模式。由于从现有的设备到教材,从教师到学生的认识并不完全具备团队实验的条件,加上教学计划和教学大纲等因素的限制,这次实践,仅是一个开始。但我们认为,这的确是个值得研究探讨且具有挑战性的课题。

在未来的计划中,我们正考虑从以下几方面发展团队实验:(1)争取将团队实验设置成开放实验,以解决课时问题;(2)研究适合团队实验的新实验和新教材;(3)建立由不同地域、不同专业的教师组成的小组,共同研究团队实验教学。

实践证明团队实验不仅能做还要能做得好,学会用科学的思维方法指导实践。本文通过示例,说明这样的教育是可行的,不仅能够提高教学效率,而且有利于学生素质的培养。

参考文献

[1]Tom Barnaby.Distributed.NET Programming in C# [M].Apress,2004.

[2]NET Remoting Versus Web Services Thiru Thangarathinam.2003.

[3]Using Smart Clients to Build Scalable Services Chad Yoshikawa Computer Science of California Berkely,2004.

[4]李文军,用晓聪,李师贤.分布式对象技术[M].北京:机械工业出版社,2004.

[5]钟涵,李志蜀,王汾雁,罗妍,刘鸿源,任益枚.NET Re moting和Web Service结合的分布式应用设计与实现[J].计算机应用,2007,(S1).

DSP系统程序设计论文 第5篇

实际上，只有从芯片开始仔细设计，才能方便地实现多处理器系统的调节功能。这里选用的是AD公司新出品的SHARC级处理器ADSp21160。

ADSp21160具有很大的片内存储区、多重内部总线结构、独立的I/O子系统；具有构造多处理器系统的所有特点，能够真正支持处理器数目的可调节功能，十分适合组成高性能浮点的多DSp系统。

VxWorks是目前世界上用户数量最大的实时操作系统。这使它除了具有优越的技术性能之外，还具有丰富的应用软件支持、良好的技术服务和可靠的系统稳定性。由于它具有以上优点，本系统中选用了VxWorks作为MVME167的操作系统。

一、ADSp21160的特点

ADSp21160 是AD公司采用超级哈佛结构的一种新产品。21160的汇编代码与2106x兼容，处理器具有SIMD（单指令流多数据流）功能；而2106x只具有SISD（单指令流单数据流）功能。为了充分利用这种新的功能，一些指令做了一些改变。ADSp21160包括1个100/150MHz的运算核、双端片内SRAM、1个支持多处理器的集成在片内的I/O处理器和多重内部总线以消除I/O瓶颈。

ADSp21160的汇编源代码与2106x兼容。SIMD计算结构：2个32bit的计算单元，其中每一个单元包括乘法器、ALU、移位寄存器及寄存器文件。具有完备的与外围设备接口功能。包括独立的I/O处理器、4Mbit 的片内双端SRAM、可直接连接的多处理器特性及端口（串口、连接口、外总线及JTAG）。

ADSp21160包括2个运算处理单元，具有SIMD功能。处理单元指的是pEX和pEY。pEX始终是有效的，而pEY的有效是通过设置MODE1寄存器中的pEYEN位来实现的。当pEY模式有效时，同一条指令在2个处理器单元中都得到执行，但每一个处理器单元中的操作数不同。

SIMD模式在存储区和处理器单元之间的数据传输也是很有作用的。当使用SIMD模式，通过加倍数据带宽来保证处理器单元的操作。在SIMD模式，当使用DAGs来传输数据时，存储区每次访问所传输的是两个数据值。

ADSp21160包括4Mbit的片内SRAM，分为两块，每一块2Mbit。可以定义为不同字长的指令和数据存储。每一个存储块的双端口结构可以使存储块独立地被运算核处理和I/O处理器访问。21160的存储区最大可以容纳128K的32bit数据，或256K的16bit数据，或85K的48bit指令，或其他混合字长的数据，但总和最大为4Mbit。所有存储区可以16、32、48、64bit字长的字访问。外端口支持处理器与片外存储器及外设的接口，片外的4G地址空间属于21160的统一地址空间。

外端口支持同步、异步及同步BURST访问。DMA控制器的操作相对处理器运算核是独立和不可见的，即DMA操作可与执行指令同时进行。DMA传输可以在内部存储区与外部存储区、外围设备或主机之间进行。21160共有14个DMA通道，其中：连接口(linkport)占6个；串口占4个；外端口(external port)占4个。21160可以通过DMA传输来下载程序，外围异步设备也可以通过DMA请求/应答线来控制2个DMA通道。

21160具有许多特点支持多DSp系统。外端口与连接口支持多处理器系统的直接连接，外端口支持统一的地址空间，允许DSp之间互相访问。片内具有分布式总线仲裁逻辑，最多支持6片21160和主机连接。外端口的最大数据传输率为400MB/s，广播写信号可以同时发

送到各片21160。6个连接口提供了另一种方法实现多处理器之间的通信。连接口的最高传输速率为600MB/s。

整个系统基于VME总线。VME总线系统作为最早的国际通用开放式总线，自1981年起，经历了近20年的发展。其影响不断扩大，功能不断完善，现已成为性能最好、应用最广的国际总线标准之一。

根据设计要求，采用了4片ADSp21160。片外共享内存SRAM可以被主机和各片DSp直接访问；EpROM用来存放初始化程序和各片DSp要运行的程序，在系统上电后这些程序被下载到各片DSp中；LEDs用来显示插件的状态，如reset、normal等。每一片都有1个连接口连到插件的前面板，这样前端采集来的数据就可以很方便地传输到多DSp上，而且也使数据的传输模式更加灵活。

连接口(linkport)是SHARC系列DSp芯片的一个特点。ADSp21160共有6个8bit连接口提供额外的I/O服务。在100MHz时钟下运行时，每个连接口可达100MB/s。连接口尤其适合多处理器间点到点的连接。连接口可以独立地同时操作，通过连接口的数据封装成48/32bit字长后，可以从片内存储区直接被运算核读取或DMA传输。每一个连接口有它自己的双缓冲I/O寄存器，数据传输可编程，硬件由时钟/应答握手线控制。4片DSp使用连接口实现DSp间两两互连。

21160的主机接口可以很方便地与标准微处理器总线（16/32bit）相连，几乎不需要额外硬件。主机通过21160的外端口对其进行访问，存储区地址映射为统一的地址空间。4个DMA通道可以用于主机接口，代码和数据传输的软件开销很小，主处理器通过Hbr、HBG和REDY信号线与21160进行通信，主机可以对片内存储区进行直接读写。

二、开发环境Tornado

VxWorks的开发环境是WindRiver公司提供的Tornado。Tornado采用主机-目标机开发方式，主机系统可采用运行Sun Solaris、Hp-UX以及Win95/NT的工作站或个人计算机，VxWorks则运行在Intel x86、MC68K、powerpC或SpARC等处理器上。Tornado支持各种主机-目标机连接方式，如以太网、串行线、在线仿真器和ROM仿真器。

Tornado的体系结构使得许多强有力的开发工具可以用于各种目标机系统和各种主机-目标机连接方式下，而不受制于目标机的资源和通信机制。同时VxWorks具有良好的可剪裁性。因此它适用于各种嵌入式环境的开发，小到资源极其有限的个人手持式设备如pDA（personal Digital Assistant）；大到多处理机系统，如VME系统。

Tornado可提供一个直观的、可视化的、用户可扩充的开发环境，极大缩短了开发周期。同时，由于Tornado是一个完全的开放系统，使得集成第三方开发工具变得十分容易。

主机与目标机之间的通信是通过运行各自处理器上的代理进程来完成的，使主机上的开发工具和目标机的操作系统可以完全脱离相互连接的方式。

为了摆脱主机-目标机通信带宽和目标机资源的限制，Tornado将传统的目标机方的工具迁移到主机上，如shell、loader和符号表等。这样，系统不再需要额外的时间和带宽在主机和目标机之间交换信息，降低了对连接带宽的需求，也避免了目标机的资源（如内存）被工具或符号表大量占用，使得应用程序拥有更多的系统资源。同时这种迁移也使得各种主机开发工具独立于目标机存在，从而使同一主机平台上的工具可以用于所有的目标机系统。

作为一个应用软件开发环境，Tornado提供了友好的可视化开发界面、交叉编译环境、源码级调试工具、目标机命令解释器和目标机状态监视器等多种应用工具，为应用软件开发提供了一个高效而可靠的平台。

三、程序设计

我们选用的DSp开发工具是AD公司提供的VisualDSp。这是一个集成开发环境，支持对SHARC系列DSp芯片的开发。实时操作系统VxWorks的开发工具是WindRiver公司的Tornado集成开发工具。VisualDSp可以C语言或汇编语言编

写的DSp代码，最新版本的VisualDSp还支持C++。它还有1个优点，就是可以编译多片DSp的源代码，并产生下载文件，这就可以很方便地进行多DSp系统的软件模拟。

ADSp21160阵列的设计结构使它既可以构成单指令流多数据流（SIMD）的并行处理机，也可以构成多指令流单数据流（MISD）或多指令流多数据流（MIMD）的流水线处理机，视用户的要求而定。这两种并行方案的选择，简单来说就是选择分割数据流还是分割处理工序。SIMD方案的原理如图1所示。

以下介绍我们实验室承担的水声信号处理系统。本系统以VME总线为系统开发平台，前端调理模件、模数转换模件和前端控制模件等为VME插件，采用SHARC级DSp芯片阵列完成声纳信号实时处理，基于嵌入式实时操作系统VxWorks及X窗口系统的中央控制和显示。

图2是4片DSp的任务分配图。从前端采集来的信号，经波束形成和复解调，再经过窄带滤波后的信号分为两路，一路送去进行幅度检波，一路做频域处理。幅度检波就是对复信号求模，根据信号幅度判决有无目标存在。频域处理分两种情况：当发射信号为单频脉冲时，进行功率谱估计，然后根据多普勒频移估计目标速度；当发射信号为双曲调频信号时，进行相关处理。

声纳综合数据处理主要包括主动声纳信号处理和被动声纳信号处理。其中，主动声纳信号处理又根据发射信号的不同，分为非相干处理、相干处理、功率谱处理。声纳综合数据处理主要完成：目标自动检测、目标参数测定和动目标跟踪。

四、操作流水线

操作流水线是模块内数据计算与I/O的流水线，物理上表现为CpU与I/O端口的DMA之间的并行。在前端处理中由于数据率高，通信开销很大。以通信任务最为繁重的复解调和多普勒补偿模块为例，输入数据率为2Mw/s，输出数据率为4Mw/s，高速连接口Linkport最高速率为100Mw/s，如果采用串行传输的话，通信时间就将占用60%以上的处理时间，计算时间显然严重不足。所以必须采用并行执行，流程图如图3所示。这也是一种异步流水线方式，每次传送和计算完成都须要设置标志以通知下一操作。

结束语

在VxWorks实时操作系统下，4片ADSp21160上的程序已经通过模拟输入和系统测试。采用SHARC DSp 阵列能够很好地完成声纳信号实时处理,每一片DSp至少有10%的计算裕量，基本达到设计要求。

送到各片21160。6个连接口提供了另一种方法实现多处理器之间的通信。连接口的最高传输速率为600MB/s。

整个系统基于VME总线。VME总线系统作为最早的国际通用开放式总线，自1981年起，经历了近20年的发展。其影响不断扩大，功能不断完善，现已成为性能最好、应用最广的国际总线标准之一。

根据设计要求，采用了4片ADSp21160。片外共享内存SRAM可以被主机和各片DSp直接访问；EpROM用来存放初始化程序和各片DSp要运行的程序，在系统上电后这些程序被下载到各片DSp中；LEDs用来显示插件的状态，如reset、normal等。每一片都有1个连接口连到插件的前面板，这样前端采集来的数据就可以很方便地传输到多DSp上，而且也使数据的传输模式更加灵活。

连接口(linkport)是SHARC系列DSp芯片的一个特点。ADSp21160共有6个8bit连接口提供额外的I/O服务。在100MHz时钟下运行时，每个连接口可达100MB/s。连接口尤其适合多处理器间点到点的连接。连接口可以独立地同时操作，通过连接口的数据封装成48/32bit字长后，可以从片内存储区直接被运算核读取或DMA传输。每一个连接口有它自己的双缓冲I/O寄存器，数据传输可编程，硬件由时钟/应答握手线控制。4片DSp使用连接口实现DSp间两两互连。

21160的主机接口可以很方便地与标准微处理器总线（16/32bit）相连，几乎不需要额外硬件。主机通过21160的外端口对其进行访问，存储区地址映射为统一的地址空间。4个DMA通道可以用于主机接口，代码和数据传输的软件开销很小，主处理器通过Hbr、HBG和REDY信号线与21160进行通信，主机可以对片内存储区进行直接读写。

二、开发环境Tornado

VxWorks的开发环境是WindRiver公司提供的Tornado。Tornado采用主机-目标机开发方式，主机系统可采用运行Sun Solaris、Hp-UX以及Win95/NT的工作站或个人计算机，VxWorks则运行在Intel x86、MC68K、powerpC或SpARC等处理器上。Tornado支持各种主机-目标机连接方式，如以太网、串行线、在线仿真器和ROM仿真器。

Tornado的体系结构使得许多强有力的开发工具可以用于各种目标机系统和各种主机-目标机连接方式下，而不受制于目标机的资源和通信机制。同时VxWorks具有良好的可剪裁性。因此它适用于各种嵌入式环境的开发，小到资源极其有限的个人手持式设备如pDA（personal Digital Assistant）；大到多处理机系统，如VME系统。

Tornado可提供一个直观的、可视化的、用户可扩充的开发环境，极大缩短了开发周期。同时，由于Tornado是一个完全的开放系统，使得集成第三方开发工具变得十分容易。

主机与目标机之间的通信是通过运行各自处理器上的代理进程来完成的，使主机上的开发工具和目标机的操作系统可以完全脱离相互连接的方式。

为了摆脱主机-目标机通信带宽和目标机资源的限制，Tornado将传统的目标机方的工具迁移到主机上，如shell、loader和符号表等。这样，系统不再需要额外的时间和带宽在主机和目标机之间交换信息，降低了对连接带宽的需求，也避免了目标机的资源（如内存）被工具或符号表大量占用，使得应用程序拥有更多的系统资源。同时这种迁移也使得各种主机开发工具独立于目标机存在，从而使同一主机平台上的工具可以用于所有的目标机系统。

作为一个应用软件开发环境，Tornado提供了友好的可视化开发界面、交叉编译环境、源码级调试工具、目标机命令解释器和目标机状态监视器等多种应用工具，为应用软件开发提供了一个高效而可靠的平台。

三、程序设计

我们选用的DSp开发工具是AD公司提供的VisualDSp。这是一个集成开发环境，支持对SHARC系列DSp芯片的开发。实时操作系统VxWorks的开发工具是WindRiver公司的Tornado集成开发工具。VisualDSp可以C语言或汇编语言编

写的DSp代码，最新版本的VisualDSp还支持C++。它还有1个优点，就是可以编译多片DSp的源代码，并产生下载文件，这就可以很方便地进行多DSp系统的软件模拟。

ADSp21160阵列的设计结构使它既可以构成单指令流多数据流（SIMD）的并行处理机，也可以构成多指令流单数据流（MISD）或多指令流多数据流（MIMD）的流水线处理机，视用户的要求而定。这两种并行方案的选择，简单来说就是选择分割数据流还是分割处理工序。SIMD方案的原理如图1所示。

以下介绍我们实验室承担的水声信号处理系统。本系统以VME总线为系统开发平台，前端调理模件、模数转换模件和前端控制模件等为VME插件，采用SHARC级DSp芯片阵列完成声纳信号实时处理，基于嵌入式实时操作系统VxWorks及X窗口系统的中央控制和显示。

图2是4片DSp的任务分配图。从前端采集来的信号，经波束形成和复解调，再经过窄带滤波后的信号分为两路，一路送去进行幅度检波，一路做频域处理。幅度检波就是对复信号求模，根据信号幅度判决有无目标存在。频域处理分两种情况：当发射信号为单频脉冲时，进行功率谱估计，然后根据多普勒频移估计目标速度；当发射信号为双曲调频信号时，进行相关处理。

声纳综合数据处理主要包括主动声纳信号处理和被动声纳信号处理。其中，主动声纳信号处理又根据发射信号的不同，分为非相干处理、相干处理、功率谱处理。声纳综合数据处理主要完成：目标自动检测、目标参数测定和动目标跟踪。

四、操作流水线

操作流水线是模块内数据计算与I/O的流水线，物理上表现为CpU与I/O端口的DMA之间的并行。在前端处理中由于数据率高，通信开销很大。以通信任务最为繁重的复解调和多普勒补偿模块为例，输入数据率为2Mw/s，输出数据率为4Mw/s，高速连接口Linkport最高速率为100Mw/s，如果采用串行传输的话，通信时间就将占用60%以上的处理时间，计算时间显然严重不足。所以必须采用并行执行，流程图如图3所示。这也是一种异步流水线方式，每次传送和计算完成都须要设置标志以通知下一操作。

结束语

分布式多层模型库管理系统设计研究 第6篇

【关健词】模型字典;模型库管理系统;分布式多层技术

随着软件应用范围的日益拓展，软件规模越来越大，结构也越来越复杂，对于很多功能相同或相近的软件系统，都可以通过模型复用的技术重用已有的成果，以降低软件开发费用、提高开发效率、保证软件质量和可靠性。

基于分布式多层结构的模型库管理系统，能够更加广泛地共享已有模型资源，增加了模型的重复使用性，整个系统的开发和维护成本都降低了，性能也大幅提升。

1.模型库管理系统的应用分析

模型库系统是对模型進行分类和维护、支持模型的生成、存储、查询、运行和分析应用的软件系统，主要包括模型库、模型库管理系统，以模型库为基础的应用程序和模型库管理员等4个部分。模型库是为一定目的服务，以特定的结构存储的相关联的模型集合。模型库管理系统是处理模型存取和各种管理控制的软件，实现对模型库系统的有效管理，是模型库系统的核心组成。模型库系统的好坏关键看其模型库管理系统设计是否科学有效。

1.1 模型库管理系统的用户分析

模型库管理系统具有多层次的用户，其中，模型库管理员通过管理系统对模型库进行规划、设计、协调、实现、维护、测试等。开发人员通过模型库管理系统实现对现有模型的查询，根据其算法、精度等特征决定已有模型在新应用中的可复用程度。应用程序通过模型库管理系统调用模型库中模型，得到运行后的结果数据，提交给用户界面。

1.2 模型库管理系统的基本功能

根据模型库管理系统的应用，模型库管理系统一般包括以下几个基本功能：模型的表示，用知识、数据、子程序、对象等方法表示基本模型;模型的存储，提供模型在计算机中的存储方式，便于进行模型管理;模型的维护，提供模型的增加、删除、修改、查询、浏览、帮助等功能;模型的运行，模型独立于数据而存在，仅在运行时才与数据相结合，从数据库调取数据，得出计算结果，提供给系统前台;模型的测试，对于每一个模型，系统都应提供检测模块，便于用户测试模型的正确性和准确性;控制管理，包括安全保密控制、优先级控制、完整性控制和开发控制等。

1.3 实现模型库管理系统的技术分析

设计模型库管理系统应达到如下目标：有效的模型表示方法，能够涵盖模型的理论模型、数学模型、工程模型、应用领域、精度、误差、算法复杂度以及所需要的数据等;优良的人机用户界面，能够支持模型的各种特征视图，支持具有查询、应用等不同需求的用户;可靠接口，能够实现模型与数据和管理系统的有效联接;模型的理论模型、数学模型和工程模型应相对独立存储，便于模型的调整，提高应用程序的适用性。

2.基于分布式多层结构模型库管理系统设计

2.1 模型表示

视图是人们看到的模型库中的逻辑结构。为了更好地分离模型的逻辑表示和物理实现，在模型库管理系统的设计中采用内部视图、概念视图和外部视图3级视图结构。其中内部视图是最接近于物理实心的模型表示，是模型的物理模式。在内部视图中，每个模型都对应于且只对应于一个文件或某个数据结构，它是模型库管理员看到的模型库。概念视图是内部视图的抽象，在概念视图中的模型可以对应于内部视图中的一个模型，也可以是内容视图中若干个模型的逻辑组合，它是够末人员看到的模型库的全貌。外部视图是概念视图某个部分的抽象，是一般用户看到的模型库。在外部视图和概念视图中，我们将每个模型都看作一个对象或实体，表示为一个四元组：M=（A，I，O，C）。其中，A是模型描述集，I是输入变量集合;O是输出变量集合;C是约束条件集合。每个模型的存储都包括两个部分，既模型体和模型说明，模型体依模型的表示方式不同，可以是一个程序文件，也可以是一个索引结构，比如复合模型的表示，模型说明是有关该模型的各种特征和领域意义的描述。

2.2 模型字典

模型字典是模型库管理系统的核心，它包含模型库中所有模型的描述和存储信息，是关于模型描述信息的特殊数据库，它是模型库系统设计和实现人员在模型库系统设计、实现、运行、维护以及扩充等阶段中控制并管理有关模型的信息工具。模型库系统中关于模型的描述、存储和使用等信息成为模型库系统的元数据，模型字典就是管理和控制模型库系统元数据的工具。模型库系统的模型管理功能是通过模型字典的方式来实现的。将模型字典看作模型库管理下的一个用户数据库，可获得模型库含有什么样的模型、模型的定义、使用范围、使用方法、数据格式、开发人员、开发时间以及系统作出修改时可能的影响等方面的信息。

模型字典分为3级，1级字典存储的是模型的总体信息，包括模型名称、模型编号和模型在分类结构中的位置信息，根据位置信息便可建立模型分类结构树，有助于方便有效的组织管理模型。2级字典存储的是各个模型的个体信息，包括模型编号、输入变量表名、输出变量表名、方法编号、模型变量与方法参数匹配关系表名、精度范围、算法复杂度、建模单位以及建模日期等。3级字典存储的是模型的输入变量表、输出变量表、子模型表等有关信息。变量表包括变量名称、类型、长度、单位、小数位数、值或值区间，以及意义的说明。子模型表存储复合模型的子模型信息。

2.3 复合模型

一般来说，模型可分成两大类，原子模型和符合模型。原子模型是最小单位的模型，符合模型是由夺个字模型组合而成的模型，其中的子模型可以是原子模型，也可以是复合模型。

2.4 方法库

方法中的方法是可执行的程序单位。每个方法均由方法首部和方法体两部分组成。方法首部是方法与外部的接口，任何方法与外部交换数据只能通过方法首部进行。方法首部具有标准的接口形式。方法体是描述算法的程序。方法库由源代码库、说明库、目标代码库三部分组成，统一由方法字典管理。方法字典包括方法编号、方法名称、方法标题、输入输出参数的序号、名称、类型、长度、方法描述、源代码地址、目标代码地址。

3.模型库管理系统运行机制

当有权限的用户运行模型时，用户只需要推动人机界面提供必要的数据，系统自动搜索模型并运行得出结果，模型的内部运行机制分两种情况，对于原子模型，从模型字典中找到模型，取得输入变量、拘束条件等数据，然后按照匹配关系调用从模型方法中找到的方法，求解模型，当运行复合模型时，系统首先从子模型列表及顺序信息中取得复合模型包含的子模型及其各自的优先顺序，然后每运行一个子模型，系统都要从参数信息中度曲相应子模型计算结果的取舍信息，以保证个格子模型之间数据传递的准确性。

由于系统采用了多层应用系统的结构，模型字典、方法字典都可以存储在异地数据库中，但是模型的方法有些不同，因为模型的运行需要调用方法的目标代码，所以可执行的目标代码（一般以DLL、COM等技术实现）要保存在本地，以简化处理。

参考文献

[1]曲成义，唐德顺，等.决策支持系统与专家系统[M].北京：社会科学文献出版社，1988.

[2]李瑞，黄明.CIMS环境下面向对象模型库管理系统分析与设计[M].计算机应用，1999.

分布式电梯监控系统设计 第7篇

在工业控制系统中, 基于PLC控制技术的设备具有抗干扰能力强, 稳定性好, 开发方便的特点而得到广泛应用。但由于PLC在对通用网络技术, 特别是TCP/IP技术的支持功能较弱, 而且从目前工业发展现状上讲, 各个PLC供应厂家在PLC通信协议方面也相对独立。虽然在硬件层面上都完全支持或者部分支持串行数据接口标准, 如RS-232, RS-422与RS-485通信标准, 但由于上述协议支持用户建立自己的高层通信协议, 许多厂家都建立了一套高层通信协议, 甚至在同一厂家的不同PLC系列都采用不同的高级通信协议, 或公开或厂家独家使用。

由于各PLC系列在数据接口标准和高级通信协议上的不统一, 传统工业控制上对于基于多PLC控制设备的监控实现都只能采用特向开发的方式, 根据系统特点要求和所应用的PLC系列所提供的通信协议, 再根据系统设计时系统实际信息与PLC输入点, 输出点以及部分内部工作点的状态建立关联, 建立专门的监控程序系统[1]。

由于系统设计功能的专用性太强, 升级拓展功能极差, 通常在硬件系统升级或PLC系列更新时, 原有的监控系统就被迫要被放弃重新开发, 系统构件的重用性极差。同时由于监控系统开发的专用性, 其数据的共享与网络应用也受到很大的限制, 这些反过来也限制了PLC技术在分布式大型监控系统开发应用上的发展[2]。

电梯控制系统就是PLC技术典型的应用实例之一, 由于PLC应用技术的特点, 目前大部分电梯系统都不能提供统一的网络监控系统, 其工作过程及工作状态的监控功能基本只能采用本地报警蜂鸣器、故障指示灯等硬件方式报警方式实现, 这种方式对于安装分散且数量较多的多电梯监控系统存在明显的弊端, 跟目前自动化楼宇的安全监视也不相适应。例如故障报警分散, 人工巡逻检查造成人力资源浪费, 且报警、维修不及时;故障报警点太多则容易造成线路复杂化;硬件报警能够实现的故障信息量太少等等[3]。

虽然部分自动化楼宇安全中心采用安装视频监控系统方式实现了部分多电梯系统状态的监视功能, 但由于其所能观察到的只能是电梯运行空间的视觉效果, 基本只能用人工方式进行判断分析, 对人力资源浪费极大;加上系统不能实现对电梯内部的工作点状态监控功能, 更不能通过改变PLC工作点状态实现对电梯工作状态的操作, 监控系统所能实现的功能比较有限。随着计算机和自动化技术的大量应用, 可以将故障信息通过进行初步监控, 然后再由PLC上传到计算机中, 由计算机处理故障信息, 进行报警、记录、显示故障信息。具有可进行集中监控, 节省人力, 故障信息直观、丰富, 便于分析等优点。

1 软件体系结构的选择

考虑到目前各PLC系列所提供的通信协议和各基于某PLC系列开发的电梯控制系统在设计应用上的独立性, 考虑采用基于层次消息总线方式进行软件体系设计[4]。

如图1所示, 利用标准构件的方式实现电梯系统中PLC与各控制工作站之间的通信, 而控制工作站与监视主机, 浏览工作站与控制主机之间采用TCP/IP方式进行联网。

基于TCP/IP进行联网时, 以异构形式实现网络连接, 如图2所示。控制工作站与监视主机之间采用C/S方式实现数据更新。而控制主机与监视主机及浏览工作站之间采用B/S结构实现电梯运行状态的监视, 控制主机在需要直接对某部电梯进行强行操作时可以通过C/S方式直接实现。

2 PLC与控制工作站接口构件的设计

设计的核心是将PLC与各控制工作站之间的通信以标准构件的方式进行实现。作为监视通信接口的标准构件, 必须完成图3中四个方面的内容。

由于采用将PC机与各类型的PLC之间通信的通信协议以库的方式作为构件的一部分, 通过在控制工作站之间独立选择相应的端口即总线类型, 再根据不同电梯系统中工作点的配置情况, 通过工作点命名模块将本来没有相关逻辑关系的各个关系点定义为电梯号和相应电梯号下的信号名称编码 (包括上行/下行状态, 超载报警, 呼梯请求, 所在楼层号等) 。

由于对于所有电梯操作而言, 信号名称和使用意义基本是统一的, 只是在PLC内部定义不一样, 通过工作点命名模块实现了关联, 动态扫描模块可以对需要扫描的工作点进行动态扫描, 并根据相应状态的变化量向监视主机通信模块发出申请。与监视主机通信模块只需要向监视主机发出编码方式下的状态, 而不需要涉及具体工作点的数据点状态。

通过这种将串行数据接口下的PLC接口协议及工作点进行编码的方式, 通过命名模块实现了在两级网络之间的隔离, 对于TCP/IP层通信而言, 不用涉及具体的PLC型号和PLC内部的配置情况, 而对于串行数据接口层, 由于可以将通信协议标准化, 采用端口选择和工作点统一命名的方式, 也能够方便地实现通信协议的重用和升级扩充。对于整个系统而言, 只要命名模块即命名方法统一, 各个构件之间基本独立升级或替换, 重用性能够得以保障。

同样的, 监视通信接口的标准构件模型如图4所示, 由于控制主机采用编码方式下达操作指令, 具体的PLC内部工作点由PLC操作模块根据工作点命名模块的信息自行处理, 实现了两级隔离。

3 结束语

由于采用了基于层次消息总线方式进行软件体系设计了方法, 采用标准构件的方式实现不同电梯系统和不同系列的PLC与PC机之间的通信接口, 从而克服了多PLC控制系统在分布式网络中由于通信协议不统一, 监控系统重用性差, 升级困难的问题, 而且两级通信网络之间通过命名模块进行编码实现关联, 同时也实现了隔离, 两级网络之间相对比较独立, 各自的升级扩展关联较弱, 也有利于构件之间的重用与扩展。通过对通信接口模块实现构件化处理, 从而克服了多种总线多种协议共存系统中数据共享及交流的困难, 上述方法对类似的多PLC分布式控制系统监控程序具有参考价值。

摘要：介绍以PLC为分布式控制单元的多电梯监控系统的设计方案, 通过采用基于层次消息总线方式进行软件体系设计, 采用标准构件的方式实现不同电梯系统与PC机之间的通信接口, 从而克服了多PLC控制系统在分布式网络中由于通信协议不统一, 监控系统重用性差, 升级困难的问题。

关键词：层次消息总线方式,PLC,分布式控制系统,串行数据接口,TCP/IP

参考文献

[1]陈少波.遗失PLC密码的处理方法[M].新技术新工艺, 2004 (9) :29-30.

[2]郝洪霆, 张赞, 王永升, 等.基于PLC和PC的分布式计算机监控系统的设计[M].可编程控制器与工厂自动化, 2007 (5) :64-67.

[3]姜敏, 马旭东.基于PLC的串口通信技术对电梯模型远程监控[M].微计算机信息, 2001 (8) :12-15.

分布式呼叫中心系统的设计 第8篇

为了更好的帮助现代企业实现高效的客户服务和业务拓展, 本分布式呼叫中心打破了传统呼叫中心的构建方式, 利用计算机通信技术将通信与计算机结合在一起, 采用IP内核的一体化设计, 无需外挂其他语音网关设备, 就可以在网络上构建一个语音和数据的统一接触平台, 为企业提供一系列先进呼叫中心功能, 其中包括:电话交换机 (包括自动话务台功能和预知拨号、监听插话等呼叫管理功能) 、自动话务分配、IVR生成、Vo IP功能、Web呼叫、语音信箱、文本转语音 (TTS) 、传真及录音、电话会议、远程IP分机、Exchange集成、CDR (通话详细报告) 、Alti API服务、系统级连等, 并且通过远程管理工具可以有效地银行机构实现分布在各地、各种不同业务的信息资源的集中管理和全面共享, 大大提高企业的客户服务能力, 从而在一定程度上提高了客户的忠诚度。

主要系统功能

1、电话交换功能 (PBX)

2、VOIP网关功能, 实现电话分机的远程部署

3、实现呼叫中心的客户关系管理 (CRM)

4、自动话务分配功能 (ACD)

5、灵活方便的实时电话录音功能

6、呼叫等待的队列管理功能

7、强大的语音信箱功能

8、语音会议室功能 (多方电话会议)

9、通话详细报告CDR及全面的话务分析报表

10、自动语音应答系统 (IVR)

11、坐席扩充:无线量扩充, 只要增加相应的网络设备和话务就可以达到坐席数量的增加

12、软件升级:HC800IP呼叫中心所有软件系统都采用B/S架构, 无需安装任何客户端, 还享有呼叫中心软件一年内免费版本升级服务。

良好的服务有助于提高客户的保持度

根据数据显示, 企业每年平均客户流失率为20%, 根据来自哈佛商业评论的研究表明, 客户保持度上升5%后, 企业盈利能力将提高100%。如何让企业具有良好的客户保持度?本IP分布式呼叫中心针对企业的应用, 有效的融合电话、网络等非现场交易方式, 并且可以根据客户的等级设置来电接听顺序, 可以使管理人员有效监控服务质量和效果, 提供实时的监听插话, 当面临一些棘手的问题, 座席人员无法给予相关的服务的时候, 班长席或者其他管理人员可以随时参与到通话, 可以直接与客户进行交流, 也可以隐蔽地指导座席人员, 这样可以有效解决一些特殊事件并有效防止客户产生不快的情绪。本分布式呼叫中心系统可以帮助企业实现专人电话服务, 即每一通电话都会有找到与之匹配的服务人员接听, 甚至这个电话被转接了很多次, 甚至被路由到其他分支机构, 每一次电话服务之后, 系统提供一个"report card"记录着座席人员客户服务的过程。这样, 非常便于企业呼叫中心运营管理对工作组和个人的绩效进行考评。而且, 提供电脑数字化技术电话录音, 具有多线同时录音, 录音记录, 录音回放等多种功能, 进一步保证了座席人员的服务质量。当企业利用先进的技术, 为客户的每一次接触提供一个良好的服务窗口, 并且保证良好的客户服务和解决问题的能力, 那么客户的满意度和保持度将随之提高。

先进的技术帮助企业更好地服务于不断增长的客户群体

随着企业的竞争越来越激烈, 在不增加服务人员的情况下如何面对不断增长的客户群体?通过良好的个性化的服务获得广泛的声誉, 进一步提高客户的满意度, 因为他们深知在行业良好的口碑关系到企业的发展。

通过良好的管理提供有针对性的个性化服务

企业越来越重视客户的分级别管理, 针对不同等级的客户提供有针对性的个性化服务可以大幅度提高客户的满意度。当有客户通过奥迪坚IP分布式呼叫中心系统打电话联系企业的时候, 他们将听到亲切的真人问候。奥迪坚IP分布式呼叫中心技术把信息通信技术与Vo IP技术完美地结合在一起, 企业各分支营业点之间的语音和数据可以通过IP实现同步, 使得各个分支机构工作起来就象在一个地方一样, 各地的服务人员都可以给客户提供24小时不间断的服务, 客户可以通过多种方是拨打企业的统一对外的服务号码进入服务中心, 其来电和基本信息都会被显示, 在电话转接的同时, 语音和数据都可以得到同步的转移, 所以无论是哪一个地方哪一个座席人员接听, 客户都会听到包含其姓名在内的亲切问候, 使得用户感觉到被受重视和尊重。在开始客户服务之前, 座席人员还可以看到客户以往的通话纪录, 包括来电次数, 来电内容, 每次来电长度以及服务等级等信息。班长席可以根据这些信息做出正确的服务判断从而为客户提供相应的服务, 这样使得每一次客户致电企业, 都会获得快速和准确的服务。

分布式构架有助于企业统一分散在各地的资源

大型企业分支机构众多, 现代的企业更倾向于采用统一的通讯服务, 通过Vo IP有效联系分散在各地的分支机构。本分布式呼叫中心系统由于采用分布式的构架, 可以有效突破时空瓶颈, 实现客户服务资源和信息的统一和管理, 各地的座席人员在提供良好的本地化服务的同时也克服了管理上带来的难题。

基于IP的通讯最大程度地降低企业的服务成本

利用IP语音能够让无论身在何处的人不必再担心昂贵的通讯费用, 本分布式呼叫中心在利用Vo IP技术方面表现卓越, 其核心是系统底层的IP一体化设计, 不需要任何外挂的语音/媒体设备就实现了Vo IP的功能, 使得IP语音和数据传输与频宽使用效率皆高的同时, 可以大幅度企业通讯费用。使用本分布式呼叫中心系统, 不仅仅大大节省了长途通讯费用, 而且大大减少了人员系统维护和管理的费用, 系统强大的自动管理能力以及灵活简单, 人性化的功能实现, 它可以帮助企业的员工出差在外的时候也能远程为客户提供服务, 这让每一个员工的服务效率和服务贡献得到极大的提高。

结束语

对于大部分企业的客户而言, 他们渴望在每一次和企业的联络中都获得快乐的服务体验, 企业能够快速而准确地解决他们的问题。本设计在呼叫中心平台构建和功能实现上无疑为广大银行机构提供了一条便捷的与客户进行通讯的途径。

分布式运动控制系统设计研究 第9篇

关键词：分布式运动控制系统,RTDX,模块机器人

一、引言

目前工业机器人工作于工业环境, 结构形式单一, 构型基本固定。由于不同应用领域的需求, 机器人产品正朝着多品种、多规格、小批量、复杂化等方向发展。模块化设计方法与传统设计方法相比, 不仅可以通过选择适当模块迅速构建客户所需机器人, 而且还能很好解决机器人品种、规格与设计制造的周期、成本之间的矛盾。在分布式运动控制系统中, 每个模块作为单独的一个控制单元, 可以满足模块化机器人设计的要求。分布式运动控制系统相对于传统的集中式运动控制器, 具有如下一些特点。

(1) 独立数据处理。每个模块单元在运动学和动力上应具有相对的独立性。在机器人的运动学和动力学中, 各单元之间的耦合非常强, 为了实现模块化设计, 应尽可能保证模块在运动学和动力学上的独立性, 可以考虑通过模块来分别调整机器人的各运动学参数。

(2) 独立驱动。每个主动模块应具有驱动能力, 完成特定的运动和动作。在机器人结构中, 每个主动单元就是实现一个或多个自由度的关节或运动单元。为了减少在模块问的机械运动传递, 因此每个主动模块都有自己的驱动系统。

正是由于这些特点, 分布式运动控制系统广泛使用于众多运动控制领域, 如机器人, 多自由度机械臂, 多轴工作台等对象上。本文针对采用分布式运动控制系统单个模块的硬件架构和软件设计, 上位机除了与分布式运动控制单元进行正常的通信外, 还可以采用RTDX技术, 对关键数据进行实时监控。

二、分布式运动控制系统硬件架构

机械臂的执行机构采用分布式运动控制技术, 即机械臂的每个运动关节均具有一定的指令接受及位置信息反馈能力, 而不是单纯的实现位置环、速度环、电流环控制, 通过主控器按一定时序发送运动控制指令至各个关节即可实现机械臂的联动控制。

布式运动控制系统模块采用DSP TMS320F28335 作为运动控制器的控制核心, 配套外围电路, 与上位机进行通信, 对进行电机控制。其运动控制指令通过模拟电压的形式输出到驱动器上。该模拟信号由DSP的DAC外设产生, DSP通过IO口并行输出控制量给DAC外设。DAC将再数字量转化为电压量, 作为驱动器给定信号。该DAC外设可实现多路控制, 对死区的处理和线性度上, 性能可能有较大的改进。运动控制卡采用CAN总线与上位机工作数据的通讯。

系统的硬件包括DSP, D/A转换电路, 以及外围电路。其中, 采用DSP TMS320F28335 作为运动控制器的控制核心, 该款DSP芯片是一款性价比极高的32 位浮点型数据信号处理芯片, 最高主频可达高达150MHz, 包括一个32 位的单精度IEEE754 浮点单元 (FPU) [1]。32x32 位MAC64 位处理能力使得控制器能够有效地处理更高的数字分辨率问题。数字信号处理器TMS320F28335DSP作为一款运动控制芯片, 其所具备良好的数据采集速度和数据运算速度, 可靠性强和实用性高, 可以在不同的控制系统中运用。

系统采用的DAC8728 是一款低功耗, 16 位并行输入, 8 路输出, 输出电压范围可达+/-16.5V的数模转换器。该DAC的写入速度可达50MHz, 操作I/O电压与DSP28335 引脚电压相兼容。有八个数模转换器, 它们共用5 根地址线寻址和16 根数据线。

DAC8728 其内部主要是由三个部分组成:逻辑控制电路, 数模转换电路, 输出放大电路。其内部逻辑控制信号为:CLR, LDAC, RST, R/W来控制转换的电路, 同时锁存数模转换器, A0, A1, A2, A3, A4 这五根地址线选出相应的数模转换器。每一路的数模转换器都包含一个输出放大器。

在进行传感采样的外围电路中, 我们需要将电机运行时正交编码器产生的正交编码信号, 进行电气隔离, 得到较好的波形, 然后在输入DSP正交编码电路中进行处理, 得到电机的速度, 位置等信息。

三、软件架构

RTDX作为传输数据的实时分析工具, 可以进行主机与分布式控制器之间的数据传输, 并将数据结构实时显示于主机界面上。虽然CAN总线的位传输速率能达到1Mbps, 可以满足一般的通讯要求。但是, 要将系统工作的实时数据情况反馈给系统, 需要先经过相应的处理, 在处理数据的过程中, 常常需要调用中断来进行数据的处理及CAN的通讯传输。而RTDX的方法, 则采用类似在线硬仿真 (ICE, in-circle emulation) 的方式来执行监视, 可准确的反映系统的真实数据。采用合适的配置, RTDX技术的传输速率可达到2Mbps, 能产生一个高速的数据流, 实现主机与分布式控制器之间的数据传输。

本文采用MATLAB平台下的Simulink来迅速自动生成代码, 载入分布式运动控制器中执行。在Simulink中能提供图像界面环境和一些列相应的模块库以供调用。模块可以在Simulink中生成可在DSP中执行的代码。同时, 采用RealTime工作库, C语言代码可以快速生成可直接使用到DSP中的实时仿真模型。当把代码下载到分布控制器的DSP中时, Real-Time Data Exchange (RTDX) 的通讯通道将在该分布式DSP与上位机之间产生。 (如图1 所示) 该技术可以允许上位机对DSP进行读写操作[3-4]。在本应用中, 上位机上绘制电机实时速度曲线绘制 (如图2 所示)

四、结论

本文设计了一种可应用于多自由度机械臂的分布式控制系统。在硬件上, 该系统采用DSP作为控制核心, 与驱动器一起控制电机的运动, 同时与上位机及其各个控制器之间, 通过CAN总线进行通信。在软件上, 通过基于图形化模式的RTDX技术, 快速生产执行代码, 对电机的重要参数进行实时监控, 保证了数据的准确性和实时性。该分布式控制系统可应用于构建多自由度的运动控制系统, 具有一定的实用性。

参考文献

[1]TMS320F2812数据手册[/OL].Texas Instruments Incorporated, http://www.ti.com/lit/ds/symlink/tms320f28335.pdf.

[2]X.M.Chen, Rapid Development of Real-Time Applications Using MATLAB/Simulink on TI C6000-based DSP[M], Proceedings of the Internatinal Multi Conference of Engineers and Computer Scientists 2010 VolⅡ, IMECS 2010 March 17-19, 2010, Hong Kong.

[3]D.Allensworth, “How to write an rtdx host application using matlab”[J].Texas Instruments, Tech.Rep., May 2002.

分布式多媒体通信系统设计 第10篇

支持的协议越多, 系统本身就越复杂, 为了使系统能够具有独立性, 需要从技术上保证业务与控制分离, 呼叫与承载分离, 让系统作为底层通信平台时能够为业务提供更多的服务, 这就需要在系统架构设计过程中考虑使用组件级复用技术和服务级复用技术, 从功能上分为5层, 实现分布式多媒体通信系统。目前, 国内一些多媒体通信系统出现了一些音视频指标较差、红外遥控信号的学习成功率较低等缺陷, 本文设计的分布式多媒体通信系统就能解决这些问题。

1 总体架构

分布式多媒体通信系统的体系结构, 如图1所示, 从功能上分为5层:业务应用层、服务层、交换控制层、媒体接入层、传输层。

其中应用层完成具体的业务逻辑, 服务层提供业务无关的基础服务, 交换控制层是基于纯软件模块的抽象媒体交换层, 该层负责整个系统各种类型的媒体资源的建立、维持及释放, 完成该多媒体通信体系结构中媒体调度的核心控制。媒体接入/处理层完成非IP网络与IP网之间的衔接工作, 完成媒体编解码、媒体数据持久化、视频分析、IP媒体传输以及非标准的第三方视频服务器的接入。传输层完成数据在各种网络上的传递, 如IP分组网、电路交换网。

2 核心功能设计

2.1 业务应用层设计

业务应用层中定义多媒体业务系统, 业务应用层与服务层间的信令交换通过私有协议实现, 如视频监控业务通过私有协议查询多媒体存储服务中的录像分布情况;业务应用层与服务层间的媒体交换通过统一的交换控制层接口完成。

视频监控业务主要完成IP网络视频监控设备管理功能, 实现任意用户在任意地点远程登录系统来管理视频监控设备, 基本功能包括视频浏览、PTZ (云台控制) 、电子地图、电视墙、录像回放、报警事件管理等功能。

3G视频报警业务主要完成基于3G无线网络的视频报警及接警功能, 基本功能包括自动呼叫分配、IP管理等;该业务系统与传统报警系统最大的不同之处就在于支持视频报警功能, 通过统一的交换控制层接口与3G视频网关完成音视频的交换。

2.2 服务层

在多媒体领域, 有许多基础服务是与业务无关的, 例如多媒体存储服务、视频智能分析服务等, 在不同的业务中都能够使用这些通用的服务, 业务可以通过与基础服务进行交互从而完成一个业务功能点, 因此有必要单独定义服务层, 这样设计也是为了该多媒体通信系统作为底层通信平台时, 为业务提供更多的服务。

不同服务之间以及服务层与应用层之间的信令交换通过私有协议实现[1], 而媒体交换均通过统一的交换控制层接口完成。

2.2.1 目录服务

服务层中最底层的服务类型, 主要实现以下几个功能:

1) 用户管理:完成用户信息的持久化;支持管理员对用户信息进行增删改, 支持用户的分组管理, 一个用户只能属于一个用户组, 用户组可以嵌套。在权限控制中, 用户或用户组将层层继承父用户组对资源拥有的权限。

2) 权限管理:完成权限相关信息的持久化;目录服务设计为采用基于角色的访问控制方法, 即RBAC模型。RBAC的基本思想[1]如图2所示, 是在用户和访问权限之间引入角色的概念, 将用户和角色联系起来, 通过对角色的授权来控制用户对系统资源的访问。

用户通过角色享有权限, 它不直接与权限相关联, 权限对存取对象的操作许可通过角色实现。这个模型比传统的自主访问控制 (DAC) 和强制访问控制 (MAC) 具有更高的灵活性和更好的扩展性。

3) 数据同步:由于服务层不做数据持久化, 业务应用层在使用服务层提供的服务时, 目录服务必须担负起数据同步的任务。如管理员修改了某路视频的存储计划, 目录服务必须通过私有信令在业务应用层与多媒体存储服务间进行数据同步。

4) 私有信令路由:业务应用层将通过私有信令和服务层进行交互, 如视频监控业务与监控前端接入服务或多媒体存储服务进行交互。目录服务负责维护业务应用层与服务层间的信令连接, 当需要信令交互时, 如用户对某个监控前端进行PTZ操作, 目录服务首先查找该监控前端位于哪个前端接入服务实例 (因为在大容量接入时, 允许存在多个前端接入服务的实例) , 再根据相应的通信节点号将控制请求发送出去, 类似的操作在与多媒体存储服务交互时也十分常见。

2.2.2 多媒体存储服务

完成多媒体数据的存储、检索与访问功能, 通过交换控制层接口能够提供统一的媒体数据存储与访问。

2.2.3 监控前端接入服务

负责接入和控制国内外主流厂商的视频监控前端设备及各种报警设备, 负责接收来自各种视频前端的音视频流, 通过交换控制层接口能够将采集到的媒体流交换给其他系统;负责接收来自各种报警设备的报警事件, 并通过私有信令将报警事件上报。

2.2.4 视频智能分析服务[2]

通过交换控制层接口与其他系统进行媒体交换, 得到视频流后调用媒体处理层视频解码的接口, 解码后的数据作为智能算法的输入, 经过分析后获取智能事件信息, 并通过私有信令将事件上报。

2.2.5 3G视频网关

实现基于3G网络的呼出与呼入功能, 通过媒体处理层的转码模块完成H.263与H.264之间的视频转码, 通过交换控制层完成与其他系统的媒体交换。

2.2.6 视频会议接入服务

实现基于H.323或SIP的视频会议系统设备的接入, 主要功能是与视频会议终端点对点通信或以终端的身份接入视频会议MCU (多点控制单元) 。

2.2.7 全球眼平台接入服务

实现对于电信全球眼平台的接入服务, 完成全球眼平台与该多媒体通信系统的对接。

2.2.8 电视墙服务

实现该多媒体通信系统的任意视频流上墙服务。

2.3 媒体接入与处理层

媒体接入与处理层负责执行上层模块传送来的动作指令, 包括各种类型呼叫的建立与释放、媒体通道的建立与释放、多媒体转码、基于RTP (实时传输协议) 的多媒体传输、视频分析、媒体数据持久化、基于私有协议的第三方视频服务器的信令传递以及媒体传递等。

2.3.1 协议栈设计

该系统协议栈的设计, 要求能够适配包括SIP、H.323、3G-324M在内的所有当前主流的通信协议, 同时也能融合将来可能出现的协议, 因此在设计思路上, 可以设计独立的不依赖于具体协议的抽象协议接口, 以适配不同协议之间的差异;采用抽象协议接口具备如下特点:

1) 具备抽象的协议接口, 上层应用无须依赖底层具体协议的实现细节;

2) H.323、SIP、3G-324M可作为独立的模块, 按需装配;

3) 如果需要支持新的协议, 只需要实现协议本身, 其他上层应用无须改动。

当前主流的通信协议, 从设计和实现的角度, 主要由两部分内容构成:1) 静态的通信消息数据结构以及消息结构的编解码, 比如SIP协议有Invite、ACK、BYE等消息, 这些消息采用文本方式编解码;而H.323协议的呼叫建立SETUP、ALERT消息则采用ASN.1的格式进行编解码。2) 基于通信有限状态机的协议交互过程。

因此, 具体协议的设计, 如图3所示, 主要从通信消息以及呼叫建立/释放、能力协商等过程展开。设计独立的协议栈适配层, 封装SIP、H.323、3G-324M协议栈的呼叫建立和媒体协商功能。

协议栈适配层提供统一的呼叫类接口供应用层调用, 如呼叫建立、呼叫释放等;捕获具体协议栈上报的消息, 并以事件回调的方式通知应用层, 如呼叫到来事件。

统一呼叫类接入分为两类:呼叫接口与事件接口, 具体描述如下:

1) 呼叫接口

2) 事件回调接口

2.3.2 多媒体传输[3]设计

在设计多媒体传输时, 需要避免数据标题头占用空间小、传输实时性与可靠性的平衡、媒体发送端线程资源的独立性、媒体接收端对数据包进行重组的时间空间开销、丢包重传对网络的负面影响, 以及Nat穿越等问题。为了避免这些问题, 需要:

1) 独立的媒体发送队列。每一路媒体源拥有独立的发送缓存, 缓存大小可以自由指定, 码流数据需要传输时只要将其放入相应的发送队列中即可。

2) 独立的媒体重传队列。每一个媒体发送队列配备有相应的重传队列, 队列的大小可以自由指定, 发送队列中每发送完成一个数据包就将其放入对应的重传队列中供丢包重传时使用。通过控制重传队列的大小, 可以在传输的实时性与可靠性之间找到平衡点。

3) 独立的媒体发送线程。由于引进了媒体发送队列, 为了保证媒体数据采集任务[1]不受网络数据发送的影响, 采用独立的发送线程读取发送队列中的媒体数据进行网络发送, 该线程采取“尽力而为”的工作模式, 尽量多地从发送队列中读取数据进行发送, 并将发送完成的数据放入重传队列中。

4) 独立的媒体接收队列。接收端针对每一路媒体拥有独立的接收缓存, 缓存大小可以自由指定;接收队列按照网络接收的先后顺序存放数据包, 接收队列的大小对于传输的实时性与可靠性也会产生影响。

5) 独立的媒体接收线程。接收端创建独立的网络数据接收任务, 将收到的网络数据包按照先后顺序放入相应的接收队列中;该线程也是采取“尽力而为”的工作模式, 尽量多地从套接字中接收数据包并放到接收队列中。

6) 独立的数据重组线程。考虑到网络传输中可能的丢包和乱序, 在接收队列中的数据需要进行重新排列才能还原成为原始的媒体数据。数据重组任务[4]将根据数据包头中的包序号以及其所属的帧序号判断该帧数据是否已经完整地传输到本地, 并将已经完整的帧数据按照帧序号的大小顺序抛出;若发现某些帧数据的重组进度大幅落后于后续帧的重组进度, 则发送重传请求给发送端, 要求重新发送缺失的包。

7) 基于标签的Nat穿越。每一路媒体数据的接收端都会得到一个系统全局唯一的标识, 该接收端在启动媒体接收的同时将发送带有该唯一标识的数据包给发送端。发送端收到该数据包, 根据数据包的源地址建立该全局标识与网络IP、端口之间的映射关系, 之后的数据发送都将基于该地址进行。该方式实现的Nat (网络地址转换) 穿越功能可以非常好地适应目前市面上存在的绝大多数对称与非对称Nat。

3 物理部署图

3.1 系统部署图

多媒体通信系统物理部署分为4个层次:应用层、服务层、接入层、设备层。系统部署如图4所示。

应用层由视频监控应用服务器、视频监控业务客户端、3G视频通信服务器及3G视频通信业务客户端组成, 一般部署在中心机房, 与其他系统组件通过局域网连接。

服务层由目录服务器、多媒体存储服务器、多媒体转发服务器、智能视频分析服务器和指挥调度集成接口服务器组成, 这些服务器一般部署在中心机房, 与应用层通过局域网连接。

接入层由3G网关、视频监控设备接入服务器及视频会议接入服务器组成。3G网关一般部署在中心机房, 与应用层及服务层设备通过局域网连接, 通过E1线与3G运营商的3G移动交换机连接。监控设备接入服务器即可部署在中心机房, 也可部署在视频监控区域, 可通过局域网或Internet网与服务层及应用层连接, 可通过局域网及Internet与视频监控设备及其他视频监控系统连接。视频会议接入服务器一般部署在中心机房, 通过局域网与应用层及服务层连接, 可通过局域网或Internet网与视频会议MCU和终端连接。

设备层包括3G无线通信设备、视频监控前端设备、视频监控解码设备、视频会议MCU、视频会议终端。

3G网关部署在中心机房, 一端通过局域网接入协同通信系统, 一端通过E1线路与运营商的3G交换机相连。考虑到报警系统的平滑升级, 需要语音报警和视频报警两套系统同时运行, 这需要在中心机房同时部署3G网关和程控电话交换机, 具体部署图如图5所示。

3G网关与DS固网交换机 (上海迪爱斯设备有限公司产品) 之间通过E1线连接, 3G网关可将3G呼叫的语音部分转接到DS固网交换机。

4 客户端界面设计效果

4.1 点对点3G视频通信

点对点的3G视频通信设计效果如图6所示, 只能和接收某一个视频通话, 视频效果清晰。

4.2 多点3G视频通信

多点3G视频通话设计效果如图7所示, 可以接收多个地方的视频通话, 避免了不能即时处理来自多方向的事务。

4.3 视频通信坐席监控

视频通信坐席监控的界面设计效果如图8所示, 可以看到多个坐席的视频通话信息, 也可以选择某一个坐席的视频通话。

5 小结

目前, 该系统已经应用于上海迪爱斯设备有限公司协同通信系统, 整个系统具有可靠性、准确性、便捷性。文中主要给出该多媒体通信系统核心部分的设计方案和界面的设计方案。该方案适用于分布式通信系统, 实现多种业务的协同通信, 也实现了任意用户在任意地点远程登录系统来管理视频监控设备。在服务层中的3G手机报警系统, 在现实生活中也具有实用性, 有利于警员更加直觉、更加快速地判断受害人的详细情况, 这个系统也验证了该多媒体通信系统作为一个底层的多媒体平台的技术可行性。

参考文献

[1]杨兴华.移动网络视频监控系统[M].北京:电子工业出版社, 2013.

[2]王龙.分布式CMMB移动多媒体广播监测系统的实现[J].电视技术, 2012, 36 (17) :178-180.

[3]胡浩, 王峰.基于DM368的智能视频监控系统设计[J].电视技术, 2012, 36 (9) :124-126.

[4]GA/T367, 视频安防监控系统技术要求[S].2001.

[5]吴丽, 余宝生.多媒体通信的发展趋势[J].电视技术, 2004, 28 (11) :79-80.

[6]黎洪松.数字视频技术及应用[M].北京:清华大学出版社, 2005:60-75.

[7]RFC 3261, SDP:Session description protocol[S].2002.

分布系统程序化设计 第11篇

关键词：分布式光伏；发电子系统；监控；优化

0 引言

太阳能作为一种开发潜力巨大的新能源和可再生能源受到国内外的空前重视，从能源供应安全和清洁利用的角度出发，世界各国正把太阳能的商业化开发和利用作为重要的发展趋势。太阳能光伏发电以其绿色、可持续等优点，被公认为21 世纪最重要、最有发展前途的能源之一。

光伏发电站主要分为大型集中式电站与分布式光伏电站。相比集中式电站而言，分布式光伏发电因在位置选取、电能传输与规划、数据监控等方面具备明显优势，于世界范围内得到了广泛应用。在欧洲，分布式光伏在整个光伏发电应用中的比例高达70%，这一比例在美国更是超过了83%，而中国目前这一比例还不足35%，因此，国内分布式光伏发电应用仍具有广阔的市场空间。

海宁30MW分布式光伏发电项目利用金山开发区多个企业工业厂房屋顶作为建设场地。由于该项目涉及到海宁星莹家具、浙江联鸿纤维科技等11个家工厂的近40个工业厂房屋顶，为了方便项目完工后的运维及项目建设成本的控制，因此该项目对光伏发电子系统监控方案提出更高要求，在这种情况下提出对海宁30MWp分布式光伏电站子系统监控的优化方案，降低项目成本，便于电站后期运维。

1分布式光伏发电子系统常规监控方案

目前国内光伏电站中的光伏发电子系统监控方案通常采用配置通信柜的方式来实现对该子系统的汇流箱、逆变器、箱变测控、计量表计等设备的通信及监控。通信柜主要包括通信管理机，光纤环网交换机，视频交换机，尾纤盒，柜体及附件等。如图1所示，光伏发电子系统的汇流箱、逆变器、箱变测控、计量表计等设备通过RS485现场总线的方式接入到通信管理机中通信，通信管理机再通过光纤环网交换机与其他子系统组成光纤环网接入到站控层监控系统。光伏场区枪机、球机等摄像机通过以太网总线的方式接入到视频交换机，与其他子系统组成光纤环网接入到站控层视频监控系统。

这种子系统监控方案是目前光伏电站主流的方式，涉及到的设备厂家众多，通信线缆多，项目造价成本较高，而且对电站的运维人员技术要求提出更高要求。

图1 分布式光伏发电子系统常规监控方案

2 设计优化后分布式光伏电站子系统监控方案

海宁30MWp分布式光伏发电项目由于及到海宁星莹家具、浙江联鸿纤维科技等11个家工厂的近40个工业厂房屋顶，为了便于项目建成后运维方便及项目建设成本的控制，在这种情况下提出对海宁30MWp分布式光伏电站子系统监控的优化方案，降低项目成本，便于电站后期运维。

在项目设计过程中，通过与多个设备厂家进行技术咨询及交流发现，目前市场上有一种新产品——光伏发电单元智能监控装置。该装置其不仅具备箱变的保护、测控和通讯功能，同时提供了8路/16路RS485通信接口，支持MODBUS协议，可内置Zigbee无线通讯模块，实现发电单元内逆变器、智能汇流箱、计量表计等设备的接入，同时内置光电转换模块，可通过光纤环网接入光伏电站的监控系统，实现与站控层监控系统的通信。装置在功能上相当于通信管理机、光纤环网交换机、箱变测控装置加通信柜，在功能上可根据不同的项目需求进行配置，选配不同的模块插件，而一体化的功能设计不仅具有体积小、中转接线少、安装方便的优点，而且投资小，集成度高，通信方式灵活。

图2海宁项目光伏发电单元智能监控装置功能配置图

图2为海宁项目光伏发电单元智能监控装置功能配置图，从图中可以看该装置具备箱变测控的电压电流信号输入及控制输出，同时还具有16路RS485通信接口，提供了6路以太网电口及4对光纤接口。

图3优化后发电子系统监控方案

图3为设计优化采用光伏发电单元智能监控装置后的海宁项目光伏发电发电子系统监控方案，从图中可以看出，设计采用光伏发电单元智能监控装置，可以代替原有箱变测控、通信管理机、光纤环网交换机等设备。该智能装置可以采用箱变低压室就地安装，安装维护方便，无需柜体，中转接线少。

3 优化方案的预期效益

对比海宁30MWp分布式光伏发电项目分别采用常规方案和优化方案的设备成本：

经过对比看出，设计优化采用光伏发电单元智能监控装置代替原有通信柜的方案设备成本能够节约72.8万元，能够有效节约项目成本。如果算上设备的安装费用，由于常规方案比优化方案设备多，其安装成本亦高于优化方案。而且优化方案仅采用一家公司的光伏发电单元智能监控装置，相比常规方案通信管理机，箱变测控等几家公司的设备，减少了通信中断的故障点及运维人员的工作量，同时运维人员只需熟练掌握该光伏发电单元智能监控装置即可。

4结束语

该项目建成以后，项目公司通过成本核算，该方案确实减少了项目成本，在整个项目过程中起到了降本增效的作用。且通过现场运维人员反馈情况来看，经过设计优化的分布式光伏电站子系统监控方案运行稳定，可靠。综上所述，设计优化采用光伏发电单元智能监控装置的分布式光伏电站子系统监控方案值得在以后大型集中式电站与分布式光伏电站借鉴与推广。

参考文献：

[1]寿挺，张思建.小型并网光伏电站智能监控系统的研究.中国电力，新能源，第45卷，第9期，2012

基于CORBA的分布式系统的设计 第12篇

传统的应用软件开发中大多采用两层C/S结构, 它具有开发简单、技术要求相对较低的特点, 但是随着软件规模不断扩大和用户需求的不断提高, 软件系统变得越发庞大, 这种结构的弊端也就逐渐暴露出来, 主要表现在程序代码可重用程度低、系统的维护工作繁琐困难、程序应变能力弱等方面。

针对以上问题, 本文提出并采用了在软件开发过程中引入CORBA中间件的概念, 通过构建基于CORBA的三层分布式结构, 取消了原有两层模型中客户机与服务器间的一一对应关系, 使得系统结构更加清晰合理。

1 CORBA体系结构

CORBA (Common Object Request Broker Architecture) , 即公共对象请求代理体系结构, 是在不同平台、不同语言之间实现对象通信的模型, 它为分布式应用环境下的对象资源共享、代码重用、可移植和对象间相互访问建立了通用标准[2], 同样也为在大量硬件、软件之间实现相互操作提供了良好的解决方案, 是构建三层应用理想的平台。

1.1 对象请求代理ORB (Object Request Broker)

ORB是CORBA的核心, 其主要功能是定位服务对象, 分析客户对象的请求, 获取服务对象的功能接口, 在客户与服务对象间建立通信连接。

1.2 CORBA对象的接口IDL (Interface Definition Langu-age)

IDL是CORBA的另外一个重要组成部分, 用于说明CORBA服务对象完成的功能, 但不能够利用IDL实现该功能。不同于其它面向对象程序设计语言, IDL是独立于其他编程语言的功能描述性语言, 不能用它指定它所定义的类或者方法的具体实现。因此, 它仅仅是定义底层对象接口的语言。

1.3 Stub和Skeleton

CORBA应用程序类似于其他面向对象应用程序, 不同之处是当对象在另一台机器上的时候, 客户端和服务器端必须通过一个特殊的层来管理网络的通讯, 这个层在客户端称为桩 (Stub) , 在服务器端称为框架 (Skeleton) 。Stub和Skeleton是IDL与对象实现语言之间的桥梁, Stub负责客户请求的编码, 并把请求发送到ORB, 然后对接收到的处理结果进行解释, 把结果或错误信息返回给客户。Skeleton对客户的请求进行解码, 调用所请求的对象的方法, 执行该方法, 并把执行结果或错误信息编码返回ORB。

2 三层结构模型

不同于传统应用开发中所采用的两层结构, 三层结构的组成如下:

第1层:表示层, 也叫界面层。该层提供给用户一个视觉上的界面, 用户可以通过它完成数据的输入与获取等功能。第2层:逻辑层, 也叫中间层。中间层响应界面层的用户请求, 执行任务并从数据层抓取数据, 并将必要的数据传送给界面层。第3层:数据层, 数据库服务器, 它响应逻辑层的请访问数据。这一层通常由大型的数据库服务器实现。三层结构的示意图如图1所示:

三层结构中, 客户端与数据库之间加进了一个中间层, 相对于两层结构模型, 三层结构较好的将用户界面与业务逻辑分离开了, 从而既保证了原有客户端的功能, 又提供了一个非常简洁的界面。在这种结构下, 如果要对应用程序进行修改, 不需要对客户端界面进行“大手术”, 只需要对中间层作出修改即可。这样, 开发人员可以专注于系统核心业务逻辑的开发, 从而简化了开发, 增强了程序的灵活性, 大大降低了后期维护的难度。

3 基于CORBA的分布式应用

3.1 基于CORBA的三层模型

中间件使开发人员在进行开发时只用处理某种类型的函数接口, 而其他细节则由中间件处理。CORBA被称为通信中间件, 因为CORBA实现了应用程序和通信核心的分离, 引入CORBA后, 三层结构的体系, 如图2所示:

在CORBA三层结构中, 任何应用系统只要符合CORBA系统定义的接口规范, 就可以方便地集成到CORBA系统中。

3.2 CORBA应用程序实例

通过CORBA, 服务器应用程序实现了能被远程客户应用程序调用的对象, 对该对象的调用通过定义良好的接口进行。

Delphi是Borland公司的集成应用系统开发工具, 它提供了对CORBA中间件的支持, 用Delphi开发基于CORBA的应用程序的结构, 如图3所示:

在CORBA的客户端, Stub通过ORB接收客户的应用服务请求, 并通过智能代理提供的命名服务寻找和定位应用服务对象。在CORBA的服务器端, ORB把应用服务器的服务程序接口传递给Skeleton, 并通过基本对象适配器在智能代理上注册应用服务。以下是CORBA在Delphi中的具体应用:

3.2.1 IDL接口的定义

在以上CORBA结构中, 系统首先应建立IDL文件, 用来定义功能接口, 可让客户端知道可以调用哪些操作及调用的方法。

Visi Broker会自动根据IDL文件生成相应的Stub和Skeleton。

3.2.2 服务器的实现

在服务器端, 对IDL定义的每个接口, 都要编写相应的对象实现类。服务器主程序还要对ORB环境进行初始化。

(1) 服务端 (Skeleton)

(2) IDL接口实现类

在initialization部分, 生成了创建类工厂对象实例的代码。当一个客户程序调用CORBA服务器时, 类工厂对象的实例将创建或者定位一个CORBA对象的实例。

3.2.3 客户端的实现

(1) 客户端 (Stub)

(2) 主函数

通过GUI获得参数, 获得CORBA服务对象的实现 (Account) 后, 调用服务对象的相应方法即可。

4 结束语

本文基于CORBA的三层分布式结构在Delphi环境下实现。实验结果表明:基于CORBA的三层分布式结构有利于系统功能逻辑的高度集中和系统“瘦”客户端的构建, 有利于提高系统的可配置性、可伸缩性、可重用性和可维护性。

摘要：指出了软件开发过程中传统两层C/S结构存在的不足, 提出了基于CORBA的三层分布式结构, 在Delphi环境下完成了CORBA中间件模型。实验表明:系统中三层结构层与层之间相互独立, 任何一层的改变不影响其它层功能。这种结构使得客户程序与服务器端分离, 更有利于系统的维护和代码的重用。

关键词：公共对象请求代理体系结构,分布式,三层结构

参考文献

[1]S MISHRA, L FEI, X LIN.On group communication support in CORBA[J].IEEE Transaction on Parallel and Distributed Systems, 2008 (2) .

[2]WERGERS SC, NAYLOR DL.CORBA infrastructure for distributed learning and meta-learning[J].Knowledge-Based Systems, 2008 (5) .

[3]王万诚, 李伟华.基于CORBA-JAVA软件复用查询系统中间件技术的研究与实现[J].计算机应用与软件, 2008 (2) .

[4]黎卓虹, 罗智佳, 彭奕文, 毛宗源.基于三层结构数据可视化的开发及应用[J].微计算机信息, 2008 (3) .

[5]宋毅, 刘云超.CORBA分布式应用程序动态配置[J].计算机应用与软件, 2006 (1) .