面向對象編程是計算機高級語言的一種高級編程模式，這種設計思想也可以應用于工業控制系統的plc程序中。雖然我們無法實現面向對象編程的許多優秀特性，如“繼承性”甚至完全不具備面向對象編程語言的特性，但面向對象編程的基本概念是類和類的實例(即對象)，我們只需要使用這個概念。在計算機編程中，我們需要在編寫類之前抽象和總結一些東西。在工業控制系統中，電機、閥門等控制對象是顯而易見的控制類別，無需抽象就可以顯而易見地為其編寫類。下面將用西門子的Step7編程語言和施耐德的Unity編程語言來講解PLC的面向對象編程。

?一、實施方式

面向對象編程在步驟7中使用功能塊(FB)編程。說到這個，我們會想到西門子提出的模塊化編程。是的，就是這個模塊化編程。但是西門子提出的模塊化、后臺數據塊、多背景等術語，并不能讓所有人都非常清楚地理解和使用這個優秀的設計理念。如果你從面向對象編程的角度來理解它，你就能很好地理解這種設計模式。“FB塊”被視為“類”，可視為同類控制對象的代碼歸納。比如MM440的變頻器可以寫FB塊:MtrMM440，在面向對象編程中稱為“類”。當需要對特定的電機進行編程和控制時，可以給它分配一個后臺DB塊，在面向對象編程中稱為類的實現(即創建class: object的一個實例)。需要時，FB塊可以作為實現類的參考。在步驟7中還有另一種程序塊，即FC塊。基于FC塊的編程在西門子稱為結構化編程，也可以與計算機編程中面向過程的編程相比較，即單純基于函數的編程。

施耐德的Unity軟件編程可以更好的理解面向對象編程。它的DFB定義包括輸入/輸出參數、私有/共享變量和代碼實現，它們是計算機面向對象編程中“類”的基本元素。創建類的實例(對象)就像創建普通的“布爾”變量一樣，只需在“功能塊”中定義這個“類”的變量。

Step7和Unity都可以采用面向過程和面向對象的編程方法。這兩種編程方法的區別類似于計算機高級語言中C語言和C++語言編程的區別。

下面的解釋將把步驟7中的FB和Unity中的DFB稱為“類”，步驟7中的FB+背景DB和Unity中的DFB實例稱為“對象”。

二、面向對象的編程架構

以上解釋是關于實現細節，編程思路是基于程序架構的。如果不在本地使用面向對象的方法，可以稱為這種編程或面向對象編程。這種編程需要從以下幾個方面入手:

1.結構化電路設計。

本文主要介紹自動線，它可以是單機的簡化結構。

自動線級:這是最高級別，它有一個主控PLC，控制其下的區域。

工程層:有獨立的配電系統，但沒有PLC，只有分布式模塊，由自動線控制。顧名思義，它具有很大的獨立性，可以作為一個單獨的項目進行設計和制造。當自動線很小時，這個級別可以省略。

功能組層:根據工藝劃分，將實現某一工藝功能的工段設備劃分為一個功能組，屬于工程層，當省略工程層時，屬于自動線層。

面向對象編程不一定需要使用上述結構，但是好的電氣結構更有利于面向對象編程。

2.任何控制對象邏輯都是在“類”中實現的。

為此，有必要分析與受控對象相關的信息。例如，對于電機，需要考慮以下相關信息:

輸入信息:

、電路保護信息，如電機的空氣開關、熱繼電器等。

、功能保護信息，如電機限位開關、風扇氣壓開關、油泵油位開關等。

、啟停條件下，上述電路保護和功能保護可能導致電機運行終止，而復位也可能導致重啟，但這里的條件是指正常運行的啟停條件，如順序控制的流程步驟。

控制方式:如手動和自動。

故障復位:通過復位信息重啟。

輸出信息:

控制輸出，如控制電機的主接觸器。

，狀態信息輸出

，故障輸出

.........

狀態存儲信息:

用于代碼實現的中間變量和可由人機界面讀出的狀態變量等。

將以上所有信息集成到一個類中，并嘗試標準化該類的參數。但是，與高級編程語言有一些不同。對于Step7，應該遵循的標準是:程序結構用FC實現，對象控制用FB實現。以下結構體系(其電氣結構來源于上面的介紹):這只是一個粗略的PLC程序架構體系，好的架構應該更完善、更科學。

3.規劃數據結構。

數據結構的定義很重要，盡量統一這些結構，不用擔心存儲空間。如今的PLC內存足以容納大量數據。有一點是，在步驟7中，我們應該盡量不要在類外定義數據結構(UDT)，而是在類內定義它。雖然會造成同一結構在不同類中的重復定義，但會提高類的獨立性。

?第三，優越性

1.標準化

使用這種設計模式，程序設計可以分為兩個階段，即標準庫、基礎架構開發和實際應用級設計。其中，標準庫和基礎架構是使程序標準化的基礎，而應用層設計是針對具體的控制工程編程，這樣程序員可以分為兩類，一類是標準開發，由資深程序員負責，另一類是應用設計(包括程序調試規劃到應用設計)，由經過標準化培訓的一般程序員完成。通過這種分配，可以解決中國工業自動化面臨的尷尬局面。在中國傳統的受控行業，一個程序是一個人設計的，所以他還必須負責現場調試，經驗豐富的程序員一般都是30歲以后，已經結婚了，顯然長期出差對家人不好，所以很多優秀的程序員為了家庭考慮不得不改行，要么轉行到管理崗位，要么去制造工廠維修設備，這是資源的嚴重流失。毫無疑問，使用上述設計流程，我們可以讓有經驗的程序員設計標準庫和架構，讓剛踏入這個行業的年輕人設計和調試應用。這不僅能讓老程序員在不影響家庭的情況下繼續自己的工作，還能讓年輕程序員參與現場調試，培養自己的經驗，增加收入。

這可能會讓一些人擔心年輕程序員能否參與現場調試？可以肯定的是，沒有標準化支持的程序不僅可以由年輕的程序員編譯，而且在現場調試中也存在很多問題。但是有了好的標準化，一年半以上工作經驗的程序員應該可以獨立面對自動線。

PLC中面向對象編程的核心是黑盒編程。對于步驟7，我們使用FB來控制每個對象。控制邏輯、報警處理和信號交換都在FB中。對于應用程序設計人員來說，他們不需要了解里面的代碼實現，只需要知道FB的功能以及如何很好地使用它，這就大大降低了對應用人員編程能力的要求。對于編程，他們只是遵循架構，復制代碼并更改輸入和輸出條件。

調試呢？很多人認為使用FB編程最大的麻煩是在反復調用FB后無法診斷這些代碼。嚴格來說，這是真的。除了從后臺數據庫查看信息，我們無法監控FB反復調用后的代碼。但正如我所說，這是黑盒編程。我們不需要診斷這些代碼，只需要知道什么樣的輸入和什么樣的參數設置導致什么樣的輸出。代碼的邏輯和功能是標準庫開發人員的責任，這就要求標準開發人員在不同的條件下對自己設計的功能塊進行不同的測試，以保證正確性，同時還要編寫完整詳細的功能描述文檔，方便應用程序設計人員理解這些塊。標準架構不是一勞永逸制定出來的，需要針對千變萬化的項目不斷完善和修訂，這也是工程公司實際可以積累知識的地方。

程序不僅需要調試人員使用，還需要用戶(設備維護人員)知道，如果將完整的標準庫文檔交給用戶，可能存在技術泄露的可能；如果沒有，可能很難為他們診斷設備，這就需要標準制定者制作另一個文檔，即設備維護文檔，而知識的公開僅限于用戶使用程序進行診斷的能力。

2.可重用性和可管理性

計算機面向對象編程的優點還包括可重用性和易于管理，這在可編程邏輯控制器中也有應用。以步驟7為例，有必要討論FC和FB的區別。觀察數據類型，FB只比FC多了一個“STAT”類型。在使用中，FB需要后臺DB，而FC不需要。但由于這種差異，FB有自己獨立的數據存儲空間，而FC的數據存儲必須依賴公共變量(如中間變量M或共享DB)。有一個規則，程序塊的獨立性越強，它的可重用性越好，數據訪問沖突的可能性越小，管理也越容易。有些公司生產的PLC，其編程語言沒有類似FB的這個特性，可以用類似“FC+共享DB”的替代解決方案來解決，但其獨立性已經大大降低。

同一代碼的獨立性是制定標準的重要環節。很難想象一個與其他功能塊有著千絲萬縷聯系的功能塊，能夠在不同的項目中被有效地復用為標準塊。

縱觀計算機語言的發展，最初的編程是令人恐懼的，但今天的編程給了人們極大的解脫。有許多現成的標準類庫可供實際使用。人們可以把更多的編程精力投入到實現功能本身。plc編程也應該朝著這個方向發展。更多的人應該從事應用級的設計。那些標準功能塊不應該由不同的人重復開發。雖然各大PLC工廠都開發了大量的程序庫，但不同行業的工業控制對象也各不相同，此處可以結合plc視頻教程來學習。

3.先進的設計理念

在電路圖設計中，我們已經使用了控制對象的繪制方法，即在配置好基本的主配電電路和PLC后，我們將為電機、閥門、氣缸等各個現場控制對象繪制電路圖。它們的電源來自獨立的分配電路，控制和反饋與PLC相連，硬件鏈根據實際情況調整，控制對象堆砌得像積木一樣有組織。同樣，編程也可以通過對每個控制對象使用相應的標準控制塊來實現，有效地封裝了程序的控制細節，使程序看起來簡潔，易于維護，而好的設計可以使原理圖和程序有很好的連接，甚至實現一對一的關系。比如原理圖中的一個控制對象可以在程序中找到對應的FB調用，真正實現控制面向對象編程。

有些人可能會有疑問，PLC編程大多是分步編程，每個標準塊都是針對控制對象的，那么如何實現控制順序呢？這就需要編寫一個專門的FB塊進行順序控制，或者用西門子現成的Graph7來實現，這和一般的編程沒什么區別。

結論:目前工業控制領域有很多程序大師。他們非常精通算法，有自己的編程思路。當我和一些人討論標準化時，他們意識到標準化的高效率，但他們認為這不能反映他們的編程水平。是的，如上所述，應用層面的編程不應該有很高的編程水平，但是想一想，一個人能一輩子都在做現場調試嗎？如果你想展示你的價值，你可以從事標準編程。也希望他們能花一點時間研究一下程序架構，各行各業，真正的高手是系統架構設計師，而編程小技巧只是一個好架構的錦上添花。本文來源：www.jcpeixun.com。
?

　　審核編輯：鄢孟繁