歷史模件(HM)自動停止運行故障及其解決方法

李 楨

(中國石化股份有限公司茂名分公司化工分部，廣東 茂名 525000)

1996年建成投產的茂名石化乙烯廠乙二醇裝置采用美國霍尼韋爾公司的TDC 3000 DCS控制其生產過程，后來DCS升級為TPS系統(tǒng)，操作站由原US改造成全局用戶操作站(GUS)。2011年裝置進行了擴能改造，增加了一個冗余的HPM控制器和一個GUS操作站，開車投用后，歷史趨勢常出現(xiàn)斷線，歷史模件(HM)常出現(xiàn)自動停止運行。2014年大修后，HM自動停止運行的頻率達平均每天4次，是大修前的3倍以上，該問題的存在嚴重影響了裝置的正常生產。筆者針對該故障進行分析，最終查明并解決了該問題。

TPS系統(tǒng)是一個多層網絡通信系統(tǒng)，由PCN(計算機局域網)、LCN(控制管理網絡)、UCN(過程控制網絡)及其掛接模件組成[1]。LCN是一條冗余的通信網，符合IEEE802.4標準，采用“令牌總線”協(xié)議，掛接在網上的模件主要有GUS和APP(Application Processing Platform)，用于歷史數(shù)據(jù)的記錄、訪問及系統(tǒng)資源文件存儲的HM等。UCN的通信采用IEEE802.2和802.4標準協(xié)議令牌傳送方式，通過其上掛接的高性能過程管理器(HPM)、安全管理器(SM)實現(xiàn)過程的數(shù)據(jù)采集和控制。冗余的網絡接口模件(NIM)用于UCN與LCN實時數(shù)據(jù)交換，TPS系統(tǒng)配置如圖1所示。

圖1 TPS系統(tǒng)配置

2 故障分析

由于造成HM自動停止運行故障的原因很多，筆者采用了排除法進行分析，即結合硬件更換測試和狀態(tài)檢測記錄逐個排除不可能的因素，通過對歷史事件記錄、HM故障的現(xiàn)象分析，確定主要影響因素。

對于HM自動停止運行現(xiàn)象，可能原因是：磁盤驅動器供電有瞬間中斷；SBHM主板故障或固件(Firmware )版本低；硬盤存在問題；卡籠有問題；HM的負荷大。

更換、升級電源模塊，更換卡籠測試，問題依舊。采用FLUKE VR1710電壓質量記錄儀對電源質量檢查、記錄，不存在供電瞬間中斷的情況，排除了磁盤驅動器供電瞬間中斷的可能性。通過對SBHM主板的Firmware確認、更換SBHM主板、硬盤測試，但問題依舊，排除了硬盤、SBHM主板存在問題的可能。

對歷史事件記錄進行分析，HM自動停止運行發(fā)生在0∶00、8∶00、16∶00的數(shù)量占總數(shù)的73%，0∶00、8∶00、16∶00恰好是班報調度打印的時間，從系統(tǒng)配置上禁用班報調度打印功能后，HM自動停止運行的次數(shù)明顯減少。

另外，根據(jù)操作工介紹，在裝置出現(xiàn)報警時，他們在操作站上調用相關的操作組，按HOURAVG鍵，看10h內的平均值，然后調用歷史趨勢顯示時，常發(fā)生趨勢斷線，經調查，這些趨勢斷線恰是HM已經停止運行造成的。

通過不斷觀察，還發(fā)現(xiàn)HM自動停止運行的瞬間，HM的PSDP(Processor Status Data Point)中HM Drive Operating Characteristics(歷史模件驅動器運行特性)的PRIM XFERS 1 MIN(1min平均主數(shù)據(jù)傳送)參數(shù)為4021，未發(fā)生HM自動停止時，HM 1min平均數(shù)據(jù)傳送有時達988，根據(jù)系統(tǒng)手冊，1min平均數(shù)據(jù)傳送為800～900已是最大負荷了，因此可知，HM的負荷大是主要影響因素。

3 HM負荷大原因分析與解決辦法

3.1 原因分析

3.1.1HM的CPU負荷檢查

正常時HM的CPUFREE為97%～98%，有時CPUMIN的值為67.5%，高于Honewell推薦值40%，因此，CPU的負荷不重。

3.1.2連續(xù)歷史負荷計算

連續(xù)歷史負荷用PARSEC參數(shù)衡量，單位為P/s(Parameters-per-second)。連續(xù)歷史組態(tài)情況見表1。

表1 連續(xù)歷史組態(tài)情況 P/s

連續(xù)歷史對HM造成的負荷=20/60×(25+12+11+9+9+3+7+10)=28.7P/s，該HM是系統(tǒng)HM，大約20～30P/s可能就是最大負荷了，這主要取決于其他HM的負荷(checkponits，趨勢和畫面請求、記錄、突發(fā)事件及文件訪問等)[2]。經查，自動checkponit是停用的，平時趨勢調用、畫面請求、記錄的量不大，很少有文件訪問。

因此，HM負荷大與HM硬件、系統(tǒng)軟件、組態(tài)無關，也不是操作人員對歷史數(shù)據(jù)、HM中的文件訪問量大造成的。

3.1.3HM自動停止運行關聯(lián)事件的分析

對歷史事件記錄研究、分析，GUS08站出現(xiàn)死機的次數(shù)較多，GUS08站死機的時間與HM自動停止運行的時間很近。據(jù)此，將該操作站停電2d，觀察HM的運行情況，結果，HM自動停止運行的故障消失。由此可知，GUS08操作站存在的問題是造成HM負荷大的原因。

3.2 解決辦法

深入研究、分析歷史事件記錄，GUS08曾出現(xiàn)3次變?yōu)镮SOLATED的情況 ，說明GUS08與其他節(jié)點間通信可能有問題。筆者重新安裝了GUS站的操作系統(tǒng)、LCNP4板(通信接口板)的驅動程序和GUS安裝軟件，結果問題依舊。然后，用LCNP4備件替換原接口板，系統(tǒng)運行正常，再未出現(xiàn)HM自動停止運行的問題。

4 結束語

通過更換GUS08操作站的LCNP4板，解決了HM頻繁自動停止運行的問題，經過一年的運行，原故障再未出現(xiàn)。HM是TPS系統(tǒng)中的關鍵節(jié)點，在處理歷史模件的故障時，要認真分析每一故障現(xiàn)象，充分利用系統(tǒng)在線測試軟件提供的各種信息。不僅要考慮HM硬件、軟件存在的問題，還要考慮其他負荷對HM的影響。

[1] 欒云，張立麗，閆振龍，等.TPS與TRICON技術結合實現(xiàn)透平機組的控制[J].化工自動化及儀表，2010，37(10)：115～117.

[2] 李楨.霍尼韋爾TPS系統(tǒng)歷史模件故障分析與解決[J].計算機應用與軟件，2009，26(5)：273～274.