凍干機的數據云端化改造

應亦豐

（上海世卓科技有限公司，上海201323）

0 引言

近年來，“互聯網+”“物聯網”“智能控制”“工業互聯網”等概念層出不窮。同時，黨的十九大報告指出：“加快建設制造強國，加快發展先進制造業，推動互聯網、大數據、人工智能和實體經濟深度融合”。一時間，各大企業紛紛加強了自身在信息化、智能化建設方面的投入。為滿足制藥企業信息化、智能化改造的需求，筆者經過潛心鉆研，以較低的成本初步完成了舒博拉尼凍干機的信息化、數據云端化改造。

本文以舒博拉尼凍干機的信息化、數據云端化改造為例，具體闡述其詳細的開發過程，為制藥裝備數據云端化改造提供參考。

1 項目體系架構

凍干機的數據云端化改造系統架構如圖1所示。由于篇幅原因，本文只舉例最簡單、最必要的體系架構，從下至上只需要4個環節，即可實現制藥裝備數據在移動端的顯示和查詢功能。

在該項目中，使用了ARM開發板取代傳統的PC機，與傳統的PC系統架構相比，ARM開發板具有如下優勢：

圖1 凍干機的數據云端化改造系統架構圖

（1）體積小。ARM開發板只有一本小號筆記本的大小，某些型號的開發板甚至只有一張名片的大小。

（2）功耗低，發熱量小。ARM開發板的供電一般都是DC5V、2A，發熱量極小，主芯片上往往都不用加裝散熱片，很少發生因為發熱造成系統死機的情況。

（3）操作系統穩定。ARM開發板的操作系統基本是經過調整的Linux系統，而Linux操作系統往往被國際軟件開發商定制開發成服務器操作系統，如美國的RedHatLinuxServer系列產品甚至可與微軟的WindowsSERVER在服務器領域分庭抗禮。因此，ARM開發板的操作系統具備長時間不間斷運行的特性。

（4）安裝方便。由于ARM開發板體積小，可將其安裝在設備控制柜內部，通信線直接連接到附近的PLC上，程序調試穩定后，不用連接顯示器、鍵盤和鼠標，開機程序自動運行。

市場上ARM開發板的品牌、型號琳瑯滿目，本文推薦使用通用型的、可安裝Linux操作系統且自帶RS232/485串口的ARM開發板。

2 系統開發需要的硬件準備工作

2.1 系統開發所需硬件

系統開發所需硬件如表1所示。

2.2 各硬件連接方式

各硬件連接方式如圖2所示。

連接PLC上RS232串口線和USB轉接線的串口線需要自己動手制作，購買RS232接頭公、母頭各一個，按圖3方式連接就可以。

3 運行環境搭建

首先，要確定開發語言，ARM開發板的官方推薦開發語言是Python，基于特殊原因，最終決定采用Java來完成這個開發工作。

表1 開發所需硬件列表

圖2 ARM開發板硬件連接

圖3 PLC串口線制作接線圖

Java是一門歷史比較悠久、成熟、跨平臺、面向對象的開發語言，其第三方插件和開源庫不計其數，幾乎可以滿足任何開發要求（該項目要使用到RXTXcomm開源庫，以達到和PLC串口通信的目的）。其跨平臺的特性，可以實現先在Windows系統上開發，完成后再部署到Linux系統上運行。

運行環境的搭建具體流程：

（1）登陸開發板官方網站下載頁，下載Linux鏡像文件，本文使用較新的版本：2017-07-05-jessie.img。

（2）下載win32_disk_imager燒錄軟件，將鏡像文件燒錄到TF卡。

（3）將所有硬件連接到位，包括顯示器、USB鍵盤和鼠標，最后將TF卡插入開發板，打開電源，可以在屏幕上看到系統啟動畫面和啟動信息。

（4）進入桌面環境，點擊“打開終端”按鈕，打開系統終端。這是個類似于微軟DOS界面的終端，以后的所有工作基本上都是在這個終端界面里面完成。

（5）一般情況下，Linux發行版里面都會自帶Java，可通過以下方式進行確認：在終端里面輸入命令“java-version”并回車，可以看到如圖4所示的提示信息，表明系統已經自帶了1.8版本的Java運行庫。

（6）接下來，安裝第三方RXTXcomm開源庫，沒有它的支持，開發板無法訪問串口。但是，RXTXcomm開源庫最后的更新時間大致是在2006年左右，因為除了工業領域，商業市場上幾乎99%的硬件都已經拋棄了串口這種連接方式，所以RXTX主頁上壓縮包里面的文件只支持Linux IA32/IA64的架構，并不支持ARM架構，需要通過編譯源代碼來完成RXTXcomm在開發板上的安裝。

4 開發環境搭建

Linux系統雖然強大，但比較適合做服務器方面的應用。對于開發環境而言，還是在Windows系統上搭建比較便利。

4.1 下載適合操作系統的JDK開發包

下載適合操作系統的JDK開發包并安裝（32位或64位），開發版本可以使用1.6、1.7或1.8。隨后，根據提示安裝，基本上是一路點擊“下一步”和“確定”按鈕。

4.2 系統環境配置

圖4 系統自帶Java運行庫

（1）添加Java的系統變量Path屬性，如圖5所示。打開Windows的“系統屬性”對話框，點擊“高級”標簽頁，再點擊“環境變量”按鈕。在“系統變量”中找到名為“Path”的系統變量，雙擊進入編輯模式。在“變量值”一欄的最后輸入“;%JAVA_HOME%in;%JAVA_HOME%jrein”。

圖5 設置Java的“Path”變量對話框

（2）新增Java的JAVA_HOME系統變量屬性，如圖6所示。點擊“環境變量”對話框的“新建”按鈕，變量名一欄輸入“JAVA_HOME”，變量值一欄輸入Java程序的安裝路徑“C:ProgramFilesJavajdk 1.8.0_40”。

圖6 新建“JAVA_HOME”變量對話框

（3）新增Java的CLASSPATH系統變量屬性，如圖7所示。再次點擊“環境變量”對話框的“新建”按鈕，變量名一欄輸入“CLASSPATH”，變量值一欄輸入Java程序的安裝路徑“.;%JAVA_HOME%lib;%JAVA_HOME%lib ools.jar”。

圖7 新建“CLASSPATH”變量對話框

（4）下載EclipseIDE開發軟件，將其解壓至一個文件夾，雙擊目錄下“eclipse.exe”，打開IDE開發界面即可進行編程工作，至此開發環境搭建完成。

5 PLC通信協議

在動手寫代碼前，要先搞清楚凍干機的PLC通信協議。簡單來說，就是開發板和PLC“交流”的一種規范，通常采用“一問一答”形式。開發板會首先發起一個請求代碼，傳送到PLC；PLC再根據請求碼的內容，提取出合適的數據，再以相同的規范發回給開發板，這樣就可以采集到PLC內存區中的實時數據并加以分析利用了。

舒博拉尼凍干機采用的是歐姆龍CJ2M-CPU13-V2.0的CPU單元，這種PLC遵循歐姆龍公司的HostLink協議，現在就具體分析一下這種協議的編碼方式。

5.1 請求碼

HostLink請求碼規范如圖8所示。

圖8 HostLink請求碼規范

（1）請求碼開頭始終用@開始，回復碼也是一樣。

（2）單元號，指的是PLC編程時設定的序號，默認為0，可以在電腦上用歐姆龍CX-Programmer程序打開查看，如圖9所示。

圖9 單元號設置對話框

（3）頭部代碼：始終為FA，回復碼也一樣。

（4）響應時間：設置范圍為0～F，單位為10ms。例如，設置為1，則響應等待時間為10ms。

（5）ICF、DA2、SA2、SID：通常固定設置為00。

（6）讀/寫命令：讀命令（0101）、寫命令（0102）。

（7）操作內容：包含3個請求內容，即請求PLC哪個區域的數據？從哪個地址開始操作？連續操作幾個數據？區域代碼查詢如表2所示。

（8）校驗碼：算法比較復雜，這里不具體展開，可下載一個名為“HostLink校驗碼計算器”的軟件進行計算，如圖10所示，計算時需要輸入請求碼的前面所有字符，包括“@”。

（9）終止符：請求碼和回復碼都一樣，始終是“*回車”。

5.2 回復碼

HostLink回復碼規范如圖11所示。

回復碼的前半部分定義和請求碼相同，這里就不再重復解釋。PLC返回的數據基本是包含在回復碼的后半段。如圖11所示：從校驗碼前面開始推算，最靠近校驗碼的是請求的最后一個數據，再往前推算是N-1個、N-2個，以此類推。

6 數據準備

舒博拉尼凍干機的過程數據都存放在PLC的DM區中，各參數對應地址如表3所示。

表2 區域代碼

圖10 HostLink校驗碼計算器

圖11 HostLink回復碼規范

表3 舒博拉尼凍干機PLC地址列表

通過觀察可以發現，參數地址基本上都在一個比較集中的區域，可以采取一種連續讀取的方法，將D100～D152的數據一下子讀取出來，再進行內部分析，對應到每個參數上。

7 編寫代碼

代碼編寫工程分為四個類，采用盡可能簡單的架構。因為本文主要是為了闡述一個數據采集的過程，所以不引入Java的各種設計模式，力求讓代碼的邏輯過程簡單易讀。

7.1 獲取開發板的串口表達字符串

串口一般在Windows系統上表達為“COM1、COM2”之類的。但是，在Linux系統下就完全不一樣了。先要運行一個自己編寫的小程序，列出開發板上可用的串口列表和在Linux系統下串口的表達字符串。這個字符串在接下來的數據采集代碼中是要用到的。

小程序會收集所有串口列表并顯示出來，將程序編譯后的.class文件復制到開發板上，運行結果如圖12所示。

從圖12可以看到，串口的字符串是“/dev/ttyUSB0”，和Windows系統下的完全不一樣，開發者一定要注意，不然串口通信是連接不上的。

7.2 凍干機數據采集程序

該套數據采集程序很簡單，只有四個類，其調用關系如圖13所示。

圖12 Linux系統下的可用串口

圖13 四個Java類之間的調用關系

以上程序使用到了Java的線程機制，由于后期還將把這個程序功能擴展為將采集數據上傳到SQL數據庫、移動端手機顯示數據等，加上網絡原因等，一次讀寫操作耗時3～4s是很常見的事情。有移動開發經驗的工程師知道，在Andoird開發中，如果有涉及網絡的操作都必須在子線程中完成，不得寫入UI線程。因此，如果將數據采集和數據庫讀寫操作都放在一個線程中，難免會導致線程阻塞。此處程序通過采用每隔30s就從后臺開辟一個新線程去讀取PLC數據的方法，避免線程阻塞。

將所有程序編譯后，所有.class文件復制到開發板中，運行程序最終結果如圖14所示。

至此，凍干機的數據都被采集顯示出來了，由于圖14所顯示的設備正處于二次干燥階段，所以，干箱壓力和冷凝器壓力這兩個壓力傳感器獲取的是PLC默認值，并不反映現場實際的生產情況。

圖14 程序運行最終結果

隨后即可將采集的數據上傳至位于云端的MySQL數據庫中，再結合手機前端的編程即可在任意時間、任意地點遠程監控車間中運行的凍干機實時參數了，如圖15所示。

8 結語

通過本次對舒博拉尼凍干機的信息化、數據云端化改造，為其他各種類型的制藥裝備信息化改造提供了參考，更為重要的是，數據采集的過程已經將所有的制藥裝備運行數據存放于位于云端的SQL數據庫中，對將來各種大數據的統計以及藥品質量的追溯來說，具有重大的意義。

圖15 手機端顯示凍干機實時運行參數

［參考文獻］

[1]OMRON.CJ2m_CJ2H_編程手冊[Z].

[2]OMRON.PLC_HostLink通信手冊[Z].

[3]李興華.JAVA開發實戰經典[M].北京：清華大學出版社，2009.