医用气体实时监测平台的设计与实现

张凡进 郭立君 张 荣 周丰平

1(宁波大学信息科学与工程学院 浙江 宁波 315211) 2(宁波视线软件科技有限公司 浙江 宁波 315200)

0 引 言

医用气体是指医疗过程中使用的气体，用于治疗、麻醉患者或驱动医疗设备等，常用的医用气体有氧气、氮气、二氧化碳、压缩空气、真空吸引等。医用气体系统是指生产医用气体或抽排废气废液的一整套装置。医用气体系统建设关乎患者生命安危和医疗环境安全，作为生命支持系统，它是现代医疗体系的重要组成部分，具有广泛的应用。相关规范[1]规定：医用气体系统宜设置集中监测与报警系统。由于该规范缺乏强制性条款，落实情况并不乐观。医院各站房和楼层的数据信息分散独立，传统人工巡检抄表登记的监测方式仍在采用。传统监测方式存在着诸多弊端[2-3]：值班员需24小时不间断巡检，人力成本高；巡检周期长，难以保证监控的连续性，效率低下；安全隐患大，故障报警不能及时掌握和处理，严重时可能造成医疗事故；巡检形成的数据文档较多，数据零散，难以统一管理；历史数据查询困难，难以从中挖掘出有价值的信息。

为了解决传统监测方式存在的问题，结合医用气体监测数据的实时性、海量性、并发性等特点，立足业务发展的需要，设计并开发了医用气体实时监测平台。本文平台实现了监测数据集中式地采集与云端存储、远程实时监控、报警联动、历史数据检索及统计分析等功能。借助该平台，医院可以实时监测制气设备的运行状态和气体的使用情况，保障医疗用气的安全性和可靠性，降低维修成本，减少经济损失。

现有一些监测平台[4]的数据采集端针对组态软件而设计，数据接入方式受限，严重影响了平台的通用性和实用性。本文提出基于参数配置表的数据接入方式具有较强的开放性和灵活性，采集端依照约定的协议整合数据并上传至数据接收端口，便可完成平台的接入，监测设备的扩展便捷。针对医院站点增加和设备增多导致的数据量增大和并发数据上传等问题，提出一种基于缓冲队列的并发数据处理机制，解除业务间不必要的耦合，提高了平台数据处理的性能。平台用户采用分级机制，各级用户根据需要使用设备运行数据，提高了数据利用率。现有基于WebSocket技术实时监测系统的研究工作[5-7]，缺乏对WebSocket在浏览器兼容性上的考虑，本平台融合WebSocket和SockJS技术实现浏览器与服务端真正的全双工实时通信，且增强了对浏览器的兼容性。

1 架构设计

为使平台的处理逻辑更清晰，提高代码的复用力度和平台的可维护性，当需求发生变化时，方便业务的完善和扩展，设计如图1所示的分层架构。平台分为数据层、业务层、控制层、表现层和用户层五层，各层各司其职，具有较强的内聚性，降低了层与层之间的耦合程度。最右侧为各层相应的主要技术选型。

图1 平台开发架构图

(1) 用户层：从用户视角对应的权限管理及功能视图，用户通过浏览器访问表现层以获取信息资源。

(2) 表现层：平台具有较好的交互性，以合适的图表形式呈现数据资源，实现平台和用户的交互。

(3) 控制层：该层负责业务流程及访问权限的控制，将用户的请求路由至业务层相应的处理模块。

(4) 业务层：该层负责具体业务逻辑的实现，包括用户管理、设备管理、监控报警、数据可视化等。

(5) 数据层：该层为业务层提供数据支撑，细分为数据访问层和数据存储层。访问层定义了数据和文件的访问接口；存储层负责数据的持久化，包括数据库和文件系统。

2 功能设计

通过对业务需求的分析，抽离出一个个功能模块，各自负责特定任务。模块间相互独立，耦合度较低，便于程序的维护和功能的扩展，提高开发效率。如图2所示，平台划分为用户管理、设备管理、数据采集、监控报警、设备后维护五大功能模块。

图2 平台功能模块结构图

2.1 用户分级管理

平台涉及管理员、安装公司和医院三种角色，并基于角色进行权限的划分，赋予不同角色以不同的操作权限，实现了数据的隔离访问与高效利用。管理员是逻辑上主机设备和平台用户的管理者，安装公司给医院安装气体设备并负责维护，医院则是气体设备的使用者。三者通过主机设备进行关联，如图3所示。

图3 用户-设备关系图

管理员具有最高权限，负责安装公司的合法性审核，进行主机设备的创建、配置、分配和绑定，可以查看监测数据；安装公司将分配到的主机绑定至医院，有权更改主机的配置，并基于历史数据分析进行设备的后维护；医院权限最低，只能查看监测数据。安装公司在注册时提交营业凭证，待管理员审核通过后，才能获得相应权限。管理员与安装公司之间、安装公司和医院之间、管理员与医院之间皆为一对多的关系。

2.2 设备管理

设备管理模块作为平台的核心模块之一，包括设备参数信息的配置、设备的分配、绑定和认证。设备参数配置完成后，可导出参数配置表，配置表为数据采集端整合数据提供依据。通过设备管理，明确管理员、安装公司、医院对设备的职责，保证设备安全。安装公司从数据中挖掘规律，从而制定高效的设备维护计划和升级方案，向用户提供更优质的服务。医院全面掌握气体生产和运行情况、保障医疗安全，提高了设备运行数据的利用率。

如图3所示，管理员将创建好的主机设备分配给安装公司，安装公司将设备绑定至具体医院。安装公司可以分配得到多个主机设备，但一家医院只能有一个主机设备，且一个主机设备只能绑定至一家医院。主机设备绑定成功后产生唯一识别码，数据上传时须携带此码，作为设备合法性认证的依据。该模块还提供了开关报警短信通知的功能，在此功能开启的情况下，当设备发生报警时，会立即将报警内容以短信形式发送到医院负责人手机上。

2.3 数据接入

部署于医院的数据采集端依照参数配置表，采用约定的JSON格式，并携带设备的唯一识别码，将数据上传至平台的数据接入模块。如图4所示为数据接入流程图。

图4 数据接入处理示意图

该模块负责对数据的完整性和合法性进行校验。所谓完整性是指上传的监测参数是否和参数配置表一致，合法性指取值合法性和设备识别码是否正确。若通过校验，则进行数据的解析存储等其他处理并返回“数据上传成功”的消息，否则返回数据错误原因。

2.4 监控报警

监控报警模块提供了数据实时监测、异常情况平台报警和短信报警、数据推送及数据可视化。交互性良好的可视化设计便于用户掌握监测数据的变化趋势，用户可根据需要切换数据的展示方式。

图5为监控报警流程示意图。该模块接收到通过完整性和合法性检验的数据后，解析数据包中的标志位以确定该数据是否为报警数据，如果是，再判断该主机设备的报警短信通知业务是否开启，若开启，则将报警短信发送给医院负责人，提示其及时采取应对措施，排查报警设备。无论是否为报警数据，都会进行数据的存储，同时将数据推送到客户端浏览器，实现数据的实时更新和可视化。

图5 监控报警流程示意图

2.5 设备后维护

平台提供了历史数据和报警记录检索、数据统计分析等功能，根据用户设定的时间段，以图表形式展现数据的变化情况。平台可为用户统计出某时间段内设备上传的数据量、报警发生率等信息，并导出统计报表。此模块可辅助设备维护人员做出更为合理的决策，制定更高效的设备检修和维护方案，提高设备管理效率和服务质量。例如，对于报警发生率高的设备或区域，应提高检修频率，反之，可以适当降低检修频率。

3 关键技术

3.1 针对高并发情况的数据处理与访问机制

3.1.1 并发数据处理机制

在数据接入模块中，单条数据的处理要经过数据校验(记为B1)和数据推送及存储(记为B2)两个阶段。图6(a)为常规的处理方式，在同一线程中依次进行B1和B2处理，B2处理结束后给予采集端响应，然后再处理下一条数据。当出现数据并发上传时，数据处理速度可能会滞后于数据接收速度，从而可能造成数据的阻塞或丢失，严重时可能导致平台停止响应。

(a) 常规方式 (b) 异步方式图6 业务数据处理方式

上述处理方式中，B1和B2两个子业务由于发生严重耦合，导致处理性能的下降。为此，设计了并发处理机制，如图6(b)所示。主线程仅负责业务B1的处理，将校验成功的数据放入缓存队列，然后给予采集端响应，同时激活B2业务处理器，并为之开辟新线程。新线程不断地从缓存队列中获取数据进行处理，同时主线程可继续下一条数据的接收与处理。当队列中无数据可处理时，B2处理器所在线程进入休眠状态，以减少对服务器CPU资源的占用。这种处理机制实现了子业务间的解耦，方便与源数据处理相关业务的扩展，缓解了主线程的压力，大大提升了服务端的响应速度和应对高并发数据的处理能力。

3.1.2 高访问处理机制

监测数据最终持久化于关系型数据库中，处理资源请求的过程即是对数据库进行I/O操作的过程。当有并发访问时，频繁的I/O操作会使得关系型数据库的性能瓶颈凸显，导致数据库系统性能下降。为此，考虑将数据缓存于内存，以应对并发访问。如图7所示，服务端接收到来自客户端的资源请求，首先查找缓存中是否存在目标资源，若存在，直接获取并返回；否则，前往关系型数据库查找，将查找结果返回客户端并更新缓存，以便下次访问。

图7 基于缓存的资源访问设计

基于缓存的资源访问缓解了关系型数据库的读压力。由于缓存数据库占据内存，当缓存了大量历史数据，系统整体吞吐量将降低，内存空间也会受到压缩，造成内存空间不足，导致整体性能下降[15]。平台采用最近最少使用LRU(Least Recently Used)策略淘汰“过期”资源数据，以防止内存空间不足产生的影响。

在诸多缓存数据库中，Redis能够支持K/V、List队列等多种数据结构，支持数据持久化。服务器断电和重启不会造成数据丢失。本文平台选用Redis作为缓存数据库。

3.2 基于参数配置表的数据接入方案

为方便监测数据接入平台，本文提出基于参数配置表的数据接入方案。方案约定数据采集端需将监测数据以JSON数据包形式通过HTTP上传至平台数据接收端口。表1为方案中所设计的数据包协议，协议规定了包中应有的元素及其取值类型。

表1 监测数据JSON数据包协议

Excel参数配置表包含两张sheet：其一描述了主机设备的唯一识别码、数据上传的接口地址及方式；其二明确了各设备站和区域配置的参数信息及其代号。假设某主机只启用了二氧化碳生产设备并只监测瓶组1压力、瓶组1低压报警限值及出口压力3项参数，且添加了一个编号为BF101的区域并监测该区域氧气的使用状态，导出的配置表如图8所示。

(a) 主机身份及接口说明

(b) 设备站/区域参数明细图8 某主机参数配置表

根据配置表信息和数据包协议，组织JSON数据如下，最后调用数据上传接口将数据包发送至平台，实现数据接入。

{

"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"

}

]

}

]

}

该方案对数据采集端的形式未加约束，只要可以按照数据协议整合数据并进行HTTP数据传输的均可作为采集端，极大地提高了采集端的灵活性和平台的开放性。

3.3 基于WebSocket和SockJS的实时通信

通信实时性是医用气体实时监测平台的重要指标。服务端接收到监测数据后，应即刻将数据推送到客户端，以实现客户端浏览器数据的实时刷新，从而使得用户能够在第一时间掌握设备的运行状态。

传统实现Web实时交互的功能常采用轮询技术和Comet技术[5-6]，Comet技术分为长轮询和流技术。轮询要求客户端定时向服务端发送请求，以频繁请求的方式保持数据的同步，但并非每次请求都能返回有效数据，由此造成带宽资源的浪费。长轮询与轮询的区别在于，当服务端数据没有更新时，请求会被挂起以保持连接，直至有数据更新或连接超时，这种方式降低了无效的网络传输和请求，但请求的挂起会导致资源的浪费，且当数据更新比较频繁时，较轮询在性能上没有本质的提高。流技术是客户端向服务端发起一个长连接请求，服务端为之做出响应并不断更新连接状态以保持连接，服务端通过此连接将数据主动推送给客户端。相较于轮询和长轮询，流技术减小了服务器处理请求的压力，但在数据并发程度高时易造成网络阻塞。

传统的Web实时技术是基于HTTP协议的请求响应模式。图9为传统Web实时技术客户端/服务器通信交互图，通信只能由客户端发起，并没有实现真正意义的实时通信，只是借助Ajax异步请求来模拟实时交互效果。

图9 传统Web实时技术客户端/服务端交互图

医用气体实时监测的参数多，数据量大，数据上传频率高(秒级)，服务端的数据更新快，数据需要被频繁地推送至客户端以实现数据的实时展示。综合以上分析，传统的Web实时技术在医用气体实时监测平台中并不合适。

WebSocket作为HTML5的新特性[8]，实现了客户端浏览器和服务器之间的全双工通信，是真正意义的实时通信。图10为WebSocket客户端/服务器交互图，浏览器使用JavaScript向服务端发送建立WebSocket连接的HTTP请求，建立连接后，客户端与服务器均能主动地向对方发送消息。

图10 WebSocket客户端/服务端交互图

WebSocket在本质上是基于TCP的协议，相较于基于HTTP协议的轮询和Comet技术，数据传输更为稳定高效，数据传输量更小[9]，从而减轻了服务器负载，节省网络带宽资源，提高了监测平台的实时性、稳定性和可靠性。

当前大多数浏览器均支持WebSocket，少部分(如IE10以下版本的浏览器)并没有提供支持。对于这类浏览器，平台采用SockJS作为备选方案。SockJS是对WebSocket的模拟，旨在为浏览器和服务器之间创建一个低延迟、全双工、跨域通信的通道，且提供了JavaScript API，增强了浏览器的兼容性。在医用气体实时监测平台中，对支持WebSocket的浏览器优先使用WebSocket，其次考虑SockJS。客户端关键代码如下:

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");

}

//连接错误的回调函数

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

//连接成功的回调函数

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

//接收到服务端数据的回调处理函数

websocket.onmessage=function(event) {

//解析event.data，实现数据的更新

}

//连接关闭的回调函数

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

3.4 基于REST的Web服务接口

表述性状态转移REST(Representational State Transfer)是Roy Fielding在其博士论文[10]中提出的一种软件架构风格，为构建可扩展、可移植和松耦合的Web程序提供了一个架构上的准则[11-14]。REST将Web中的所有事物抽象成资源，使用统一资源标识符URI(Uniform Resource Identifier)对每个资源进行标识，通过复用HTTP协议的动词，对资源进行操作，这种基于资源的设计改变了传统的基于服务的设计思想。

为资源设计简洁明了、结构良好的URI是构建REST服务的关键。本文平台主要使用了POST、GET、DELETE、PUT、PATCH五类动词，分别用于新建资源、获取资源、删除资源、修改资源整体、修改资源局部信息。表2为本文平台设计的RESTful API(符合REST的接口)示例。

表2 URI应用示例

RESTful API中的URI只使用名词，用于标识资源，用HTTP动词标识具体的行为，可读性高。接口的响应采用JSON对资源进行描述，实现了资源描述和视图的解耦。REST便于设计和对外提供可被第三方调用的Open API。

3.5 其他技术

(1) 轻量级的数据交换格式 考虑到采集端数据上传频率高、服务端与客户端数据通信频繁等特点，平台选用轻量级的JSON作为数据交换格式。相较于XML，JSON数据有效减少了数据格式中的冗余标记，体积小，传输速度快，带宽占比小。JSON数据可被直接解码为JavaScript对象，解析便捷，与Ajax完美搭配，实现客户端浏览器信息数据的异步读取和局部刷新。

(2) 基于ECharts的数据可视化 监测数据可视化是医用气体实时监测平台的一大重要内容。数据可视化旨在为用户提供直观的图形图表，便于观察数据的变化趋势。本文平台基于ECharts实现监测数据可视化。ECharts是一款开源的、基于JavaScript实现的数据可视化图表库，其底层依赖于轻量级的Canvas类库ZRender，提供了直观、可交互、可个性化定制的数据化图表，浏览器兼容性好，在PC和移动设备上运行流畅。

4 实 现

4.1 物理结构

本文平台采用如图11所示的物理结构。数据采集端部署于医院，负责数据的采集。组态软件或其他数据汇集器整合制气设备的运行参数和各区域气体的使用状态数据，通过调用相应的API将数据上传至服务平台。服务平台提供了友好的RESTful API，方便设备接入和客户端访问。相较于C/S开发模式部署复杂、维护困难、扩展性差等弊端，平台选用更为灵活的B/S模式，用户借助可联网终端(如手机、电脑、平板)通过Web即可访问平台，随时随地掌握设备的运行状态和气体的使用情况。

图11 平台物理结构图

4.2 安装公司管理

如图12所示为管理员进行安装公司管理。管理员可查看安装公司上传的营业凭证及其详细信息，对其进行合法性审核。审核状态分为“未经审核”、“审核通过”和“审核不通过”，管理员可分类查看各审核状态下的用户列表，默认显示全部安装公司。

图12 安装公司管理

4.3 设备管理

图13为主机设备列表页，不同颜色标注主机的分配情况。点击“添加主机”，并输入主机编号以创建主机。主机编号不能与已有主机编号相同，否则将创建失败。

图13 主机列表

点击已创建的主机，进入主机详情页，可进行设备站(指各类气体的生产设备)的启用、停用，参数的配置，区域的增删、配置以及报警短信通知的开关等。图14为液氧源监测参数配置过程。

图14 主机参数配置

主机各设备站和区域参数配置完成后，将主机分配给通过审核的安装公司，图15为主机分配过程。接下来，将主机绑定至安装公司旗下的医院。

图15 主机设备分配

图16为绑定过程，已绑定到主机的医院不会再显示于列表中。主机分配工作由管理员进行，主机配置与绑定工作可由管理员或安装公司进行。

图16 主机设备绑定

主机被绑定后，产生唯一识别码，作为数据上传的凭证，如图17所示。主机配置完成，可点击“导出参数表”按钮以导出Excel参数配置表。

图17 主机唯一识别码

4.4 实时数据展示

当浏览器接收到服务端推送的数据，实时更新图表数据和时间。图18为某主机氮气生产设备运行状态实时展示界面，该设备同时监测了瓶组1和瓶组2压力状态，图表以不同颜色标识，将鼠标放在时间点会显示相应时刻各瓶组的压力值。

图18 实时数据显示界面

4.5 历史数据检索与统计分析

图19为某区域某时间段氧气压力历史数据查询结果。平台默认以折线图展现最近的150条数据，用户可拖动图表下方滚动条以展示更多数据，图表右上角的工具按钮可用于实现数据呈现方式的切换等。

图19 区域氧气历史数据查询结果

如图20为数据统计结果。用户可查看截至当前时刻，平台共接收到的数据总量、正常数据、异常报警数据数量及其所占比例。

图20 区域氧气报警数据统计结果

5 测试与对比

为验证本文平台具有高响应率和高性能的特点，将本文的并发处理机制与传统的同步方法进行对比，并进行了4组测试，分析在处理800、1 500、2 500、3 600 Byte左右大小JSON数据包的时间消耗情况。数据采集频率设为1秒，每次测试连续发送200次数据，取平均值作为耗时结果，结果如图21所示。结果表明，本文方法能明显降低平台的响应时间，进而可以处理更多的数据包，提高了平台的处理性能。

图21 耗时对比图

从功能点角度，将本文平台与现有同类平台进行对比，如表3所示。

表3 功能点对比

6 结 语

本文设计和实现的医用气体实时监测平台有效克服了传统监测方式巡检周期长、安全隐患大、工作效率低、数据利用率低等弊端，实现了数据接入、远程实时监测、报警联动、历史数据检索及统计分析等功能。并发处理机制的设计缩短了平台服务的响应时间，提高了平台应对并发海量数据的处理性能。缓存技术的引入降低了数据库负载，提高了平台的访问效率。在数据接入方面，提出基于配置表的数据接入方案，提高了平台的开放性、通用性和实用性。融合WebSocket和SockJS技术实现B/S的全双工实时通信，克服了传统Web实时技术的弊端，解决了WebSocket浏览器兼容性问题。平台选用JSON作为数据交换格式，节省带宽资源，提高了数据传输和解析效率。该平台的应用可以降低医疗用气的风险，节省维护成本，提高工作效率。目前，平台已投入试运行阶段，且运行状况良好。