实时数据库简介

实时数据库简介

1.前言 
一提到数据库，大家肯定会想到SQL Server、Oracle等关系型数据库。实际上，数据库的种类非常多，在计算机发展的历史上，存在着多种类型的数据库。
早期，关系型数据库与层次型数据库、网络型数据库并驾齐驱，但关系型数据库依靠其描述简单、实现容易等特点，在竞争中取得了胜利，在上世纪90年代初期，从Foxpro、Access到Oracle、Informix、SyBase、SQL server，关系型数据库一统天下。
但在特定的应用领域中，关系型数据库并不能完美表现，于是，产生了新的数据库类型：在协同办公领域中使用的文档型数据库（如NOTES）,在嵌入式应用领域中使用的嵌入式数据库（如SQLite），在工业监控领域使用的实时数据库（如PI），等等。
本文章将对实时数据库进行简单的介绍。
2.在工业监控领域中，数据库应用的特点 
工业监控系统的定义非常大，所有需要对运行设备进行自动化监视、控制的系统都可以定义为工业监控系统，这里面就包括火电厂厂级监控系统（SIS），在这类应用领域中，数据库应用有如下特点：
 测点数量多
一个新建300WM的火电厂的SIS系统，需要处理的测点数超过了10000点，这些测点的变化周期通常在1秒钟之内，也就是说，需要将超过10000点的数据在1秒钟之内保存到数据库中。
 存储量大
实时数据库的核心就是对大量的实时信息进行处理，由于成年累月的数据将占据大量的硬盘空间。例如对于 1万点的系统，每 1秒钟存储一次，每次单点占用 8个字节，那么保存 10年的数据量将有 10000*8*10*365*86400=25228800000000字节，也就是 23TGB。若用 80GB的硬盘存放，需要存放 293块硬盘！ 
 时效性强
每个需要处理的测点的值都与时间相关，一秒钟之后的数据与一秒钟之前的数据可能就不一样了，因此，在保存测点值的同时，必须通过某种方法将其对应的时间也纪录起来。
3.不选择关系型数据库的理由 
关系型数据库，较难处理工业控制领域的数据。主要原因是：
 插入速度慢
一般关系型数据库是基于事务处理的，在处理失效后，还要回滚作业。所以至少要存放两处，该机制使速度较慢；既使用今日的Intel P4 双至强类CPU，在对2000 个测点进行插入时也用占用10s 以上的时间。而工业监控系统需要面对的是数万点的实时数据以秒级的间隔存放数据。
 维护困难
商用数据库为了保证完整性，所有的内容往往放在一个文件内，这对海量数据的存放维护发生困难。如果有一个200G 的数据库，完全备份就可能要一天。备份文件中有一个错误就可能导致200G 的备份文件失效，所以不实用。
 不能满足实时应用的需求
用数据库存放实时数据据及查询方式不能满足实时应用的需要。一个简单的例子是假定以1 秒为间隔存放好了数据，一周有数据604800 组，但是现要以60 秒为间隔取出其中10080 组或者以等间隔原则取出8888 组，标准SQL 语法就较难实现。
因此，工业监控领域以及电厂SIS应用领域，必须寻找适合实时应用需要的实时数据库系统。
4.实时数据库的压缩算法介绍 
实时数据库系统的技术核心在于数据压缩。需要将数据经压缩后再存入硬盘，当需要用数据时再解压缩硬盘上的数据。目前用于国内外实时数据库上的压缩算法通常分为两类：无损压缩和有损压缩。
4.1 无损压缩
大多数信息的表达都存在着一定的冗余度，通过采用一定的模型和编码方法，可以降低这种冗余度。Huffman编码是无损压缩中非常著名的算法之一。WinRar和WinZip等软件都采用了类似Huffman编码的压缩方式。这些压缩方法的共同特点是：压缩和解压过程中，信息不会发生变化。
在实时数据库中，也可以采用这些无损压缩技术，但是在实现时，必须要考虑压缩和解压缩的效率，如果某个压缩算法的压缩比非常高，但是其解压的速度非常慢，则肯定不能用于实时数据库中，否则，人们在查询数据时，会等待得失去耐心。
4.2 有损压缩
相对于无损压缩，有缩压缩肯定会丢失一些信息，但必须要保证这些丢失的信息不能影响系统数据的精度。大家在其它领域中也遇到过有损压缩的应用，比如：JPG图像压缩就是一种有损压缩，MP3声音压缩也是一种有损压缩。
在实时数据库中，有损压缩主要有两种方法：死区压缩和趋势压缩。
 死区压缩
所谓死区就是定义某一测点的值不变的范围。采用死区压缩就是记录该点死区之外的数据值。例如有一测点 A，定义其死区为 1%，上次记录的测点值为 110.00，那么此次采集的测点值为 111.00，那么两者差值(111-110)/110<1%，那么认为此次测点值在该点的死区范围内，则认为不变化，即不记录。若下一次测点值为 120.00，那么两者差值(120-110)/110>1%，那么认为此次测点值在该点的死区范围外，则认为变化，记录。
 趋势压缩
趋势压缩，是根据测点的阶段性趋势进行压缩，原则上只记录满足趋势条件的起点和终点。PI的旋转门压缩技术是该类算法的典范。
 
一般的趋势压缩如上图所示，T1到 T2时刻某测点的值保持者该趋势，那么在此趋势上下的两条容差线将是下一时刻点的死区范围，若下一时刻 T3在此两条两条容差线之间，那么不记录此值，两条容差线将适用于下一时刻，若下一时刻 T4在此两条两条容差线之外，则记录该值，趋势发生改变，两条容差线将发生改变，下一时刻测点将按改变后的容差线来判断。
5.实时数据库的访问方式
 使用实时数据库提供的API
这种方式效率最高，也最简单。
 使用ODBC
大部分实时数据库提供了标准的ODBC接口，也提供了SQL查询语言，通过这些方法，用户可以将实时数据库当作一个标准的数据库来使用。但这种方法速度较慢，且不能体现实时数据的全部优势。
 使用OPC方式（OLE for Process Control）
因为太多的数据库和DCS使用自己的API方式存取数据，无法做到算法的通用，因为工业监控领域提出了一个标准的存取接口，这就是OPC，如今有超过两百家产商加入到OPC组织中，声势浩大。
6.可供选择的实时数据库产品 
目前进入国内市场比较成熟的实时数据库产品如下所列：
 美国OSIsoft公司，PI；
 美国Wonderware公司，IndustrialSQL Server，简称INSQL；
 美国 GE,Intellution公司，iHistorian；
 美国 InStep公司，eDNA；
 美国HONEYWELL公司，Process History Database，简称PHD ；
 美国AspenTech公司，InfoPlus；
总的来说，国外实时数据库产品在工业监控行业占垄断地位。其中OSIsoft公司的PI采用了旋转门压缩专利技术和独到的二次过滤技术，使进入到PI数据库的数据经过了最有效的压缩，极大地节省了硬盘空间，是效率最高，使用最简单，使用最广泛的实时数据库。因为其杰出的性能，PI已经多次提高了它的价格。 
7.总结 
实时数据库在SIS系统中起着非常重要的作用，是SIS系统存贮数据的基础。实时数据库是一种特殊类型的数据库系统，但它有许多与关系型数据库存在差异。只有理解了这些相同之处和差异部分，才能对实时数据库有更深地了解。

研究现状与发展。
    目前在国内比较流性的国外实时数据库产品有Wonderware公司的Industrial SQL，OSIsoft公司的PI  ，AspenTech公司的 IP21 (

InfoPlus 。21 )。以5000点数据库和20客户端应用为例，几个数据库价格分别是：

PI----10万美元，每个接口6000美元，OPC接口收费；

InfoPlus.21----11万美元，每个接口1万美元，OPC接口不收费；
Industrial SQL Server----6.5万美元，每个IDAS1200美元，OPC Link免费。

     实时数据数据库产品
      PI将所有数据存于专有数据库中，对于过程数据的存储模式，每个点只有6个域可以由用户定义。PI是纯实时数据库，如果要实现企业更高级的应用还要配备关系型数据库。
      PI采用了旋转门压缩专利技术和独到的二次过滤技术，使进入到PI数据库的数据经过了最有效的压缩，极大地节省了硬盘空间。据计算，每秒1万点数据存储一年，仅需要4G的空间，即一只普通硬盘也可存贮五到十年的数据。是效率最高，使用最简单，使用最广泛的实时数据库，因为其杰出的性能，PI已经多次提高了它的价格，而且PI在其文档中公开了它的各种算法，比如上面提到的旋转门压缩和二次过滤。
 
    OSI公司没有提供PI服务器软件和客户端软件汉化版本，但是据说在开发中，可以看见DataLink的某个汉化版本。国内某些公司也在为客户做授权的汉化工作。

     系统性能
    每个PI服务器可容纳150万点(高端服务器)，在PI的高端产品服务器中可以处理每秒钟150万点的数据。在客户端软件ProcessBook上，可以在秒级时间内从2年或3年历史中取到1000点数据。

    参考OSI公司提供的数据：实时信息点的数据值1天的平均变化次数为500，每个信息点所占的存储空间为3个字节，那1万个点在线存储1年所需的存储空间是：
变化次数 × 单点存储空间 × 信息点数 × 1年的天数 = 总空间要求
500 × 3 × 10000 × 365 = 5.475GB

     当然，硬盘很便宜，但是节约空间不是我们的出发点，关键是快速回放数据。

    设备接口支持
OSI公司提供全球600多种DCS接口软件，同时可以支持OPC数据采集，使得PI数据库成为企业生产控制系统与管理信息系统连接的桥梁。

客户端工具
PI-ProcessBook：组织和显示过程信息，提供流程图、实时和历史趋势，包含VBA编程环境。
Pi-datalink:Excel 内嵌的宏。为最终用户提供了非常灵活的过程数据分析工具。可以提供用VBA来建各种所需的数学分析，可提供了最常规分析工具，包括：平均值、移动平均、几何平均、标准偏差、累计值等等。
PI-Batch：生产批处理程序。
PI-ML：手动录入终端（提供软件或硬件两种形式）。
PI－ ACE：允许用户写方程式。在捕获相似的数据集时，可以不用费力地重复使用这些方程式。
PI ICE：适于企业级实时绩效管理的最有创新意义的web应用。
PI ActiveView：无缝地给web提供现有的PI ProcessBook显示。
PI告警视图：汇总PI 告警服务器信息，以分层次的树形结构向任意个现场客户或场外客户显示那些数据。
PI批视图：在Windows台式电脑计算机上显示PI 批数据。
PI系统管理工具：一套通过客户的PC机对PI系统实施管理的应用程序。
PI模块数据库：将PI系统中的内容分成有用的组，帮助组织实时数据，储存参数或规格，并使它们随时可以用于程序和显示中。
RLINK：生产数据（PI）与SAP R/3、JD Edwards OneWorld、MRO Software Maximo和Indus International PassPort/EMPAC等ERP或EAM（企业资产管理）系统之间的一个双向网关。

 

二次开发工具
PI提供API，SDK, PI ODBC & PI OLEDB二次开发工具实现从数据库读取数据或写入数据到实时数据库中。另外，PI的客户端ProceBook中内嵌了VBA，方便对ProceBook功能的扩充和客户化。

PI API (Application Programming Interface，应用程序开发接口)
PI-API是一组C语言函数，提供了对PI系统进行访问的通用编程接口，应用程序可以通过调用PI-API函数访问或操作PI系统。许多PI的客户端软件，包括PI ProcessBook、PI

DataLink、PI ProfileView等，都是通过PI-API与PI服务器通信。用户可以在UNIX,WINDOWS平台上调用。

PI SDK（Software Development Kit，软件开发包）
PI SDK是PI提供的另一个编程工具集，用以访问PI服务器以及相关子系统。它采用微软ActiveX技术，内含一个ActiveX进程内组件，一个ActiveX控件和其他一些支持代码库，如

在线文档、示例代码、支持文档等。ActiveX基于COM组件技术，在Microsoft Windows平台下具有开发语言无关性特点。用户可以在开发简便的。NET中使用PI SDK访问PI服务器，

也可以在高效的C++中使用，以及在其他所有支持COM技术的开发工具中使用PI SDK。

PI ODBC & PI OLEDB

ODBC是数据库领域的一个开放的工业标准。OLEDB是微软基于COM的一个数据库访问接口标准。使用PI ODBC和PI OLEDB，用户能够像访问关系数据库一样访问PI系统。基于PI ODBC

或PI OLEDB的数据接口程序和客户端应用程序，可利用标准的SQL语句访问PI数据库，包括PI Archive、PI Point Database或其他配置数据。

国内用户
OSI将其数据库定位于企业信息化集成平台，专注于实时数据软件的研发和服务，主要用于大型流程行业用户，如电力、石油、化工和冶金等。目前中国使用PI软件的企业达到一

百多家，主要集中在电力、石油、化工行业，国内冶金行业用户有唐山钢铁公司厂、太原钢铁集团第2炼钢厂、石家庄钢铁公司等。

实时数据库的简介（初稿） 关系数据库使用得比较广，为大部分人所熟悉，以至于谈到数据库，缺省情况下指的就是关系数据库，但实际上还有一些其他种类的数据库在生产生活中被广泛使用，比如我将谈到的实时数据库，它们用在要求非常严格、数据量非常大的生产工控中。

【要点】 当今国际国内广泛使用的实时数据库只有三个产品： a. 美国OSI公司的 PI ( Plant Information System ) b. 美国HONEYWELL公司的 PHD ( Process History Database ) c. 美国AspenTech公司的 IP21 ( InfoPlus .21 )

这些实时数据库的价格是非常昂贵的，以百万人民币为单位，但是它们不全是以套也不全是以点(可容纳的数据点)为单位来出售，所以无法数字化的比较其价格。因为工作的关系，我有幸能接触到这三种数据库，在此对它们做一个比较。

1. PI 采用了旋转门压缩专利技术和独到的二次过滤技术，使进入到PI数据库的数据经过了最有效的压缩，极大地节省了硬盘空间。据计算，每秒1万点数据存储一年，仅需要4G的空间，即一只普通硬盘也可存贮五到十年的数据。是效率最高，使用最简单，使用最广泛的实时数据库，因为其杰出的性能，PI已经多次提高了它的价格，确实不坠OSI的名号，而且PI在其文档中公开了她的各种算法，比如上面提到的旋转门压缩和二次过滤。

2. PHD HONEYWELL占据了DCS大部分份额，因此PHD使用得也比较广泛，PHD在内部其实使用了Oracle关系数据库，因此购买PHD就必须先购买Oracle。因为 PHD内部使用Oracle简化了开发量 和 Oracle的性能限制比较严重，所以 PHD 的价格在这三种数据库最低，算不上正宗的实时数据库。但不要以为PHD内部使用Oracle就认为Oracle很强，如果直接使用Oracle，只要两三秒的时间，巨大的数据量就会令它崩溃。HONEYWELL其志不在实时数据库这一块，而是她的DCS。

3. IP21 IP21基本上还未进入中国市场，它正在通过先期赠送的办法打开中国市场。 在评价IP21之前，我需要先申明“我对IP21的看法只是个人看法，不是任何产品的托儿”。 IP21是我见过的最差的关系数据库，也是我见过的最差的一个软件， a. 其软件的安装程序的运行需要一个硬狗，这种小气的做法和PI公开算法的做法没法比，问题还在于它的这条狗经常会死翘翘。 b. 其软件的安装即使是其公司的专业员工也不能保证安装成功，10台计算机让它的专业员工来安装大约只能成功一两台。 c. 其软件的安装盘只有一张，但这一张盘需要安装四个小时以上，中途不停地看到在安装某个版本的Java解释器，其后它们又被删除。 d. 没有实现真正的自动安装，在安装之前它们的工程师需要在计算机上修改不少的文件。 e. 安装中途如果出现错误是不立即报告的，需要四个小时之后安装完毕才能看到安装失败的字样，但也仅仅只能知道安装失败，不知道在哪一步安装失败。 f. 管理维护软件非常的复杂，除非有人愿意牺牲以后的前途来学习它，否则就只能让它自己的员工来鼓弄。 g. 运行效率非常低下，而且占用系统资源非常严重，一台服务器只能给一个IP21使用。

【要点】 实时数据库的访问方式 a. 使用自己的API，这种方式效率最高，其实也最简单。 b. 使用ODBC，这种方式其实没有多大作用，因为实时数据库不同于关系数据库，ODBC没有太大的用武之地，所以在使用ODBC时有非常多的限制，大部分功能并不支持ODBC方式。 c. 使用OPC方式（OLE for Process Control） 因为太多的数据库和DCS使用自己的API方式存取数据，无法做到算法的通用，因为提出了一个标准的存取接口，这就是OPC，如今有超过两百家产商加入到OPC组织中，声势浩大，包括臭名昭著的M$，之所以讲M$臭名昭著是因为M$强制性的在这个标准的存取接口中使用了COM/DCOM，令OPC只能在windows下使用，且效率（因为是工控场合，所以效率非常重要）低下。M$在OPC组织中非常的积极，所以现在的OPC基本上也脱离了当初制定的目标，令很多产商不满，包括OSI在内，虽然OSI PI提供OPC接口，但OSI不建议客户使用它，也不对它进行技术支持。在OPC中的COM还有另外一个大问题，因为COM规定必须支持先前制定的接口，而工控要求又非常严格，开发测试的费用和时间都非常高，没有任何厂商愿意支持先前的COM接口，因此没有真正符合COM标准的OPC。 发表于 Tuesday, June 22, 2004 5:23 AM

评论 # re: 实时数据库的简介（初稿） 6/28/2004 11:31 PM USER 谢谢周星星的文章，非常好且非常有用。

我想问一个问题： 现在OPC接口可谓来势汹汹，并且PI也提供OPC接口，如果PI对其不提供技术支持话，是否还选择这个接口？ 能客观平均一下其OPC接口和专用接口之间的区别吗？

# to USER： 6/29/2004 1:55 AM 周星星 ：）我的评论很难客观，但我尽量做到客观吧 1. 仅仅对于实时数据库，那么使用OPC并没有太多的优势，因为实时数据库就这么几种，而且价格昂贵，更换的可能性并不大；对于众多的DCS而言，使用OPC的优势不言而喻。 2. 专用接口的缺点是不统一，这种不统一反映在编码上的复杂度是指数级增长的。比如写一个从A DCS到B DCS的程序，如果DCS有10种，那么就需要写10*10种不同的代码。 3. OPC的缺点有下几个 a. OPC 发展的过于离谱，现在的OPC是什么，很难说；这是任何一个做大了的技术免不了的通病，什么都想囊括进来，最终腹胀而死。 b. OPC 服务器开发困难，因为COM要支持以前的荒废了的COM接口。 c. 客户部署困难，需要安装太多的COM d. OPC的安全机制使用的是DCOM的安全机制

# re: 实时数据库的简介（初稿） 6/29/2004 6:52 AM pi 你对ip.21的评价有问题！

# re: 实时数据库的简介（初稿） 6/29/2004 11:54 PM user 谢谢您的点评！

# to PI： 6/30/2004 1:47 AM 周星星 有什么问题就说嘛，俺欢迎不同意见！^_^

# re: 实时数据库的简介（初稿） 7/1/2004 5:58 AM ggg 肤浅

# to ggg： 7/1/2004 6:18 AM 周星星 ：）欢迎不同意见！ 不过本文确实肤浅，这只是一个实时数据的简介，不得不肤浅呀。 判断一个数据库的好坏无法就是 a. 性能 b. 价格 c. 提供的操控接口 您还希望能有什么其他信息？

# re: 实时数据库的简介（初稿） 7/8/2004 5:31 AM 快乐浪子 现在国内有些行业用的是配置oracle等大型商用磁盘数据库来实现将部分或者全部数据cache到内存来满足实时要求，比如广东网通；还有的是自行开发的实时数据库，采用的是自行开发前端的实时数据库同时配合后端的商用数据库来实现的，比如我接触的这个厂家的调度自动化系统，说是自行开发的具有c/s结构的分布式实时数据库系统。以前接触的一个公司的产品据说也是自己开发的实时数据库；我查了一些资料，对自己开发实时数据库还是一头雾水，大部分都推崇的是内存数据库来实现，不过我还是一窍不通，不知星星有没有这方面的研究或实践？

# to 快乐浪子： 7/9/2004 12:36 AM 周星星 我对实时数据库的原理不清楚，PI采用旋转门等有损压缩技术来实现数据的存储，当然不仅仅如此；内存是肯定需要最大限度的利用的，但PI的吞吐量非常的大，仅仅依靠内存肯定不行，一定有自己的独门算法。 PI数据库的平均价格是1,500,000元，可见实时数据的利润很大，但既然能买到这么高的价格，肯定技术含量一定很大。 topgrass所在公司也有自己的实时数据库，名RealMIs.

# re: 实时数据库的简介（初稿） 7/10/2004 1:32 AM 物以希为贵 你用过分布式实时数据库系统么，中科软件所的Agilor2.81

# re: 实时数据库的简介（初稿） 7/10/2004 6:14 AM 阿昌 我正在做这方面的研究 不知道各位对实时事务在windows nt下的调度了解不 有兴趣跟我联系 [email protected]

# re: 实时数据库的简介（初稿） 7/13/2004 9:06 AM 周星星 看来大家对实时数据库比较关心，我现所在公司考虑到PI过于昂贵准备换另一家美国公司的实时数据库，我现在还不知道是哪一家公司，到时候再一起讨论。

# re: 实时数据库的简介（初稿） 7/15/2004 3:57 AM 物以希为贵 你们有没有考虑过中科软件所的Agilor,便宜又使用

# re: 实时数据库的简介（初稿） 7/17/2004 12:33 PM 吴孟达 我用过，的确不错。

# re: 实时数据库的简介（初稿） 7/18/2004 9:05 PM mm 我也是因为工作机会刚接触PI， 的确不错。美国的wonderware公司是否也有这种实时数据库产品呢，有谁了解，请多多指教。

# re: 实时数据库的简介（初稿） 7/21/2004 12:43 AM 周林 楼主对INFOPLUS.21的认识的确有问题，我从事IP.21的项目4年多了，使用的IP.21从V2.5到V6.0，我还没有发现楼主所说的一些问题。可能是安装技巧的问题吧！

下次有机会与大家交流PI和PHD，我对PI和PHD不是很了解，但IP21还是熟悉。欢迎大家交流。我的E-MAIL:[email protected]

# to 周林： 7/21/2004 10:10 PM 周星星 在上次那个项目中用的是6.01版本，它对中文支持有很多问题；这些IP21是AspenTech为了打开中国市场而先期赠送给中石化集团的；安装数据库的人也是AspenTech自己的员工，个人觉得他有点猪头。

# 实时数据库 8/6/2004 4:53 PM 阿刚 不知大家的系统为何要用实时数据库，用到了那些实时特性呢，总该不只是速度较普通数据库快吧，有关事物的实时调度，事物截止期，过期数据处理等不知是否也用到了。我正在做实时嵌入式数据库方面的研究，希望收集一些需求，与大家一起探讨这方面的问题。

# to 阿刚： 8/6/2004 10:14 PM 周星星 在生产制造行业中，数据的实时存取很重要，正如你所说，实时数据库就是一个字“快”，比如PI，快到每秒可以有百万的数据流量；高压缩，一只普通容量的硬盘可以保存8年的数据，当然要配置正确。这种高速度高容量不是普通数据库可以胜任的，如果用Orcal的话，这样的流量只需要几秒钟就使之崩溃。

生产制造行业为什么需要“实时”我就不多说了吧，比如电厂，如果一个重要的阀门的状态很久都不传过来，可以就会紧急制闸，损失是巨大的；还有，这种行业的生产过程计算机程度化比较高，如果慢吞吞的从数据中取得数据再去分析的话，就没办法指导机器的下一步行动。

实时数据库与关系数据库相比，从名字上可以看得出，实时数据库重在数据的实时，关系数据库重在数据的关系，对于实时数据库中的数据，它们的关系是很复杂的，需要用到很多的科学计算和公式翻译，这是SQL查询语句做不到的，因此实时数据库基本上也不提供这种关系的查询。

嵌入式系统上也有实时数据库，我是第一次听说，因为实时数据库对机器的性能要求非常的高，所以一般都运行在小型机上。

# re: 实时数据库的简介（初稿） 8/11/2004 10:42 PM flybear 请问您有详细一些的PI数据库介绍吗，包括系统规模，部署时间和代价等等

# re: 实时数据库的简介（初稿） 8/13/2004 7:34 AM dugunit 打个广告：紫金桥软件的e尔3.6虽然比不上国外的实时数据库但在国内还是一流的网址：http://www.realsoft.com.cn

# re: 实时数据库的简介（初稿） 8/14/2004 5:15 AM gu 能仔细讲讲旋转门压缩算法吗？或者能否提供相关文档？

# re: 实时数据库的简介（初稿） 8/18/2004 12:07 AM 物以希为贵 请问如何跟你联系呢

偶的信箱[email protected] ^_^

# re: 实时数据库的简介（初稿） 8/18/2004 1:33 AM Tiger - Beijing [email protected]

1. 【要点】OSIsoft正在淡化PI的概念，严格来说2000年后PI就不叫实时数据库了，现在OSIsoft推出的是实时企业智能化解决方案RtPM，PI实时历史数据引擎是RtPM中RtBaseline的一小部分。只是国内现在看来还没到那个阶段:) 国内电力行业用PI作为企业实时数据库的比较多，石化用的不多，其他行业就更少了，主要还是一些合资企业带进来的。PI的价格其实一直比较稳定，面向的是高端客户群，若比较性能价格比的话，PI明显优于PHD和IP.21，变来变去的是OSIsoft在中国的政策。OSIsoft是OPC基金会的成员，主要在OPC内部制定HDA的标准，没有听说过OSIsoft不支持OPC接口,OSIsoft的OPC接口是其版本更新速度最快的一个接口。

2. Honeywell曾经是OSIsoft公司最大的集成商，80年代至90年代初期，通过Honeywell销售的PI比OSIsoft自己销售的PI还多。Honeywell现在卖PHD的目的不是帮助DCS的销售，而是Honeywell在石化行业的信息解决方案，如APC等需要一个实时数据平台的支撑，靠卖PHD，Honeywell是不能存活的，事实上用户如果买Honeywell的APC等应用，PHD可以免费，不过羊毛出在羊身上，再说要是用了PHD，最好就一直买Honeywell的高级应用了。

3. Aspentech的IP.21和Honeywell的PHD定位一样，靠卖IP.21,Aspentech也活不了。Aspentech产品线很长，几乎都是靠收购来的产品，买来后整合难度很大。IP.21也是Aspentech买来的产品，原来是SetPoint公司的产品，现在IP.21维护更新的开发队伍也就几个人，没准哪天IP.21赔的太多，这个部门就砍了。

总结：OSIsoft卖PI赢利，在实时数据处理方面是越来越专，越来越深。Honeywell和Aspentech卖PHD和IP.21赔本，现在在实时数据库技术上吃老本，商务上是能黑就黑一把，最好是买他们的一体化解决方案，永远上他们的贼船。

# re: 实时数据库的简介（初稿） 8/18/2004 1:57 AM Tiger - Beijing [email protected]

PI的价格

从50万左右起~200多万都有

# to Tiger_1999777： 8/20/2004 12:15 AM 周星星 谢谢 Tiger - Beijing 精彩的回复，我现所在公司又尝试了 Matrikon 公司的 Desktop Historian 实时数据库，正在尝试中。

# re: 实时数据库的简介（初稿） 8/20/2004 12:28 AM [email protected] 我是了解周星星的，其对COM技术很反感， 不过其对各个数据的评论确实我也很同意，用过的几个中比较PI确实很简单，而且其各个方面的技术都比较全面，其一，ACTIVEX的WEB支持中可以发现其技术已经很完善，而且整个软件系统之间的规划很好，让人用的很舒服， 但PI还是有些缺陷，其WEB都是机器直接通过本地的API与服务器连接，这样过多的用户浏览时候会造成服务器负担， 还有用户访问大量历史数据时候对服务器也是一种负担， 当然这些方面OSI已经解决了一部分并使这些缺陷不影响PI的使用 顺便提一下，PI对数据压缩确实强，其算法压缩数据量很大，有一套完整的数据压缩算法，从其累加点的计算上就可以看出， 不过PI确实贵

# to 周星星 8/23/2004 2:35 AM 周林 周星星提到： 在上次那个项目中用的是6.01版本，它对中文支持有很多问题；这些IP21是AspenTech为了打开中国市场而先期赠送给中石化集团的；安装数据库的人也是AspenTech自己的员工，个人觉得他有点猪头。 －－－－－－－－－－－－－－－－－－－ 回答： 1、IP.21的确对中文支持不是太好，V6.0还是英文的，打上V6.0.1的补丁后才是中文界面。 2、其WEB使用效果也不是太好，V6.0存在严重的内存泄漏和WEB21服务挂起等问题 3、IP21一直也在走上层路线，呵呵，从中石化集团公司入手，这我有些了解。 4、我所知道，ASPEN原来在北京是代表处，一些圈内的人士我认识，主要是销售其产品，IP.21 在国内没有真正的技术。目前ASPENTECH刚刚在北京成立公司，所有即使你提到的‘AspenTech自己的员工’来安装，我也对其实际的IP21新版本的工作经验不敢妄加评论。我所知道的IP.21的实施主要是国内几家公司在做：上海申迪、北京华创、北京三维，中石化盈科，其他我就不是太了解了。所以这些单位实施的最终用户和上述公司的技术人员比较熟悉IP.21。由于不了解你提到的项目，所有我不敢评论。 5、顺便说一句，我原来在扬子石化工作，后来辞职到北京工作。一直做IP21项目的实施，所有从V2.5到V6.01的版本一直在用，目前还在做IP21项目。

希望有机会与你交流我不熟悉的PI和PHD！

# to 周星星 8/23/2004 2:42 AM 周林 你所提到的项目可能是 中石化的‘沪宁甬’项目，果真如此，那我就知道‘AspenTech自己的员工’是怎么回事了！呵呵

# to 周林: 8/23/2004 5:04 AM 周星星 ^_^ 是沪宁甬项目，看来你是前辈了，失敬！ 沪宁甬项目有很多公司参与，而我现所在公司有不少猪头，……，为了避免被人耻笑，所以我没参加沪宁甬项目。

我觉得安装IP21需要硬件狗实在没必要，它有三个缺点： 1。使得安装变得特别麻烦。 2。使用IP21都是些大公司，即使有盗版，他们也不会要，因为盗版没有售后服务。 3。假如有公司想使用IP21应该怎么办？如果他花费巨资买了IP21发现不是他想的那样，他就亏大了，为了不吃亏，只要不要买。所以要不提供演示版，要不闭一眼，让程序员可以拷贝使用，假如没有其他公司的程序员会使用IP21，那么只有AspenTech只能自己孤单的推销IP21。

# to 周星星 8/23/2004 6:16 AM 周林 前辈谈不上，过奖了！ 希望能有机会与你交流IP21并向你请教PI与PHD的知识。

IP21在V3版本以前是不需要硬件狗安装的，只是使用一张LICENSE软盘，所谓的序列码，V3.0及以后的版本一直使用狗，不过很丑陋，只是安装时需要，实际运行就不需要了。当然很麻烦！ 其实IP21有不需要狗的LICENSE,当然紧紧供内部人员使用了。

其实ASPEN的售后支持一直是新加坡的支持中心在实施，而且也只有最终用户有权利得到技术支持，实施单位是无法得到支持的。除非有合法的帐号，所以也很苦了这些实施单位了－－发现BUG导致项目拖延......。

总体来说，只要你是合法的用户，同时购买了ASPEN的服务（一般软件含一年服务，一年后要另外购买），网上的技术支持还是很快的，2小时内一般有响应。当然，一般的技术问题很快老外就可以告诉你解决的方法。但重大缺陷的地方还是拖着。我有个项目，WEB21总挂起，同时存在严重的内存泄漏，半年多了，老外一直没有解决，TMD急呀！

# re: 实时数据库的简介（初稿） 8/23/2004 11:17 PM [email protected] 破周星星，留点口德，别评论我们公司的其他人，呵呵。 恩，周林很厉害啊。另外我觉得老外的技术支持也挺麻烦的，搞不定就两边差开了，老外回答的不是你要的，一个来回一个工作日就没有了。

# re: 实时数据库的简介（初稿） 8/26/2004 5:04 AM Tiger - Beijing Matrikon的产品比较尴尬哦，另外他们的Desktop Historian（原来叫OPC Historian）实在是太小了，，曾经Matrikon是PI在加拿大最大的系统集成商，2002年因为门户问题两家还打了场官司:(，现在两家是彻底掰了，Matrikon的数据库产品不适合和PI等产品进行比较，其实Matrikon现在卖IP.21和另外一家公司的产品。

# to Tiger： 8/26/2004 8:26 AM 周星星 谢谢，原来 Matrikon 是这样呀！^_^，看来便宜没好货！

# re: 实时数据库的简介（初稿） 9/1/2004 5:11 AM kkk 全都是250， 你们除了会配标准接口外，还会什么？ 会开发接口吗？一群蠢猪。 不要做半瓶醋，回家多看点书，好好学点。

AspenTech的猪头

# re: 实时数据库的简介（初稿） 9/1/2004 5:16 AM kkk 听说周林自己开公司了。是不是还想做Honeywell的Uniformance何OSI PI的代理开发？

# to kkk： 9/1/2004 10:32 PM 周星星 啊！ “配标准接口”和“开发接口”是什么意思？我只写代码跟实时数据库交换数据，连数据库的安装都没做过；自己也想编写一个实时数据库，可没人出钱请我做，也没人买，嘿嘿！因此我既不是“会配标准接口”，也不是“会开发接口”，再说，我只对编程语言感兴趣，不对开发出来的产品感兴趣。

# re: 实时数据库的简介（初稿） 9/2/2004 6:09 AM csun 实时数据库要从dCs系统中取数据把,接口就是编程让实时数据库能从dcs中取得数据.

# re: 实时数据库的简介（初稿） 9/2/2004 6:17 AM csun 有人写过OPC-PI的接口程序么,想知道流程是怎么样的 好像设备的OPC服务器是由 OPC厂商提供的,客户端是不是需要自己开发?如果开发SDK到哪里找呢,有没有免费的API可以用那?

# to csun： 9/2/2004 8:02 AM 周星星 我写过西屋的一个产品的OPC客户端，发现西屋OPC服务器有不少Bug，看来印度阿桑只能写写破MIS，技术要求一高就开始胡来； PI的OPC客户端没写过，因为使用PI API操控PI比OPC方便很多，个人还是觉得OPC太烂，不用为妙；OPC其实是通用的，我用给西屋编写的OPC客户端一样可以去IFix中取数据。

# re: 实时数据库的简介（初稿） 9/2/2004 10:14 AM CSUN 你的API哪里来得??有免费的么 我只能找到收费的 如果可以不知道可不可以把你的程序给我看看 我得msn是[email protected] 希望有机会和你交流

# to csun： 9/2/2004 10:08 PM 周星星 【要点】 说实话，我不太明白你的意思，PI API就是 PI 的应用程序接口，它怎么会有免费收费之说呢？ PI提供一个PIAPI32.DLL文件，通过它访问PI数据库，所以只需要拷贝它到客户端就行了，相关的文件如下： piapi.h piapix.h piba.h pidefs.h pisql.h PIAPI32.DLL piapi32.lib API全在这些.h文件中定义着。

程序是不能给你看的，不是我小气，而是怕公司某些人有意找我麻烦，这里告诉你一个最简单的流程： piut_setservernode 设置PI服务器，参数计算机名称和端口号 piut_login 登陆PI，参数用户名、密码、权限[out] pipt_findpoint 根据名称找点 pipt_pointtype 根据点找类型 pisn_putsnapshots 向PI写数据

# re: 实时数据库的简介（初稿） 9/3/2004 12:35 PM csun 我说的是OPC的API呵呵

# re: 实时数据库的简介（初稿） 9/3/2004 12:37 PM csun 用PI的api开发我也写了不少了，最近可能要做DCS到PI的接口不知道用OPC好还是用厂家自带的驱动，从DCS取数据的流程是什么样子的我也不太清楚，呵呵

# re: 实时数据库的简介（初稿） 9/3/2004 11:39 PM 周星星 介绍 “工控论坛-OPC论坛” 给你：http://www.gongkong.com/tech/forum/list38.asp

# re: 实时数据库的简介（初稿） 9/10/2004 11:26 AM ALB 哦，第一次找到讨论PI实时数据库的论坛。我在工作中要用到PI数据库，很想和各位交流和交换技术文档

# re: 实时数据库的简介（初稿） 9/12/2004 3:54 AM beejoy 今天是第一次认识了实时数据库（能不能称作RTDB?），原来我还以为Oracle已经很实时了，因为Oracle与SQLServer比较起来实时性能好多了。而且因为也是刚接触过BerkeleyDB,又觉得BerkeleyDB也是RTDB。

我想请问一下实时数据库的统计分析功能是如何实现的？这是利用用户的二次开发实现的，还是数据库内置的？ 如果是内置的，那实施数据库的开发公司岂不是要针对很多不同的行业设计很多不同版本的数据库？ 如果是二次开发的，那么二次开发后的应用软件效率如何保证？因为二次开发人员不一定是实时数据库的专家，那么二次开发的软件就可能成为RTDB的瓶颈？

# to beejoy： 9/13/2004 3:06 AM 周星星 你问得真好，估计这就是关系数据库和实时数据库的差别了。 “我想请问一下实时数据库的统计分析功能是如何实现的？这是利用用户的二次开发实现的，还是数据库内置的？” 应该是两者皆有吧，PI数据库有对一段时候内数据求最大值，最小值，均值等的内置实现，不过实时数据库毕竟不是关系数据库，数据之间的关系还是需要自己去计算。

# re: csun 9/17/2004 3:01 AM [email protected] 从DCS取数据，说的太含糊，你是从DCS中取，通过485接口读DCS内部数据，还是通过该DCS的组态软件获取组态中的数据，当然该组态软件的数据也是从DCS中取得 我想一般是从组态软件中取数据 然后再了解该组态软件有没有对外得接口，如西屋得WPDF是Socket，OVATION是OPC，IFIX有ODBC和DDE，高版本得IFIX是OPC等等

# re: 实时数据库的简介（初稿） 9/17/2004 11:35 PM wangrui 本人原是上海申迪IP.21项目工程师，参与实施过酒钢集团IP.21(45000点)、安庆石化IP.21(20000点)，现任石化盈科仪征化纤IP.21(45000点)项目负责人，熟悉OPC开发，在实验室安装过PHD和PI，正等机会去实施。想借贵地交一些实时数据库和实时系统的朋友。

# re: 实时数据库的简介（初稿） 9/29/2004 11:43 PM 冰火仔 不知周星星为何方神圣，哪位能给个介绍

# to 冰火仔： 9/29/2004 11:47 PM 周星星 我知道 ^_^ 周星星是南京一家无名公司的一个庸才，满腹牢骚，借Blog以发泄。 跟他谈ASM/C/C++可以，谈MIS/ERP就免了。

# re: 实时数据库的简介（初稿） 9/30/2004 12:01 AM 冰火仔 我看你他对PI很有研究哦，能否交流交流。小弟我一直干着安装/卸载PI的工作。

# to 冰火仔： 9/30/2004 2:42 AM 周星星 不明白的问，PI的安装/卸载是非常简单的事，难道还需要专业人士来做这项工作？估计是我孤陋寡闻，【要点】我觉得PI管理中最重要的事是确定标签点的Zero、SPAN和偏差，这是影响PI效率最大的部分，但这项工作又需要很强的行业知道，比如主气温度，对一个非电力专业的人而言，是不可能知道温度偏差多少是不重要的。

顺便问几个问题： 1。PI中有根据一组标签名称取一组标签id的API吗？ 2。PI中根据标签名称取标签id的API的执行速度特别慢，为什么不建一个hashtable来加快索引速度？ 3。PI内部的数据是big-endian，还是big-endian？她是怎样做快速转换的？因为我觉得PI for win比PI for Unix效率还高，自认为是byte order的原因造成的。