物聯(lián)網(wǎng)應(yīng)用案例-基于 NB-IoT 的 AED智能管理系統(tǒng)

基于NB-IoT的AED智能管理系統(tǒng)物聯(lián)網(wǎng)應(yīng)用案例6.1背景與需求分析6.2功能設(shè)計6.3系統(tǒng)實(shí)現(xiàn)6.4總結(jié)與展望目錄目前，全球的心血管疾病患病率和死亡率都處于上升階段，心源性猝死（SuddenCardiacDeath，SCD）已成為主要的致死原因。導(dǎo)致SCD的主要原因是室性心動過速和室顫，早期電除顫是增加患者生存率的主要方法。救護(hù)車通常會配備專業(yè)的除顫儀，然而限于較長的院前急救反應(yīng)時間，救護(hù)車通常無法在5分鐘內(nèi)及時到達(dá)現(xiàn)場，從而錯過了救援的黃金時間。因此，一種廣泛放置于公共場所、供百姓在緊急醫(yī)療事件發(fā)生時使用的便攜式體外除顫儀的開發(fā)被逐漸提上日程。6.1.1案例背景自動體外除顫儀（AutomatedExternalDefibrillator，AED）是一種自動化程度極高的除顫設(shè)備。目前國外的AED生產(chǎn)廠家有美國的美敦力（Medtronic）公司、荷蘭的飛利浦（Phillips）公司和日本的光電公司等，國內(nèi)主要是邁瑞（mindray）公司在進(jìn)行AED的生產(chǎn)。邁瑞B(yǎng)eneHeartD1型AED的實(shí)物圖如圖6-1所示。圖6-1邁瑞B(yǎng)eneHeartD1型AED實(shí)物圖中國的AED工程開始于2004年，從現(xiàn)階段來看，AED在中國主要部署在大型城市的機(jī)場、火車站和地鐵站等，在特大型城市的核心區(qū)域部署密度相對較大。圖6-2展示了上海中心城區(qū)的AED分布情況。6.1.1案例背景從整體上來看，中國的AED部署情況還是遠(yuǎn)遠(yuǎn)不如發(fā)達(dá)國家。據(jù)公開資料顯示，截至2015年，全國固定AED的部署數(shù)量不足千臺，每10萬人僅配備0.2～0.3臺AED，遠(yuǎn)低于日本——世界AED人均部署數(shù)量最多的國家的393.7臺。在中國政府的不斷倡導(dǎo)和推動下，不久的將來，中國使用AED進(jìn)行對心臟驟停患者的院前急救將會得到更高程度的普及，AED部署數(shù)量也將逐漸與發(fā)達(dá)國家齊平。圖6-2上海中心城區(qū)的AED分布情況（紅點(diǎn)表示AED）在實(shí)際應(yīng)用中，通常會遇到以下幾個問題。6.1.2需求分析設(shè)備找尋當(dāng)有緊急醫(yī)療事件發(fā)生時，“第一反應(yīng)人”往往無法及時獲知周邊AED的部署情況，從而無法快速獲取最近的AED（假定心臟驟?；颊咛幱贏ED覆蓋密度較大的區(qū)域，例如上海中心城區(qū)）。設(shè)備維護(hù)設(shè)備使用電量是決定AED能否正常工作的關(guān)鍵因素，AED長時間靜置會導(dǎo)致電量流失，如果不加維護(hù)，很有可能導(dǎo)致在有緊急醫(yī)療事件發(fā)生時，該AED無法正常工作。AED設(shè)備價值昂貴，進(jìn)口AED均價在2～4萬元，國產(chǎn)AED價格也在1萬元以上，一旦被盜，損失較大，且影響在緊急情況下的使用。由于目前國內(nèi)的急救培訓(xùn)覆蓋率仍較低，大部分人不會使用也不敢使用AED，從而造成了AED的閑置。設(shè)備防盜對于上述最后一個問題，可以通過政府加大AED使用的培訓(xùn)力度及建立健全急救相關(guān)法律法規(guī)得以解決。為了解決以上問題，本案例提出將AED納入物聯(lián)網(wǎng)范疇，設(shè)計一個基于NB-IoT的AED智能管理系統(tǒng)，通過設(shè)備傳感器上報數(shù)據(jù)，在管理平臺實(shí)時反映設(shè)備安全狀態(tài)和電量情況，保證AED的有效性。6.1.2需求分析設(shè)備找尋01OPTION針對在緊急醫(yī)療事件發(fā)生后，“第一反應(yīng)人”可能無法及時找到周邊AED這一問題，騰訊公司在2016年與中國紅十字會合作，推出了“互聯(lián)網(wǎng)+急救”AED地圖。ADE地圖問題：使用方法卻相對復(fù)雜，未對距離使用者最近的AED進(jìn)行提示，并不能告知用戶某一設(shè)備是否能夠正常工作（如是否被盜、是否出現(xiàn)故障等）。解決問題：本案例在騰訊AED地圖的基礎(chǔ)之上添加了地圖交互功能，使用者每次打開App，系統(tǒng)會自動提示距離其最近的AED位置，簡化了尋找AED的過程，增加顯示該AED的狀態(tài)，如果AED被盜、電量過低或是正在被其他人使用，地圖上將使用不同顏色的點(diǎn)來標(biāo)記。6.1.2需求分析設(shè)備維護(hù)02OPTIONAED維護(hù)的重點(diǎn)便是設(shè)備電量，AED的電量是決定AED能否正常工作的關(guān)鍵因素，過低的電量將導(dǎo)致AED無法完成一次完整的充放電，即無法完成除顫操作，從而影響搶救進(jìn)程。加大巡視維護(hù)頻率或采取專人看管的方式固然可以保證AED的正常使用，卻極大地浪費(fèi)了人力、物力，效率低下，也是一種不可取的方式。本案例在AED內(nèi)部增設(shè)NB-IoT模組，使得其原本自帶的電量和故障檢測結(jié)果信息可以通過NB-IoT模組發(fā)送至AED設(shè)備管理平臺。管理方工作人員只需觀測上報數(shù)據(jù)便可實(shí)時了解設(shè)備的工作狀態(tài)，如果設(shè)備出現(xiàn)故障，便可以立刻派遣維修人員前去維修。這樣可以較大程度節(jié)省人力、物力，同時提高工作效率。6.1.2需求分析設(shè)備防盜03OPTION目前有兩種較為常見的做法。一種是將AED上鎖，使用時需要由專門的人（一般為保安等）來開鎖；另一種是直接將AED放在有人看管的地方。上述兩種做法的問題：對于前者，雖然能保障AED的安全，但找相關(guān)負(fù)責(zé)人開鎖，詢問過程浪費(fèi)時間，后者則其適用范圍較為狹窄，僅適合有問詢臺的室內(nèi)場所。本案例在AED內(nèi)部新增一個傳感器，用于監(jiān)測設(shè)備的運(yùn)動狀態(tài)，并實(shí)時上報管理平臺。當(dāng)AED發(fā)生非合法運(yùn)動，即在非使用或維護(hù)狀態(tài)下發(fā)生運(yùn)動，則監(jiān)測系統(tǒng)將立即發(fā)出警告，告知工作人員設(shè)備被盜，從而啟動相應(yīng)程序。6.2.1系統(tǒng)架構(gòu)圖6-3為AED智能管理系統(tǒng)的整體架構(gòu)。AED定時將采集到的數(shù)據(jù)上報至云平臺，管理平臺和移動客戶端從云平臺獲取數(shù)據(jù)，并在界面上實(shí)時顯示各AED的工作狀態(tài)。與此同時，工作人員可以通過管理平臺（“第一反應(yīng)人”可以通過移動客戶端）向AED下發(fā)命令，從而改變其工作狀態(tài)（如復(fù)位等）。圖6-3AED智能管理系統(tǒng)的整體架構(gòu)6.2.2管理平臺AED管理平臺是供AED管理機(jī)構(gòu)了解各AED工作狀態(tài)的軟件。它主要滿足設(shè)備維護(hù)和設(shè)備防盜的需求，其界面大致如圖6-4所示。管理平臺顯示的內(nèi)容包括各AED的序號、位置和狀態(tài)等。作為管理方，它需要精確顯示各AED的確切工作狀態(tài)，包括“正常工作”“低電量”“使用中”“維修中”和“已被盜”5種狀態(tài)。圖6-4AED管理平臺界面6.2.2管理平臺“低電量”：管理人員就可通知相關(guān)的維護(hù)人員前去維護(hù)充電?！笆褂弥小保汗芾砥脚_會立即與急救指揮中心取得聯(lián)系，確認(rèn)該AED附近是否有求救信息，倘若沒有相關(guān)信息，則等待一定時間后再次查詢，循環(huán)往復(fù)，直至預(yù)先設(shè)定的次數(shù)（這里假定為10次）。“已被盜”：時管理平臺會根據(jù)AED的運(yùn)動信息判斷其是否被盜，若AED確實(shí)在運(yùn)動，則平臺自動下發(fā)命令將AED的工作狀態(tài)改為“已被盜”并啟動相關(guān)程序；“正常工作”：若AED并未運(yùn)動，則平臺自動下發(fā)命令將AED的工作狀態(tài)改為“正常工作”?！笆褂弥小保簳r的流程圖如圖6-5所示。圖6-5設(shè)備狀態(tài)為“使用中”時的流程圖6.2.2管理平臺管理平臺還提供新增AED的功能，管理人員只需單擊“添加設(shè)備”按鈕，彈出“注冊新設(shè)備”界面，輸入AED設(shè)備中NB-IoT模組的IMEI號及其部署位置（Location），如圖6-6所示，即可成功添加設(shè)備。待該設(shè)備正式部署到位并上電后，便會在主界面中顯示相應(yīng)的設(shè)備信息。圖6-6“注冊新設(shè)備”界面6.2.3移動客戶端移動客戶端是供普通大眾在發(fā)現(xiàn)心臟驟停患者后及時找到最近的AED的軟件，它主要滿足了設(shè)備找尋需求，其主界面大致如圖6-7所示。由于AED具有市政設(shè)施的屬性，且屬于急救醫(yī)療的重要一環(huán)，因此，本軟件的使用者必須實(shí)名注冊，從而便于政府監(jiān)督和規(guī)范其使用行為。實(shí)名注冊的內(nèi)容包括用戶姓名、手機(jī)號、身份證號、是否為注冊急救員等。一方面，實(shí)名注冊有利于政府追蹤惡意使用AED的使用者，從而依法對其做出處理。另一方面，當(dāng)緊急醫(yī)療事件發(fā)生時，若使用者啟用某一設(shè)備，實(shí)名注冊將有助于系統(tǒng)及時向周邊的注冊急救員發(fā)送相關(guān)信息，請求其到現(xiàn)場提供更加專業(yè)的救助（如心肺復(fù)蘇等），從而進(jìn)一步提高心臟驟?；颊叩纳媛?。圖6-7移動客戶端的主界面6.2.4維護(hù)平臺作為一個完整的AED管理系統(tǒng)，除了之前提到的供管理方使用的AED管理平臺和供大眾使用的移動客戶端之外，還應(yīng)包括供維修人員使用的維護(hù)系統(tǒng)。維修人員的客戶端主要顯示目前出現(xiàn)故障的AED信息，主要包括其地理位置等。維修人員在對某一AED進(jìn)行維修前，首先需要點(diǎn)擊AED維護(hù)系統(tǒng)工作界面上相應(yīng)AED的“維護(hù)”按鈕以獲得授權(quán)，再對其進(jìn)行維修。設(shè)備維修完畢后，維修人員仍需在界面上點(diǎn)擊“復(fù)位”按鈕恢復(fù)其正常工作狀態(tài)。AED維護(hù)系統(tǒng)工作界面如圖6-8所示。圖6-8AED維護(hù)系統(tǒng)工作界面6.3.1感知層技術(shù)AED智能管理系統(tǒng)主要監(jiān)測AED的電量和運(yùn)動情況，根據(jù)其不同情況下的組合得出相應(yīng)的工作狀態(tài)?？紤]到真正的AED設(shè)備已集成了電壓傳感元件，本案例在原型中僅僅將運(yùn)動傳感元件——六軸傳感器作為感知層的內(nèi)容。12由于案例選用的ThundersoftTurboXNB-IoT開發(fā)板上已預(yù)置了六軸傳感器，因此不需要再采購新的傳感元件。在技術(shù)細(xì)節(jié)上，由于六軸傳感器已經(jīng)預(yù)先集成在案例選用的開發(fā)板上，因此無須對其進(jìn)行硬件連接。六軸傳感器是通過UART串口與開發(fā)板進(jìn)行通信的，因此案例使用相應(yīng)的串口函數(shù)來不斷獲取數(shù)據(jù)。3六軸傳感器獲得的數(shù)據(jù)包括傳感器所在的空間相對位置坐標(biāo)及其姿態(tài)（即相對x、y、z軸的傾角）。由于只需了解AED是否在運(yùn)動，因此我們只需要獲取AED的位置坐標(biāo)而可以忽略其姿態(tài)信息。6.3.1控制層技術(shù)在控制層，本案例選用ThundersoftTurboXNB-IoT開發(fā)板作為主板，主控芯片為STM32L476?？刂茖又饕瓿蓪鞲衅魉杉瘮?shù)據(jù)的處理，以及對下發(fā)命令的響應(yīng)。AED的狀態(tài)轉(zhuǎn)變圖如圖6-9所示，各下發(fā)命令的含義見表6-1。圖6-9AED的狀態(tài)轉(zhuǎn)變圖下發(fā)命令含義0令A(yù)ED工作狀態(tài)恢復(fù)為“正常工作”2令A(yù)ED工作狀態(tài)轉(zhuǎn)變?yōu)椤笆褂弥小?令A(yù)ED工作狀態(tài)轉(zhuǎn)變?yōu)椤熬S修中”6.3.3傳輸層技術(shù)本案例選用NB-IoT作為傳輸層技術(shù)，這主要是因?yàn)镹B-IoT具有廣覆蓋、大容量、低成本、低功耗的特性。在具體實(shí)現(xiàn)上，本案例選用QuectelLTEBC95-B8NB-IoT模組。它是一款高性能、低功耗的NB-IoT無線通信模塊，能較大限度地滿足終端設(shè)備對小尺寸模塊產(chǎn)品的需求，同時有效地幫助客戶減小產(chǎn)品尺寸并降低產(chǎn)品成本，其產(chǎn)品如圖6-10所示。圖6-10QuectelLTEBC95-B8NB-IoT模組產(chǎn)品6.3.4平臺層技術(shù)Profile文件開發(fā)01OPTIONProfile文件是一種用來描述一款設(shè)備是什么、能做什么及如何控制該設(shè)備的文件，它是json文件格式。Profile文件分為兩個部分，包括設(shè)備能力描述和服務(wù)描述。本案例的Profile文件見下表。服務(wù)屬性取值含義conditionisMoving0或1AED是否運(yùn)動，0表示否，1表示是batteryLevel0～100AED電量status0～4AED狀態(tài)，0表示正常工作，1表示低電量，2表示使用中，3表示維修中，4表示被盜6.3.4平臺層技術(shù)編解碼插件的運(yùn)用02OPTION與Profile文件開發(fā)一樣，現(xiàn)有的華為云物聯(lián)網(wǎng)平臺支持在線編解碼插件開發(fā)。由于此項(xiàng)開發(fā)較為簡單，華為官方網(wǎng)站上已有成熟的教程指導(dǎo)，故這里不再贅述具體細(xì)節(jié)。編解碼插件相關(guān)知識本書2.3.2小節(jié)已進(jìn)行介紹。本案例之所以要使用編解碼插件，是因?yàn)槟舷蛟O(shè)備與華為云物聯(lián)網(wǎng)平臺之間的通信是基于CoAP協(xié)議的，而不是采用較為流行的json格式，這主要是因?yàn)槟舷蛟O(shè)備對省電要求較高，使用CoAP協(xié)議能夠以更少的字節(jié)傳輸相同的內(nèi)容。6.3.5應(yīng)用層技術(shù)管理平臺01OPTION在案例使用JavaScript來開發(fā)管理平臺，并使用Model-View-Controller（MVC）框架作為案例的開發(fā)框架。MVC框架是一種非常重要的軟件設(shè)計模式，如圖6-11所示。這種模式被廣泛應(yīng)用于應(yīng)用程序的分層開發(fā)，具體內(nèi)容如下。Model（模型）：數(shù)據(jù)模型，提供要展示的數(shù)據(jù)，包含數(shù)據(jù)和行為。它是應(yīng)用程序中用于處理應(yīng)用程序數(shù)據(jù)邏輯的部分。View（視圖）：一般就是我們見到的用戶界面，負(fù)責(zé)進(jìn)行模型的展示，是應(yīng)用程序中處理數(shù)據(jù)顯示的部分。Controller（控制器）：控制器接收用戶請求，委托給模型進(jìn)行處理（狀態(tài)改變），處理完畢后把返回的業(yè)務(wù)數(shù)據(jù)傳遞給視圖，由視圖負(fù)責(zé)展示。圖6-11MVC框架6.3.5應(yīng)用層技術(shù)按照MVC模式，本案例將應(yīng)用程序劃分為3個部分，并為每一個部分建立自己的包。12ch.IOT.model包：這個包用來放置模型類。ch.IOT.view包：這個包用來放置所有界面布局文件和控制類。3ch.IOT