云朵朵 的个人资料弥漫的味道照片日志列表更多 ![]() | 帮助 |
《计算机仿真中的HLA技术》读书笔记--第3章(2)《计算机仿真中的HLA技术》读书笔记--第3章(2)――――――――――――――――蓝乾艺―――――――――――――――――――
OMT(对象模型模板)规定了所有FOM的结构,每一个联邦有一个作为这个特定联邦词汇表的FOM模型,联邦的每一次运行都使用联邦的FOM。也就是说,FOM是RTI的一个参数,在联邦运行的开始,FOM作为数据提供给RTI。FOM定义了联邦成员相互传递的事情和事件的名字,FOM只描述联邦成员的内部事情,FOM是联邦运行时通过RTI交换数据的词汇表。
这样,FOM的改变不影响到RTI和HLA标准。
OMT的主要组件有:对象类和交互类。
3.2.4.1交互:通过RTI的数据集
交互是在一个时刻通过RTI传送到其它联邦成员的数据集。一个交互可以用来表示仿真模型中多于一个联邦成员感兴趣的一个事件,它在仿真时间的一个点上发生。每个交互传送一组参数,一个交互被接受后,其不再继续存在。
FOM定义了交互类,一个联邦成员发送一个交互是一个特定类的交互。交互类是一个单向继承的层次结构,这个层次结构的根叫交互根(InteractionRoot)。在缺省情况下,交互根不定义参数。每一个交互类定义由它一起发送的参数,每一个类继承它所有父类定义的参数。一个类的完整有效的名字是通过连接由根到类的名字构成,中间又用“.”分隔。在FOM中完整有效的类名必须是唯一的。如图所示。
3.2.4.2对象:持续的仿真实体
RTI中的对象是如下仿真实体:
l 和多个联邦成员有关,并由RTI来处理。
l 在仿真时间的某些期间持续存在。
OMT定义了对象类,每个类有一个名字,每个类定义(可能是空的)一个称为属性的数据集。联邦成员产生这些类的实例。在联邦中,每一个实例都有自己的标识,都有独特的实例属性。仿真时,联邦成员通过给属性提供新的值来更新对象实例的状态。
对象类形成一个层次结构。每一个对象类一定有一个直接的父类[Mu1] ,对象类形成一个单向继承树。根类叫对象根(ObjectRoot),一个类的完整有效的名字是通过连接由根到类的名字构成,中间又用“.”分隔。在FOM中完整有效的类名必须是唯一的。
那些为一个类声明的属性值和那些从其父类继承来的属性称为有效属性,根类有一个必须的属性,即删除对象的特权(PrivilegeToDeleteObject),因此每一个类至少有一个有效属性。如图所示。
当属性是RTI操作主体时,它们要么是一个对象类的属性,要么是一个特定对象实例的属性。
l 一个对象类的属性称为类属性(Class Attribute)
l 一个特定对象实例的属性称为实例属性(Instance Attribute)
注意:HLA的对象不是完全面向对象的,那么它们的相同点在于:
(1)HLA的对象是对象类的实例,拥有唯一标识;
(2)对象类形成一个层次结构,从父类继承属性。
不同在于:
(1)在FOM中,HLA对象没有和它相联系的行为;
(2)“类属性”的概念不对应于Smalltalk中的“类变量(Class Variable)”或C++和Java中的“静态成员(Static Member)”。在HLA中,类属性是一个类的属性,它不考虑实例,被认为是一个类,没有值的概念。
关于RTI的实现:
(1)术语“对象”并没有要求RTI或任何联邦成员必须用面向对象的语言来实现。
(2)术语“对象”并没有要求HLA对象要作为对象结构存在于面向对象语言的任何API中。事实上,HLA对象在API中不是“语言对象”。
3.2.4.3交互和对象
在某种意义上,对象和交互之间是可以相互转化的,因此任何联邦模型可以全部采用对象或全部采用交互来实现。对象属性状态的变化是瞬间发生的(当属性值被更新时),所以联邦设计者总能用对象来实现交互的效果:通过产生其状态改变被当作交互的对象属性;同样,一个对象状态的变化可以表示为属性值变化的一系列交互。
下面是使用对象还是交互建模的基本规则:
l 任何发生的事情或事件用交互来建模。
l 如果要建模的实体有持续的状态,这个实体应该表示为对象。
3.2.4.4类的层次结构保护联邦成员免于变化
在对象模型中继承的主要目的是保护联邦成员免于变化。简单地说,使用确定对象类和交互类的联邦成员,即使通过添加子类扩展FOM后,它仍能继续使用。
HLA规则是构成HLA标准的3个组成部分之一,它表达了对HLA兼容的联邦成员和联邦的设计目标和限制,总结了HLA如何应用的方式。
联邦规则
规则1 联邦应该有一个联邦对象模型即FOM,FOM遵循HLA的对象模板即MOT。
规则2在联邦中,所有和仿真有关的对象实例的描述应该在联邦成员中,而不在RTI中。
规则3在联邦执行过程中,联邦成员间所有FOM数据的交换都应该通过RTI来实现。
规则4在联邦执行过程中,联邦成员和RTI之间遵循HLA接口规范进行交互。
规则5在联邦执行过程的任何时刻,一个实例属性最多能由一个联邦成员拥有。
联邦成员规则
规则6联邦成员应该有一个仿真对象模型SOM,SOM遵循HLA的对象模型模板即MOT。
规则7联邦成员应该能更新和/或反射其SOM中规定的任何属性、发送和/或接收其SOM中规定的交互。
规则8 在联邦执行过程中,联邦成员应该能够按SOM中的规定,动态地转移和/或接收属性的所有权。
规则9联邦成员应该能够按SOM中的规定,改变更新属性的条件(例如阈值)。
规则10联邦成员应该能管理局部时间,从而允许它和联邦中其它成员协调数据交互。
联邦管理服务通过下列2种方式管理联邦。
l 根据存在和成员资格定义联邦的执行。
l 完成联邦范围内的操作。
声明管理服务是联邦成员用来声明它们产生(发布)或消费(订阅)数据意图的方式,RTI使用这些声明来安排数据的路由、转换数据和管理兴趣。
关于路由,RTI使用订阅来决定当实体产生或更新时通知哪个联邦成员。
声明被用来转换联邦成员收到的数据。在使用前,收到的数据要根据联邦成员的订阅完成修剪和推销(重新贴标签)。它用来保护联邦成员免受FOM扩展的影响和鼓励联邦成员重用。
最后,RTI使用声明来表明对发布联邦成员的兴趣,RTI能告诉一个联邦成员是否有任何其它的联邦成员订阅了它打算产生的数据,以便在其它联邦成员不需要这个信息时,该联邦成员能停止产生数据。
对象管理服务是用于实现数据实际交换的那些服务。联邦成员使用这些服务来发送和接收交互,这些服务也用于登记一个对象类的新实例和更新其属性。其它联邦成员将调用这组中的服务来接收交互、发现新实例和接收实例属性的更新值。
在HLA的规则5和规则8要求联邦成员在更新实例属性前必须先拥有它,RTI保证在一个时刻最多只能有一个联邦成员能拥有一个给定实例的属性,该联邦成员负责更新它。仿真一个实体的职责能以下两种方式在联邦成员实现分享:
首先,一个实体的完整建模可以由多个联邦成员分享。如果这个实体由带有几个属性的一个实例表示,不同的联邦成员可以拥有这个实例的不同属性,并负责更新它们各自拥有的属性。属性管理服务允许这样做。
其次,实体的仿真在联邦执行过程中能从一个联邦成员转移到另一个联邦成员,也就是一个实例属性的所有权可以从一个联邦成员转移到另一个联邦成员,所有权的转移可以由当前的拥有者启动,也可以由将来的拥有者启动。
如果一个联邦不需要所有权管理,则可以忽略它,但一般情况下应该考虑对象所有权的管理服务。
联邦成员在它们自己的线程控制下执行,因此联邦成员间事件的正确顺序是需要解决的重要问题。在HLA中,事件的排序用“仿真时间”来表达。仿真时间是一个抽象的概念,没有必要把它和任何时间表示或时间单位相联系。RTI的时间管理服务负责下列2件事情。
(1) 允许每个联邦成员和其它联邦成员协调起来推进它自己的仿真时间。
(2) 控制时间戳事件的发送,保证联邦成员永远不会接收来自其它联邦成员的“过去”事件,“过去”事件就是事件的仿真时间小于该联邦成员的仿真时间。
RTI允许联邦成员选择参与时间管理的程度。联邦成员可以是时间受限的,在这种情况下,它的仿真时间推进受其它联邦成员的控制;联邦成员可以是时间调节的,在这种情况下,它的仿真时间推进将调节其它联邦成员的仿真时间推进;联邦成员还可以即受时间受限的又是时间调节的,也可以两种都不是。联邦成员将根据它的目标和联邦的需求做出不同的选择,RTI允许联邦执行中联邦成员有不同的选择。
数据分发管理(Data Distribution Management,DDM)服务控制着联邦成员间生产者与消费者的关系。尽管声明管理服务根据交互类和对象类管理这些关系,但是DMM根据对象实例和抽象的路由空间进行管理。DMM提供了强大的工具来改善生产者与消费者的关系。
Corba是一个用作“中间件”的体系结构,“中间件”是应用和操作系统之间的一层软件,Corba允许对象的计算分布在多台计算机上。Corba标准是软件供应商和用户组成协会OMG的一个产品,Corba是这类标准中应用得最广泛的一个,还有具有类似功能得其它中间产品,如:DCOM(Distributed Common Object Model)。
Corba定义了一个对象请求代理ORB(Object Request Broker),它是实现Corba功能的支撑框架。对HLA得初学者来说,RTI有点想ORB。它们确实有相似的地方:ORB是分布式对象间实现交互得媒体;RTI是联邦成员间实现交互的媒体。但是这种相似性是表明的,其体系结构区别:
(1) 在体系结构的意义上,Corba是用于建立面向对象系统的,这样,其所有的元素是显式交互的;而在HLA中,联邦成员隐式地进行交互。
(2) RTI支持联邦成员层次得组件模型,而Corba不支持,Corba只是一个能定义组件模型的平台,OMG目前正在为基于Corba的组件模型制定标准。
联系:
(1) 联邦成员和RTI之间得接口可以充当Corba接口。OMG IDL是一种API,使用这种API, RTIambassador 和FederateAmbassador能被当作Corba对象。事实上接口规范的1.3版本和IDL API都已经被OMG接受为其“用于分布式系统的工具”。
(2) ORB和Corba服务是实现RTI的可选工具,它们在RTI中的应用被有效地隐藏在RTI接口的后面;同样地,联邦成员能在它们的实现中自由地使用Corba,有使用ORB实现的RTI和联邦成员。
《计算机仿真中的HLA技术》第3章读书笔记(1)
|
语言是由句子组成的集合,是由一组符号所构成的集合。 汉语--所有符合汉语语法的句子的全体 英语--所有符合英语语法的句子的全体 程序设计语言--所有该语言的程序的全体
语义 -- 表示按照各种表示方法所表示的各个记号的特定含义。(各个记号和记号所表示的对象之间的关系) 语用 -- 表示在各个记号所出现的行为中,它们的来源、使用和影响。 每种语言具有两个可识别的特性,即语言的形式和该形式相关联的意义。 语言的实例若在语法上是正确的,其相关联的意义可以从两个观点来看,其一是该句子的创立者所想要表示的意义,另一是接收者所检验到的意义。这两个意义并非总是一样的,前者称为语言的语义,后者是其语用意义。幽默、双关语和谜语就是利用这两方面意义间的差异。 如果不考虑语义和语用,即只从语法这一侧面来看语言,这种意义下的语言称作形式语言。形式语言抽象地定义为一个数学系统。“形式”是指这样的事实:语言的所有规则只以什麽符号串能出现的方式来陈述。形式语言理论是对符号串集合的表示法、结构及其特性的研究。是程序设计语言语法分析研究的基础。 |
对P,NP,NPC,NP-H问题的认识和理解
author: 云朵朵lanqy
由于对P,NP,NPC,NP-H这几个问题一直都属于模糊的认识状态,特在网上找了些相关P,NP,NPC,NP-H问题的解释,网上相关于它们的解释版本很多,其中还存在不少错误的解释版本,令人越看越晕,越来越糊涂。最后在不断的努力下,似乎明白了一些,以下是对P,NP,NPC,NP-H问题的一些认识、理解和考证。如果理解还有什么偏差的话请高手批评指教。
版本1:
计算复杂性理论源于对判定问题算法的研究。
判定问题:其答案不是“是”就是“否”的问题。如,一个图的两顶点之间存在路径吗?判定问题有.三类:P,NP和NPC.
P类:已有多项式时间算法的判定问题.
NP类:已有指数时间算法的判定问题,包括P类.
NPC类:是NP的一个子集,且其中每一个问题均能由NP中的任何问题在多项式时间内转化而成.问题A能在多项式时间内转化为问题B可理解为,问题A有一个算法以问题B的算法为子程序,当把每次对B算法的调用看作一个基本操作(只花常数时间)时,A的这个算法是多项式时间的.
在NPC问题之外还有一些问题,其难度与NPC相当或难度超出NPC,这就是NPH问题.何谓NPH问题呢?
NPH类:若问题A不属于NP类,已知某一NPC问题可在多项式时间之内转化为问题A,则称A为NP难题.例如,“TSP”是NPH问题.
版本2:三、什么是NP问题?
指那些既不能证明其算法复杂性超出多项式界,又未找到有效算法的一类问题。
版本3:
P是所有可在多项式时间内用确定算法求解的判定问题的集合。
NP是所有可在多项式时间内用不确定算法求解的判定问题的集合。
版本4:
P问题:在多项式时间内由确定的图灵机(DTM)可以解决的问题称为P类问题,或称其属于P类。
NP问题:如果一个问题,其解法可以在多项式时间内由一个NTM(不确定图灵机)实现,那么此问题是NP问题
NP-HARD:从多项式规约的角度来看, 如果任何一个NP问题的都不会比某个问题L难,那么我们就说L是NP-HARD问题
NPC:如果某个问题是NP-HARD问题,同是它又是NP问题。那么,我们称它为NPC问题
版本5
1。P类问题:由确定型图灵机在多项式时间内可解的一切判定问题所组成的集合;
2。NP类问题:由非确定型图灵机在多项式时间内可计算的判定 问题所组成的集合;
3。NP完全问题:如果判定问题π∈NP,并且对所有其他判定问题 π∈NP,都有π'多项式变换到π(记为π'∞π),则称判定问题π 是NP完全的。
我的看法与理解:
1.P与NP的定义
通过考证,版本4和版本5对P问题和NP问题的定义较为严谨,其实版本2和通常的:“复杂度类P包含所有那些可以由一个确定型图灵机在多项式表达的时间内解决的问题;类NP由所有其肯定解可以在给定正确信息的多项式时间内验证的决定问题组成,或者等效的说,那些解可以在非确定图灵机上在多项式时间内找出的问题的集合。”是一层意思,剩下的几个版本可以认为是广义上非严格的定义。值得注意的是:这里NP的N是Non-Deterministic的N,不是Non-Polynomial的N。P问题与NP问题的关系问题是计算理论最大的未解决问题,也就是常说的P vs PN问题或P =?NP问题。
2.P =?NP 与 NPC问题
P =?NP 是“千僖难题”之一,美国麻州的克雷(Clay)数学研究所于2000年5月24日在巴黎法兰西学院宣布以一百万美元的报酬悬赏此问题。先看BBS上的一段说法:
NP就是Non-deterministic Polynomial的问题,也即是多项式复杂程度的非确定性问题。什么是非确定性问题呢?有些计算问题是确定性的,比如加减乘除之类,你只要按照公式推导,按部就班一步步来,就可以得到结果。但是,有些问题是无法按部就班直接地计算出来。比如,找大质数的问题。有没有一个公式,你一套公式,就可以一步步推算出来,下一个质数应该是多少呢?这样的公式是没有的。再比如,大的合数分解质因数的问题,有没有一个公式,把合数代进去,就直接可以算出,它的因子各自是多少?也没有这样的公式。这种问题的答案,是无法直接计算得到的,只能通过间接的"猜算"来得到结果。这也就是非确定性问题。而这些问题的通常有个算法,它不能直接告诉你答案是什么,但可以告诉你,某个可能的结果是正确的答案还是错误的。这个可以告诉你"猜算"的答案正确与否的算法,假如可以在多项式时间内算出来,就叫做多项式非确定性问题。而如果这个问题的所有可能答案,都是可以在多项式时间内进行正确与否的验算的话,就叫完全多项式非确定问题。完全多项式非确定性问题可以用穷举法得到答案,一个个检验下去,最终便能得到结果。但是这样算法的复杂程度,是指数关系,因此计算的时间随问题的复杂程度成指数的增长,很快便变得不可计算了。
人们发现,所有的完全多项式非确定性问题,都可以转换为一类叫做满足性问题的逻辑运算问题。既然这类问题的所有可能答案,都可以在多项式时间内计算,人们於是就猜想,是否这类问题,存在一个确定性算法,可以在指数时间内,直接算出或是搜寻出正确的答案呢?这就是著名的NP=P?的猜想。
解决这个猜想,无非两种可能,一种是找到一个这样的算法,只要针对某个特定NP完全问题找到一个算法,所有这类问题都可以迎刃而解了,因为他们可以转化为同一个问题。另外的一种可能,就是这样的算法是不存在的。那么就要从数学理论上证明它为什么不存在。
前段时间轰动世界的一个数学成果,是几个印度人提出了一个新算法,可以在多项式时间内,证明某个数是或者不是质数,而在这之前,人们认为质数的证明,是个非多项式问题。
可见,有些看来好象是非多项式的问题,其实是多项式问题,只是人们一时还不知道它的多项式解而已。
看了这段文献,也许会明白版本1中“NP类:已有指数时间算法的判定问题,”是断章取义的定义。但是对于NPC(NP-completeness)的理解和解决P =?NP问题的两条出路可能还不是那么清楚,那看一下1982年图灵奖获得者:斯蒂芬.库克(Stephen A. Cook)有关于NP完全性理论的奠基(来自《ACM图灵奖——计算机发展史的缩影》(高等教育出版社))的材料,也许就会更清楚些了:
1971年5月,他在ACM于俄亥俄州的 Shaker Heights举行的第三届计算理论研讨会上发表了那篇著名的论文:“定理证明过程的复杂性”(The Complexity of Theorem Proving Procedures),在这篇论文中,库克首次明确提出了NP完全性问题,并奠定了NP完全性理论的基础,所谓“NP完全性”(NP-completeness)问题是这样一个问题:由于P =?NP问题难以解决,库克就另辟途径,从NP类的问题中分出复杂性最高的一个子类,把它叫做NP完全类。库克证明,任取NP类中的一个问题,再任取NP完全类中的一个问题,则一定存在一个确定性图灵机上的具有多项式时间复杂性的算法,可以把前者转变成后者。这就表明,只要能证明NP完全类中有一个问题是属于P类的,也就证明了NP类中的所有问题都是P类的,即证明了P=NP。库克的这一研究成果为研究P=?NP的科学家们指明了一条捷径和一个方向,不必再像大海捞针似地去盲目探索了。虽然科学家们沿着库克指明的这条“捷径”仍在艰难地前进,至今没有达到光辉的终点(P=?NP的问题至今仍未有结论),但学术界公认库克的NP完全性理论是对计算复杂性理论的一个重大贡献。库克的论文只证明了命题演算的可满足性问题是NP完全的,但在它的启发下,卡普(R. Kap,1985年图灵奖获得者)在第二年就证明了21个有关组合优化的问题也是NP完全的,从而加强与发展了NP完全性理论。
库克在建立NP完全性理论时,为研究复杂性类之间的关系提出的方法,叫“复杂性归纳”(complexity reduction),用以比较问题的计算难度。库克所用的归约方法是多项式时间图灵归约,有时直接把它叫做库克归纳。其要点如下:假设所考虑的问题都已编码成字母表Σ上的语言(实例的集合)。设L1、L2是Σ上的两个语言,若存在以L2为oracle集的多项式时间图灵机M,其接受的语言为L1,则称L1多项式时间图灵机约到L2,记为L1≤prL2。这时,对X是否属于L1的判别可转化为至多|x|的多项式个元素是否属于L2的判别, 因此,l2εp便导致L1εp。从这种相对的意义上说,L1的计算不比L2难。≤Pr可以是定义在任何言类@上的一种二元前序关系,如果存在Lε@,对于任何L1ε@,都有L1≤PrL,则L就是@中(在多项式时间图灵归约下)“最困难的”,称其为@-T完全的。
因此,不严格的讲,NP完全问题是NP类中“最难”的问题,版本4的“NPC:如果某个问题是NP-HARD问题,同是它又是NP问题。那么,我们称它为NPC问题”定义的方式也许就来源于这种理解(NP完全问题是NP类中“最难”的问题)。同样,还有一层意思,也就是说它们是最可能不属于P类的:所有其它的NP问题都可以归约到这些NP完全问题。这一层面上出现了版本5有关于NPC的定义。
但是,从NPC问题的本意来看,其本质在于解出一个NPC就意味这可以解出所以的NP,NPC应该是指这类具有这样性质的NP问题的集合,转换只是一种解问题的手段,至于“难”和“最难”都是比较笼统的说法。如果说这种转换是NPC问题的必要和充分条件,那么版本5中的不应该是“都有π'”使得“π'∞π”,而是“任意NP问题π'都有π'∞π”,因为版本5中的“都有π'”只是给人“存在一些π',…”的意味。可惜自己不是学数学的,有关与数学具体的定义不是很了解。如果理解还有什么偏差的话请高手批评指教。
3.对与NP-HARD的说法
按版本4的说法(NP-HARD:从多项式规约的角度来看, 如果任何一个NP问题的都不会比某个问题L难,那么我们就说L是NP-HARD问题),通俗的说也就是一个比NP问题还要难的问题,但是这个问题不一定属于NP问题,即:不是NPC问题。
以下是看的一些参考材料,还有一些关于这些问题的花边,没时间拿出写了,贴出来吧,就算是参考文献吧。
主要参考文献:
1.P,NP,NPC问题 作者: boy 发表日期: 2006-05-29 20:19
http://kelab.hit.edu.cn/blog/blog.php?do_showone/tid_40.html
2.理论计算机初步:P vs NP - 问题概述©Zhang-Zi, August 23, 2006 @ 10:40 pm · Filed under Computer Science
http://zhiqiang.org/blog/412.html
3.理论计算机初步:P vs NP - 历史,现状和未来 同上
4.P/NP问题
http://baike.baidu.com/view/286218.htm
| 如何成为一个好的系统分析员 |
| 李华 系统分析员基本功 好的系统分析员都是从优秀的程序员中产生的,坚实的编程功底、丰富的经验是今后做系统分析的基础。 没有对系统本身进行过透彻剖析过,很难领会到其中一些难以言述的精华。但并不等于好的程序员就能够 成为好的系统分析员。 合理的知识结构。语言能力、文字表达能力、技术的全面性等是对系统分析员的基本要求。比如说c/s和3 层开发,如果仅仅对netscape公司的产品熟悉还不够,还需要了解比如微软等产品,并且要了解他们中产 生历史,发展思路,技术优劣,以应付各种穷追猛打的提问。但更重要的是,这是你为应用定制技术要求 的前提。 系统分析员思想 全局观念是系统分析员必须具备的观念。如果系统分析员设计时太注重细节,往往会陷入在某个问题上纠 缠不清的泥潭。(93年,我论文指导老师的一席话影响了我随后几年对软件开发的理解----今后计算机会 越来越快,多写几行代码少写代码无关紧要,最重要的是整体;一开始就错了,某个部份编得再好,也是 没有用的) 系统分析员要有面向用户的思想。系统分析员应当有能力将自己扮演成用户,来了解要交付的项目看起来 想什么样式,感觉想什么,从而了解用户的想法并挑选出合理部份去开发。从这个意义上说,系统分析员 才能获得有意义的见解去引导他的开发组成员。系统分析员头脑中要对项目结局有一个清楚的认识,并保 证项目不偏离方向。系统分析员要有根植于技术,高于技术思考问题的思想。纯粹的程序员通常对最终结 果考虑的不是很多,当一种新的技术在市场上出现时,他们对能否按时交付的考虑就比较少,而强烈希望 他们的计划能够建立在新的技术之上。因此,系统分析员的想法和行动要象一个用户,又要能够站在技术 的高度,成为真正的用户、程序员之间的代言人。 任务难度的预测能力 系统分析员要具备快速的任务难度预测能力以及具备快速确定开发小组人员构成和任务划分的能力。(我 将这条归为思想,而不是能力)昆虫自然会长出翅膀,而思想却需要长期的浸润。要做到这点,需要大量 的思考、学习。设计远比编程重要。当今软件业的发展,各种开发工具的出现,编程已经不是什么问题, 程序员的工作某种程度上讲是将别人现成的东西拼凑堆砌起来。系统分析员要清楚的认识到,现在大多数 程序员没有学会怎么去整体的了解一个系统,有些甚至不了解编程(这不是说他们不会写代码)。可视化 的开发工具加五花八门的控件,程序员可以偷点懒了。(这可不是夸大,我好几年的管理工作,接触过大 量的程序员)基于技术,跳出框架。基于现有技术结合用户需求思考问题,设计时跳出框架。 系统分析员的关键 获得信任。系统分析员最重要的素质是获得信任,这是成为优秀系统分析员的关键。成熟最为关键。成熟 可以为整个项目组提供正确的支持,能够理解技术怎样才能解决用户的需求。 系统分析员的准备工作 统一的各种文档模式,这其中包括今后软件变量、字段命名规则。我推荐用pb制定的规则做基础,通过改 造成为适合自身实用的标准。统一的文档管理。统一的分析软件。比如说rose(uml太规范,国内的软件 管理水平根本用不上,只不过尽量应用,你自己对系统分析的理解有好处) 方法是思想的放映,在具体方法上就不多说了。我托人从u$a弄到几本书,用于面向对象系统开发的使 用》、《面向对象的分析》、《项目管理》等都是很不错的,推荐大家看看。 我在拙作"在中国没有人懂计算机"里发了点牢骚,听说挨了部份人(习惯性的)骂。其实,bbs本来就是 发泄的地方,在这里从来就罕有有内容的文章。 自从"维纳斯"登陆深圳后,大家更着眼于从宏观看中国的it业了。中国it这棵小树,说实在的,长到今天 实在是不容易。一些人提出了"反对微软霸权"的口号,不少人呼唤中国"硅谷"的出现。微软的成功不是技 术的成功,更多的是商业运作的成功。中国it这棵树能长多高,取决于他所植根于的土壤。而现在的事实是,这片土壤实在是太贫瘠了!如果按我们现在的思路和搞法,是长不成大树,更别指望能结?quot;微 软","硅谷"这样丰硕的果实。如果说,我们的软件技术落后美国十年,我们的硬件制造技术则落后美国 二十年,我们的管理水平落后美国至少三十年。而最终决定发展速率的恰恰是我们的死穴──低劣的管理 水平。低劣的管理水平的形成的原因有着深厚的背景和多方面的原因。 系统分析工作是解决一个问题的工作,目标是将一个对计算机应用系统的需求转化成实际的物理实现,其中 复杂就复杂在实际的面太多.在系统分析过程之中注意问以下的问题,可能会所进行的系统分析设计工作有帮助 1)您所完成的系统目的是什么?注意不是功能要求,而是目的.也就是为什么要建设、为什么要现代建设。在考虑系统目的时,我更多的侧重于系统的最终目标考虑,因为一个系统不可能一下子完美,为系统留些 余地。 2)您所完成的系统有哪些方面参与,各方面的初衷是什么?那些人可能在系统建设中起重要作用,他们 会采取什么样的态度?你对他们有多少影响力?中国it行业的失败之一就是人"太年轻",一定要有领导的 支持,否则完蛋。不要认为自己对他们会有多少影响力,即便有,也要尽可能的认为是决策者再影响他 们。在中国,一个技术员,你算老几?说到这里我很悲哀。哪些人在系统中起重要作用并弄清楚他们的态 度,这点十分关键。 3)您的系统是否有一个明确的评价标准?最好从参与的各方面都进行考虑。不知道这样说对不对,在系 统建设之前,对你的程序员、对你的领导要有至少不同的两种评价。 4)你的系统设计思想是什么?是否能够得到各方面的认可。如果高明,对领导、对程序员都采用引导, 得到认可的最好办法,就是让他们认可他们自己的想法。(我力图这样做,但做得不好,系统分析员有一 点要学会韬光养晦,忍) 5)你对参与系统设计开发的人员了解吗?他们的特长在哪里,是否愿意与你合作,为什么?你对他们有 足够的影响力吗?软件发展到一定的程度,不是编程,不是数学,而是管理。 6)你的系统开发计划是否完善?你的计划表有明确的阶段吗?任何一阶段都应该怎样完成?如何对这一 阶段完成的情况进行评价? 7)你对所采用的系统开发方法以及工具是否熟悉?你的夥伴是否熟悉?事实上,不是每种好的工具都要 使用,也并不一定都要他们熟练掌握。提醒诸位一句,当你将方案做得可以不依赖某个程序员,你在程序 员面前就无信任可言,因为从此程序员将受到更大的生存压力。我坚决不在公司使用rose。 8)你所完成的系统是否有原型?计算机的或者物理的。 以上的几个问题都是在系统分析以及系统规划时涉及到的,供各位参考。 这文章很好,我的话是:"需求分析实际应该是问题分析"。含义是系统要解决的是问题。而不是用户提出 的需求。经常发现系统完成后,客户说"我的问题还没有解决"。可是,需求分析稿上的目标都搞定了。 既然是问题分析,所以,熟悉目标系统的知识就是必要的。甚至,可以说,一个好的系统分析员也应该是 好的业务专家。 我很高兴在这里遇到许多分析高手,可以交流分析中的问题。我赞同从来的观点。在中国作分析重要的是 人气,因为中国的企业级信息系统的建设在很大程度上可以说并非确有需求,而是迫于某种压力。用户在 很多时候考虑的不是系统的长远发展,而只是短期的成果,要求开发单位在很短的时间内完成一个很大的 系统的开发,没有时间对系统进行周密的分析,在这种情况下,很多开发商就会粗分析,粗设计,尽快进 入编码阶段,这样的系统的生命周期肯定不会很长。说了这么多,只是想说,系统分析员确实应是业务和 管理专家,并且需要有很好的语言组织能力,他需要根据问题域中存在的问题去尽力说服用户,引导用户 需求,毕竟,我们是专家,如果让用户牵着鼻子走,系统不会是成功的系统。(当然了,这要建立在用户 是可引导的前提下)本人拙见。 在理解和分析用户的需求时,应说服用户明白:建立计算机应用系统并不是简单地用计算机代替手工劳作,它更应该是管理思想的一次革命,是现用户模式的一次升华和提高。如果系统不能高于现实,开发的系统将长期陷入需求的反复修改,其软件的生命周期也短了。 |
[产品定位不容忽视]
有的小型软件公司在发展的过程中没有产品定位,总想着只要是软件项目就接,如果干不了,就转包给其他公司。实际上这样的想法对公司没多少好处。公司一定根据自己的能力和熟悉的环境,确定自己的核心产品,也就是对自身要深入了解。例如以前做过办公自动化项目,对这方面的业务很熟悉,就先在这方面下工夫,不必要赶时髦,想着实施ERP业务。如果人员大多对WEB开发感兴趣,那就在网站建设、电子商务方面寻求出路。
当然在公司初期要生存,做一些系统集成也可以,但公司的核心业务和次要业务要分明。随着公司的发展,逐步形成自己的核心竞争力。公司一定要制定出技术发展、企业发展的战略规划,向这个目标奋进。把公司做大做强固然好,但在初期能够很好地在竞争中得到生存发展或许对一些小型软件公司来说是最重要的。这种公司的发展规划是对市场和自身进行详细周到的分析得出的结果,如果不出现特别大的环境变化,就要坚持住,不要今天做这个行业的软件,明天做那个行业的软件。
[加强管理水平]
当小软件公司只有几个人的时候,不存在什么管理上、沟通上的问题,出现一些事情,大家一说就可以了。当随着人员的增加,管理问题就显得很重要了。我们深入了解他们的管理现状的时候,就会发现他们在管理过程中存在很多问题。例如,一般的软件公司员工在30人以下,大都设两个主要的部门:技术部、市场部,技术部主要负责软件的设计与开发,市场部负责市场的开拓与服务。但通过大量的项目实施可以看出,两个部门在沟通存在问题,很容易给项目的管理实施造成了很大障碍;另外在对技术部门的人员绩效考核上一般是发固定工资,一旦市场人员的工资高于开发人员时,技术部人员容易造成心理不平衡。随着软件公司的发展,公司规模的扩大会使这些问题更加突出。
由于公司规模小,可能管理制度不完善,随意管理的现象存在。最让员工头疼的是公司的负责人随便制定一些制度,又随意破坏一些制度,所以公司应当与员工一起商量,制定一些切实可行的规章制度,大家共同遵守。另外有时候感情管理很重要,多与公司员工讨论公司的未来和现在的处境,让员工把公司的未来看成是自己的未来。每个公司都有自己的发展规划,一定让员工知道公司的长期愿景,可能的话帮助每位员工进行职业生涯设计,让员工对公司和自己充满信心。公司最好有个综合管理部门——办公室,主要工作涉及到除了技术、市场之外所有工作,保证为技术和市场部门服好务,另外还要进行公司的绩效考核。
为了更好的了解各部门的工作,建议在公司内部建立一套办公自动化系统(OA),内容不要求很多,但重点是加强内部的沟通与交流,让大家方便联系,相互了解大家的工作进度。通过建立这样一个交流平台来解决管理问题,是很容易做到的,也是很有成效的。一般办公自动化系统都有电子邮件系统,它可以帮助大家很方便的传递信息,也是上下级沟通的一个好渠道,有时不好当面说的问题,可能通过EMAIL可以很容易地完成。系统中如果设有BBS就更好了,大家在闲暇时间可以对公司的管理、软件开发过程中的问题等等发表自己的见解,通过其中的内容,管理者可以改善管理,大家可以共同学习,共同提高,也可以通过BBS逐步建立起具有自己公司特色的企业文化。还有一点需要说明的是,最好在OA中加入对工作日志的管理,这样方便对员工的考核,也督促大家的工作。
[搞好人员管理]
小型软件也面临着人才流失的问题,目前软件行业流动率很高,往往出现人在项目在,人走项目瘫的局面。这包括两部分,一是市场人员的流失,二是技术人员的流失,都会给公司造成很大的影响。 为了避免市场人员的流动导致客户的流失,公司要加强对客户的管理。小型软件公司也要有客户关系管理系统,要对客户的情况了如指掌,对客户的沟通过程和进度也要控制。加强市场人员的工作协同,促进信息的共享。为了稳定技术核心人员的方式主要是报酬、发展和学习机会相结合。对于普通的编程人员需要做好档案的记录工作,比如软件的设计报告、测试报告、软件的客户需求报告等等要求尽量详细。尽管这样会占到软件编程的1/2时间,但是这样可以很好地保证项目的连续性。对软件开发人员要晓之以理,动之以情,把公司的美好前程多灌输给他们,让大家对自身的前途看好。更重要的还要让他们能够在公司得到发展,能在技术上得到提高,业务上得到拓展。
或许小型软件很难招聘到高层次、高水平的人才,这样就需要对员工的培训上多下工夫。另外公司要创造机会和渠道让大家多积累经验、多提建议,把大家的知识共享出来,从而提高整体水平的提升。例如对于市场人员,把他们的一些市场调查报告放在OA上,让技术人员更加深刻的了解客户的需要。市场人员可以让技术人员对解决方案提建议,把成熟的解决方案放在网上,大家可以借鉴。这样时间长了,可能公司发现工作效率得到了提高,公司人员的工作能力也得到了提高,人员的配合上也会得到改善。通过对知识共享的管理,更重要的是让员工养成一种团队意识,让员工的自主管理意识加强。
[保证正规化运作]
小型软件公司虽然规模小,但也是公司,所以就要公司化运作。在一些事情的处理上,多征求大家的意见,如果大家以公司的发展视为自己的发展,就会对公司提出自己的合理化建议。一般员工也会很容易地沟通,在一些事情也能够发表自己的建议。公司在处理员工提出的问题上也要斟酌,不要随意马虎,否则很容易伤一人而惹众怒。
在公司正规化运作方面有几点与大家探讨,或许对大家有所启发。由于技术人员和市场人员缺少沟通,对一些项目的实施造成很多麻烦。技术人员以技术研发为主,对市场的理解甚少,有时候可能无法理解市场的需求。市场人员虽然了解市场需求,但在和客户接触的过程中又不能很好的把握技术的实现可能性。这样一来,建议最好针对一些项目成立项目组,设立项目经理,项目经理全权负责整个项目的开展。项目组中要求既有技术研发人员,又有相关市场经验的人。项目组的考核与利润挂钩,通过这种方式可能会解决市场和技术研发沟通的问题。
今天客户服务至上的原则对小型软件公司显得尤为重要,因为小型软件公司的客户大多是小型企业,这样的客户实际上对自己真正的需要不大明确,对软件功能的要求提的比较笼统。首先市场部的人员应该有意识的引导客户,向有利于技术实现的方面发展。同时注意适当的培训客户,让他更多理解公司的技术和可以实现的方式,这样才能真正留住客户和完成技术。虽然客户规模小,但是客户群大,如果服务到位了,在客户中的信誉就会提高。从而客户可以宣传你的产品,从而公司可以从客户群得到更多的客户。另外现在软件公司的发展趋势也是服务,现在服务开始收费大家已经接受了。软件就是服务的口号,软件公司也会慢慢领会到的。
小型软件公司要想在竞争中立于不败之地,要做的工作很多很多,上面提及的一些问题或许对于公司的发展是再平常不过的了。可还是有很多软件公司不从中总结经验教训,为了眼前一些短期利益,有点软件公司就会放弃自己原定目标,有的软件就可能放弃临时的利益去追求公司更大的发展。小型软件公司只要多动脑筋,遵循规律,多总结,就会从众多的软件公司中脱颖而出,找到自己的出路。
组态软件:一般英文简称有三种分别为HMI/MMI/SCADA,对应全称为Human and Machine Interface/Man and Machine Interface /Supervisory Control and Data Acquisition,中文翻译为:人机界面/监视控制和数据采集 软件。目前组态软件的发展迅猛,已经扩展到企业信息管理系统,管理和控制一体化,远程诊断和维护以及在互联网上的一系列的数据整合。
1. 组态软件产生的背景
“组态”的概念是伴随着集散型控制系统(Distributed Control System简称DCS)的出现才开始被广大的生产过程自动化技术人员所熟知的。在工业控制技术的不断发展和应用过程中,PC(包括工控机)相比以前的专用系统具有的优势日趋明显。这些优势主要体现在:PC技术保持了较快的发展速度,各种相关技术已臻成熟;由PC构建的工业控制系统具有相对较低的拥有成本;PC的软件资源和硬件资丰富,软件之间的互操作性强;基于PC的控制系统易于学习和使用,可以容易地得到技术方面的支持。在PC技术向工业控制领域的渗透中,组态软件占据着非常特殊而且重要的地位。
组态软件是指一些数据采集与过程控制的专用软件,它们是在自动控制系统监控层一级的软件平台和开发环境,使用灵活的组态方式,为用户提供快速构建工业自动控制系统监控功能的、通用层次的软件工具。组态软件应该能支持各种工控设备和常见的通信协议,并且通常应提供分布式数据管理和网络功能。对应于原有的HMI(人机接口软件,Human Machine Interface)的概念,组态软件应该是一个使用户能快速建立自己的HMI的软件工具,或开发环境。在组态软件出现之前,工控领域的用户通过手工或委托第三方编写HMI应用,开发时间长,效率低,可靠性差;或者购买专用的工控系统,通常是封闭的系统,选择余地小,往往不能满足需求,很难与外界进行数据交互,升级和增加功能都受到严重的限制。组态软件的出现,把用户从这些困境中解脱出来,可以利用组态软件的功能,构建一套最适合自己的应用系统。随着它的快速发展,实时数据库、实时控制、SCADA、通讯及联网、开放数据接口、对I/O设备的广泛支持已经成为它的主要内容,随着技术的发展,监控组态软件将会不断被赋予新的内容。
2. 组态软件在我国的发展及国内外主要产品介绍
组态软件产品于80年代初出现,并在80年代末期进入我国。但在90年代中期之前,组态软件在我国的应用并不普及。究其原因,大致有以下几点:
①国内用户还缺乏对组态软件的认识,项目中没有组态软件的预算,或宁愿投入人力物力针对具体项目做长周期的繁冗的上位机的编程开发,而不采用组态软件;
②在很长时间里,国内用户的软件意识还不强,面对价格不菲的进口软件(早期的组态软件多为国外厂家开发),很少有用户愿意去购买正版。
③当时国内的工业自动化和信息技术应用的水平还不高,组态软件提供了对大规模应用、大量数据进行采集、监控、处理并可以将处理的结果生成管理所需的数据,这些需求并未完全形成。
随着工业控制系统应用的深入,在面临规模更大、控制更复杂的控制系统时,人们逐渐意识到原有的上位机编程的开发方式。对项目来说是费时费力、得不偿失的,同时,MIS(管理信息系统,Management Information System)和CIMS(计算机集成制造系统,Computer Integrated Manufacturing System)的大量应用,要求工业现场为企业的生产、经营、决策提供更详细和深入的数据,以便优化企业生产经营中的各个环节。因此,在1995年以后,组态软件在国内的应用逐渐得到了普及。下面就对几种组态软件分别进行介绍。
①InTouch:Wonderware的InTouch软件是最早进入我国的组态软件。在80年代末、90年代初,基于Windows3.1的InTouch软件曾让我们耳目一新,并且InTouch提供了丰富的图库。但是,早期的InTouch软件采用DDE方式与驱动程序通信,性能较差,最新的InTouch7.0版已经完全基于32位的Windows平台,并且提供了OPC支持。
②Fix:Intellution公司以Fix组态软件起家,1995年被爱默生收购,现在是爱默生集团的全资子公司,Fix6.x软件提供工控人员熟悉的概念和操作界面,并提供完备的驱动程序(需单独购买)。Intellution将自己最新的产品系列命名为iFiX,在iFiX中,Intellution提供了强大的组态功能,但新版本与以往的6.x版本并不完全兼容。原有的Script语言改为VBA(Visual Basic For Application),并且在内部集成了微软的VBA开发环境。遗憾的是,Intellution并没有提供6.1版脚本语言到VBA的转换工具。在iFiX中,Intellution的产品与Microsoft的操作系统、网络进行了紧密的集成。Intellution也是OPC(OLE for Process Control)组织的发起成员之一。iFiX的OPC组件和驱动程序同样需要单独购买。
③Citech:CiT公司的Citech也是较早进入中国市场的产品。Citech具有简洁的操作方式,但其操作方式更多的是面向程序员,而不是工控用户。Citech提供了类似C语言的脚本语言进行二次开发,但与iFix不同的是,Citech的脚本语言并非是面向对象的,而是类似于C语言,这无疑为用户进行二次开发增加了难度。
④WinCC:Simens的WinCC也是一套完备的组态开发环境,Simens提供类C语言的脚本,包括一个调试环境。WinCC内嵌OPC支持,并可对分布式系统进行组态。但WinCC的结构较复杂,用户最好经过Simens的培训以掌握WinCC的应用。
⑤组态王:组态王是国内第一家较有影响的组态软件开发公司(更早的品牌多数已经湮灭)。组态王提供了资源管理器式的操作主界面,并且提供了以汉字作为关键字的脚本语言支持。组态王也提供多种硬件驱动程序。
⑥Controx(开物):华富计算机公司的Controx2000是全32位的组态开发平台,为工控用户提供了强大的实时曲线、历史曲线、报警、数据报表及报告功能。作为国内最早加入OPC组织的软件开发商,Controx内建OPC支持,并提供数十种高性能驱动程序。提供面向对象的脚本语言编译器,支持ActiveX组件和插件的即插即用,并支持通过ODBC连接外部数据库。Controx同时提供网络支持和WevServer功能。
⑦ForceControl(力控):大庆三维公司的ForceControl(力控)从时间概念上来说,力控也是国内较早就已经出现的组态软件之一。只是因为早期力控一直没有作为正式商品广泛推广,所以并不为大多数人所知。大约在93年左右,力控就已形成了第一个版本,只是那时还是一个基于DOS和VMS的版本。后来随着Windows3.1的流行,又开发出了16位Windows版的力控。但直至Windows95版本的力控诞生之前,他主要用于公司内部的一些项目。32位下的1.0版的力控,在体系结构上就已经具备了较为明显的先进性,其最大的特征之一就是其基于真正意义的分布式实时数据库的三层结构,而且其实时数据库结构可为可组态的活结构。在1999~2000年期间,力控得到了长足的发展,最新推出的2.0版在功能的丰富特性、易用性、开放性和I/O驱动数量,都得到了很大的提高。在很多环节的设计上,力控都能从国内用户的角度出发,即注重实用性,又不失大软件的规范。另外,公司在产品的培训、用户技术支持等方面投入了较大人力,相信在较短时间内,力控软件产品将在工控软件界形成巨大的冲击。
其他常见的组态软件还有GE的Cimplicity,Rockwell的RsView,NI的LookOut,PCSoft的Wizcon以及国内一些组态软件通态软件公司的MCGS,也都各有特色。
3. 组态软件的功能特点发展方向
目前看到的所有组态软件都能完成类似的功能:比如,几乎所有运行于32位Windows平台的组态软件都采用类似资源浏览器的窗口结构,并且对工业控制系统中的各种资源(设备、标签量、画面等)进行配置和编辑;都提供多种数据驱动程序;都使用脚本语言提供二次开发的功能,等等。但是,从技术上说,各种组态软件提供实现这些功能的方法却各不相同。从这些不同之处,以及PC技术发展的趋势,可以看出组态软件未来发展的方向。
3.1数据采集的方式
大多数组态软件提供多种数据采集程序,用户可以进行配置。然而,在这种情况下,驱动程序只能由组态软件开发商提供,或者由用户按照某种组态软件的接口规范编写,这为用户提出了过高的要求。由OPC基金组织提出的OPC规范基于微软的OLE/DCOM技术,提供了在分布式系统下,软件组件交互和共享数据的完整的解决方案。在支持OPC的系统中,数据的提供者作为服务器(Server),数据请求者作为客户(Client),服务器和客户之间通过DCOM接口进行通信,而无需知道对方内部实现的细节。由于COM技术是在二进制代码级实现的,所以服务器和客户可以由不同的厂商提供。在实际应用中,作为服务器的数据采集程序往往由硬件设备制造商随硬件提供,可以发挥硬件的全部效能,而作为客户的组态软件可以通过OPC与各厂家的驱动程序无缝连接,故从根本上解决了以前采用专用格式驱动程序总是滞后于硬件更新的问题。同时,组态软件同样可以作为服务器为其他的应用系统(如MIS等)提供数据。OPC现在已经得到了包括Interllution、Simens、GE、ABB等国外知名厂商的支持。随着支持OPC的组态软件和硬件设备的普及,使用OPC进行数据采集必将成为组态中更合理的选择。
3.2脚本的功能
脚本语言是扩充组态系统功能的重要手段。因此,大多数组态软件提供了脚本语言的支持。具体的实现方式可分为三种:一是内置的类C/Basic语言;二是采用微软的VBA的编程语言;三是有少数组态软件采用面向对象的脚本语言。类C/Basic语言要求用户使用类似高级语言的语句书写脚本,使用系统提供的函数调用组合完成各种系统功能。应该指明的是,多数采用这种方式的国内组态软件,对脚本的支持并不完善,许多组态软件只提供IF…THEN…ELSE的语句结构,不提供循环控制语句,为书写脚本程序带来了一定的困难。微软的VBA是一种相对完备的开发环境,采用VBA的组态软件通常使用微软的VBA环境和组件技术,把组态系统中的对象以组件方式实现,使用VBA的程序对这些对象进行访问。由于VisualBasic是解释执行的,所以VBA程序的一些语法错误可能到执行时才能发现。而面向对象的脚本语言提供了对象访问机制,对系统中的对象可以通过其属性和方法进行访问,比较容易学习、掌握和扩展,但实现比较复杂。
3.3组态环境的可扩展性
可扩展性为用户提供了在不改变原有系统的情况下,向系统内增加新功能的能力,这种增加的功能可能来自于组态软件开发商、第三方软件提供商或用户自身。增加功能最常用的手段是ActiveX组件的应用,目前还只有少数组态软件能提供完备的ActiveX组件引入功能及实现引入对象在脚本语言中的访问。
3.4组态软件的开放性
随着管理信息系统和计算机集成制造系统的普及,生产现场数据的应用已经不仅仅局限于数据采集和监控。在生产制造过程中,需要现场的大量数据进行流程分析和过程控制,以实现对生产流程的调整和优化。现有的组态软件对大部分这些方面需求还只能以报表的形式提供,或者通过ODBC将数据导出到外部数据库,以供其他的业务系统调用,在绝大多数情况下,仍然需要进行再开发才能实现。随着生产决策活动对信息需求的增加,可以预见,组态软件与管理信息系统或领导信息系统的集成必将更加紧密,并很可能以实现数据分析与决策功能的模块形式在组态软件中出现。
3.5对Internet的支持程度
现代企业的生产已经趋向国际化、分布式的生产方式。Internet将是实现分布式生产的基础。组态软件能否从原有的局域网运行方式跨越到支持Internet,是摆在所有组态软件开发商面前的一个重要课题。限于国内目前的网络基础设施和工业控制应用的程度,笔者认为,在较长时间内,以浏览器方式通过Internet对工业现场的监控,将会在大部分应用中停留于监视阶段,而实际控制功能的完成应该通过更稳定的技术,如专用的远程客户端、由专业开发商提供的ActiveX控件或Java技术实现。
3.6组态软件的控制功能
随着以工业PC为核心的自动控制集成系统技术的日趋完善和工程技术人员的使用组态软件水平的不断提高,用户对组态软件的要求已不像过去那样主要侧重于画面,而是要考虑一些实质性的应用功能,如软件PLC,先进过程控制策略等。
软PLC产品是基于PC机开放结构的控制装置,它具有硬PLC在功能、可靠性、速度、故障查找等方面的特点,利用软件技术可将标准的工业PC转换成全功能的PLC过程控制器。软PLC综合了计算机和PLC的开关量控制、模拟量控制、数学运算、数值处理、通信网络等功能,通过一个多任务控制内核,提供了强大的指令集、快速而准确的扫描周期、可靠的操作和可连接各种I/O系统及网络的开放式结构。所以可以这样说,软PLC提供了与硬PLC同样的功能,而同时具备了PC环境的各种优点。目前,国际上影响比较大的产品有:法国CJ International公司的ISaGRAF软件包、PCSoft International公司的WinPLC、美国Wizdom Control Intellution公司的Paradym-31、美国Moore Process Automation Solutions公司ProcessSuite、美国Wonder ware Controls公司的InControl、SoftPLC公司的SoftPLC等。国内推出软PLC产品的组态软件还不见有,国内组态软件要想全面超过国外的竞争对手,就必须搞创新,推出类似功能的产品。
随着企业提出的高柔性、高效益的要求,以经典控制理论为基础的控制方案已经不能适应,以多变量预测控制为代表的先进控制策略的提出和成功应用之后,先进过程控制受到了过程工业界的普遍关注。先进过程控制(Advanced Process Control,APC)是指一类在动态环境中,基于模型、充分借助计算机能力,为工厂获得最大理论而实施的运行和控制策略。先进控制策略主要有:双重控制及阀位控制、纯滞后补偿控制、解耦控制、自适应控制、差拍控制、状态反馈控制、多变量预测控制、推理控制及软测量技术、智能控制(专家控制、模糊控制和神经网络控制)等,尤其智能控制已成为开发和应用的热点。目前,国内许多大企业纷纷投资,在装置自动化系统中实施先进控制。国外许多控制软件公司和DCS厂商都在竞相开发先进控制和优化控制的工程软件包。据资料报道,一个乙烯装置投资163万美元实施先进控制,完成后预期可获得效益600万美元/年。从上可以看出能嵌入先进控制和优化控制策略的组态软件必将受到用户的极大欢迎。
4.结束语
用户的需求促使技术不断进步,在组态软件上这种趋势体现得尤为明显。未来的组态软件将是提供更加强大的分布式环境下的组态功能、全面支持ActiveX、扩展能力强、支持OPC等工业标准、控制功能强、并能通过Internet进行访问的开放式系统。
HMI是Human Machine Interface的简称。
HMI其实广义的解释就是“使用者与机器间沟通、传达及接收信息的一个接口”。
举个例子来说,在一座工厂里头,我们要搜集工厂各个区域的温度、湿度以及工厂中机器的状态
等等的信息透过一台主控器监视并记录这些参数,并在一些意外状况发生的时候能够加以处理。
这便是一个很典型的SCADA/HMI的运用,一般而言,HMI系统必须有几项基本的能力:
实时的资料趋势显示——把撷取的资料立即显示在屏幕上。
自动记录资料——自动将资料储存至数据库中,以便日后查看。
历史资料趋势显示——把数据库中的资料作可视化的呈现。
报表的产生与打印——能把资料转换成报表的格式,并能够打印出来。
图形接口控制——操作者能够透过图形接口直接控制机台等装置。
警报的产生与记录——使用者可以定义一些警报产生的条件,
比方说温度过度或压力超过临界值,在这样的条件下系统会产生警报,通知作业员处理。
|
|