現場總線互用性測試
加入技術交流群
解決問題
關于解決問題已經討論過一些。當測試出現一些問題時，一些技術或是工具可以解決問題，或是提供一些數據細節。包括：
● 使用NI配置或是其它操作臺校正工具例如Rosemount375來研究問題是出在設備上還是系統上。例如，NI配置軟件可以確認一些即使標出可讀/可寫，但是其實并不可寫的一些參數。
● 使用監視軟件來捕獲一些總線上的時間用來確認設備的行為是否正確。這需要對基本的FF協議特性有著高度的理解，而不是一般的普通用戶所能掌握的。
● 使用DD瀏覽器來檢測所提供的DD文件的細節。例如，我們可以看到關于參數預定性能的一些細節。當然，這也需要對FF規則有著深入的理解。
● 使用其它的設備（已經成功的檢測過的），對一些性能進行比較和對比，例如報警和控制功能。
隨之而來的一些問題就是某個問題是來自設備還是系統。有時必須要參照一些FF技術規則，以用來確認是不是在某種程度上有些規則上的違背，但是，經常會遇到一些“灰色區域”，就必須與基金會一起解決。當這些問題出現時，就要就需要一方或是多方可以起草一個AR文件，來取得技術規則上的一致。AR進一步澄清規則的不明確部分，并可以進一步改進FF技術。有一種錯誤的理解就是，既然一個注冊設備已經經過測試了，互用性問題必須是主機所默認的。
這里必需明確一點，就是設備之間會有區別。當FF設備供應商被要求在他們的設備和功能塊上使用特定的標準參數時，他們也被允許添加自己的特殊參數，而且并沒有要求標準的模塊的內部功能性能完全一致。例如，兩個不同廠商的設備上的PID模塊可能看上去一樣，但是執行起來并不完全一樣。他們內部的一些公式等還是屬于廠家所有。這是被允許的，也為區別提供了可能。實際上，區別有時看起來并不大，用戶當然也在他們的一致性上得到很好的服務。
Honeywell 測試的特點
Honeywell堅持使用兩套獨立的系統來進行對現場總線設備的測試，每套系統的側重點不同。我們主要的設備細節測試工廠是位于印度Bangalore的現場總線互用性測試實驗室，實驗室隸屬HTSL。圖3中所示，為我們的主管工程師和系統在實驗室。圖4、圖5也是實驗室。以前所討論的方法都是在這個實驗室使用的。一個現場總線設備的平均測試時間大約要花費一周左右，但是這些在設備上根據功能塊的數目和設備的復雜性而有所差別。正如所想象的那樣，這也和所遇到的問題有關。
圖3 在印度Bangalore的Honeywell現場總線測試工程師。 我們在華盛頓賓夕法尼亞街區還擁有一個Experion PKS測試的大型系統，基于我們的發展工廠。這個大型系統主要關注于擁有H1負載，大量的報警和顯示負載的大型系統。圖6和圖7顯示的是大型系統的一部分。我們把從不同廠家的設備集成在一起。
另外，一些小型的系統也為開發、解決問題和驗證目的所保留。包括Honeywell的TAC所運行的一些系統。但是測試的主要責任還是屬于Bangalore工廠。
圖4 于印度Bangalore的Honeywell現場總線戶用性測試實驗室
評論