最近做了几个油气田的项目；

pcs：1500 或1500r 或和利时lk的dcs

设计要求一个pcs站下面挂30个左右的井场rtu，站与井场之间相距几十公里。pcs除采集井场rtu外还要控制rtu里面的气动阀门。这之后还要将所有的数据汇总到数据中心。

这几个项目已完工并交付。站内1000多点，下端井场rtu通讯过来的竟有3000多点。

下面说以自己的心得。

1. 按照设计院要求必须用plc与井场的plc建立modbus通讯。但这个不现实，其一井场数据标准modbus，pcs通讯过来还要进行数据大小端转换，其二这么多数据cpu肯定死翘翘，其三，如果对方rtu变量地址变动，或是各个厂家产品不一样，那岂不累死。。。。实测1511 1ak02 带正常逻辑程序下，加了两个modbustcp client 通了两台流量计，循环时间由不加的3ms 到150ms  而且下完程序就报黄灯这已经超看门狗时间了，加到循环中断1000ms勉强最大循环时间60ms。这个最后用了一台电脑安装第三方的通讯软件，再通过opc发个wincc，相当于架设了一台专门搞通讯的服务器，而且配了多个网卡，因为各个厂家的ip段不一样，也不好统一，设计院的无脑不讨论也不需骂，毕竟没干过实际项目。也不要说配台华三 三层，这涉及三层交换根本无法实现，因为下方的设备厂家不会听你那一套去刷自己的ip和路由，而且很多设备都是多年的老家伙，你连厂家都找不见，点位地址全靠猜。
   

2. 1200-1500等modbus不足之处。用过昆仑，和利时的modbus通讯大小端转换只需要改一下组码顺讯，之后这个驱动通讯过来的数据都会一股脑给你转换过来，如果1200或1500通讯上千个变量，大小端转换岂不是累死，另外有些厂家的流量计读地址跨度很大，需要分包去读。如果1500就只能无脑写通讯或是做烧脑的轮训。总之通讯很麻烦很麻烦。也不要说自己可以轻松搞定，魔改过或自己写过通讯驱动，实际项目不会让你这么做，因为每个pcs站都是在黄图高坡的深山老林里，去一趟就要100km，而且都是山路，雨雪天气根本没法走。我们要的是稳定不出错，效率高。这期间用过南大奥拓，和利时，汇川等基于ie6113标准的cpu，他们的通讯就显得比较容易，通讯地址就像填表格一样，填上目标起始地址，读取的个数，存放的地址起始位置就行了

3. 关于modbus server问题。以前用smart200，数据长度超过125个字节就报错了，与其他设备通讯就要把real变成word。这样的情况也存在于AB的控制器，这个是猜测因为每次跟杰瑞的天然气压缩机通讯，他们都会丢给我们word让我们自己算成real。然而1200，1500就不会，数据长度可以映射的很长，clent只需要分包120个去读就行了。但每个server只能允许一个port，允许一台client，这个...有点不友好啊，若多个client去读你的server，server端必须多写几个server FB，而且每加一个就会占用一个通讯资源，对于1200来说只有可怜的14个，像某些厂家的clent都不允许改对方的port，只允许502，那这个就有点.....崩溃了...用过其他厂家的不会出现这种情况，基本可以允许多客户端去和你建立连接。

4.关于485总线方式，真的很不稳定。某个集气站，主控用的和利时lk，大多数设备一个端口对一台设备，有一个卡件的某个端口压了三台流量计，另一个端口压了一台空压机一台可燃气体检测主机（通道不够用了一个通道带俩）。对方的接地没做，好遇雷雨天气，雷击劈到了空压机的集装箱上，空压机是一台smart，和利时卡件上所有的通道电势瞬间被拉高，三台流量计（其中一台流量计为sick配艾默生计算机，485口还加了某竹的spd，500多一片）空压机及可燃气体检测主机悉数烧毁，但我们的和利机柜，，挂在其他通道的分子筛（200smart，对方技术不太懂，调试期间很听我的话，让他提前做好了等电位）安然无恙。在这做油气田项目两年，经历过多次机柜雷击，机柜可以不加信号spd，但防雷接地等电位一定要做好。还有碰到两端电势不对等的，相差20多伏，烧端口的。与高压电缆同沟的，与高压同伴一定要用好的485设备，好485芯片抗干扰能力很强。便宜的485芯片如便宜的流量计，即便跟高压电缆不同沟，稍微挨动力电近点，芯片就会死机。另外全站接地一定要做好，这个需要全站挖地深埋接地扁铁，这个在油气工程要求比较高，不像某些私企，钢构板房上一摸都电人。通讯线的屏蔽层是必要的，但只要全站设备接地做好了，通讯线接不接地，用不用双绞线都不重要了，因为你在线上根本测不到感应电动势，即便你跟高压同沟，而且高压还是高压变频。再者碰到能走网口的一律走网口，即便自己掏钱买个几十块的家用tplink，也要把它改了，如果不牵扯到通讯逻辑控制，只采集上位机观看数据，那用家用的wifi走中继都很稳定。这个不用讨论行不行，我们在项目上已经用了很多，家用WiFi走wifi中继，夏天5-60度的空压机房，已经用了2年半，这种情况往往出现在485不稳定，写程序复杂，又放不了网线。

5.关于485的距离。做过从山谷连接山顶的放空火炬柜，最少一公里多吧，没什么问题。这个是芯片质量决定的，便宜的芯片就是不行，做了这么多，200，200smart，ab的好牌子还是可以的，见得最差的是某些流量计，电能表，尤其是中安的可燃气体探测器。比如某些可燃气体探测器，485地址，寄存器地址，全靠猜才，这些相信各位伙伴深感痛恶，而且正常通讯后隔了几天莫名掉站，距离仅几米，波特率也很低，只用4800，120欧姆也加上了，但就是会掉站，要说cpu的卡件不行吧，但别的设备通的好好的，每次出问题还要大老远跑过去，这个只能修改超时时间及重复连接次数，再不行就是重启大法，修改超时时间能改善一批。

关于通讯速率。这个不是指的波特率，亲历过一台低温脱水设备（主机1215）被我的485给扫死。对方程序主程序逻辑多，通讯量不到120个字节，我方服务器client以500ms的询问扫描，对方直接报红灯死机，这个估计又超出扫描时间了。如果不信自己可以试试，用一台1200配wincc上位，读自己的1200，关联800左右的s7通讯点，再在主程序了加几个server和clent，看看会不会最大循环时间超150ms。所有正常1-2s一次数据包就可以了。

关于组网。工控人一定要学一下网络基础知识，理解网络架构，报文转发原理。如果你做小设备如运动控制，可能用不到这些，但如果搞集散控制，化工，工业智能，物联网这些。一个项目互相通讯的设备相隔几百公里，且数量又多，协议又杂，地址不统一，这样你就需要好好规划网络架构，用到路由交换跨网段，统一协议等。传输媒介上就要考虑下用4g走透传还是电信专线走vpn，还是用光缆搭建全光网络走认证互联，亦或是走2.4g或5.8g无线网桥，组建蜂窝网络。

关于上位。刚开始的的项目用的最老板的昆仑通态，相信很多网友都用过他的pc版，已经多年不更新了。通讯驱动少的可怜。后来又换了kingview，某控等，最后都陆陆续续把老的项目都重新写了一遍换成了cc75，。这也许是配西门控制器的生态优势。项目上经常会有新的设备添加或数据改动，用过前面这些的应该不陌生，改了关联地址删不掉，表格导入出错等，非常麻烦。这牵扯到项目效率问题，做第一个项目的时候，kingview不会表格导入，800多个点一个个添加用了2-3天，而且还错好多，改过的删不掉，变量名一旦引用也没法改，地址表里乱哄哄的一团糟。而用cc只需几秒即可全部导入。再结合博途的结构体，和画面模板 ，上位效率简直不要太爽。报警语音提示也是一样，不需要繁杂的脚本。这些不多说，由其他软件换过来的，应该深有体会。

关于数据库。以前用的某控，某king等，自带access只要2G，对于几千点的记录来说根本不行，要想做到数据追源，就需要关联第三方数据库了，可是还要写繁杂的sql语句，编写表头，工作量实在太大。对于几个人的小公司，既要画图又要写程序，还要接线，还要维护，根本没那么多精力。

今年两个项目上就遇到过数据追源。某项目1，用的和利时LK dcs ，所有操作记录，数据记录等，系统运行会自动建表并记录，只要你硬盘够大几乎可以无限存储。今年夏天雷雨季，雷击后，操作人员将dcs断电重启，3min后上电，就在重启几分钟间，输气管线压力上升，重启运行后阀门自动执行超压放空逻辑，且多出设备安全阀起跳，引起大事故。上方领导追责，以他们运维方经验，认为我方系统问题。要求彻查追责，我到后，查找系统运行记录，及控制采集等参数，找到了多出干线压力值上升超过设定值，阀门自动开启的运行记录，这里面有运行的曲线和时间间隔的报表记录。怼的他们领导哑口无言。。。。

项目2，用的wincc+1511 1pn 。今年某个项目，全站用的高端电动阀（24v干接点开关控制）。运维人员称某个放空管线电动阀无故自动打开，而且过力矩，电动头与阀体都已经分离。事故虽小，由于该项目未验收，运维人员及阀门厂家要定控制逻辑出了问题，导致这次阀门损毁。好在cc所有关联变量都丢到了数据记录组里，查找控制变量及采集变量，事故期间控制器均正常运行，无任何输出。这有一次怼的他们哑口无言，然后监理及业主方要求施工方将这里所有的站电动阀主板全换了一遍，一个有问题，就认为这一批次或这个厂家质量不行。由此可见忠实的运行数据记录有多重要。如果我用某king或某控的上位，我也许会只给他们做几个关键点的数据记录，这不是存储大小问题，而是数据库建表太繁琐，报警记录添加也繁琐。几千个变量根本没法一个个去添加，这就是为啥点数多了都用dcs了，上万点的项目，往往都是一两个人干，工程师还是不要把精力都浪费在这些上，还是多优化下控制逻辑，画面操作简单易用上。

时间不早了 ，先写这些。。。