井场数据采集系统的架构演化

XXX井场数据采集系统，是实现XXX物联网的基础，它从井场设备上采集钻井工程过程中的各种数据，远程传输到地区公司的数据中心，提供实时和准实时数据给远程作业支持中心和专家中心的各种专业软件进行处理，指导井场钻井作业。采集系统最早开始于2012年初着手架构和开发，期间经历了从无到有，从有到优的一个改进过程，共发生过四次架构演化。vcsky.net

探索出来的架构

这个时期的架构，可以说是一种猜想的架构。因为此时并没有获取任何关于采集系统的需求。我们只知道需要做一个软件系统，这个系统能够将井场仪器上产生的数据采集到指定的计算机。我们做了这样几件事情，定义出系统开发的编程语言，软件采用的架构模式，是采用B/S结构，还是C/S结构，系统采用的数据库，是使用实时数据库，还是使用传统的关系型数据库，或者不使用数据库。项目组调研了大量类似的采集系统，并对其进行对比分析，得出采集系统需要使用C++语言进行开发，考虑到跨平台的问题，标准C++语言能够最大程度的挖掘计算机硬件资源，运行效率最高。借鉴于工控行业的组态软件，计划使用实时数据库来存储数据。在功能架构方面，主要分为数据采集、数据处理、数据存储。系统作为一个服务程序，在后台运行，没有界面显示。我们要做一个可执行程序，它能够采集多种设备的数据，并进行解析和存储。我们采用原型生命周期模式，尽快的开发一个采集系统原型出来，这就是采集系统的最初架构，我们通过模拟一个设备，来进行数据采集系统的测试，系统运行正常，打开了一个良好的开端。

贴近需求的架构

随着需求一点点挖掘和探索出来，采集系统需要采集的设备种类多达上百种，也就要求能够与上百种设备进行通信，而每种设备所采用的协议接口千差万别。这种情况下就需要不断往采集系统中增加代码，如果系统已经部署了，则需要替换老系统，才能实现系统对新设备的支持。如何灵活的支持多种设备，而对原有采集系统的代码产生尽量小的影响，是需要考虑的问题。这时，我们参考Apache中的流水线思想，将各种设备的采集接口程序，作为一个个可被调用的动态库来对待。采集系统由单一的、大而全的EXE程序，变成了一个EXE通用框架加上多个DLL动态库程序。基于这种架构模式，项目组开始更改原型：

这种架构模式，很好的解决了多种设备的采集问题。如果新增一种设备，只需要开发此设备的驱动DLL，而不需要对采集框架进行更改，这确保了采集框架是稳定的，同时通过加载DLL，实现对多种设备的采集扩展。确定了这种架构后，我们接下来对程序进行了一次重构，重构后的工程目录结构，也变得更加清晰，便于维护：

为了能够让多个DLL有条不紊的工作，我们采用XML文件将DLL的信息保存下来，例如DLL对应的设备名称，所采集的数据项等。采集框架通过读取XML文件，依次调用相应的DLL，从而实现对多种设备的采集。与此同时，我们大量调研了实时数据库，经过反复分析和实现，得出实时数据库并不适用于井场数据存储，于是果断的放弃实时数据库。为了更好的为其它应用系统提供数据，采集框架需要即时的将采集到的数据提供给其它系统，如果存入传统的关系型数据库中，则需要其它系统定期轮询数据库，势必会造成数据获取的延迟。因此，我们想到用推送的方式，为其它系统提供数据。一旦采集到数据，采集框架将在第一时间主动把数据发送给其它系统，这样就保证了其它系统得到数据的及时性。在这段时间里，我们的架构得到了较大的提升，下面是架构图：

这种架构看起来已经很成熟了。可是随着设备增多，我们发现配置DLL的XML文件，经常出现因编码方式造成的乱码问题，而且需要维护的配置信息越来越多。将配置信息统一的进行管理和维护，是一项重要的工作，架构必须进行调整。配置信息可以保持到关系数据库中，也可以保存到内存数据库中，考虑到井场可能不安装关系数据库的因素，我们决定将配置信息存放在内存数据库中，同时需要开发一个专门维护配置信息的程序，配置服务器和配置监测终端呼之欲出。

功能强大的架构

此时的采集系统架构由采集框架+多个DLL，演变为采集框架+多个DLL+配置服务器+配置监测终端。

配置服务器采用C++语言开发，同样作为一个后台服务程序运行，它用于管理采集框架和传输客户端的配置信息，当有配置信息增加、修改或删除时，配置服务器将把最新的配置信息推送给采集框架和传输客户端。由于配置服务器没有界面，在操作的时候，需要通过界面来完成，这也就是配置监测终端产生的原因。配置监测终端用于显示当前的配置信息，它通过给配置服务器发送消息来完成对配置信息的更改，使用java开发。这种架构模式下，配置服务器作为中间的枢纽，联系着采集和传输，所有的配置信息，都需要配置服务器来加载和管理。配置服务器还充当了与地区公司的管理系统收发文件的角色，用于动态升级DLL文件，甚至是采集框架和传输客户端EXE文件。此时的架构模式已经有些复杂，关联的系统比较多，从下面的架构图中可见一斑：

这种架构看起来近乎完美了。能够针对不同井场所有不同设备、仪器的数据进行标准化采集；通过远程传输到地区公司的数据中心，供专业软件分析和实时监测；采集和传输平台支持通过远程的管理平台对井场的系统进行配置和监测。项目组在开发过程中，进行了大量的单元测试，系统间的调试。新架构的采集系统，已经可以连续正常运转。2012年11月9日，项目组向XXX数字化油气藏建设项目，水平井随钻导向子系统负责人介绍了井场采集和传输系统架构及功能，他认为现在实现的系统解决了XXX项目井场数据采集系统的数据传输延时大，丢数据和难以维护的问题。模拟的设备数据，不足以支撑系统运行的要求了，新系统急需去实际井场做试验，验证系统的真实运行效果。

得到验证的架构

项目组成员去了井场，见到了各种各样的设备，在井场计算机上部署安装采集系统，发现了较大的问题：整个采集系统配置起来非常繁琐；采用订阅-发布的推送方式隐患很多，极易造成传输客户端无法重新连接到采集框架；以服务方式运行的采集框架，不能调用共享文件夹方式的设备进行采集。面对这些问题，我们重新思考了采集的架构，这次需要做较大的调整。首先放弃繁琐的配置流程，考虑到其它的井场应用程序，井场一定会存在一个关系型数据库，于是我们将配置信息存放到数据库中，采集框架和传输客户端直接读取数据库，由配置监控程序代替配置服务器，直接针对数据库中的配置记录做修改；将不能采集到的共享文件夹方式的设备上，部署一个采集程序，自动向采集框架发送数据。调整的方案如下：

采集系统包含5个功能：数据采集功能，配置/监视功能，数据传输功能，手工录入功能，井场数据存储功能。其中，数据采集和数据传输客户端是后台进程，不带用户界面，他们的配置通过配置/监视功能实现，配置/监视程序是一个带界面的应用程序，这个应用实现对采集仪器的配置和对传输客户端的配置，并且负责启动和停止采集程序和传输客户端。手工录入是一个独立的应用，手工录入工具录入的数据写入数据库，传输客户端从数据库中读取数据并传输。手工录入工具除了录入钻井工程数据外，还负责上传图片等文件。文件传输不走传输客户端，而是直接发送到地区公司的数据接收端。井场数据库存储以下数据：实时自动采集数据、手工录入数据、历史数据、断网时临时缓存的待发送数据包、系统配置数据、数据传输状态。架构图如下所示：

基于这种架构，开发出来的系统，经过再次去井场部署安装，得到了用户的认可。同时，用户也提出越来越多的建议和意见帮助我们完善这个架构，目前采集系统已经在井场部署安装了三十多套，运行正常。大规模的部署即将展开，预计今年将部署两百多口井。项目仍在继续，采集系统的架构也在不断完善，我们等待着迎接新的挑战。vcsky.nethttp://vcsky.net 转载请注明出处