MapReduce在MES中的應用

MapReduce作為一種重要的編程思想，在互聯網開發特別是分散式開發中得到了廣泛的應用，MES通常是集中式開發系統，但是MapReduce的方法論也可以予以借鑒，本文以三個實際應用的例子來進行探討。

應用一：動態工藝參數下載

在MES中，動態工藝參數下載是一個很常見的場景，即在生產的過程中，需要從系統下載得到一些動態工藝參數，比如一些工單的屬性、BOM中的特殊零件物料號、在某工位測試的次數等。

最簡單的應對方法是寫一個專門的程序，把所有可能的邏輯都包含進去，這樣帶來的問題是：

1) 這個程序的邏輯非常複雜。

2) 每次增加工位都需要對程序進行升級，並且升級時可能需要系統停線。

現在我們用MapReduce的方法論對它化繁為簡。

首先我們認識到，這個程序的核心是一個函數，輸入產品序列號和工位，輸出工藝參數，其中工藝參數是若干個工藝變數的組合。而工藝變數的生成方法是：

1) 常數

2) 工單屬性

3) 正則表達式

4) 資料庫查詢

現在我們分別進行Map和Reduce的操作。

1. Map

首先我們建立一個Map表，把所有工藝參數的變數在資料庫中進行配置：

2. Reduce

然後我們分兩步進行Reduce：

1) 分別得到各個工藝變數的值。

2) 將多個工藝變數的值進行規範處理，並組合得到完整的工藝變數。

其中對於第1步，分別對每一種工藝變數類型定義一個Reduce函數，如：

1) 常數直接從內存中提取Map查詢得到的值。

2) 正則表達式則進行運算處理。

3) 對於資料庫查詢，則運行對應的資料庫函數，並配合輸入的產品序列號和工位，經過計算得到對應的變數值。

這樣處理的好處是：

1. 化繁為簡，每一步都是相對獨立的操作，減少了系統的耦合性。
2. 每一個工位、每一個工藝參數、每一個工藝變數的定義都是相對獨立的。增加新工位不會影響舊工位，更新一個工位的參數不會影響其它工位，儘可能地減少了變數對系統全局的影響。

詳細設計可參見我的文章：《淺談 MES的通用設計之二：工藝參數的下載》

應用二：通過物化視圖同步數據

某工廠需要將生產數據從MES同步到維保系統，其中生產數據包括：產品序列號、工單信息、上線時間、上線工位、下線時間、下線工位、關鍵零件部批次號、關鍵檢測工位檢測次數、是否一次性通過等。

常見的做法是通過SQL把原始數據映射到物化視圖，然後另建一個SCHEDULED JOB去定期刷新。

但是問題在於，這個SQL的業務邏輯非常複雜，要關聯多張表，並且要進行分組統計、遞歸等較消耗資源的計算。

下面我們看看怎樣用MapReduce的方法論來進行簡化。

1. Map

首先我們列一個表，看看最終輸出欄位的計算邏輯。

從上表中我們可以看到要查詢很多的歷史記錄表，而這些表在設計時並沒有針對統計進行優化。

下面我們看看怎樣在Reduce操作時減少查詢的時間。

2. Reduce

首先有一個額外的因素要考慮：數據同步的時機。

場景一：數據同步和MES生產是錯開的，比如生產在下午結束，而同步在晚上進行，那麼即使同步時消耗了大量的資料庫資源也不會對生產造成影響。

場景二：生產和同步同時進行，那麼就必須排除同步作業時資料庫查詢對MES實時生產作業的影響。

下面我們分別針對各欄位進行Reduce的優化說明。

1) 產品序列號

由於序列號屬性表是一個主表，結構較簡單，一般直接查詢即可。

針對場景二，如果數據量特別大(比如小型數碼產品的生產，一天可能多達近100萬的數據量)，那麼可以這樣處理：

a) 建一個新表N，用於存放已下線產品的數據，定義屬性：序列號、工單、上線時間、上線工位、下線時間、下線工位、關鍵檢測工位檢測次數、是否一次性通過。

b) 在序列號屬性表裡建一個觸發器T，每當狀態屬性更新為下線時，自動將序列號、工單、上線時間、上線工位、下線時間、下線工位這些數據查詢得到後複製到表N。

這樣我們就得到了一個數據量較小的表，而且同步所需的許多數據直接查詢此表就可以得到。

2) 工單信息

直接從序列號屬性表查詢就可以得到了。

針對場景二，工單和序列號一起進行複製作業。

3) 上線時間

上線時間需要查詢歷史記錄表，而且需要做一個分組統計的動作，非常消耗資源。

為了簡化邏輯，我們可以編寫一個查詢上線時間的資料庫函數FFT，根據序列號檢索，得到第一次經過上線工位的歷史記錄時間。

針對場景一，我們可以直接在查詢SQL調用此函數得到輸出欄位。

針對場景二，我們可以讓觸發器T調用此函數得到上線時間然後輸出到表N。

4) 上線工位

編寫一個查詢上線工位的資料庫函數FFS，根據序列號檢索，得到第一次經過上線工位的工位名稱。

針對場景一，我們可以直接在查詢SQL調用此函數得到輸出欄位。

針對場景二，我們可以讓觸發器T調用此函數得到上線工位然後輸出到表N。

5) 下線時間

編寫一個查詢下線時間的資料庫函數FLT，根據序列號檢索，得到最後一次經過下線工位的歷史記錄時間。

針對場景一，我們可以直接在查詢SQL調用此函數得到輸出欄位。

針對場景二，觸發器T直接更新表N的下線時間屬性。

6) 下線工位

編寫一個查詢下線工位的資料庫函數FLS，根據序列號檢索，得到最後一次經過下線工位的工位名稱。

針對場景一，我們可以直接在查詢SQL調用此函數得到輸出欄位。

針對場景二，觸發器T直接更新表N的下線工位屬性。

7) 關鍵零部件批次號

由於BOM存在層級結構，零部件的追溯記錄存在一定的遞歸關係，做遞歸查詢較消耗資源。

但是由於要同步的關鍵零部件的結構關係是較固定的，因此我們可以編寫一個視圖VG來複制關鍵的業務數據。

針對場景二，如果結構特別複雜，我們可以針對每個關鍵零部件分別編寫函數FG1/FG2/FG3來進行數據抽取，然後利用觸發器進行調用後複製數據到表N。

8) 關鍵檢測工位檢測次數

編寫函數FTC來計算檢測次數。

針對場景二，利用觸發器進行調用後複製數據到表N。

9) 是否一次性通過

編寫函數FTT來計算是否一次性通過。

針對場景二，利用觸發器進行調用後複製數據到表N。

下表列出了新增的Reduce操作：

然後再輔助以下的操作，以方便將來的維護、調整：

1) 新建一個視圖VW，結構和物化視圖一致，通過查詢表、視圖VG，並調用相關的函數，來得到所有需求的數據。

2) 把物化視圖的SQL更新為：SELECT * FROM VW; 這樣做的好處是，如果需要做一些調整，我們可以直接在視圖VW里進行更新，而不需要重新編譯物化視圖。

3) 新建一個存儲過程SPW，用於執行刷新物化視圖的操作。

4) 在SCHEDULED JOB里直接調用存儲過程SPW，實現定期刷新。

通過以上的Map-Reduce操作，我們就把一個業務邏輯非常複雜的物化視圖查詢邏輯，轉換成許多個業務邏輯相對簡單、耦合性弱、查詢效率高的資料庫操作，簡化了邏輯，增強了性能。

應用三：與PLC通訊

在許多工廠，用PLC控制設備，然後通過OPC與MES建立通訊。

OPC是一個廣泛使用的工業標準，開發和部署都非常方便，而.NET對OPC的集成支持也非常好。

通常的做法是，在MES伺服器上部署一個OPC CLIENT，建立與OPC的通訊，而MES對OPC的讀寫可直接映射成對PLC的讀寫操作。

而這樣做的缺點是：

1) MES和PLC的耦合性太強，一旦MES停止響應則PLC也無法指導設備工作。

2) MES里集成了很多和PLC握手的控制邏輯，和MES的業務邏輯交織在一起，增強了邏輯的複雜度，降低了問題診斷的效率。

而現在有不少MES商業軟體供應商慢慢地把PLC通訊的這一塊從MES業務邏輯中分離出來，方法是建立一個通訊的中間層。如Telit公司的deviceWISE能夠把PLC數據流轉換成JAVA消息隊列，這樣對於應用系統來說，PLC來源的數據和其它來源的數據在經過轉換後已經沒有了形式上的區別，應用系統只要處理業務邏輯即可。

這裡有一個前提，就是所有握手邏輯都在PLC里實現，OPC中間層只轉換業務數據。

更進一步地，我們可以建立一個IT PLC，專門處理控制層的邏輯，並且為OPC中間層準備特定格式的數據。這樣就形成了設備PLC-IT PLC-OPC-MES伺服器這4層結構。

下面舉一個汽車裝配工廠車輛識別模塊的例子。

下圖是傳統互動式握手的示意：

我們可以看到在MES伺服器上需要編寫握手的邏輯。

下圖是增加IT PLC後，以請求/應答方式進行握手的示意圖：

我們用MapReduce的方法論對它進行分析：

我們可以看出，經過MapReduce處理後，在每個層面上的邏輯複雜度都得以減少，更加專註於業務的實現。