現場(chǎng)總線(xiàn)互用性測試
加入技術(shù)交流群
供應商要進(jìn)行測試，還因為（a）用戶(hù)希望系統穩定（b）DD/CFF文件有時(shí)也會(huì )發(fā)現問(wèn)題（c）設備性能有時(shí)也會(huì )出現問(wèn)題（即使通過(guò)FF認證）（d）主供應商希望調試或是改進(jìn)他們的系統。最后一個(gè)原因很重要，因為所有的這些測試也是在幫助控制系統更加穩健。除了系統供應商的現場(chǎng)總線(xiàn)互用性測試，其它無(wú)法做到。
HIST系統測試的任務(wù)
在把上述觀(guān)點(diǎn)發(fā)展深入之前，討論Foundation’s Host System Interoperability Test,即HIST，旨在認證FF主機。這個(gè)過(guò)程的更多解釋參見(jiàn)基金會(huì )網(wǎng)站，在此不再贅述。概括的講，HIST是一個(gè)用來(lái)檢測系統可以執行基本的現場(chǎng)總線(xiàn)功能的測試。盡管它作為一種確認哪種功能是主系統已經(jīng)實(shí)施的工具，但是它不保證這些功能對于所有的注冊設備或是應用程序可以工作正確。這無(wú)需責怪HIST程序，但是卻是事實(shí)。它并沒(méi)有要成為一個(gè)全面的功能測試程序。雖然HIST是一個(gè)很有價(jià)值的工具，但是它不能取代供應商提供的主系統互用性測試，而且這種情況在近期也不會(huì )改變。但是，也同樣指出，HIST已經(jīng)在很廣泛的產(chǎn)品范圍內應用，從完全成熟的控制系統到實(shí)驗室或是工作臺控制工具。但是控制系統所要求的功能遠比工作臺校準工具要多，所以，HIST必須可以在這個(gè)領(lǐng)域的兩個(gè)極端實(shí)施。
一般測試原則
本小節將會(huì )闡述Honeywell現行的互用性原則，在很多情況下，這些原則也同樣被其它廠(chǎng)商所采用，但是這些規則卻在供應商之間促在差異，但是從沒(méi)有人把他們做對比。
通常系統供應商會(huì )免費為用戶(hù)或是設備供應商提供他們所采用的原則，作為回報，系統供應商要為他們提供設備來(lái)進(jìn)行測試。至今，這已經(jīng)成為廣泛接收的實(shí)踐。這里，必須給予FF標準以足夠的信任，就像在大多數系統中所實(shí)施的一樣，把一個(gè)新的設備集成到一個(gè)系統相對容易。這有助于進(jìn)行相關(guān)的合理測試。
在告知用戶(hù)和系統供應商那些設備已經(jīng)被檢測等這些測試方面不同的系統供應商之間有所區別。在Honeywell，我們把已經(jīng)在公共網(wǎng)站上成功檢測過(guò)的設備文件郵寄出去。http://www.acs.honeywell.com。這是我們的慣例。既然我們的系統可以直接使用設備文件，它也是支持用戶(hù)工程的重要機制，其它大多數公司好像是利用網(wǎng)絡(luò )工具達到這個(gè)目的。需要指出，我們特別郵寄出的這些與我們系統配合工作的設備文件，可能需要或是不需要被修改或修正，或許有很多版本的可用文件。我們也包括將此設備集成到我們系統的任何信息。后者是系統供應商郵寄設備文件的最主要原因。即使設備文件工作正常，也許會(huì )有其它一些系統差別將會(huì )被指出。
當測試揭示了一些問(wèn)題時(shí)，接下來(lái)該怎么辦呢？一般來(lái)講，供應商力求通力合作，把問(wèn)題解決，這永遠是首先要做的。耐心在這里很重要，因為修理和改變需要時(shí)間，而這些過(guò)程往往需要再測試，但是有時(shí)用戶(hù)需要規定這個(gè)節奏。如果有些問(wèn)題或是性能沒(méi)有被解決，尤其是涉及控制，我們經(jīng)常會(huì )通過(guò)設備文件為設備供應商提供可以相互接收的信息。注意，我們并沒(méi)有公布測試報告的細節；我們認為設備文件可以引起足夠的注意。
我們的互用性測試計劃和原則并沒(méi)有公開(kāi)，但是對于提出要求的用戶(hù)和設備供應商都有效。
測試步驟
測試的主要目的是按照用戶(hù)要求支持所選用的基金會(huì )現場(chǎng)總線(xiàn)，是注冊的設備與主系統可以相互操作。這個(gè)目的在工業(yè)得到一致響應，因為其它系統供應商支持他們的用戶(hù)。文件的互用性和測試過(guò)程中發(fā)現的功能型問(wèn)題，與供應商之間合作解決問(wèn)題也是一些很重要的目的。
以下是測試設備時(shí)的一些基本要點(diǎn)，這些已經(jīng)應用到我們的設備，但是對于其它供應商也非常普遍：
● 從供應商或是用戶(hù)處得到典型的設備和設備文件。
● 根據設備文件建立一個(gè)設備的系統模型（通常叫做實(shí)驗室模型）這是測試設備文件的第一步（這一步在廠(chǎng)家之間各不相同）。
● 如果遇到問(wèn)題并且我們可以解決它，我們解決并告知供應商。極少數情況下，我們如果不能解決，我們要與供應商一起解決。這時(shí)會(huì )發(fā)現必須對我們的系統需要做一些改變或是修正。
● 下一步是加載設備，（在我們的系統中）也要加載電源和所有的傳感器模塊。要保證：（a）應用默認設置協(xié)議的設備穩定（b）所有的參數工作正常。當我們尋找任何潛在的互用性問(wèn)題時(shí)，這在一個(gè)從現在多個(gè)廠(chǎng)家的設備所組成的設備混合體的系統中完成。
● 一旦測試基本的設備操作，在控制策略中的各種可用功能塊將會(huì )被使用和測試。這一步可以涉及AI或是DI模塊到輸入輸出和功能塊的大量組合。（在下一節中將會(huì )有詳細介紹）。
● 測試功能塊要通過(guò)“硬件控制”和“軟件控制”設置實(shí)現。這是兩個(gè)非常重要的測試環(huán)節。另外要使用不同的或是很大的循環(huán)周期。
● 其它一些行為和特征的測試包括確認：
○廠(chǎng)家指定的可以讀寫(xiě)的讀寫(xiě)參數。
○只讀參數可以被讀取，并且包含廠(chǎng)商規定的期望值。
○設備地址分配和標志名可以被更改。
○可選的，如果文件可用，則可以執行設備校準。
○對于設備，可以執行LAS，連接到主系統LAS失敗恢復和正確恢復工作。
○系統行為，例如報警、總線(xiàn)電源恢復失敗，與活動(dòng)的總線(xiàn)連接/斷開(kāi)、設備如期保存或是恢復工作。
○電源模塊的所列選項工作正確，尤其是事件報告。
● 注意，有些設備有額外的廠(chǎng)家專(zhuān)有的傳感器模塊需要測試。例如，大多數Rosemount 傳感器擁有TRANSDUCER_LCD模塊控制顯示行為。
控制行為測試
使用功能塊對于基金會(huì )現場(chǎng)總線(xiàn)來(lái)說(shuō)十分特殊，所以要格外注意功能模塊控制行為。從某種意義上說(shuō)，這個(gè)測試對于控制系統供應商具有一定的意義。 基金會(huì )現場(chǎng)總線(xiàn)設備是控制系統這幅巨圖中的一部分。大多數系統供應商以控制的基本原則為基礎，很好的理解那些必須正確工作的行為。
下面是測試現場(chǎng)總線(xiàn)設備功能塊行為的一些典型測試案例。圖2顯示了一個(gè)PID互用性控制測試應用的典型案例。記住，輸入輸出模塊連接到傳感器模塊，所以這些將會(huì )一同測試?？刂乒δ軌K（PID等）沒(méi)有這樣的聯(lián)系。
● 測試簡(jiǎn)單的輸入設備（AI和DI）連接到主機或是其它設備功能塊。驗證由報警或是AI和DI模塊的狀態(tài)值所引起的VALUE和STATUS改變。驗證報警行為，包括禁止和優(yōu)先權。確認發(fā)布信息每個(gè)周期將會(huì )更新。確認與傳感器模塊的正確工作范圍。有些情況下，當有很多通道時(shí)，要確認所有的通道正確工作。
● 測試PID控制行為，使用IN、CAS_IN、 RCAS_IN、 ROUT_IN、和FF_VAL作為輸入，檢查各種控制和PV選項工作正常。確認震蕩形式的正確性。測試任何讀回或是反饋功能工作正常。對于多通道設備（如DO模塊），確認通道分配任務(wù)正確且不沖突。
● 檢測設備上的功能塊可用。對于不同的控制有不同的設備特定指令。
● 測試設備功能塊——輸入、輸出和控制——和主功能塊。
● 因為有兩種不同的功能塊連接，發(fā)布/訂閱和異步連接，兩種都應該測試。例如，RCAS_IN或是RCAS_OUT是遠程的客戶(hù)服務(wù)連接，為DDC控制而設計，CAS_IN是發(fā)布/訂閱連接。在應該被應用的地方，初始化應該被確認。這些測試也同樣在重載連接時(shí)進(jìn)行。
圖2 典型的現場(chǎng)總線(xiàn)兼容性控制應用程序 ● 確認默認的功能塊和設備的操作狀態(tài)。注意，在很多鐘情況下許多默認的狀態(tài)是不可以測試的，因為這會(huì )具有破壞性，很難模擬，因為系統供應商并不了解它們。
評論