一、方案要求：
1.项目多家以太网通讯；共5个300PLC与DCS冗余CPU通讯；
2.PLC厂家没有上位机；
3.通过通讯方式将需要监控的测点送到DCS侧；
4.保持DCS的监控系统整体画面风格一致；
二、通讯及控制方案：
1.H型CPU与5个PLC以太网通讯。由于通讯距离较远，采用光纤通讯介质，通讯双方通过光电转换交换机，转换成以太网。
2.通讯CPU的型号为414H；
3.由于双方通讯数据量大，弃用PUT/GET，采用AG_SEND/AG_RECEIVE方式；
4.尝试过400H侧使用SFB12/SFB13，PLC的300侧使用FB12/FB13，未能成功，原因不详，由于时间紧迫，放弃此种方案；
5.DCS组态增加一个单项目，用于组态5个PLC的硬件组态（仅组态CPU+CP343-1即可，目的是建立通讯连接）；
6.AG_SEND,AG_RECEIVE由于是S5兼容性通讯方式，因此无法使用S7连接。采用ISO连接；
7.DCS侧400H的两个CPU分别建立ISO连接，记下ID，以备编写通讯程序时使用；5个PLC分别建立与400H的ISO连接。共计10个ISO连接。
8.编写通讯程序：BLOCK下建立FC（注意不要超出使用范围）
9.FC程序中填入AG_SEND/AG_RECEIVE（注意由于库中的FC5，FC6超出PCS7的使用范围，因此改名字为FC105，FC106）；
10.编写程序就很简单了，需要注意的是LEN的长度。还要注意触发脉冲；
11.DCS,PLC侧分别建立通讯DB数据块。
11.PLC侧编写相应的通讯程序；双方程序类似；注意SEND/RECEIVE对应伙伴的RECEIVE/SEND。
12.DCS侧下载网络连接；PLC的网络连接也有DCS侧增加的单项目来下载（因为PLC侧都是单项目，无法找到通讯伙伴，无法建立通讯连接）
13.DCS,PLC分别下载通讯程序。
14.为了保证PLC通讯过来的数据在上位机画面中与DCS保持一致，牺牲了PO，在DCS程序中使用了标准的程序功能块，将相应的通讯数据连接到功能快上，然后通过OS编译后，保持了ICON,FACEPLATE与DCS一致。当然客户有钱，购买的PO点数授权足够使用。
15.通讯数据量大概67BYTE*4+110BYTE的读数据和67BYTE*4+110BYTE写数据。
16.在线查看CPU的WORK MEMORY占用57%。
三、碰到的问题与解决办法：
1.通讯速度慢，大约8S左右：
1.1问题出在触发脉冲时间较大，原来使用的是1S触发脉冲，后更改为100MS触发脉冲，通讯速度明显提升，不到1S；
2.五套PLC通讯程序都添加到414H后，OS报警，扫描周期超时；
2.1由于通讯数据量大，过快的扫描周期导致1个周期内，无法扫描完整个程序；在线查看CPU扫描时间最大为200MS左右；为了保证通讯速度，同时保证一个周期内能够扫描完整个程序，将通讯程序放在了OB33中，500MS的扫描中。OS报警消失，CPU内部故障消失。
四、感受
1.由于使用417H的项目很多，很少使用低档次的CPU，对于扫描周期，扫描速度方面注意的不够。导致了项目中出现了这些问题。
2.此种控制方案本身就有很多的问题。PLC无上位机+大量的通讯+保持PLC与DCS画面风格一致，这种方式不仅浪费了DCS中的PO，而且相当于PLC,DCS编写了两套程序，不但没有节省费用，反而很大的工作量。本项目由于商务方面的问题，造成DCS工程师免费完成了这些大量的工作。不但PLC的画面由DCS厂家来完成，还要为了保持画面风格一致，而在CFC中编写大量的程序。
3.其实对于PLC的画面，可以使用PCS7中的ICON图符，CFC不需要编写程序。然而这种做法就需要在WINCC画面中，动态变量需要一个点一个点去连接，工作量超大。考虑到本项目中CPU的MEMORY占用率很低，方考虑了CFC中使用功能块编写程序，然后WINCC画面中直接连接结构变量的方式。
4.其实就是通讯数据在DB块中，然后其他的程序都按照PCS7的方式来完成的。
5.牺牲了CPU的MEMORY，牺牲了PO授权，带来了程序的相对方便。
6.这种方式不建议大家采用，本项目也是无奈之举。