上位機軟件的主要功能是采集各儀器的數據，然后存儲起來，并傳送到環保局平臺。

剛開始使用的是組態軟件（用以顯示流程圖），然后再開發了報表軟件、數據上傳軟件。因為組態軟件使用的是標準Modbus協議，而很多儀器使用的協議根本就是自定義的，所以還要加一個協議轉換軟件，把各種各樣的協議轉換成Modbus協議，讓組態軟件去讀。除此之外，我們還希望軟件能夠開機啟動，就增加了延遲啟動的第三方軟件。

這樣一來，每個站點要安裝和部署的軟件非常多和雜亂。加上每個站點都有自己的特點，軟件出現了大量的版本。有上位機的版本管理、升級維護時，出現了極大的麻煩，管理成本極高。很多時候會有這樣一種情況，前面開發的人走了，后面就沒有人能維護他的軟件了。

基于上面的情況，我和團隊重新設計和開發了上位機軟件，具有以下特點：

（1）軟件集組態、采集、傳輸、報表、自動啟動等功能于一體，一臺工控機只有一個上位機軟件。

（2）上位機只有一個版本，所有站點都一樣。站點的不同特點通過配置文件來實現，而這個配置文件不隨更新而變化。

（3）儀器五花八門，但我們把它們歸于一體，用同一個模型去表現。

（4）在對儀器的支持和界面功能上，具有強大的擴展特性和靈活性。

以下是部分軟件界面截圖：

儀器歸一化設計

這是具體內容的第一篇，我們先來講述儀器的歸一化設計。

儀器是各種功能都有的，我只舉我們在環境監測這方面所用到的儀器。我們要測試水是不是有污染物質，污染到什么程度，我們要測試水體的高錳酸鹽指數、氨氮、總磷、總氮等值。我們的站房有一個后備電源，我們要知道市電是否斷電了，是否在用備用電源。我們的站房是有空調的，我希望知道站房的溫度和濕度，于是就有了一個溫濕度計。我們可能還會有流量計、DTU、數字儀等儀器。這些儀器跟工控機的連接也不盡相同，有的使用串行線，有的使用網線。用網線的儀器，有的作為客戶端，有的作為服務端，有的使用UDP。總之，這些儀器的通訊協議是五花八門的，通信鏈路也是有區別的。

但我們需要對儀器做出歸一化設計。

其實無論儀器有什么功能，工控機對儀器的操作無非就兩個：讀和寫。讀的話，可能是讀到測量的值、儀器的狀態等；寫的話，就是啟動儀器測量、修改儀器的參數等。而讀和寫的操作，都是通過發送和接收完成的。雖然通信協議各不相同，但我們總是可以把發送和接收的內容轉化為最基礎的字節流。要發送怎樣的字節流，接收到的字節流如何解釋，就要根據儀器的特性去定義了。

根據這樣的特點，我們為所有儀器定義了一個基類，它包含了發送字節流和接收字節流兩個方法。而所有儀器類，都繼承自這個基類。

每個儀器特定的類，只需要完成拼裝發送的字節流，和解析接收的字節流即可，它不需要理會如何發送和接收。而實際上的發送和接收，我們知道鏈路是有多種的，如上面提到的串行線和網線。使用哪種方式去傳輸，我們需要根據儀器的屬性去判斷。如下圖所示的方法，在基類里實現。

解決了上面儀器類的結構設計以后，我們需要考慮儀器的屬性如何表示和存儲。我們把所有儀器都稱為設備，設備包含以下內容：

（1）名稱。

（2）傳輸方式，以及傳輸的參數。例如用串口，那應該有串口號、波特率等。如果用網線，應該有IP、端口等。

（3）使用的通信協議。選定之后，上位機能夠找到相應的通信協議類，對字節流進行操作。順便一說，我們把通信協議類用反射的方法去做，每個協議是一個dll，選擇不同的協議即會執行不同的代碼。

（4）因子列表。

沒錯，說到這里，我們就發現，工控機設備里有一個因子的概念。因子是什么？這個比較難解釋。從最原始的因子來看，因子就是儀器的測量值。例如我們有一臺溫濕度計，它的測量值會有兩個，分別是溫度和濕度。我們就把溫度和濕度作為兩個因子。我們對因子的概念進行擴展，把狀態也作為因子。例如儀器的工作狀態、故障狀態，都可以看作是一個個的因子。甚至，我們把控制儀器的命令，也看成是因子。例如是啟動測量、更換運行模式，每一個動作都看成是一個因子。這樣下來之后，儀器的所有功能，都變成了因子的列表。因子有很多屬性，但不是所有因子都一樣的。名稱是我們想到的唯一一個共性屬性。我們在實際的開發過程中，定義了幾種因子：

（1）實際因子：就是測量值。它應該有單位、超標限制、因子地址（Modbus協議）等屬性。

（2）計算因子：跟實際因子類似，只是它不是直接讀取儀器值得到的，而是根據實際因子計算出來的。這樣的話，計算因子就要有一個表達式的屬性，例如是：溫度*9/5+32

（3）狀態因子：儀器的狀態。它的值不一定是數，可能是一個字符串。

（4）反控因子：對儀器的控制命令。可以用一個數字去表示控制的類型，工控機只需要在協議類里面解釋清楚即可。

通過上面的方法，我們把所有儀器都歸一成統一的類了。