西門子PLC “事務型” 信息的通信

楊繼志

（北京航天試驗技術研究所， 北京 100074）

0 引言

西門子PLC 之間的通信有兩種最為常用的方式，一種是雙邊通信，通信雙方都需要編寫通信程序，還有一種是通過PUT/GET 機制實現(xiàn)的單邊通信，這種通信方式只需要通信一方編程，因此應用也是非常普遍的。 本文簡要介紹兩種機制在實際工程中的應用方式，但是本文并不準備討論西門子PLC 之間的各種通信方式的實現(xiàn)細節(jié)以及區(qū)別，而是在討論兩種最常用的西門子PLC 之間的通信方式基礎上，討論為“事務型”數(shù)據(jù)的通信提供一個更高層的協(xié)議的原因、 如何構造一個這種協(xié)議，以及協(xié)議通過SCL 程序的實現(xiàn)方法。 為什么需要一種更高層的協(xié)議，主要在于PLC 之間的通信機制的設計思想主要是為設備的控制，傳統(tǒng)上一臺PLC 與其他的PLC 之間的通信主要目的是控制或獲得對方的IO 點狀態(tài)或信息，但是隨著PLC 處理能力的提高，一些工藝、整線上的信息有些也在PLC 中進行處理，這樣就出現(xiàn)了一些“事務型”數(shù)據(jù)通信交換的需求，而這種針對控制設計的通信對于“事務型”數(shù)據(jù)的通信支持存在一些問題，因此需要一個高層協(xié)議解決這些問題。

1 目前的通信方式及特點

1.1 西門子PLC 之間常用的通信方式

西門子PLC 之間的通信常用的有兩種方式， 一種是在通信雙方的CPU 中調用通信函數(shù)（TSEND_C，TR CV_C）；還有一種通信方式采用PUT/GET 機制，通信雙方只需要一方進行編程， 這在設備控制通信中非常方便，相當多的SCADA 系統(tǒng)與西門子PLC 之間的通信也是采用這種方式，優(yōu)點是PLC 側不需要額外的編程，只需要將接口（DB 全局數(shù)據(jù)塊）屬性設置為允許PUT/GET 并且關閉塊的優(yōu)化存貯即可，這種通信不但適用于西門子最新的1200、1500 系列PLC 而且還適用于其較早一些型號的PLC，包括SMART200 等，因此應用較廣。 無論哪種通信方式一般的通信編程結構如下：把通信雙方叫做A、B，以采用PUT/GET 通信方式為例，其中PUT/GET 指令編程在A 中實現(xiàn)，控制功能是A、B 雙方控制一整套工藝設備，其中A 控制的工藝設備需要與B 控制的工藝設備進行通信， 在A 中生成兩個全局數(shù)據(jù)局塊如DB1_PUT，DB2_GET，用于向B 發(fā)送數(shù)據(jù)和接收B 的數(shù)據(jù)， 同樣，B 中生成兩個結構相同的全局數(shù)據(jù)塊，如DB1，DB2，其中DB1 與A 中的DB1_PUT 鏈接，DB2與A 中的DB2_GET 鏈接，通信過程見圖1。

圖1 常用的通信模式

通過這種通信方式，設備A 中的各控制點的狀態(tài)就實時傳遞到了PLC_B 中了，同樣地，設備B 中的各控制點的狀態(tài)也時時傳遞到PLC_A中。 PLC_A 控制設備B 中的控制點或獲得設備B 中的控制點狀態(tài)就如同控制本PLC 下的控制點一樣簡單和容易。

圖1 表達的這種通信方式工藝數(shù)據(jù)是存貯在接口中的， 而且一方的通信接口持續(xù)不斷接收另外一方的數(shù)據(jù)，造成本PLC 內的程序也不可以對接口中的工藝數(shù)據(jù)進行修改了，可以將這種現(xiàn)象叫做數(shù)據(jù)的“鎖死”。鎖死式通信是設備控制所必須的一種機制，所以對于單純的設備控制任務這種通信模式不存在任何問題，而且是必須的，但是對于讀寫整線唯一信息這類非實時數(shù)據(jù)就存在問題，包括不同通信方并發(fā)改寫問題，而且由于編程水平的不同，如果是不同單位分別負責整線某段設備控制，當一方程序存在瑕疵，則這種鎖死式通信會造成問題長期得不到解決，控制總體希望即使某些工藝段程序存在瑕疵， 問題也僅僅存在整線的一部分，不會對整線的數(shù)據(jù)和通信造成較大的影響，這些需求在“鎖死”式通信的情況下無法解決。

1.2 “鎖死”式通信

1.3 數(shù)據(jù)與接口耦合

圖1 表達的這種通信方式對于IO 控制是最為方便的，可以看到這種模式數(shù)據(jù)和接口是耦合在一起的，接口即是通信雙方的界面，也是工藝數(shù)據(jù)存貯的位置。在邏輯和工程實踐中均需要接口和數(shù)據(jù)解耦， 一方面在接口變化時不至于對數(shù)據(jù)存貯造成影響， 另外一方面保證數(shù)據(jù)的統(tǒng)一性。 這種數(shù)據(jù)與接口耦合情況可見圖2。

圖2 “事務型”信息接口和數(shù)據(jù)耦合

在通信雙方的全局數(shù)據(jù)塊接口中均有“事務型”信息，接口中的數(shù)據(jù)通過PLC_A 內部的處理后會將更新狀態(tài)放置在與PLC_B 通信的DB 塊位置處。同樣PLC_B 也可能根據(jù)本PLC中的設備運行狀態(tài)和工藝狀態(tài)對這個信息進行處理，之后再傳遞給PLC_A。 并不是所有的“事務型”信息的傳遞都采用如上的方式， 有些具體的項目的信息傳遞可能只有該過程的一部分， 但是完整的邏輯鏈條與上圖基本是一致的。

2 存在的問題

2.1 數(shù)據(jù)存儲于接口

如圖2 所示，直接采用單邊、雙邊通信機制傳遞事務型數(shù)據(jù)， 接口中的數(shù)據(jù)既是要存儲數(shù)據(jù)也要與多方進行“鎖死”通信，這樣存在的問題就是，多方均可對該數(shù)據(jù)進行直接的操作， 唯一數(shù)據(jù)管理方對該數(shù)據(jù)的管理能力削弱，根本原因是接口與數(shù)據(jù)存貯耦合，而一般在設計上希望的是進行一定的判斷之后才進行存貯數(shù)據(jù)的修改等操作，總控PLC 有相應的接受與拒絕修改工藝數(shù)據(jù)的能力，在這種接口與存貯耦合的狀態(tài)下就難以實現(xiàn)。 接口與存貯解耦、分離是解決“事務型”數(shù)據(jù)通信的一個核心思想，可以參考面向對象的思想解決這個問題， 接口中只存在一些實現(xiàn)（函數(shù)），數(shù)據(jù)只有通過接口中的實現(xiàn)才能獲得。

2.2 接口僅能傳遞數(shù)據(jù)

一般來說對接口能力的要求除能夠傳遞數(shù)據(jù)外，有時還需要能夠申請一些過程的運行，也就是由PLC_B 通過接口可以啟動PLC_A 中的某些過程，這也是接口與存貯解耦后的一個自然要求。 接口需要得到存貯在其他位置的數(shù)據(jù)顯然是需要通過某些過程實現(xiàn)的。 也就是接口除能夠傳遞數(shù)據(jù)還能夠傳遞某些函數(shù)的“指針”。通過PLC_A 中自己的函數(shù)對數(shù)據(jù)進行修改，同樣獲得這些數(shù)據(jù)也需要通過接口進行而不是直接獲得或修改，這樣便于將此類數(shù)據(jù)進行封裝。 而圖1、2 表達的通信過程接口僅能夠傳遞數(shù)據(jù)。

2.3 接口形式變化影響大

接口不可能一次性全部設計完成， 在項目進行過程中接口中的數(shù)據(jù)變得越來越復雜。 希望的接口一方面在項目實施過程中有一定柔性， 在項目的進化過程中接口的含義可以發(fā)生變化， 而這種變化卻不會帶來太多的編程結構方面的變化是最好的。 顯然這種模式要么在雙方通信前全部定義完成接口的含義， 并在后續(xù)的過程中接口完全保持不變，如果在項目進展過程中接口發(fā)生變化，則雙方的程序變化量較大， 特別是增加了協(xié)作雙方的溝通成本。 最好的方式是，在接口的大體形式確定后，在后續(xù)的項目演化過程中即使通信的需求發(fā)生了變化但是雙方的接口可以保持不變或基本不變， 而且通信一方若不對通信方面的編程進行修改也不會影響到這個項目的通信，這是一種自然的需求。 而這種鎖死的、接口和數(shù)據(jù)完全耦合在一起的通信方式是無法實現(xiàn)這個需求的。

3 解決辦法

3.1 通信接口與數(shù)據(jù)存貯分離

接口和數(shù)據(jù)分離是“事務型”數(shù)據(jù)通信的自然需求，能夠保證數(shù)據(jù)的唯一性和統(tǒng)一性， 但是需要接口和數(shù)據(jù)之間有一些函數(shù)關系， 比如通過確定的函數(shù)將數(shù)據(jù)放入存貯位置，或提取最新的數(shù)據(jù)并放入接口，因此需要在接口中描述這些動作以及動作需要的參數(shù)， 另一方面需要在全局數(shù)據(jù)塊開辟一個專門的DB 用于存貯數(shù)據(jù)，見圖3。

圖3 接口和數(shù)據(jù)分離

實現(xiàn)方式是設計一個全局數(shù)據(jù)塊，這個數(shù)據(jù)塊中包含一些信息，利用這些信息可以運行PLC 中的一些函數(shù)，顯然這樣的數(shù)據(jù)塊至少需要包含需要啟動的函數(shù)的函數(shù)名稱（當然并不一定是字符串型的數(shù)據(jù)類型，可以是整數(shù)型的數(shù)據(jù)類型，其實這種數(shù)據(jù)類型在后續(xù)的處理時更為方便） 和函數(shù)的參數(shù)。通過這個函數(shù)實現(xiàn)接口和數(shù)據(jù)存貯分離，即使是通信對象不遵守該協(xié)議的情況下也不會影響其他遵守協(xié)議的通信方。

3.2 通過接口啟動過程

通過一個全局數(shù)據(jù)塊實現(xiàn)驅動函數(shù)運行， 而且是函數(shù)名變量發(fā)生變化時運行一次， 避免了多個通信方得通信鎖死問題，而且實現(xiàn)了利用接口數(shù)據(jù)啟動PLC 內過程。利用這種機制建立一層協(xié)議，避免任何一方直接“鎖死”通信信息，雖然同一個信息也可能出現(xiàn)在不同的位置，但是這些位置只有一個是臨時的存貯位置， 而且任何一個通信方都不可能對其進行“鎖死”式的通信，避免由于某個通信方程序瑕疵造成影響。 協(xié)議的自動機描述見圖4。

圖4 協(xié)議狀態(tài)機描述

協(xié)議的狀態(tài)機描述：接口中函數(shù)名稱是否發(fā)生變化，如果未發(fā)生變化則繼續(xù)監(jiān)控接口，如果發(fā)生變化，則在函數(shù)驅動表中檢索響應的函數(shù)并執(zhí)行一次， 之后回到繼續(xù)監(jiān)控接口表中函數(shù)名是否發(fā)生變化。

接口中本質上是存貯函數(shù)的 “指針”，PLC 中只需要在一個永遠保持運行的監(jiān)控函數(shù)中一個CASE 語句維護實現(xiàn)函數(shù)映射表即可。 本文介紹這種編程思想時采用整形數(shù)作為“指針”，采用CASE 語句進行函數(shù)表映射管理。接口中的函數(shù)參數(shù)表是所有可能運行函數(shù)的參數(shù)并集，在具體編程和操作過程中，這個表也可能需要變化，當然如果采用DB_ANY 類型的數(shù)據(jù)可以保證這個接口的不變性，但是增加了處理函數(shù)的復雜性，增加了通信的復雜性，在實際的項目開發(fā)中也許是不適當?shù)?，因此做這種折中的考慮是實際項目開發(fā)可以接受的。接口中的函數(shù)一般是只需要運行一次即可，但是接口中的數(shù)據(jù)一般情況下都是全時間保持的，所以需要檢測函數(shù)名發(fā)生變化時運行函數(shù)一次。 如下一個DB 數(shù)據(jù)塊，這個數(shù)據(jù)塊可以起名稱為“INTERFACE”，見圖5。

圖5 函數(shù)驅動接口數(shù)據(jù)塊

通過函數(shù)Fun1、Fun2……就可以執(zhí)行品牌號改寫、獲取品牌號等函數(shù)操作，也就是將品牌號碼的讀寫添加到一個函數(shù)接口，而不是直接鎖死，這樣能夠保證改寫的一致性和并發(fā)改寫，“事務型” 數(shù)據(jù)是存貯在一個位置，其他位置僅僅可能會出現(xiàn)暫存數(shù)據(jù)。 函數(shù)映射表管理見圖6。

圖6 函數(shù)映射表

在OB1 中運行一個函數(shù)時時監(jiān)控DB1 數(shù)據(jù)塊中的Fun_name 是否發(fā)生變化，如果發(fā)生變化，則以Par1、Par2等函數(shù)參數(shù)運行相關的函數(shù)一次。

3.3 解決的問題

（1）靈活的接口數(shù)據(jù)定義。 從以上通信“協(xié)議”的描述可以看到，由于數(shù)據(jù)是通過函數(shù)的參數(shù)傳遞的，因此接口中的數(shù)據(jù)含義取決于當時運行的函數(shù)， 運行不同的接口函數(shù)，在同一個位置可以得到不同含義的數(shù)據(jù)，因此接口更靈活，且數(shù)據(jù)的獲得均是通過函數(shù)獲得，函數(shù)可以進行相關的判斷處理，避免鎖死通信的問題。

（2）實現(xiàn)數(shù)據(jù)驅動。通過接口中的數(shù)據(jù)實際上實現(xiàn)了驅動PLC 中的過程， 啟動和停止， 實現(xiàn)了通過接口驅動PLC 過程的目的。 接口不僅僅是數(shù)據(jù)的交換，而且可以運行對應PLC 上不同的函數(shù)過程。在項目演化過程中，雖然不可能保證接口的永遠不變， 主要是無法確定未來的函數(shù)的參數(shù)類型和數(shù)量， 如果對函數(shù)類型和數(shù)量進行一定的限制顯然是可以部分解決這個問題的， 但是顯然接口形式的變化比數(shù)據(jù)型接口變化的要小的多。 因為他本質上是實現(xiàn)了接口函數(shù)參數(shù)的“復用”。

4 結束語

目前西門子PLC 之間的通信都是為了設備控制而開發(fā)的， 因此通過各種通信方法控制其他PLC 上的設備就像是直接在本PLC 下的設備控制一樣方便， 但是這種通信方式對于“事務型”數(shù)據(jù)的通信就存在一些問題，主要表現(xiàn)在接口與數(shù)據(jù)耦合、“鎖死”式通信等。本文提出在該通信協(xié)議的基礎上開發(fā)一種高層協(xié)議， 解決接口與數(shù)據(jù)耦合問題、PLC 中數(shù)據(jù)對象的封裝等問題，并且使得通信除了具備數(shù)據(jù)交換的功能外還可以啟動對應PLC 中的某些過程，拓展了接口的功能和能力。本文中的“事務”型信息指的是不同于設備的控制信號和狀態(tài)信號， 比如生產線中的線上正在生產的產品的牌號和批次信息， 這些類型的信息一般在不同的PLC 和設備中均需要處理和存貯，但是整條線的該信息最好是存在一個共同的位置，通信有的時候并不是僅僅傳遞一些信息， 還希望通信方按照已經(jīng)商定的協(xié)議作出某種復雜的動作， 本文提供了一種解決如上問題的改進通信機制。