4season

How to Monitor Honeywell DCS Performance in PI system(Chinese)

Blog Post created by 4season on Jun 28, 2019

Background: Honeywell TDC 3000 or EPKS DCS system  (This is Old Honeywell DCS in LCN)

這篇文章已經是好久以前寫在公司的知識分享網站上.最近把它拿出來是因為化工界常忽視DCS Performance的重要性,也剛好利用PI 的大數據特性分析,來做未來DCS 控制模組擴充的參考:

我很多的想法都是用觀察實體的操作環境來做Advance Improve,這次介紹的DCS Node Performance 是我以前看Honeywell Performance Menu 的參數時,引發的構想,當時的PI DCS Interface HoneywellCM 50S,通常收到PI information 不外乎是PV SP OP,後來再加入Digital StateMODE ,Digital Composite , DI點的PV值等!幾乎沒看過有人想監控DCS 其他的參數.
1994
,我開始研究LCN NodePerformance Monitor,因為DCS HMTrend Storage有限,若能將 Honeywell DCS Perfomance Monitor 參數引進到PI system,操作也方便,也可以進行Long Time Monitor .剛開始用LCN NodeCPUFREE ,這個參數是DCS System 中硬體還剩下多少CPU Free的意思.接下來的參數就List 在下面;
Report PSDP Parameters Common To All LCN Nodes


CPUFREE: Percentage CPU free time over previous 15 second sample. Consistent averages below 15-20% 

HEAPFRAG:Heap memory fragmentation index. Values at or above 2 indicate a potentially fatal condition. 

PARSEC :Parameters per second read from or stored to this node by other LCN nodes over previous 15 second sample. Recommended maximums (node specific) are as follows: 
AM = 615 for 68040, 410 for 68020, 270 for 68000 
NIM = 1400 for 68040, 750 for 68020
因為NIM DCS System中伴演最重要的溝通角色,所以特別針對UCN Performance 來做Monitor,其參數如下:
Specific PSDP Parameters Common To NIM Nodes
DHPARSEC(1):Parameters (stored) per second due to operator initiated

regulatory control actions (manual valve changes schematic stores, raise/lower commands), over last 15 second sample
DHPARSEC(2):Parameters (fetched/stored) per second due to AM, CG, HM (high level control),over last 15second sample
DHPARSEC(3):Parameters (fetched) per second due to display invocation (new display call-up), over last 15second sample
DHPARSEC(4);Parameters (fetched) per second due to normal display updates, over last 15 second sample

接下來就是我十幾年前做的PI DCS Performance Monitor, 這次以BU2 Demo  因為這個DCS Performance Monitor,發揮很大的力量來發現DCS Problem, Bu2 過完農曆年後開爐,可是UCN 03 PM11Status卻發生如下的情況,整個PM Module 所有AI DI的狀態會瞬間消失,然後I/O 出現"?????' ,這是一個很緊急的狀況,剛開始我以為是BU2 新增加的設備接地沒做好,所以會造成Noise!因為WWT曾因現場加裝了變頻器,導致HPM Noise 造成UCN Cable Fail,但是這次的情況Noise Nomal ,大家可看下面兩張截圖:

但是問題找不到原因,後來我看到的BU2 PI DCS Performance,我發現Real Time CPU AVG的值只有0.3.下來的參數介紹,你應可了解這些參數的意義;
Parameters for(PM. APM, and HPM) 
COMCFAVG:Percent Communication CPU average free time, over last min.Minimum recommended is 20%
CTLCFAVG:Percent Control CPU average free time, over last min. 
這次出現的問題就是Communication CPU造成的,一個PMM Module Monitor的有兩大Key module ,一個Communication 另一個是Control ,底下的PI Trend ,可看出來.

由此問題的發生,我們來探討Honeywell TDC3000的DCS Hardware問題,此次發生的是BU2 PM 11,你知道Honeywell DCS Control設備已經從PM--->APM--->HPM---->C200---->C300,你的PC 若是超過20,你會怎麼認為呢?哈哈 !簡直是骨董阿伯級的!不曉得已進博物館多久了,BU2 PM卻是已幫CAPCO Service 20.而我們的現場的Control Tag 只會增不會減,而我們又不會去care PM它到底已經LKK了嗎

PM,APM,HPM裡有個Process Units的容量, PM200 APM400 HPM800,這就像PC過去286,386,486,Pentium..Pentium4, 越來越快.這次問題的產生其實是一個警訊.到底我們的DCS Life Cycle是怎麼看待,,難道一定要等工廠發生無法控制才面對嗎?


Summary:會老調重彈其實是DCS Performance這個領域很少人去接觸,不管你用那種DCS,如果DCS System有提供Performance 參數,而你的PI Tags還有可利用的空間,不遑拿來監控DCS Performance.

 

 

Outcomes