去年年底，有一个客户提出一个需求：他们要将wincc oa/pvss 作为服务器，给另外一套scada提供大量实时数据，大约上万点的实时数据，最快刷新速度需要1秒。
虽然opc da接口最先被想到，但是出于性能和稳定性的考虑，业主希望采用modbus作为通讯协议，也就是说另外一套scada系统要把wincc oa/pvss 当做一个plc一样，来读写数据。
这个想法很好，modus协议简单，相对opc da似乎也比较可靠，性能也应该好很多。
但问题是， wincc oa 的modbus 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完整方案和快速响应客户需求的西门子产品。