去年年底，有一個(gè)客戶提出一個(gè)需求：他們要將wincc oa/pvss 作為服務(wù)器，給另外一套scada提供大量實(shí)時(shí)數(shù)據(jù)，大約上萬點(diǎn)的實(shí)時(shí)數(shù)據(jù)，最快刷新速度需要1秒。
雖然opc da接口最先被想到，但是出于性能和穩(wěn)定性的考慮，業(yè)主希望采用modbus作為通訊協(xié)議，也就是說另外一套scada系統(tǒng)要把wincc oa/pvss 當(dāng)做一個(gè)plc一樣，來讀寫數(shù)據(jù)。
這個(gè)想法很好，modus協(xié)議簡單，相對(duì)opc da似乎也比較可靠，性能也應(yīng)該好很多。
但問題是， wincc oa 的modbus driver 雖然既可以作為modbus 客戶端，也可以作為modbus 服務(wù)器，可它的modbus 服務(wù)器使用的是一種特殊協(xié)議unicos，并不是通用的modbus協(xié)議。
總部也沒有現(xiàn)成的方案。
沒有辦法，只有依靠 wincc oa/pvss 強(qiáng)大的api c++接口，擼起袖子自己編寫一個(gè)wincc oa 的modbus 服務(wù)器了。
客戶接受這個(gè)方案。那說干就干。
因?yàn)閙odbus tcp 協(xié)議確實(shí)相對(duì)簡單，其中最重要的工作就是完成點(diǎn)表的地址映射和響應(yīng)代碼的編寫，所以沒用多長時(shí)間就完成了，用第三方工具進(jìn)行壓力測試，結(jié)果發(fā)現(xiàn)：向外提供的數(shù)據(jù)少的時(shí)候，性能還行，但當(dāng)每秒大約有1 - 2千點(diǎn)請(qǐng)求時(shí)，客戶端上的數(shù)據(jù)更新速度就變得滯后較嚴(yán)重。這樣的結(jié)果肯定無法滿足客戶的要求。
性能的瓶頸會(huì)是哪呢？
每次modbus客戶端請(qǐng)求數(shù)據(jù)時(shí)，modbus服務(wù)器都需要查地址映射表，當(dāng)這個(gè)表比較大的時(shí)候，每一次查找將會(huì)是個(gè)最耗時(shí)操作。而第一版由于追求開發(fā)速度使用了最簡單，但效率極低的查表方法。故在點(diǎn)數(shù)較多時(shí)，性能衰減嚴(yán)重。
為了解決這個(gè)問題，這時(shí)自然想到教科書上的提高查表速度的方法，并結(jié)合地址映射表的特點(diǎn)，最后選取了哈希表的思路。
修改了代碼后，并加入了多線程處理，再次壓力測試時(shí)，性能飛速提升。最后的測試結(jié)果輕松超過客戶最大需求接近一倍，而且還有很大的余量， 經(jīng)過一個(gè)月左右的持續(xù)壓力測試，該modbus tcp 服務(wù)器依性能舊穩(wěn)定，cpu和內(nèi)存占用小且穩(wěn)定，而且有客戶非常滿意的modbus變量導(dǎo)入導(dǎo)出和批量組態(tài)的功能....
但是從v3.14 起（今年已發(fā)布），劇情突變，wincc oa/pvss 竟然開始直接提供 modbus 服務(wù)器功能：
而且提供了更加靈活、完善的數(shù)據(jù)映射機(jī)制。
我到底是該高興呢？還是該高興呢？
但我想客戶應(yīng)該是高興的，因?yàn)樗麄兡艿玫礁鼘I(yè)、更值得信賴的scada完整方案和快速響應(yīng)客戶需求的西門子產(chǎn)品。