基于升船機控制系統的PLC軟件設計

郭維禮，黃建平

（西安航天自動化股份有限公司，陜西 西安710065）

1 引言

雖然系統論的概念是近代才提出的，但用系統的方法來分析事物和解決問題，在中國古代就有記載，象易經、黃帝內經等。

再如我國至今為止，年代最久、唯一留存、以無壩引水為特征的都江堰水利工程，實現江水自動比例分流、自動比例排沙、控制進水流量（寶瓶口與飛沙堰），就是系統在實際工程中的應用。

本文以已經完成的某升船機主提升控制系統的設計為例，進行整理和具體闡述自動化軟件設計在較大型自動化控制系統中的應用。升船機控制系統作為一個較大型的控制系統，由多個子系統組成，各子系統之間需要緊密的、準確的配合，才能完成升船機安全可靠運船過壩通航的功能。

2 系統結構

本升船機控制系統主要由上位操作計算機、主提升子站、傳動子站、承船箱子站組成，每個子站各設有人機界面。控制系統通訊的物理拓撲采用光纖以太網環網。主提升子站與其它子站間通過電纜連接進行開關量信息交換。

3 主提升子系統的軟件架構設計

用系統的概念來考慮問題，要求我們設計時應考慮到整體→局部→具體細節，還應考慮到具體細節→局部→整體。主提升子站的軟件架構也是按照這個思路來設計的，即系統→子系統→功能和功能→子系統→系統。軟件架構是控制系統軟件的框架，它對軟件的程序流程、測試和維護有很大影響。良好的架構能使程序結構條理清晰、可讀性強，在做維護和修改時能較容易找到需要查找的部分，還能有效減少維護和修改的時間，也能降低工作人員的出錯率［1～2］。

較大型控制系統的軟件設計人員必須非常清楚系統設備的特征及設備的正確使用、各設備之間的準確關系及控制系統設備的整體流程，其流程主要包括運行流程和事故處理流程（圖1），并應形成文檔。

控制系統的軟件架構設計如圖2所示，按照信號的先后處理順序分為輸入、處理、輸出和執行四列。按照信號輸入的類型粗分為I／O 輸入、通信讀入、硬連接輸入三類，每一類里面根據信號的作用不同，可以細分更多的小類。處理過程分為故障判定及處理、指令處理、程序流程處理三大類。輸出分為三個匯總類。執行再次對輸出匯總，按照固定的接口輸出。這種架構設計實際上形成了一個網狀結構，把復雜問題簡單化，使結構層次更清晰。處理好每一列每一個網格的功能后，整個系統的功能也就基本實現了。整體和部分的有機結合，很好地實現了復雜控制系統的控制功能。相關文檔的建立對于軟件架構設計也是很重要的，首先可以有效發現架構設計中存在的功能缺陷，利于隨時補充完善。其次可供自己以后查閱或方便接手后續工作的第三人了解項目［3］。

圖1 示意流程圖

圖2 功能邏輯圖

4 主提升子系統軟件設計

基于系統的安全性、可靠性、健壯性、可測試性、可復用性、可擴展性、可維護性等的綜合考慮，主提升子站軟件結構人為地分成了主提升子站子系統、上閘首站子系統、中控室上位計算機功能、傳動子站功能、承船箱子站功能。主提升子站子系統分制動器控制功能、檢測功能、與人機界面的交互功能等。上閘首站子系統分上閘首閘門控制功能、充泄水蝶閥的控制功能、充壓水封裝置的控制功能、檢測功能等（圖3）。

對于編程語言的選擇，要依據設計者本人的知識特點和要實現的功能的復雜性考慮，選擇用梯形圖（LD）、功能塊圖（FBD）、結構化文本（ST）或指令表（IL）。也可以幾種語言混用，梯形圖（LD）、功能塊圖（FBD）直觀易讀，結構化文本（ST）更適合復雜的運算、消息處理等。

圖3 主提升子站通訊功能拓撲圖

4.1 功能變量定義

為了系統結構的清晰明了，對主提升子站的變量按子站、通訊、設備和功能進行變量名的定義，并建立相應的文檔。變量的定義和具體程序段的編寫，實現設計思路中局部→具體細節的分解。變量的定義和具體程序段編寫的合理與否，直接關系到軟件局部的質量，并會影響整個系統的軟件質量。

變量名結構：aa＿bb＿cc＿dd

aa：變量定義的最高一級，主要定義信號的來源，即來自哪個子站或信息交換的方式。

M：主提升子站（main），主提升子站自己的變量和外送的變量，省略不寫；

DR：傳動子站（drive）；

UP：上閘首站（upper lock）；

T：承船箱子站（tank）；

IO：主提升子站接收的其它站的電纜連接信號（i／o connection），又分為IO＿dr，IO＿t。

HMI：與人機界面的通訊信息；

ST：送往船廂子站的信息（send to tank）；

SD：送往傳動子站的信息（send to drive）；

RT：送往船廂子站的信息（receive tank）；

Step：上位計算機發單步指令；

Auto：上位計算機發自動指令。

bb：主要針對本站I／O 量的變量定義。對于通訊交換變量，略去bb。

I：開關量輸入；

O：開關量輸出；

Is：上閘首開關量輸入；

Os：上閘首開關量輸出；

AI：模擬量輸入；

AO：模擬量輸出。

cc：

具體設備名稱的命名，要與其文字意義一致，便于識別。如充壓水封：airvalve；充泄水蝶閥：watervalve1，watervalve2；制動器：braker 等。內部中間變量，直接命名。對于非具體設備，可以省略，如上升、下降等。

dd：

具體功能名稱的命名，要與其文字意義一致，便于識別。如閘門的開啟：open；閘門的關閉：close；閘門的停止：stop；全開：fullo；全關：fullc；水位：waterlevel；備用點：backup 等等。

4.2 程序段的劃分

按照程序處理的邏輯功能的不同，劃分多個程序段，不同的程序段執行不同的功能，且在功能的處理上是基本獨立的。具體實現設計思路中整體→局部的分解。程序段的劃分要做到軟件結構清晰。各程序段功能的劃分和程序段間的邏輯連接如圖2所示。

①輸入按照來源和功能的不同分為I／O 輸入、通信讀入、硬連接輸入。I／O 輸入是采集現地各設備的狀態、故障信號或測量數據，通信讀入是通過以太網讀入的上位機指令或其它子站的交換信息，硬連接輸入是本升船機控制系統特別設置的安全保護信號，用于緊急事故的處理。

②按照信號輸入的不同，對信號進行故障判定、指令處理、數據處理、流程程序等的處理。

在本控制系統的實施中設計有報警程序段，實現對故障信號的判定，以在流程處理程序段中使用故障報警功能。故障分停機故障（第一類故障、第二類故障等）和報警故障兩大類，停機故障發生時按照預定的停機流程停機并報警，報警信號發生時只報警。硬連接輸入的停機信號進行I／O 采集的同時直接送到執行原件，執行停機動作。

指令處理程序段：對本控制系統人機界面的短操作指令和上位機操作員站的短指令做一個變換處理，以便于流程的執行。

數據處理：對于采集的壓力、水位、行程、速度、轉矩等數據，用結構化文本（ST）來計算、處理，這樣，程序便于編寫、直觀易讀。

流程程序程序段：實現流程處理功能，使程序按照預定的設計流程執行動作，完成控制升船機設備運送船只過壩通航的任務。

③輸出程序段：對按照程序流程處理的各種中間結果進行匯總，輸出到執行元器件。

④執行程序段通過硬件來實現，執行元器件按照流程判定的結果執行對各設備的動作和報警。

4.3 自定義功能塊

在做多個數據處理或執行某類相同的動作時，盡可能考慮使用用戶自定義的功能塊。這樣，有利于保持功能的一致性，避免重復勞動和編程失誤。在做某些功能變更時，只要修改定義的功能塊就能解決問題［4］。

4.4 程序內部功能接口

在PLC 編程應用中，內部功能的軟件接口其實是一個模糊的概念，暫且就叫“程序內部功能接口”吧。這里主要是指故障和事故功能的轉接或連接接口。正確的思維才能導致正確的結果，而錯誤的思維可能導致結果的不確定。每一種功能的處理都應確保有確定的結果，而且與其它的功能結果沒有沖突。程序內部功能接口要做得盡量簡單，數量要做到最少，最好是同一種類型的事故信號只有一個出口，這樣才能保證流程設備動作的一致性。如果不這樣做，可能會出現特定情況下，設備動作與流程中預期的不一致，而且，這種不一致很難用模擬的方法來重現。

4.5 注釋

所有的自定義變量，都做相應的中文注釋。在軟件中查找時，就能直接知道變量的用途。在程序段中相應的位置也做一些中文標注，如上游水位值的處理、判定，船廂行程的計算，船廂高程的校正等。必要中文信息的添加，會使軟件閱讀變得更加容易。

4.6 與人機界面的交互

人機界面用于設備狀態監視、故障信息查看和必要的界面操作功能。友好人機界面在設計實現功能的同時，還應考慮用戶操作的便利性和實時性。本文設有菜單畫面、主畫面、流程操作和參數設置畫面（密碼登陸）、I／O 顯示畫面、幫助畫面等等，畫面分工簡潔明確。本文選用以太網通訊方式，要交互的數據放在連續的數據塊中，能有效減少人機界面讀寫數據的次數，增強數據交換的速度。本文選用RISC 400MHz 處理器10″TFT 人機界面，保證了畫面的速度和色彩。

當然，設計在實現功能的同時，還要考慮畫面的美觀性。用戶的每一次操作都是一個愉悅的過程或是用戶在操作時想不起人機界面的存在，這樣的設計才是好的設計，也應是設計者追求的方向。

5 軟件調試

軟件調試是軟件設計的一部分，是軟件設計的延伸。軟件設計的質量相當大一部分工作是在軟件調試過程中得到驗證和保證的。軟件調試按時間大致可分為編程過程中的模擬調試、廠內聯機調試和現場調試。

現在的PLC 軟件好多帶有離線模擬功能，在編程過程中隨時可以進行軟件的錯誤檢查和功能的模擬檢查。通過模擬運行程序，可以有效地發現和排除能在編程階段發現的錯誤，以提高軟件質量，縮短聯機調試時間。

聯機調試（廠內調試），不僅是驗證軟件編寫的正確與否和流程功能正確與否的關鍵過程，也是進一步完善軟件架構、功能和優化局部功能的過程，要特別注意對各個邊界條件和數據的調試。

“第一次就把事情做對”。調試只是一個發現問題和解決存在問題的必要手段。調試過程中沒有發現問題，并不能說明軟件就沒有任何問題，所以我們要有從源頭上杜絕問題的思想，這也是為什么要做軟件架構設計的原由。筆者以為，如果一個軟件的調試比軟件編寫花費同樣時間，甚至更長時間，那么這個軟件的編寫基本上是失敗的，除非存在難以解決的設備間接口或通訊問題。本文使用軟件架構設計方法編寫的軟件調試包含場地準備、硬件檢查在內只用了一個多月時間，其中對于軟件部分的調試主要集中在檢查閉鎖條件的正確性和通訊功能，顯著縮短了調試時間，改變了以前升船機控制系統廠內調試用時長達數月的狀況。

軟件調試過程中過多的更改和功能補丁，會使得軟件的結構支離破碎，會增加后續維護時的工作量，也會使得功能的可擴展性變得困難。

控制系統經過廠內調試，在現場安裝后還要進行現場調試。現場調試主要是標定實際運行參數、檢查和調試現場條件與原設計條件的變更，進一步檢查驗證和完善流程功能，并根據現場實際情況增加軟件的保安措施，增強系統的安全可靠性。

6 結束語

本文研究了用系統的方法來做較大型控制系統的軟件設計和架構設計，其軟件結構緊湊、條理清晰、整體性強，能有效縮短調試時間。本文采用適當的中文注釋和技術文檔，使得軟件便于閱讀、調試、維護和擴展，增強了軟件的功能和質量，也便于在以后類似工程中參考應用。

［1］李偉，吳慶海.軟件架構的藝術（架構之美）［M］.北京：電子工業出版社，2009.

［2］［美］Jared R，Richardson William A，Gwaltney Jr.軟件項目成功之道［M］.蘇金國，王少軒 等譯.北京：人民郵電出版社，2011.

［3］［美］普雷斯曼（Pressman，R.S.）.軟件工程：實踐者的研究方法（第7 版）［M］.鄭人杰，馬素霞 等譯.北京：機械工業出版社，2011.

［4］郭維禮.漫灣水電廠機組進水口事故閘門控制系統改造應用［J］.水電廠自動化，2012，33（1）：52－54.