去年年底，有一个客户提出一个需求：他们要将WinCC OA/PVSS 作为服务器，给另外一套SCADA提供大量实时数据，大约上万点的实时数据，最快刷新速度需要1秒。

虽然OPC  DA接口最先被想到，但是出于性能和稳定性的考虑，业主希望采用Modbus TCP作为通讯协议，也就是说另外一套SCADA系统要把WinCC OA/PVSS 当做一个PLC一样，来读写数据。

这个想法很好，Modus TCP协议简单，相对OPC DA似乎也比较可靠，性能也应该好很多。

但问题是， WinCC OA   提供的Modbus TCP Driver 虽然既可以作为Modbus 客户端，也可以作为Modbus 服务器，可它的Modbus 服务器使用的是一种特殊协议Unicos，并不是通用的Modbus协议。

总部也没有现成的方案。

没有办法，只有依靠 WinCC OA/PVSS 强大的API  C++接口，撸起袖子自己编写一个WinCC OA 的Modbus 服务器了。

客户接受这个方案。那说干就干。

因为Modbus TCP 协议确实相对简单，其中最重要的工作就是完成点表的地址映射和响应代码的编写，所以没用多长时间就完成了，用第三方工具进行压力测试，结果发现：向外提供的数据少的时候，性能还行，但当每秒大约有1 - 2千点请求时，客户端上的数据更新速度就变得滞后较严重。这样的结果肯定无法满足客户的要求。

性能的瓶颈会是哪呢？

每次Modbus客户端请求数据时，Modbus服务器都需要查地址映射表，当这个表比较大的时候，每一次查找将会是个最耗时操作。而我的第一版由于追求开发速度使用了最简单，但效率很低的查表方法。故在点数较多时，性能衰减严重。

为了解决这个问题，这时自然想到教科书上的提高查表速度的方法，并结合地址映射表的特点，最后选取了哈希表的思路。

修改了代码后，并加入了多线程处理，再次压力测试时，性能飞速提升。

最后的测试结果轻松愉快的超过客户最大需求接近一倍，而且还有很大的余量， 经过一个月左右的持续压力测试，该Modbus TCP 服务器性能依旧十分稳定，CPU和内存占用小且稳定，而且客户非常满意Modbus变量导入导出和批量组态的功能....

但是剧情突变，从V3.14 起（今年已发布），WinCC OA/PVSS 竟然开始直接提供 Modbus  服务器功能：

而且提供了更加灵活、完善的数据映射机制。

我到底是该高兴呢？还是该高兴呢？

但我想客户应该是高兴的，因为他们能得到更专业、更值得信赖的SCADA完整方案和快速响应客户需求的西门子产品。