白酒發酵過程信息化監測軟件的設計與實現

羅 林，庹先國，張貴宇,3，王 昆，高 婧

（1.四川輕化工大學 自動化與信息工程學院，四川 宜賓 644000；2.四川輕化工大學 人工智能四川省重點實驗室，四川 宜賓 644000；3.西南科技大學 信息工程學院，四川 綿陽 621010）

0 引 言

在白酒固態發酵環節，發酵溫度與窖內微生物的新陳代謝相互影響，間接導致白酒品質受到影響。發酵時入窖溫度偏高，會使發酵過程中的升溫速度過快，可能導致酵母菌活性降低，從而引發白酒品質下降等問題。入窖溫度適宜，則釀造的酒大多品質較高。對于整個發酵周期，溫度需滿足“前緩、中挺、后緩落”的變化趨勢。

鑒于發酵溫度對白酒品質的影響，各大酒企對白酒固態發酵過程中的溫度數據十分關注。傳統的白酒釀造過程中利用人工監測方式對發酵過程中的溫度數據進行監測，以溫度計作為數據采集手段，利用紙質方式記錄和存儲，但存在數據誤差大、時效性差及人工成本高等問題。近年來，各白酒企業為提高生產效率紛紛投入到自動化釀造研究中，欲借助自動化技術實現白酒的信息化、智能化生產，以技術創新降低人力成本，同時提高生產效率。現已實現潤糧、裝甑、流酒等工序的自動化，但發酵過程中的自動化技術發展卻相對滯后，無論是數據存儲還是發酵過程可視化方面都并未有有效的監測軟件。針對發酵環節自動化水平的滯后性以及發酵溫度的重要性，以發酵溫度為主要研究對象，借助Android設備便攜、開發成本低等優點，設計了一款白酒發酵過程信息化監測軟件，為白酒行業在發酵過程中實現精確化控制、數字化管理提供條件，突破人工監測的局限。

1 軟件架構設計

本設計以Android為載體進行人機交互環境的搭建，借助移動設備的便攜性解決發酵現場難以隨時隨地監控的問題。信息化監測軟件以C/S模式設計，由服務器和客戶端組成。軟件結構如圖1所示。服務器內部的數據分析模塊可對數據進行邏輯處理，為客戶端進行正確應答，客戶端負責與用戶交互，并為用戶呈現發酵過程中產生的實時數據。

圖1 軟件結構

為滿足實際需求，軟件總體功能模塊分為管理功能和基礎功能兩大部分，其中管理功能模塊負責軟件中車間的創建與刪除、車間窖池信息鎖定及各項報警閾值的設定。基礎功能模塊分為用戶模塊、發酵概況模塊、報警模塊和窖池詳情模塊，用于展示分析或者響應結果。功能結構關系如圖2所示。

圖2 功能結構

2 客戶端設計及實現

2.1 客戶端整體布局設計以及實現

軟件所有交互性功能模塊均在Login_Activity、Home_Activity和WorkShop_Activity三個自定義Activity中實現，各Activity與功能模塊的關系如圖3所示。Activity間通過Intent對象傳遞用戶等級和狀態標志等信息，進行正確的資源更新。

圖3 Activity關系

Home_Activity作為軟件的主頁，需要將每個車間的整體發酵情況呈現給工作人員，空間壓力較大。鑒于Viewpager左右滑動的特性，可成功解決空間占用問題，故本軟件利用Viewpager+Fragment，通過滑頁的方式將發酵概況模塊與報警模塊進行顯示。由于Viewpager內部機制的原因，會加載用戶不需要的資源，導致資源浪費，運行速率降低，為處理資源問題，本軟件采用懶加載機制進行資源加載。

懶加載機制可讓軟件在用戶可見時加載資源，降低軟件任務量。可通過監聽Viewpager滾動或調用Fragment內部API兩種方式實現，為使軟件具有更好的封裝性，本軟件采用調用Fragment內部API的方式。

Fragment內部的setUserVisibleHint函數會在用戶可見時調用，故Viewpager加載機制加載的Fragment不會執行此函數，基于此在 Fragment的生命周期函數和setUserVisibleHint函數中做邏輯處理即可成功實現懶加載機制。

2.2 發酵車間管理模塊

本軟件的車間管理功能可以根據企業車間情況對車間進行創建與刪除，將想要觀測的車間添加到軟件上，同時也可將無需觀測的車間從軟件上刪除。車間管理功能由Recyclerview、Viewpager、自定義的SaveStatue類 以及PopupWindow共同實現。Recyclerview作為軟件的車間條目，可以保證軟件使用的流暢性。SaveStatue是SharePreference的一個封裝類，通過鍵值對對必要數據進行保存，用于保存軟件狀態信息。車間創建的窗口由PopupWindow實現。功能執行流程如圖4所示。

圖4 車間管理執行流程

2.3 車間窖池鎖定模塊

車間創建完成后需要對車間進行窖池信息匹配，建立好待監測窖池ID與車間之間的關聯，從而獲取正確的數據信息。為減少重復布局，車間窖池鎖定功能利用自定義的窖池選擇控件實現，考慮到存在車間窖池數量太多的情況，將匹配方式分為點擊匹配和輸入匹配兩種。點擊匹配為工作人員提供一個含有所有窖池ID的復選框界面，工作人員可勾選車間包含的ID進行匹配設置。輸入匹配為工作人員提供一個區間輸入的界面，有上限和下限兩個輸入項，當兩個項輸入內容相同時表示匹配一個窖池ID，否則表示匹配區間內所有ID。設置信息會由自定義窖池選擇控件傳到Fragment，再由Fragment傳到Activity中利用SharePreference進行持久化處理。自定義窖池選擇控件、Fragment、Activity之間通過接口通信。功能執行流程如圖5所示。

圖5 窖池ID匹配流程

在本軟件開發中需要用到大量的重復布局，使用Android原生UI將會使程序結構臃腫，不僅開發效率低而且維護成本也較高。為提升開發效率和維護性，選擇控件與本軟件的自定義UI均通過自定義組合控件的方式實現，實現步驟如下：（1）將原生UI進行組合布局到XML文件中；（2）在Values.attrs.xml文件中為自定義組合控件設置屬性集；（3）自定義UI類繼承布局基類LinearLayout或RelativeLayout，構造方法中獲取屬性設置信息，并在此類中定義好相應交互接口。

2.4 窖池詳情模塊

當車間的窖池ID設置完成后，Android端會將設置的車間窖池ID發送到服務器，獲取該車間所有窖池的溫度數據以及測溫設備的電量等信息，為工作人員提供數據展示。為避免ANR現象，采用異步任務的方式進行網絡請求。數據展示共有普通展示模式和列表展示模式兩種，每種模式對應一種自定義的窖池UI。一個自定義窖池UI對應一口窖池信息，以輪詢的方式進行實時數據獲取并更新。溫度曲線繪制由MPAndroidChart實現，將每個窖池在本發酵周期內一定量的溫度數據分上中下三層進行繪制。此外，還提供了入窖日期篩選、溫度篩選以及發酵天數篩選3個子篩選功能，用戶可根據需求按照酒培入窖日期、酒培上中下三層溫度、酒培已發酵天數進行數據篩選。

輪詢主要以Service、BroadcastReceiver、AlarmManager三大組件實現。當開啟服務時，在Service內部動態注冊廣播監聽器，并開設用于通知Activity更新數據顯示的線程，然后利用AlarmManager設置定時任務，到達設定時間時激活廣播，廣播反向激活Service，并發送線程使能標志到Service，此時被再次激活的Service便會啟用線程，對服務器發起訪問，實現實時更新。

2.5 報警模塊

報警功能如下：

（1）報警綜合顯示是將測溫設備電量異常、服務器異常、入窖溫度過高、入窖溫度過低、頂火溫度過高、頂火溫度過低、頂火溫度出現過早、頂火溫度出現過遲8個方面的異常情況放于主頁進行綜合顯示，以輪詢的方式向服務器不斷檢測是否發生異常，根據報警數據量動態生成TextView控件并布置到主頁對應布局進行顯示。

（2）報警分類顯示是依據8個報警項設8個報警條目，當用戶點擊某個條目時以彈窗顯示該車間內哪些窖池有此異常，以及這些窖池何處出現異常。

（3）報警歸檔功能會將報警信息保存到Android本地，由File類和IO流實現，當發現某車間有窖池存在發酵異常時，軟件先借助Context的getExernalFilesDir獲取本應用程序在Android設備中的存儲路徑，然后利用File類在該路徑下創建該車間的報警文件夾，結合輸出流將報警信息歸檔到本地存儲。當進行歸檔數據讀取時，軟件會利用輸入流對對應車間的歸檔文件夾進行查詢，以動態布局的方式顯示歸檔數據。

2.6 發酵天數概況模塊

發酵天數概況模塊用于對某車間中發酵天數在一定區間范圍內的窖池進行數量統計，以柱形圖的方式展示。

由于白酒發酵主要關注“前緩”和“中挺”兩個階段，而濃香型白酒一般在發酵后的15～30天內結束“中挺”階段，故橫坐標上共設10個刻度點，每個刻度點表示一個發酵天數區間，針對發酵天數區間從“1～3天”以三天為一段一直到“28～30天”的窖池數量進行柱形圖繪制，柱形圖繪制以MPAndroidChart實現。

除對對應發酵天數的窖池數量進行展示外，為顯示對應天數區間的窖池具體情況，還針對“數量”設立了詳情功能。詳情功能通過OnChartValueSelectedListen接口監聽柱形圖是否被點擊，點擊事件被觸發則獲取對應的刻度信息，即天數區間，并調用異步任務將其作為參數傳至服務器查詢，以PopupWindow和Fragment形成的彈窗對結果進行展示。

3 服務器以及數據庫設計

3.1 數據庫設計

數據庫是軟件的基礎，良好的數據庫可以為軟件運行提供有力支撐。設計時需充分考慮數據完整性、冗余性等問題，以避免出現刪除異常、更新異常等情況。本軟件采用SQL Server數據庫進行數據存儲。為提高軟件運行效率，以范式標準對數據庫進行限制和設計。

3.1.1 信息表設計

根據實際企業需求，需要對發酵過程中各車間中各窖池的設備狀態以及產生的溫度數據進行存儲，據此分析可得到車間、窖池、記錄信息和測溫設備4大實體，各實體間的屬性以及邏輯結構如圖6所示。Workshop對應實體車間，Pit對應實體窖池，Record_Info對應實體記錄信息，Equip_Measure對應實體測溫設備。

圖6 E-R圖

4大實體分別對應車間信息表、窖池信息表、記錄信息表和設備信息表。車間信息表用于記錄生產車間的基礎信息。窖池信息表記錄發酵窖池的基礎信息。記錄信息表記錄對應發酵過程中產生的重要信息，如上中下三層的發酵溫度、溫度采集時間等。測溫設備信息表記錄測溫設備的基礎信息，如測溫設備型號、設備購入時間等。以記錄信息表結構為例進行展示，見表1所列。

表1 記錄信息表

3.1.2 表間關系結構

各表之間的關系可通過主鍵和外鍵進行構造，以保證實體完整性和數據完整性。如窖池ID可以對窖池信息表進行唯一標志，在記錄表中又可以將窖池ID設立為外鍵，保證數據一致性，表間關系結構如圖7所示。

圖7 EDR圖

3.2 服務器設計

服務器是在.Net框架下創建的一個Web服務端，由WebService和ADO.Net實現，負責對客戶端請求進行相應的業務處理，并返回處理結果，為客戶端提供計算支持。

WebService以消息互操作的方式完成分布式計算，具有跨軟件操作的優點，利用WebService向Android客戶端提供訪問接口，以完成PC與Android的信息交互，Web服務端與客戶端之間以Soap協議通信，本軟件利用Ksoap2進行消息的序列化處理，遠程調用Web服務接口。

ADO.Net是.Net框架下的數據庫訪問組件，通過Connection、Command、DataReader和 DataAdapter四 大 核心元素完成數據庫信息交互。

4 軟件驗證與分析

該軟件的實現使得現場監測的人力成本下降，由現場監測變成了移動監測。引入懶加載機制后數據加載速度獲得了極大提升。具體數據見表2、表3所列。

表2 懶加載效率表

表3 人力成本使用情況表

5 結 語

考察了實際發酵工藝環節后，從實用性、穩定性、可拓展性等方面入手設計并實現了發酵溫度信息化應用軟件，使得人工現場監測變成了移動監測，改變了白酒行業傳統的數據監測方式，大大提升了監測效率，為發酵環節的數字化、信息化、精細化提供了基礎。軟件在設計上充分考慮了發酵溫度的重要性，從基礎信息展示、異常數據報警，以及數據統計等方面完成了發酵過程中溫度數據的有效監測，此外，還提供了測溫設備信息展示功能。在實現上以輪詢方式保證數據實時更新，通過懶加載方式減輕資源壓力。