醫(yī)用氣體實(shí)時(shí)監(jiān)測(cè)平臺(tái)的設(shè)計(jì)與實(shí)現(xiàn)

張凡進(jìn) 郭立君 張 榮 周豐平

1(寧波大學(xué)信息科學(xué)與工程學(xué)院 浙江 寧波 315211) 2(寧波視線軟件科技有限公司 浙江 寧波 315200)

0 引 言

醫(yī)用氣體是指醫(yī)療過(guò)程中使用的氣體，用于治療、麻醉患者或驅(qū)動(dòng)醫(yī)療設(shè)備等，常用的醫(yī)用氣體有氧氣、氮?dú)狻⒍趸肌嚎s空氣、真空吸引等。醫(yī)用氣體系統(tǒng)是指生產(chǎn)醫(yī)用氣體或抽排廢氣廢液的一整套裝置。醫(yī)用氣體系統(tǒng)建設(shè)關(guān)乎患者生命安危和醫(yī)療環(huán)境安全，作為生命支持系統(tǒng)，它是現(xiàn)代醫(yī)療體系的重要組成部分，具有廣泛的應(yīng)用。相關(guān)規(guī)范[1]規(guī)定：醫(yī)用氣體系統(tǒng)宜設(shè)置集中監(jiān)測(cè)與報(bào)警系統(tǒng)。由于該規(guī)范缺乏強(qiáng)制性條款，落實(shí)情況并不樂(lè)觀。醫(yī)院各站房和樓層的數(shù)據(jù)信息分散獨(dú)立，傳統(tǒng)人工巡檢抄表登記的監(jiān)測(cè)方式仍在采用。傳統(tǒng)監(jiān)測(cè)方式存在著諸多弊端[2-3]：值班員需24小時(shí)不間斷巡檢，人力成本高；巡檢周期長(zhǎng)，難以保證監(jiān)控的連續(xù)性，效率低下；安全隱患大，故障報(bào)警不能及時(shí)掌握和處理，嚴(yán)重時(shí)可能造成醫(yī)療事故；巡檢形成的數(shù)據(jù)文檔較多，數(shù)據(jù)零散，難以統(tǒng)一管理；歷史數(shù)據(jù)查詢困難，難以從中挖掘出有價(jià)值的信息。

為了解決傳統(tǒng)監(jiān)測(cè)方式存在的問(wèn)題，結(jié)合醫(yī)用氣體監(jiān)測(cè)數(shù)據(jù)的實(shí)時(shí)性、海量性、并發(fā)性等特點(diǎn)，立足業(yè)務(wù)發(fā)展的需要，設(shè)計(jì)并開(kāi)發(fā)了醫(yī)用氣體實(shí)時(shí)監(jiān)測(cè)平臺(tái)。本文平臺(tái)實(shí)現(xiàn)了監(jiān)測(cè)數(shù)據(jù)集中式地采集與云端存儲(chǔ)、遠(yuǎn)程實(shí)時(shí)監(jiān)控、報(bào)警聯(lián)動(dòng)、歷史數(shù)據(jù)檢索及統(tǒng)計(jì)分析等功能。借助該平臺(tái)，醫(yī)院可以實(shí)時(shí)監(jiān)測(cè)制氣設(shè)備的運(yùn)行狀態(tài)和氣體的使用情況，保障醫(yī)療用氣的安全性和可靠性，降低維修成本，減少經(jīng)濟(jì)損失。

現(xiàn)有一些監(jiān)測(cè)平臺(tái)[4]的數(shù)據(jù)采集端針對(duì)組態(tài)軟件而設(shè)計(jì)，數(shù)據(jù)接入方式受限，嚴(yán)重影響了平臺(tái)的通用性和實(shí)用性。本文提出基于參數(shù)配置表的數(shù)據(jù)接入方式具有較強(qiáng)的開(kāi)放性和靈活性，采集端依照約定的協(xié)議整合數(shù)據(jù)并上傳至數(shù)據(jù)接收端口，便可完成平臺(tái)的接入，監(jiān)測(cè)設(shè)備的擴(kuò)展便捷。針對(duì)醫(yī)院站點(diǎn)增加和設(shè)備增多導(dǎo)致的數(shù)據(jù)量增大和并發(fā)數(shù)據(jù)上傳等問(wèn)題，提出一種基于緩沖隊(duì)列的并發(fā)數(shù)據(jù)處理機(jī)制，解除業(yè)務(wù)間不必要的耦合，提高了平臺(tái)數(shù)據(jù)處理的性能。平臺(tái)用戶采用分級(jí)機(jī)制，各級(jí)用戶根據(jù)需要使用設(shè)備運(yùn)行數(shù)據(jù)，提高了數(shù)據(jù)利用率。現(xiàn)有基于WebSocket技術(shù)實(shí)時(shí)監(jiān)測(cè)系統(tǒng)的研究工作[5-7]，缺乏對(duì)WebSocket在瀏覽器兼容性上的考慮，本平臺(tái)融合WebSocket和SockJS技術(shù)實(shí)現(xiàn)瀏覽器與服務(wù)端真正的全雙工實(shí)時(shí)通信，且增強(qiáng)了對(duì)瀏覽器的兼容性。

1 架構(gòu)設(shè)計(jì)

為使平臺(tái)的處理邏輯更清晰，提高代碼的復(fù)用力度和平臺(tái)的可維護(hù)性，當(dāng)需求發(fā)生變化時(shí)，方便業(yè)務(wù)的完善和擴(kuò)展，設(shè)計(jì)如圖1所示的分層架構(gòu)。平臺(tái)分為數(shù)據(jù)層、業(yè)務(wù)層、控制層、表現(xiàn)層和用戶層五層，各層各司其職，具有較強(qiáng)的內(nèi)聚性，降低了層與層之間的耦合程度。最右側(cè)為各層相應(yīng)的主要技術(shù)選型。

圖1 平臺(tái)開(kāi)發(fā)架構(gòu)圖

(1) 用戶層：從用戶視角對(duì)應(yīng)的權(quán)限管理及功能視圖，用戶通過(guò)瀏覽器訪問(wèn)表現(xiàn)層以獲取信息資源。

(2) 表現(xiàn)層：平臺(tái)具有較好的交互性，以合適的圖表形式呈現(xiàn)數(shù)據(jù)資源，實(shí)現(xiàn)平臺(tái)和用戶的交互。

(3) 控制層：該層負(fù)責(zé)業(yè)務(wù)流程及訪問(wèn)權(quán)限的控制，將用戶的請(qǐng)求路由至業(yè)務(wù)層相應(yīng)的處理模塊。

(4) 業(yè)務(wù)層：該層負(fù)責(zé)具體業(yè)務(wù)邏輯的實(shí)現(xiàn)，包括用戶管理、設(shè)備管理、監(jiān)控報(bào)警、數(shù)據(jù)可視化等。

(5) 數(shù)據(jù)層：該層為業(yè)務(wù)層提供數(shù)據(jù)支撐，細(xì)分為數(shù)據(jù)訪問(wèn)層和數(shù)據(jù)存儲(chǔ)層。訪問(wèn)層定義了數(shù)據(jù)和文件的訪問(wèn)接口；存儲(chǔ)層負(fù)責(zé)數(shù)據(jù)的持久化，包括數(shù)據(jù)庫(kù)和文件系統(tǒng)。

2 功能設(shè)計(jì)

通過(guò)對(duì)業(yè)務(wù)需求的分析，抽離出一個(gè)個(gè)功能模塊，各自負(fù)責(zé)特定任務(wù)。模塊間相互獨(dú)立，耦合度較低，便于程序的維護(hù)和功能的擴(kuò)展，提高開(kāi)發(fā)效率。如圖2所示，平臺(tái)劃分為用戶管理、設(shè)備管理、數(shù)據(jù)采集、監(jiān)控報(bào)警、設(shè)備后維護(hù)五大功能模塊。

圖2 平臺(tái)功能模塊結(jié)構(gòu)圖

2.1 用戶分級(jí)管理

平臺(tái)涉及管理員、安裝公司和醫(yī)院三種角色，并基于角色進(jìn)行權(quán)限的劃分，賦予不同角色以不同的操作權(quán)限，實(shí)現(xiàn)了數(shù)據(jù)的隔離訪問(wèn)與高效利用。管理員是邏輯上主機(jī)設(shè)備和平臺(tái)用戶的管理者，安裝公司給醫(yī)院安裝氣體設(shè)備并負(fù)責(zé)維護(hù)，醫(yī)院則是氣體設(shè)備的使用者。三者通過(guò)主機(jī)設(shè)備進(jìn)行關(guān)聯(lián)，如圖3所示。

圖3 用戶-設(shè)備關(guān)系圖

管理員具有最高權(quán)限，負(fù)責(zé)安裝公司的合法性審核，進(jìn)行主機(jī)設(shè)備的創(chuàng)建、配置、分配和綁定，可以查看監(jiān)測(cè)數(shù)據(jù)；安裝公司將分配到的主機(jī)綁定至醫(yī)院，有權(quán)更改主機(jī)的配置，并基于歷史數(shù)據(jù)分析進(jìn)行設(shè)備的后維護(hù)；醫(yī)院權(quán)限最低，只能查看監(jiān)測(cè)數(shù)據(jù)。安裝公司在注冊(cè)時(shí)提交營(yíng)業(yè)憑證，待管理員審核通過(guò)后，才能獲得相應(yīng)權(quán)限。管理員與安裝公司之間、安裝公司和醫(yī)院之間、管理員與醫(yī)院之間皆為一對(duì)多的關(guān)系。

2.2 設(shè)備管理

設(shè)備管理模塊作為平臺(tái)的核心模塊之一，包括設(shè)備參數(shù)信息的配置、設(shè)備的分配、綁定和認(rèn)證。設(shè)備參數(shù)配置完成后，可導(dǎo)出參數(shù)配置表，配置表為數(shù)據(jù)采集端整合數(shù)據(jù)提供依據(jù)。通過(guò)設(shè)備管理，明確管理員、安裝公司、醫(yī)院對(duì)設(shè)備的職責(zé)，保證設(shè)備安全。安裝公司從數(shù)據(jù)中挖掘規(guī)律，從而制定高效的設(shè)備維護(hù)計(jì)劃和升級(jí)方案，向用戶提供更優(yōu)質(zhì)的服務(wù)。醫(yī)院全面掌握氣體生產(chǎn)和運(yùn)行情況、保障醫(yī)療安全，提高了設(shè)備運(yùn)行數(shù)據(jù)的利用率。

如圖3所示，管理員將創(chuàng)建好的主機(jī)設(shè)備分配給安裝公司，安裝公司將設(shè)備綁定至具體醫(yī)院。安裝公司可以分配得到多個(gè)主機(jī)設(shè)備，但一家醫(yī)院只能有一個(gè)主機(jī)設(shè)備，且一個(gè)主機(jī)設(shè)備只能綁定至一家醫(yī)院。主機(jī)設(shè)備綁定成功后產(chǎn)生唯一識(shí)別碼，數(shù)據(jù)上傳時(shí)須攜帶此碼，作為設(shè)備合法性認(rèn)證的依據(jù)。該模塊還提供了開(kāi)關(guān)報(bào)警短信通知的功能，在此功能開(kāi)啟的情況下，當(dāng)設(shè)備發(fā)生報(bào)警時(shí)，會(huì)立即將報(bào)警內(nèi)容以短信形式發(fā)送到醫(yī)院負(fù)責(zé)人手機(jī)上。

2.3 數(shù)據(jù)接入

部署于醫(yī)院的數(shù)據(jù)采集端依照參數(shù)配置表，采用約定的JSON格式，并攜帶設(shè)備的唯一識(shí)別碼，將數(shù)據(jù)上傳至平臺(tái)的數(shù)據(jù)接入模塊。如圖4所示為數(shù)據(jù)接入流程圖。

圖4 數(shù)據(jù)接入處理示意圖

該模塊負(fù)責(zé)對(duì)數(shù)據(jù)的完整性和合法性進(jìn)行校驗(yàn)。所謂完整性是指上傳的監(jiān)測(cè)參數(shù)是否和參數(shù)配置表一致，合法性指取值合法性和設(shè)備識(shí)別碼是否正確。若通過(guò)校驗(yàn)，則進(jìn)行數(shù)據(jù)的解析存儲(chǔ)等其他處理并返回“數(shù)據(jù)上傳成功”的消息，否則返回?cái)?shù)據(jù)錯(cuò)誤原因。

2.4 監(jiān)控報(bào)警

監(jiān)控報(bào)警模塊提供了數(shù)據(jù)實(shí)時(shí)監(jiān)測(cè)、異常情況平臺(tái)報(bào)警和短信報(bào)警、數(shù)據(jù)推送及數(shù)據(jù)可視化。交互性良好的可視化設(shè)計(jì)便于用戶掌握監(jiān)測(cè)數(shù)據(jù)的變化趨勢(shì)，用戶可根據(jù)需要切換數(shù)據(jù)的展示方式。

圖5為監(jiān)控報(bào)警流程示意圖。該模塊接收到通過(guò)完整性和合法性檢驗(yàn)的數(shù)據(jù)后，解析數(shù)據(jù)包中的標(biāo)志位以確定該數(shù)據(jù)是否為報(bào)警數(shù)據(jù)，如果是，再判斷該主機(jī)設(shè)備的報(bào)警短信通知業(yè)務(wù)是否開(kāi)啟，若開(kāi)啟，則將報(bào)警短信發(fā)送給醫(yī)院負(fù)責(zé)人，提示其及時(shí)采取應(yīng)對(duì)措施，排查報(bào)警設(shè)備。無(wú)論是否為報(bào)警數(shù)據(jù)，都會(huì)進(jìn)行數(shù)據(jù)的存儲(chǔ)，同時(shí)將數(shù)據(jù)推送到客戶端瀏覽器，實(shí)現(xiàn)數(shù)據(jù)的實(shí)時(shí)更新和可視化。

圖5 監(jiān)控報(bào)警流程示意圖

2.5 設(shè)備后維護(hù)

平臺(tái)提供了歷史數(shù)據(jù)和報(bào)警記錄檢索、數(shù)據(jù)統(tǒng)計(jì)分析等功能，根據(jù)用戶設(shè)定的時(shí)間段，以圖表形式展現(xiàn)數(shù)據(jù)的變化情況。平臺(tái)可為用戶統(tǒng)計(jì)出某時(shí)間段內(nèi)設(shè)備上傳的數(shù)據(jù)量、報(bào)警發(fā)生率等信息，并導(dǎo)出統(tǒng)計(jì)報(bào)表。此模塊可輔助設(shè)備維護(hù)人員做出更為合理的決策，制定更高效的設(shè)備檢修和維護(hù)方案，提高設(shè)備管理效率和服務(wù)質(zhì)量。例如，對(duì)于報(bào)警發(fā)生率高的設(shè)備或區(qū)域，應(yīng)提高檢修頻率，反之，可以適當(dāng)降低檢修頻率。

3 關(guān)鍵技術(shù)

3.1 針對(duì)高并發(fā)情況的數(shù)據(jù)處理與訪問(wèn)機(jī)制

3.1.1 并發(fā)數(shù)據(jù)處理機(jī)制

在數(shù)據(jù)接入模塊中，單條數(shù)據(jù)的處理要經(jīng)過(guò)數(shù)據(jù)校驗(yàn)(記為B1)和數(shù)據(jù)推送及存儲(chǔ)(記為B2)兩個(gè)階段。圖6(a)為常規(guī)的處理方式，在同一線程中依次進(jìn)行B1和B2處理，B2處理結(jié)束后給予采集端響應(yīng)，然后再處理下一條數(shù)據(jù)。當(dāng)出現(xiàn)數(shù)據(jù)并發(fā)上傳時(shí)，數(shù)據(jù)處理速度可能會(huì)滯后于數(shù)據(jù)接收速度，從而可能造成數(shù)據(jù)的阻塞或丟失，嚴(yán)重時(shí)可能導(dǎo)致平臺(tái)停止響應(yīng)。

(a) 常規(guī)方式 (b) 異步方式圖6 業(yè)務(wù)數(shù)據(jù)處理方式

上述處理方式中，B1和B2兩個(gè)子業(yè)務(wù)由于發(fā)生嚴(yán)重耦合，導(dǎo)致處理性能的下降。為此，設(shè)計(jì)了并發(fā)處理機(jī)制，如圖6(b)所示。主線程僅負(fù)責(zé)業(yè)務(wù)B1的處理，將校驗(yàn)成功的數(shù)據(jù)放入緩存隊(duì)列，然后給予采集端響應(yīng)，同時(shí)激活B2業(yè)務(wù)處理器，并為之開(kāi)辟新線程。新線程不斷地從緩存隊(duì)列中獲取數(shù)據(jù)進(jìn)行處理，同時(shí)主線程可繼續(xù)下一條數(shù)據(jù)的接收與處理。當(dāng)隊(duì)列中無(wú)數(shù)據(jù)可處理時(shí)，B2處理器所在線程進(jìn)入休眠狀態(tài)，以減少對(duì)服務(wù)器CPU資源的占用。這種處理機(jī)制實(shí)現(xiàn)了子業(yè)務(wù)間的解耦，方便與源數(shù)據(jù)處理相關(guān)業(yè)務(wù)的擴(kuò)展，緩解了主線程的壓力，大大提升了服務(wù)端的響應(yīng)速度和應(yīng)對(duì)高并發(fā)數(shù)據(jù)的處理能力。

3.1.2 高訪問(wèn)處理機(jī)制

監(jiān)測(cè)數(shù)據(jù)最終持久化于關(guān)系型數(shù)據(jù)庫(kù)中，處理資源請(qǐng)求的過(guò)程即是對(duì)數(shù)據(jù)庫(kù)進(jìn)行I/O操作的過(guò)程。當(dāng)有并發(fā)訪問(wèn)時(shí)，頻繁的I/O操作會(huì)使得關(guān)系型數(shù)據(jù)庫(kù)的性能瓶頸凸顯，導(dǎo)致數(shù)據(jù)庫(kù)系統(tǒng)性能下降。為此，考慮將數(shù)據(jù)緩存于內(nèi)存，以應(yīng)對(duì)并發(fā)訪問(wèn)。如圖7所示，服務(wù)端接收到來(lái)自客戶端的資源請(qǐng)求，首先查找緩存中是否存在目標(biāo)資源，若存在，直接獲取并返回；否則，前往關(guān)系型數(shù)據(jù)庫(kù)查找，將查找結(jié)果返回客戶端并更新緩存，以便下次訪問(wèn)。

圖7 基于緩存的資源訪問(wèn)設(shè)計(jì)

基于緩存的資源訪問(wèn)緩解了關(guān)系型數(shù)據(jù)庫(kù)的讀壓力。由于緩存數(shù)據(jù)庫(kù)占據(jù)內(nèi)存，當(dāng)緩存了大量歷史數(shù)據(jù)，系統(tǒng)整體吞吐量將降低，內(nèi)存空間也會(huì)受到壓縮，造成內(nèi)存空間不足，導(dǎo)致整體性能下降[15]。平臺(tái)采用最近最少使用LRU(Least Recently Used)策略淘汰“過(guò)期”資源數(shù)據(jù)，以防止內(nèi)存空間不足產(chǎn)生的影響。

在諸多緩存數(shù)據(jù)庫(kù)中，Redis能夠支持K/V、List隊(duì)列等多種數(shù)據(jù)結(jié)構(gòu)，支持?jǐn)?shù)據(jù)持久化。服務(wù)器斷電和重啟不會(huì)造成數(shù)據(jù)丟失。本文平臺(tái)選用Redis作為緩存數(shù)據(jù)庫(kù)。

3.2 基于參數(shù)配置表的數(shù)據(jù)接入方案

為方便監(jiān)測(cè)數(shù)據(jù)接入平臺(tái)，本文提出基于參數(shù)配置表的數(shù)據(jù)接入方案。方案約定數(shù)據(jù)采集端需將監(jiān)測(cè)數(shù)據(jù)以JSON數(shù)據(jù)包形式通過(guò)HTTP上傳至平臺(tái)數(shù)據(jù)接收端口。表1為方案中所設(shè)計(jì)的數(shù)據(jù)包協(xié)議，協(xié)議規(guī)定了包中應(yīng)有的元素及其取值類型。

表1 監(jiān)測(cè)數(shù)據(jù)JSON數(shù)據(jù)包協(xié)議

Excel參數(shù)配置表包含兩張sheet：其一描述了主機(jī)設(shè)備的唯一識(shí)別碼、數(shù)據(jù)上傳的接口地址及方式；其二明確了各設(shè)備站和區(qū)域配置的參數(shù)信息及其代號(hào)。假設(shè)某主機(jī)只啟用了二氧化碳生產(chǎn)設(shè)備并只監(jiān)測(cè)瓶組1壓力、瓶組1低壓報(bào)警限值及出口壓力3項(xiàng)參數(shù)，且添加了一個(gè)編號(hào)為BF101的區(qū)域并監(jiān)測(cè)該區(qū)域氧氣的使用狀態(tài)，導(dǎo)出的配置表如圖8所示。

(a) 主機(jī)身份及接口說(shuō)明

(b) 設(shè)備站/區(qū)域參數(shù)明細(xì)圖8 某主機(jī)參數(shù)配置表

根據(jù)配置表信息和數(shù)據(jù)包協(xié)議，組織JSON數(shù)據(jù)如下，最后調(diào)用數(shù)據(jù)上傳接口將數(shù)據(jù)包發(fā)送至平臺(tái)，實(shí)現(xiàn)數(shù)據(jù)接入。

{

"no":" 37d8a***f0c5",

"send_time":"2018-09-01 00:00:00",

"type":"0",

"equire_list":[{

"equire_no":"CO2",

"cs_list":[{

"cs_no":"CO201",

"cs_value":"20.15"

},{

"cs_no":"CO202",

"cs_value":"18.00"

},{

"cs_no":"CO207",

"cs_value":"20.00"

}

]

},{

"equire_no":"BF101",

"cs_list":[{

"cs_no":"FO201",

"cs_value":"0.59"

},{

"cs_no":"FO202",

"cs_value":"0.35"

},{

"cs_no":"FO203",

"cs_value":"0.70"

}

]

}

]

}

該方案對(duì)數(shù)據(jù)采集端的形式未加約束，只要可以按照數(shù)據(jù)協(xié)議整合數(shù)據(jù)并進(jìn)行HTTP數(shù)據(jù)傳輸?shù)木勺鳛椴杉耍瑯O大地提高了采集端的靈活性和平臺(tái)的開(kāi)放性。

3.3 基于WebSocket和SockJS的實(shí)時(shí)通信

通信實(shí)時(shí)性是醫(yī)用氣體實(shí)時(shí)監(jiān)測(cè)平臺(tái)的重要指標(biāo)。服務(wù)端接收到監(jiān)測(cè)數(shù)據(jù)后，應(yīng)即刻將數(shù)據(jù)推送到客戶端，以實(shí)現(xiàn)客戶端瀏覽器數(shù)據(jù)的實(shí)時(shí)刷新，從而使得用戶能夠在第一時(shí)間掌握設(shè)備的運(yùn)行狀態(tài)。

傳統(tǒng)實(shí)現(xiàn)Web實(shí)時(shí)交互的功能常采用輪詢技術(shù)和Comet技術(shù)[5-6]，Comet技術(shù)分為長(zhǎng)輪詢和流技術(shù)。輪詢要求客戶端定時(shí)向服務(wù)端發(fā)送請(qǐng)求，以頻繁請(qǐng)求的方式保持?jǐn)?shù)據(jù)的同步，但并非每次請(qǐng)求都能返回有效數(shù)據(jù)，由此造成帶寬資源的浪費(fèi)。長(zhǎng)輪詢與輪詢的區(qū)別在于，當(dāng)服務(wù)端數(shù)據(jù)沒(méi)有更新時(shí)，請(qǐng)求會(huì)被掛起以保持連接，直至有數(shù)據(jù)更新或連接超時(shí)，這種方式降低了無(wú)效的網(wǎng)絡(luò)傳輸和請(qǐng)求，但請(qǐng)求的掛起會(huì)導(dǎo)致資源的浪費(fèi)，且當(dāng)數(shù)據(jù)更新比較頻繁時(shí)，較輪詢?cè)谛阅苌蠜](méi)有本質(zhì)的提高。流技術(shù)是客戶端向服務(wù)端發(fā)起一個(gè)長(zhǎng)連接請(qǐng)求，服務(wù)端為之做出響應(yīng)并不斷更新連接狀態(tài)以保持連接，服務(wù)端通過(guò)此連接將數(shù)據(jù)主動(dòng)推送給客戶端。相較于輪詢和長(zhǎng)輪詢，流技術(shù)減小了服務(wù)器處理請(qǐng)求的壓力，但在數(shù)據(jù)并發(fā)程度高時(shí)易造成網(wǎng)絡(luò)阻塞。

傳統(tǒng)的Web實(shí)時(shí)技術(shù)是基于HTTP協(xié)議的請(qǐng)求響應(yīng)模式。圖9為傳統(tǒng)Web實(shí)時(shí)技術(shù)客戶端/服務(wù)器通信交互圖，通信只能由客戶端發(fā)起，并沒(méi)有實(shí)現(xiàn)真正意義的實(shí)時(shí)通信，只是借助Ajax異步請(qǐng)求來(lái)模擬實(shí)時(shí)交互效果。

圖9 傳統(tǒng)Web實(shí)時(shí)技術(shù)客戶端/服務(wù)端交互圖

醫(yī)用氣體實(shí)時(shí)監(jiān)測(cè)的參數(shù)多，數(shù)據(jù)量大，數(shù)據(jù)上傳頻率高(秒級(jí))，服務(wù)端的數(shù)據(jù)更新快，數(shù)據(jù)需要被頻繁地推送至客戶端以實(shí)現(xiàn)數(shù)據(jù)的實(shí)時(shí)展示。綜合以上分析，傳統(tǒng)的Web實(shí)時(shí)技術(shù)在醫(yī)用氣體實(shí)時(shí)監(jiān)測(cè)平臺(tái)中并不合適。

WebSocket作為HTML5的新特性[8]，實(shí)現(xiàn)了客戶端瀏覽器和服務(wù)器之間的全雙工通信，是真正意義的實(shí)時(shí)通信。圖10為WebSocket客戶端/服務(wù)器交互圖，瀏覽器使用JavaScript向服務(wù)端發(fā)送建立WebSocket連接的HTTP請(qǐng)求，建立連接后，客戶端與服務(wù)器均能主動(dòng)地向?qū)Ψ桨l(fā)送消息。

圖10 WebSocket客戶端/服務(wù)端交互圖

WebSocket在本質(zhì)上是基于TCP的協(xié)議，相較于基于HTTP協(xié)議的輪詢和Comet技術(shù)，數(shù)據(jù)傳輸更為穩(wěn)定高效，數(shù)據(jù)傳輸量更小[9]，從而減輕了服務(wù)器負(fù)載，節(jié)省網(wǎng)絡(luò)帶寬資源，提高了監(jiān)測(cè)平臺(tái)的實(shí)時(shí)性、穩(wěn)定性和可靠性。

當(dāng)前大多數(shù)瀏覽器均支持WebSocket，少部分(如IE10以下版本的瀏覽器)并沒(méi)有提供支持。對(duì)于這類瀏覽器，平臺(tái)采用SockJS作為備選方案。SockJS是對(duì)WebSocket的模擬，旨在為瀏覽器和服務(wù)器之間創(chuàng)建一個(gè)低延遲、全雙工、跨域通信的通道，且提供了JavaScript API，增強(qiáng)了瀏覽器的兼容性。在醫(yī)用氣體實(shí)時(shí)監(jiān)測(cè)平臺(tái)中，對(duì)支持WebSocket的瀏覽器優(yōu)先使用WebSocket，其次考慮SockJS。客戶端關(guān)鍵代碼如下:

if ("WebSocket" in window) {

websocket=new WebSocket("ws://{socketPath}/ws");

} else if ("MozWebSocket" in window) {

websocket=new MozWebSocket("ws://{socketPath}/ws");

} else {

websocket=new SockJS("http://{socketPath}/sockjs/ws");

}

//連接錯(cuò)誤的回調(diào)函數(shù)

websocket.onerror=function(event) { //TODO }

//連接成功的回調(diào)函數(shù)

websocket.onopen=function() { //TODO }

//接收到服務(wù)端數(shù)據(jù)的回調(diào)處理函數(shù)

websocket.onmessage=function(event) {

//解析event.data，實(shí)現(xiàn)數(shù)據(jù)的更新

}

//連接關(guān)閉的回調(diào)函數(shù)

websocket.onclose=function() { //TODO }

3.4 基于REST的Web服務(wù)接口

表述性狀態(tài)轉(zhuǎn)移REST(Representational State Transfer)是Roy Fielding在其博士論文[10]中提出的一種軟件架構(gòu)風(fēng)格，為構(gòu)建可擴(kuò)展、可移植和松耦合的Web程序提供了一個(gè)架構(gòu)上的準(zhǔn)則[11-14]。REST將Web中的所有事物抽象成資源，使用統(tǒng)一資源標(biāo)識(shí)符URI(Uniform Resource Identifier)對(duì)每個(gè)資源進(jìn)行標(biāo)識(shí)，通過(guò)復(fù)用HTTP協(xié)議的動(dòng)詞，對(duì)資源進(jìn)行操作，這種基于資源的設(shè)計(jì)改變了傳統(tǒng)的基于服務(wù)的設(shè)計(jì)思想。

為資源設(shè)計(jì)簡(jiǎn)潔明了、結(jié)構(gòu)良好的URI是構(gòu)建REST服務(wù)的關(guān)鍵。本文平臺(tái)主要使用了POST、GET、DELETE、PUT、PATCH五類動(dòng)詞，分別用于新建資源、獲取資源、刪除資源、修改資源整體、修改資源局部信息。表2為本文平臺(tái)設(shè)計(jì)的RESTful API(符合REST的接口)示例。

表2 URI應(yīng)用示例

RESTful API中的URI只使用名詞，用于標(biāo)識(shí)資源，用HTTP動(dòng)詞標(biāo)識(shí)具體的行為，可讀性高。接口的響應(yīng)采用JSON對(duì)資源進(jìn)行描述，實(shí)現(xiàn)了資源描述和視圖的解耦。REST便于設(shè)計(jì)和對(duì)外提供可被第三方調(diào)用的Open API。

3.5 其他技術(shù)

(1) 輕量級(jí)的數(shù)據(jù)交換格式 考慮到采集端數(shù)據(jù)上傳頻率高、服務(wù)端與客戶端數(shù)據(jù)通信頻繁等特點(diǎn)，平臺(tái)選用輕量級(jí)的JSON作為數(shù)據(jù)交換格式。相較于XML，JSON數(shù)據(jù)有效減少了數(shù)據(jù)格式中的冗余標(biāo)記，體積小，傳輸速度快，帶寬占比小。JSON數(shù)據(jù)可被直接解碼為JavaScript對(duì)象，解析便捷，與Ajax完美搭配，實(shí)現(xiàn)客戶端瀏覽器信息數(shù)據(jù)的異步讀取和局部刷新。

(2) 基于ECharts的數(shù)據(jù)可視化 監(jiān)測(cè)數(shù)據(jù)可視化是醫(yī)用氣體實(shí)時(shí)監(jiān)測(cè)平臺(tái)的一大重要內(nèi)容。數(shù)據(jù)可視化旨在為用戶提供直觀的圖形圖表，便于觀察數(shù)據(jù)的變化趨勢(shì)。本文平臺(tái)基于ECharts實(shí)現(xiàn)監(jiān)測(cè)數(shù)據(jù)可視化。ECharts是一款開(kāi)源的、基于JavaScript實(shí)現(xiàn)的數(shù)據(jù)可視化圖表庫(kù)，其底層依賴于輕量級(jí)的Canvas類庫(kù)ZRender，提供了直觀、可交互、可個(gè)性化定制的數(shù)據(jù)化圖表，瀏覽器兼容性好，在PC和移動(dòng)設(shè)備上運(yùn)行流暢。

4 實(shí) 現(xiàn)

4.1 物理結(jié)構(gòu)

本文平臺(tái)采用如圖11所示的物理結(jié)構(gòu)。數(shù)據(jù)采集端部署于醫(yī)院，負(fù)責(zé)數(shù)據(jù)的采集。組態(tài)軟件或其他數(shù)據(jù)匯集器整合制氣設(shè)備的運(yùn)行參數(shù)和各區(qū)域氣體的使用狀態(tài)數(shù)據(jù)，通過(guò)調(diào)用相應(yīng)的API將數(shù)據(jù)上傳至服務(wù)平臺(tái)。服務(wù)平臺(tái)提供了友好的RESTful API，方便設(shè)備接入和客戶端訪問(wèn)。相較于C/S開(kāi)發(fā)模式部署復(fù)雜、維護(hù)困難、擴(kuò)展性差等弊端，平臺(tái)選用更為靈活的B/S模式，用戶借助可聯(lián)網(wǎng)終端(如手機(jī)、電腦、平板)通過(guò)Web即可訪問(wèn)平臺(tái)，隨時(shí)隨地掌握設(shè)備的運(yùn)行狀態(tài)和氣體的使用情況。

圖11 平臺(tái)物理結(jié)構(gòu)圖

4.2 安裝公司管理

如圖12所示為管理員進(jìn)行安裝公司管理。管理員可查看安裝公司上傳的營(yíng)業(yè)憑證及其詳細(xì)信息，對(duì)其進(jìn)行合法性審核。審核狀態(tài)分為“未經(jīng)審核”、“審核通過(guò)”和“審核不通過(guò)”，管理員可分類查看各審核狀態(tài)下的用戶列表，默認(rèn)顯示全部安裝公司。

圖12 安裝公司管理

4.3 設(shè)備管理

圖13為主機(jī)設(shè)備列表頁(yè)，不同顏色標(biāo)注主機(jī)的分配情況。點(diǎn)擊“添加主機(jī)”，并輸入主機(jī)編號(hào)以創(chuàng)建主機(jī)。主機(jī)編號(hào)不能與已有主機(jī)編號(hào)相同，否則將創(chuàng)建失敗。

圖13 主機(jī)列表

點(diǎn)擊已創(chuàng)建的主機(jī)，進(jìn)入主機(jī)詳情頁(yè)，可進(jìn)行設(shè)備站(指各類氣體的生產(chǎn)設(shè)備)的啟用、停用，參數(shù)的配置，區(qū)域的增刪、配置以及報(bào)警短信通知的開(kāi)關(guān)等。圖14為液氧源監(jiān)測(cè)參數(shù)配置過(guò)程。

圖14 主機(jī)參數(shù)配置

主機(jī)各設(shè)備站和區(qū)域參數(shù)配置完成后，將主機(jī)分配給通過(guò)審核的安裝公司，圖15為主機(jī)分配過(guò)程。接下來(lái)，將主機(jī)綁定至安裝公司旗下的醫(yī)院。

圖15 主機(jī)設(shè)備分配

圖16為綁定過(guò)程，已綁定到主機(jī)的醫(yī)院不會(huì)再顯示于列表中。主機(jī)分配工作由管理員進(jìn)行，主機(jī)配置與綁定工作可由管理員或安裝公司進(jìn)行。

圖16 主機(jī)設(shè)備綁定

主機(jī)被綁定后，產(chǎn)生唯一識(shí)別碼，作為數(shù)據(jù)上傳的憑證，如圖17所示。主機(jī)配置完成，可點(diǎn)擊“導(dǎo)出參數(shù)表”按鈕以導(dǎo)出Excel參數(shù)配置表。

圖17 主機(jī)唯一識(shí)別碼

4.4 實(shí)時(shí)數(shù)據(jù)展示

當(dāng)瀏覽器接收到服務(wù)端推送的數(shù)據(jù)，實(shí)時(shí)更新圖表數(shù)據(jù)和時(shí)間。圖18為某主機(jī)氮?dú)馍a(chǎn)設(shè)備運(yùn)行狀態(tài)實(shí)時(shí)展示界面，該設(shè)備同時(shí)監(jiān)測(cè)了瓶組1和瓶組2壓力狀態(tài)，圖表以不同顏色標(biāo)識(shí)，將鼠標(biāo)放在時(shí)間點(diǎn)會(huì)顯示相應(yīng)時(shí)刻各瓶組的壓力值。

圖18 實(shí)時(shí)數(shù)據(jù)顯示界面

4.5 歷史數(shù)據(jù)檢索與統(tǒng)計(jì)分析

圖19為某區(qū)域某時(shí)間段氧氣壓力歷史數(shù)據(jù)查詢結(jié)果。平臺(tái)默認(rèn)以折線圖展現(xiàn)最近的150條數(shù)據(jù)，用戶可拖動(dòng)圖表下方滾動(dòng)條以展示更多數(shù)據(jù)，圖表右上角的工具按鈕可用于實(shí)現(xiàn)數(shù)據(jù)呈現(xiàn)方式的切換等。

圖19 區(qū)域氧氣歷史數(shù)據(jù)查詢結(jié)果

如圖20為數(shù)據(jù)統(tǒng)計(jì)結(jié)果。用戶可查看截至當(dāng)前時(shí)刻，平臺(tái)共接收到的數(shù)據(jù)總量、正常數(shù)據(jù)、異常報(bào)警數(shù)據(jù)數(shù)量及其所占比例。

圖20 區(qū)域氧氣報(bào)警數(shù)據(jù)統(tǒng)計(jì)結(jié)果

5 測(cè)試與對(duì)比

為驗(yàn)證本文平臺(tái)具有高響應(yīng)率和高性能的特點(diǎn)，將本文的并發(fā)處理機(jī)制與傳統(tǒng)的同步方法進(jìn)行對(duì)比，并進(jìn)行了4組測(cè)試，分析在處理800、1 500、2 500、3 600 Byte左右大小JSON數(shù)據(jù)包的時(shí)間消耗情況。數(shù)據(jù)采集頻率設(shè)為1秒，每次測(cè)試連續(xù)發(fā)送200次數(shù)據(jù)，取平均值作為耗時(shí)結(jié)果，結(jié)果如圖21所示。結(jié)果表明，本文方法能明顯降低平臺(tái)的響應(yīng)時(shí)間，進(jìn)而可以處理更多的數(shù)據(jù)包，提高了平臺(tái)的處理性能。

圖21 耗時(shí)對(duì)比圖

從功能點(diǎn)角度，將本文平臺(tái)與現(xiàn)有同類平臺(tái)進(jìn)行對(duì)比，如表3所示。

表3 功能點(diǎn)對(duì)比

6 結(jié) 語(yǔ)

本文設(shè)計(jì)和實(shí)現(xiàn)的醫(yī)用氣體實(shí)時(shí)監(jiān)測(cè)平臺(tái)有效克服了傳統(tǒng)監(jiān)測(cè)方式巡檢周期長(zhǎng)、安全隱患大、工作效率低、數(shù)據(jù)利用率低等弊端，實(shí)現(xiàn)了數(shù)據(jù)接入、遠(yuǎn)程實(shí)時(shí)監(jiān)測(cè)、報(bào)警聯(lián)動(dòng)、歷史數(shù)據(jù)檢索及統(tǒng)計(jì)分析等功能。并發(fā)處理機(jī)制的設(shè)計(jì)縮短了平臺(tái)服務(wù)的響應(yīng)時(shí)間，提高了平臺(tái)應(yīng)對(duì)并發(fā)海量數(shù)據(jù)的處理性能。緩存技術(shù)的引入降低了數(shù)據(jù)庫(kù)負(fù)載，提高了平臺(tái)的訪問(wèn)效率。在數(shù)據(jù)接入方面，提出基于配置表的數(shù)據(jù)接入方案，提高了平臺(tái)的開(kāi)放性、通用性和實(shí)用性。融合WebSocket和SockJS技術(shù)實(shí)現(xiàn)B/S的全雙工實(shí)時(shí)通信，克服了傳統(tǒng)Web實(shí)時(shí)技術(shù)的弊端，解決了WebSocket瀏覽器兼容性問(wèn)題。平臺(tái)選用JSON作為數(shù)據(jù)交換格式，節(jié)省帶寬資源，提高了數(shù)據(jù)傳輸和解析效率。該平臺(tái)的應(yīng)用可以降低醫(yī)療用氣的風(fēng)險(xiǎn)，節(jié)省維護(hù)成本，提高工作效率。目前，平臺(tái)已投入試運(yùn)行階段，且運(yùn)行狀況良好。