基于SSM的冷鏈云平臺設(shè)計與實現(xiàn)

朱德建 胡平

摘要：傳統(tǒng)冷鏈在生產(chǎn)、運輸和存儲環(huán)節(jié)具有人工監(jiān)測費時費力、數(shù)據(jù)超標(biāo)報警不及時、問題溯源和取證困難等不足。借助阿里云平臺、物聯(lián)網(wǎng)技術(shù)和SSM開發(fā)框架，實現(xiàn)了覆蓋冷鏈全環(huán)節(jié)的數(shù)據(jù)實時監(jiān)測、記錄、查詢及報警推送功能，闡述了平臺的軟硬件組成及架構(gòu)，設(shè)計了數(shù)據(jù)發(fā)送接收協(xié)議、數(shù)據(jù)展示邏輯、報警消息延時推送等核心功能。測試表明，云平臺具有較好的可擴展性，能較好滿足食品藥品生產(chǎn)企業(yè)、運輸企業(yè)及監(jiān)管部門對冷鏈各環(huán)節(jié)數(shù)據(jù)的采集、獲取和查詢要求。

關(guān)鍵詞：冷鏈;云平臺;數(shù)據(jù)監(jiān)控;報警推送;SSM

中圖分類號：TP311? ? ? ?文獻標(biāo)識碼：A

文章編號：1009-3044（2019）24-0042-03

開放科學(xué)（資源服務(wù)）標(biāo)識碼（OSID）：

Design and Implementation of Cold Chain Cloud Platform Based on SSM

ZHU De-Jian， HU Ping

（School of Computer and Information， Anhui Polytechnic University， Wuhu 241000， China）

Abstract： In terms of production， transportation and storage， the traditional cold chain solutions has the problems of labor-intensive manual monitoring， alarm messages pushing are not timely， and insufficient for traceability and evidence collection. With the help of Alibaba Cloud platform， Internet of Things technology and SSM development framework， this paper realized the real-time monitoring， recording， query and alarm push functions that the entire link of the cold chain are involved， the software and hardware architecture of the platform are expounded， and the core functions such as data transmission and reception protocol， representation logic， and alarm message delay pushing are designed. Tests show that the cloud platform is extensive and meets the requirements of food and drug manufacturers， transportation companies and regulatory authorities for collecting， obtaining and querying data in all aspects of the cold chain.

Key words： cold chain; cloud platform; data collection; alarm pushing; SSM

1 背景

近年來，國內(nèi)外醫(yī)療事故頻發(fā)，引起了全社會以及相關(guān)媒體的關(guān)注。眾所周知，高溫會使藥品的藥效迅速降低，或使蛋白質(zhì)變性。藥品的穩(wěn)定性不僅與其自身的性質(zhì)有關(guān)，在很大程度上還受到許多外界因素的干擾，如溫度，濕度，光線，空氣中的氧氣等。這些因素往往會使藥品發(fā)生分解、揮發(fā)、沉淀、潮解、酸敗、生霉等變化。若超出溫度范圍，藥品會隨即失效。目前我國的醫(yī)藥冷鏈物流體系在智能信息化方面的發(fā)展比較滯后，無法滿足現(xiàn)代醫(yī)藥冷鏈的實際需求。因此，如何實現(xiàn)各級藥品管理單位的冷鏈實時監(jiān)測，已經(jīng)成為國家有關(guān)部門非常關(guān)注的課題。在藥品包裝領(lǐng)域，國家食品藥品監(jiān)督管理總局下發(fā)的《藥品經(jīng)營質(zhì)量管理規(guī)范》（GSP）明文規(guī)定了藥品流通、存儲等環(huán)節(jié)的溫濕度要求，且每個環(huán)節(jié)需實時監(jiān)測藥品所處的溫濕度數(shù)據(jù)。因此保持醫(yī)療藥品云冷鏈各個環(huán)節(jié)的可靠性是至關(guān)重要的。

市場上存在的冷鏈系統(tǒng)中大多只有采集、存儲數(shù)據(jù)的功能，用戶讀取數(shù)據(jù)需要通過有線方式連接電腦，滿足不了GSP關(guān)于溫濕度數(shù)據(jù)實時上傳讀取的要求，如若溫濕度數(shù)據(jù)被修改，可能會導(dǎo)致一些重大危害事件發(fā)生。

針對GSP關(guān)于冷鏈溫濕度數(shù)據(jù)實時監(jiān)測的要求，本文研發(fā)了基于SSM的云冷鏈監(jiān)測系統(tǒng)。平臺采用SSM框架搭建，智能云冷鏈技術(shù)通過相關(guān)物聯(lián)網(wǎng)技術(shù)對溫濕度數(shù)據(jù)進行多點實時監(jiān)測控制，采集的數(shù)據(jù)信號通過無線服務(wù)技術(shù)，將數(shù)據(jù)實時傳輸至后端服務(wù)器。用戶可通過訪問電腦端冷鏈監(jiān)測云平臺或移動端應(yīng)用程序，實時查看溫濕度數(shù)據(jù)，設(shè)備地理位置等信息。

2 平臺架構(gòu)

2.1 總體架構(gòu)

該平臺設(shè)計基于Spring+Spring MVC+Mybatis框架，系統(tǒng)部署于阿里云服務(wù)器，用戶通過web服務(wù)端（瀏覽器或者微信公眾號掃碼）訪問數(shù)據(jù)庫，并向控制模塊下發(fā)指令，數(shù)據(jù)采集模塊通過HTTP（GPRS或WIFI）發(fā)送數(shù)據(jù)給服務(wù)器，可實現(xiàn)對冷藏設(shè)備進行溫濕度監(jiān)測調(diào)節(jié)，報警處理等相關(guān)操作。用戶可通過Web服務(wù)端向支付接口發(fā)送支付請求，支付接口實現(xiàn)支付回調(diào)給Web端。系統(tǒng)前端采用Jquery技術(shù)和MUI框架構(gòu)建基于HTML5的Web端界面;后端采用SSM框架和WebSocket協(xié)議完成用戶與平臺之間的交互。系統(tǒng)實現(xiàn)了設(shè)備管理、模塊管理、狀態(tài)展示、報警推送、用戶管理等功能。軟件界面友好、風(fēng)格簡約，在醫(yī)療云冷鏈方面作用廣泛。

2.2 軟件架構(gòu)

平臺采用SSM框架設(shè)計，SSM即SpringMVC、Spring 與 MyBatis 三個開源框架整合而成，它們在三層架構(gòu)中的功能各不相同，各司其職，它們之間的關(guān)系如圖2所示。

SpringMVC：是一個前臺的控制框架，能夠做到自動的值的封裝。作為 View 層的實現(xiàn)者，完成用戶的請求接收功能。SpringMVC 的 Controller作為整個應(yīng)用的控制器，負責(zé)處理客戶端與客戶的請求，請求訪問過來被DispatcherServlet攔截，并且調(diào)用controller層中的相應(yīng)的方法，最終把結(jié)果返回給用戶，完成用戶請求的轉(zhuǎn)發(fā)及對用戶的響應(yīng)。

MyBatis：mybatis是一款輕量級的持久層框架，由ibatis演化而來，它是對jdbc的封裝，它讓數(shù)據(jù)庫底層操作變的透明。Dao 層，也叫作數(shù)據(jù)訪問層，主要利用MyBatis這一優(yōu)秀的持久化層框架實現(xiàn)代碼與SQL語句的分離，消除了幾乎所有的JDBC代碼和參數(shù)的手工設(shè)置以及結(jié)果集的檢索）的實現(xiàn)者，建立與數(shù)據(jù)庫之間的連接，完成對數(shù)據(jù)庫的增、刪、改、查功能。

Spring：spring是一個輕量級的控制反轉(zhuǎn)（Inversion Of Control， IOC）和面向切面（Aspect Oriented Programming， AOP）的容器框架，通過使用其獨特的配置文件以及注解方式進行開發(fā)簡化，以整個應(yīng)用大管家的身份出現(xiàn)。整個應(yīng)用中所有 Bean 的生命周期行為，均由Spring 來管理，負責(zé)協(xié)調(diào)類與類之間的關(guān)系。即整個應(yīng)用中所有對象的創(chuàng)建、初始化、銷毀，及對象間關(guān)聯(lián)關(guān)系的維護，均由 Spring 進行管理。

2.3 硬件設(shè)計

數(shù)據(jù)采集模塊的硬件主要包括溫濕度傳感器模塊（溫濕度傳感器用于讀取冷鏈保溫箱內(nèi)溫濕度數(shù)據(jù)，該傳感器具有體積小、抗干擾能力強、精度高的特點。傳感器通過規(guī)定的數(shù)字信號通過與主處理器的連接實現(xiàn)溫度和濕度的數(shù)字輸出。）、GSM通訊模塊（冷鏈云平臺采用GSM通訊模塊。該模塊是一款四頻段GSM/GRPS。另外該模塊內(nèi)嵌TCP/IP協(xié)議棧，支持多個Socket及IP地址。單片機通過發(fā)送指令與通訊模塊進行通信。以實現(xiàn)網(wǎng)絡(luò)連接、數(shù)據(jù)傳輸功能。）、顯示模塊（該模塊可以顯示時間、溫濕度數(shù)據(jù)、網(wǎng)絡(luò)信號等數(shù)據(jù)）、GPS定位（高靈敏度、低功耗，支持輔助全球衛(wèi)星定位系統(tǒng)，提高設(shè)備定位精度和速度）、另外擴展模塊可外接顯示屏和傳感器，各模塊之間的結(jié)構(gòu)與關(guān)系如圖3所示。

3 核心功能設(shè)計

3.1 數(shù)據(jù)發(fā)送協(xié)議

平臺的每個數(shù)據(jù)采集模塊有唯一的id來標(biāo)識，以16位十進制整數(shù)形式的字符串存在，分別為14位主模塊地址加上2位從模塊地址，例如：“1000200030000107”，14位加2位（主機號為00）。向服務(wù)地址“http：//公網(wǎng)IP或域名/api/upload.do？vc=校驗碼&id=…”發(fā)送數(shù)據(jù)。對于校驗碼部分，將當(dāng)前字符加下標(biāo)（從0開始）對40的余數(shù)累加到sum的方式進行累加，然后將 sum乘以37，對21867異或，再對65536求余數(shù)（以保留低16位，最后轉(zhuǎn)換為余數(shù)的16進制（小寫使用32位的類型保存sum），得到結(jié)果vc=校驗碼&，進而將URL拼接，構(gòu)成最終的URL。服務(wù)器校驗完成以后，將返回信息給數(shù)據(jù)模塊，返回值若為“s！（s=1-9）”，表明數(shù)據(jù)發(fā)送失?。?-9分別代表不同的數(shù)據(jù)發(fā)送失敗的原因）。若是“0…！”表明數(shù)據(jù)發(fā)送成功，字符0表明服務(wù)器接收了該條數(shù)據(jù)，同時回傳字符串中還包含一些由用戶在web端定義的其他信息，以便隨時控制采集模塊。

數(shù)據(jù)采集的時間由19個字符組成，形式為“yyyy-MM-dd-HH：mm：ss”通過服務(wù)地址 http：//公網(wǎng)IP或域名/api/now.do？tk=796392e20e43bbdaa69372e3df576f51獲取數(shù)據(jù)采集時間，tk字段值固定，目的是為防止他人獲取時間，服務(wù)返回結(jié)果為字符串，形如“2016-11-12 09：22：33！”，最后的！為結(jié)束字符。

3.2 設(shè)備狀態(tài)展示

客戶和管理員可以對設(shè)備的屬性進行編輯，設(shè)置報警閾值和模塊綁定。在Web端，系統(tǒng)以卡片視圖、表格視圖、地圖視圖、曲線視圖和數(shù)據(jù)視圖實時向用戶展示設(shè)備狀態(tài)、冷鏈?zhǔn)褂脿顟B(tài)、工作狀態(tài)，實時監(jiān)測數(shù)據(jù)，并可以隨時導(dǎo)出歷史數(shù)據(jù)，歷史時間段的溫度曲線圖，打印月度報表等。

設(shè)備狀態(tài)分布顯示在地圖上，如果設(shè)備溫濕度數(shù)據(jù)發(fā)生異常，在地圖上會用紅色標(biāo)記出問題設(shè)備，實時顯示，向用戶發(fā)出提醒，同時以短信，微信提醒等多種方式向用戶報警。用戶和管理員可以通過Web端查看監(jiān)控點位的溫濕度記錄儀變化情況，實現(xiàn)遠程監(jiān)測，如若設(shè)備發(fā)生異常，可以在Web端實時在線處理，實現(xiàn)了設(shè)備監(jiān)測的自動化。

3.3 報警消息推送

報警推送是各類設(shè)備監(jiān)控軟件系統(tǒng)不可或缺的功能之一，本系統(tǒng)所采用的報警推送方法彌補了目前普遍采用的報警消息推送方法的不足，例如當(dāng)設(shè)備狀態(tài)連續(xù)或頻繁處于設(shè)定閾值之外時，短期內(nèi)大量推送的報警信息可能導(dǎo)致接收者厭煩甚至錯過重要的報警信息。又或者不能滿足企業(yè)不同級別人員（如一線值班人員、管理人員和決策人員）對設(shè)備報警消息的不同關(guān)注度要求。

本系統(tǒng)采用支持多級別延時的報警消息推送方法，主要推送邏輯如圖所示。即當(dāng)云平臺接收到一條消息并存儲后，將所得數(shù)據(jù)與歷史數(shù)據(jù)進行比對，若數(shù)據(jù)正常則更新設(shè)備最新狀態(tài)表，若有連續(xù)多條設(shè)備不正常，則進入延時級別推送判斷。對已經(jīng)關(guān)注設(shè)備但沒有收到推送消息的客戶根據(jù)數(shù)據(jù)的推送延時級別進行處理。延時處理的具體方法為：

1）計算數(shù)據(jù)D的推送延時級別L;

2）獲得所有關(guān)注了對應(yīng)設(shè)備V且推送延時級別為L的用戶列表U;

3）判斷用戶列表U中的數(shù)據(jù)是否處理完畢;

4）如果沒有處理完畢，則對于U中的每個用戶，生成相應(yīng)的報警消息P并入隊到報警推送消息隊列Q，報警時間設(shè)置為上條數(shù)據(jù)C的報警時間;

5）如果處理完畢，更新設(shè)備最新狀態(tài)表。

以短信、微信公眾號、PC端報警等方式向設(shè)備關(guān)注者報警。此邏輯通過比較當(dāng)前數(shù)據(jù)和歷史數(shù)據(jù)的狀態(tài)變化，引入了延時機制，滿足了不同級別人員對同一報警消息的不同關(guān)注度。

4 平臺實現(xiàn)與測試

4.1 平臺實現(xiàn)

平臺開發(fā)基于SSM框架，sping+springMVC+mysql集成的框架。

MVC即model view controller。model層=entity層。存放我們的實體類，與數(shù)據(jù)庫中的屬性值基本保持一致，實現(xiàn)set和get方法。

service層。給controller層的類提供接口進行調(diào)用，存放業(yè)務(wù)邏輯處理，也是一些關(guān)于數(shù)據(jù)庫處理的操作，其主要是存放了查詢數(shù)據(jù)的各種方法，但它不是直接和數(shù)據(jù)庫打交道，他有一個接口和還有接口的實現(xiàn)方法，在接口的實現(xiàn)方法中需要導(dǎo)入mapper層，而這個mapper層是直接跟數(shù)據(jù)庫打交道的，他也是 個接口，只有方法名字，具體實現(xiàn)在mapper.xml文件里，service只是供我們使用的方法。在開發(fā)的過程中，service層被處理為實體Service層，而不是接口，業(yè)務(wù)邏輯直接寫在Service（Class，不是Interface）層中，Controller直接調(diào)用Service，Service調(diào)用Mapper，Service之間也是可以互相調(diào)用。

mapper層也就是dao層，現(xiàn)在用mybatis逆向工程生成的mapper層，其實就是dao層。對數(shù)據(jù)庫進行數(shù)據(jù)持久化操作，它的方法語句是直接針對數(shù)據(jù)庫操作的，主要實現(xiàn)一些增刪改查操作，在mybatis中方法主要與xxx.xml內(nèi)相互一一映射。而service層是針對我們controller，也就是針對我們使用者。service的impl是把mapper和service進行整合的文件。

controller層。控制層，也是核心控制器。負責(zé)具體模塊的業(yè)務(wù)流程控制。在controller層中的類里面一定要導(dǎo)入service層，需要調(diào)用service邏輯設(shè)計層的接口來控制業(yè)務(wù)流程，controller通過接收前端傳過來的參數(shù)后進行業(yè)務(wù)操作，然后再給前端返回一個指定的路徑或者數(shù)據(jù)表。

4.2 平臺測試

基于SSM的冷鏈云平臺部署于阿里云服務(wù)器，并外接一個GPRS無線接收端，可接收數(shù)據(jù)采集終端的數(shù)據(jù)并傳輸至PC監(jiān)控臺，在PC端呈現(xiàn)實時溫濕度數(shù)據(jù)，溫濕度數(shù)據(jù)曲線圖表（圖5），設(shè)備地理位置（圖6）顯示等。下圖是測試同一設(shè)備在不同時間的溫濕度數(shù)據(jù)，并將這些數(shù)據(jù)以曲線視圖的形式實時顯示給用戶，同時用戶也可在移動端查看地圖視圖，了解設(shè)備的所在實時位置以及設(shè)備狀態(tài)。

5 結(jié)束語

基于SSM冷鏈云平臺能根據(jù)藥品冷鏈溫濕度數(shù)據(jù)的實時監(jiān)測及GSP規(guī)范要求，對冷鏈設(shè)備進行實時監(jiān)控，實現(xiàn)監(jiān)控工作的自動化和監(jiān)測的實時性、準(zhǔn)確性，減少了人工監(jiān)測的成本，降低了因誤差監(jiān)測導(dǎo)致帶來的不必要的價值損失。溫濕度傳感器實時采集溫濕度數(shù)據(jù)，地理位置通訊模塊傳送實時位置，通過GPRS傳送數(shù)據(jù)至后端云平臺。冷鏈監(jiān)測云平臺作為后端監(jiān)測平臺，為用戶呈現(xiàn)實時溫濕度數(shù)據(jù)、地理位置等信息。測試結(jié)果表明：該平臺實時監(jiān)測溫濕度數(shù)據(jù)精度優(yōu)良，無線傳輸數(shù)據(jù)穩(wěn)定可靠，無數(shù)據(jù)丟失現(xiàn)象發(fā)生。

由于開發(fā)初期系統(tǒng)還存在著一些不足，例如數(shù)據(jù)采集的實時性方面還有待提高，采集數(shù)據(jù)的存儲效率也需要進一步的加強，更加合理的設(shè)計數(shù)據(jù)存儲方式，提高數(shù)據(jù)的查詢效率。在未來，隨著計算機技術(shù)、通信技術(shù)以及無線傳感技術(shù)的不斷發(fā)展，冷鏈監(jiān)測數(shù)據(jù)的可靠性實時性都會有很大的提高，傳輸效率也會有極大地改善，我們會不斷對系統(tǒng)做出優(yōu)化和完善！使其廣泛應(yīng)用于醫(yī)療藥品云冷鏈領(lǐng)域。

參考文獻：

[1] 張露露， 姚駿， 李霄玉. 基于GPRS技術(shù)的車載冷庫遠程監(jiān)控系統(tǒng)的設(shè)計[J]. 工業(yè)控制計算機， 2017， 30（4）： 19-23.

[2] 劉曉亮， 王文銘. 我國醫(yī)藥冷鏈物流發(fā)展的問題與對策[J]. 物流工程與管理， 2010（11）： 1-3， 6.

[3] 熊穎， 田超. 我國醫(yī)藥冷鏈物流發(fā)展現(xiàn)狀及其問題淺析[J]. 現(xiàn)代營銷， 2011（5）： 147.

[4] 師繪敏. 我國醫(yī)藥冷鏈物流發(fā)展中存在的問題及對策研究[J]. 中國醫(yī)藥指南， 2012（19）： 398-399.

[5] 鐘秀英. 我國藥品冷鏈物流現(xiàn)狀、成因與發(fā)展策略分析[J]. 中國市場， 2012（2）： 22-24， 30.

[6] 張慶年， 李東久. 醫(yī)藥品冷鏈物流運輸體系的構(gòu)建[J]. 交通企業(yè)管理， 2012（11）： 58-60.

[7] 朱超才. 物聯(lián)網(wǎng)環(huán)境下農(nóng)產(chǎn)品冷鏈監(jiān)控與追溯平臺研究[J]. 山西農(nóng)業(yè)大學(xué)學(xué)報： 社會科學(xué)版， 2015（5）： 485-490.

【通聯(lián)編輯：謝媛媛】