關鍵詞：LonWorks，驅動，LNS，組態
伴隨著LonWorks網絡技術在自動化市場的迅速發展，LON網絡驅動程序開發成為LonWorks網絡構建的重要一環。本文意在提醒可能遇到的一個難點。通用組態軟件的通用性（畫面組態方便，Windows平臺，滿足各種行業應用等）、靈活性（集成各種控制設備I/O驅動服務）和可靠性（系統運行)，成為工業級項目數據采集監控系統的首選。通用組態軟件的Lonworks驅動程序開發成為熱門話題。
LNS DDE Server由于仍然采用DDE 協議，Lonworks控制網絡設備而言，存在速度及其瓶頸問題。在一些大型系統中，可能滿足不了用戶的要求。（雖然最新的LNS DDE Server 2.1在性能上有所改進，采用IP CHANNEL，采用窗口控制的采集方式，克服了原有“串行”的采集方式，和一臺Server的瓶頸，但還是基于DDE 協議）。基于OPC的Lonworks 產品在國內也有應用。但Lonworks OPC Server基本上是國外產品，價格昂貴。
國內組態軟件開發商已經開始關注Lonworks驅動這個市場，，雖然各個開發商擁有OPC Automation 開發平臺，但是為了增加自身產品的壟斷，或者一體化等，國內通用組態軟件的驅動程序，一般為動態連接庫形式，僅應用于自己的組態軟件，比如FIX，CITECT組態軟件等Lonworks驅動（是基于16位API的，現在已經不用）。
組態軟件公司開發Lonworks驅動程序必須搞清楚Lonworks網絡配置的基本過程。基于LNS平臺開發驅動程序，必須說明是在那個版本下開發的，由于ECHELON LNS平臺向后不兼容，所以，不同的版本開發的驅動程序和網絡管理工具無法兼容。例如，用LonMaker for Windows 3.0 配置網絡，用LNS2.0平臺開發的組態軟件驅動程序就無法打開數據庫。當然，如果不是基于LNS開發的驅動，就沒有這個問題，但是，需要網卡接口API函數，同時組態軟件I/O配置可能要麻煩一些。基于LNS平臺的配置由于LNS 的層次結構，配置過程“域名化”或者“DNS化”。而非LNS平臺，直接讀取的是網絡節點的網絡映象，配置過程“邏輯地址化”。
