上回说到，实时数据库的接口类型，包括以下三种，这三种接口类型功能不同，对标准化需求的迫切性不同，标准化所需要作的工作也不同相。

①、数据采集接口；
②、内部模块数据交换接口；
③、对外数据接口；

我本来拟就此三种接口的异同、对接口标准化的需求等，一一进行分析说明，但邹骁同学已明确表示，他拟推动的乃是数据采集接口的标准化，非其它两种接口，而且，从其文章《OPC——资本和崇洋豢养的病态协议》中可以得出结论，他拟推动的标准化工作，有相当一部分任务是为了解决OPC的弊端，也就是说，该数据采集接口在很大情况下可以替代OPC。那好，今天我也就只针对该接口进行分析。

先让我们猜想一下，邹骁同学心目中，理想的、标准化的数据采集接口，到底是一副什么样子吧：

该标准协议基于以太网，基于IP层，具有自定义的简单而高效的传输控制协议，具有高效、功能完备、可扩展性强、配置简单、维护方便等特性。其它协议，包括OPC、Modbus协议等，先转换为该标准协议，再接入实时数据库。实时数据库厂商按照标准协议采集其它系统的数据，如果其它系统不存在标准协议，则为其编写一个专用的协议转发程序。实时数据库厂商可以将针对其它系统开发的协议转发程序单独销售，卖给任何需要该协议转发程序的最终用户或实时数据库厂家。

为了满足标准化的要求，该协议不应该只传实时值，它应该包括以下完整的功能点：

可选的链路层传输控制协议
可选的传输安全控制方法
多机环境下的用户权限管理
数据类型自描述体系
测点属性自描述体系
测点类型自描述体系
测点方法自描述体系
测点层次结构自描述体系
复杂数据类型自描述体系
测点属性读写
实时数据读写
历史数据读写
统计方法定义及统计数据读写
测点报警逻辑自描述体系
测点事件逻辑自描述体系
以上各种功能的订阅发布逻辑
以上各种功能的批处理逻辑
以上各种功能的同步异步逻辑

同时，还可能会考虑以下扩充功能点：

时间及时区对应逻辑
客户端数据压缩逻辑
客户端数据缓存逻辑
冗余逻辑
基于复制的可靠性服务
多主控制逻辑
多级级连系统
跨平台的协议程序实现

相信邹骁同学及其开发团队，已经严密地分析了各种应用，已经对比了OPC、Mobus、IEC-61850等各种协议，并认真地分析了OPC的功能点，虽然OPC在邹骁同学眼中的形象不太好，但它确实可以提供很多可供参考的信息，另外，相信邹骁同学也正在参考分析OPC UA协议，因为OPC UA协议也在努力地对OPC的缺陷作出修订和改进，而这些修订和改进，对我们重新制定新的实时数据库数据采集协议标准，是有非常大的参考价值的。

从以上分析，可以得到可能的问题一：制定完整的、大家都能接受的实时数据库数据采集协议，需要考虑的内容很多很多。

邹骁同学也可能会对该通讯协议的很多设计方面进行简化，以便能够尽快地拿出协议标准草案，以供大家讨论。不过，这种简化的版本，在功能上与其它厂家要求的差别到底有多大呢？

比如说，XX系统定义了5种特定的点类型，包括其独特的虚位号，问题是，其它实时数据库厂家一定也要使用虚位号的概念吗？再比如，XX系统的测点系统没有层次的测点树结构，如果别的厂家支持测点树结构，该如何取舍？

以上这些功能点，与系统的对外接口的关系更密切一些，但是，与数据采集接口的关系也是比较密切的，数据采集接口是需要考虑这些功能点的。

每个实时数据库厂家都在设计实时数据库时，定义了一套完备的系统内部功能体系，并针对这套功能体系进行了接口标准化工作，只是，这些标准化的工作只是针对该系统。举例说明：PI定义了一套自定义的功能体系，也针对该体系提供了采集接口开发包，如果国内、国外所有的实时数据库厂家都遵守PI的采集接口开发包编写程序，该接口便可以认为是接口标准。只是，这样的接口标准，必须在功能逻辑上满足PI的逻辑，是其它厂家在功能上妥协的结果。

从以上分析，可以得到可能的问题二：接口是系统功能的体现，如果不能定义出权威的系统功能，便很难定义出标准的通讯接口，目前实时数据库的系统功能并没有权威和标准，便匆忙推动接口标准化，其它厂家不可能接受。

即便该接口得到了国内实时数据库厂家的认可，那么，推行该接口的受益者是谁呢？

下回再写......