简介：面向医疗设备工程师、监护仪二次开发与系统集成人员的《美敦力BIS监护仪串口通讯协议手册》技术资料，针对BIS脑电双频指数监护系统串行端口对接中引脚定义不清、通信参数配置不明、协议版本兼容判断困难等问题，提供一手官方技术规格说明。资源包仅1个PDF文件，约1.1MB，文档编号070-0017、修订版本F，共79页，含目录、表格与插图清单，便于按章节快速定位。内容从接口规格切入，逐项讲解连接器引脚定义、通信电缆布线，以及波特率、数据位、停止位与校验方式等端口设置；随后说明串行协议版本号的命名规则，并给出跨版本兼容性矩阵，帮助判断升级路径；此外还涉及监护数据的通用显示指引，涵盖通道1/2/12、BIS、SQI、EMG、爆发计数与双侧传感器等数据项。目前已有253人学习，适合需要打通设备数据采集链路、排查串口通信故障或规划版本升级的技术人员参考。
1. 一台监护模块摆在面前，先搞清楚这 79 页写的是什么
前段时间帮人接一台脑电双频指数（BIS）监护模块，硬件连线看着没问题，串口助手打开却一个字节都不吐。折腾半天，问题出在协议手册第 7 页那张引脚表上——他手上那根现成的线是直通的，而这台设备要的是交叉。这份串口技术规格书解决的正是这类问题：它不讲 BIS 指标怎么解读，只讲这台设备如何通过串口把数据交出来。全篇 79 页，从连接器引脚、电缆布线、通信端口设置，一路写到 ASCII 与二进制两套协议、几十条上下行命令、每条记录的字段偏移与含义，末尾还附了处理后 EEG 变量的定义和原始数据换算方法。它适合做设备数据采集、院内系统对接、术中脑电数据留档的开发者，也适合要给这套监护模块写模拟器的测试人员；只想弄明白 BIS 是什么指标的读者，翻两页就会觉得闷。
2. 接口层规格：从连接器引脚到协议版本兼容矩阵
动手写代码之前，接口层这几页必须先吃透。串口通信的坑有相当一部分不在协议里，而在物理连接和端口参数上：线序反了、波特率对不上、流控开错了，后面解析逻辑写得再漂亮也没用。这一章按「接线 → 开端口 → 读版本 → 选解析器」的顺序，把手册前 10 页的内容落成可以照抄的步骤。
2.1 引脚定义与电缆布线：先确认是不是交叉线
手册的 Interface Specifications 一章给了一张连接器引脚表，把每个引脚的功能、方向、信号名都列了出来。异步串行接口的核心就三根线：发送（TX）、接收（RX）、地（GND），部分实现会额外带 RTS/CTS 硬件流控。常见的 DB9 形态下，2 脚是接收、3 脚是发送、5 脚是地，但这个对应关系在不同设备上并不统一，所以第一件事永远是拿手册的引脚表和自己手头的线对一遍，而不是凭经验插上去再说。
| 信号 | DB9 常见引脚 | 方向（相对监护仪） | 备注 |
|---|---|---|---|
| TX | 3 | 输出 | 接对端 RX |
| RX | 2 | 输入 | 接对端 TX |
| GND | 5 | — | 两端共地，不可省 |
| RTS | 7 | 输出 | 手册未要求流控时可悬空 |
| CTS | 8 | 输入 | 同上 |
电缆布线那一节讲的是线缆怎么走。设备与外部采集端之间如果是两台都有 TX/RX 的 DTE 设备，就必须用交叉线（常说的 null modem 接法），把一端的 TX 接到另一端的 RX 上；如果中间串了调制解调器类的 DCE 设备，则用直通线。屏蔽层建议单端接地，避免两端接地形成地环路把工频干扰引进来。RS-232 电平在标准里对应的可靠距离是十几米量级，现场如果线拉了二三十米，先把波特率降下来再试，比换线更省钱。
提示：接线完成后先做一次回环自测——把 TX 和 RX 短接，用串口助手发一串字符看能否原样收回。收得回说明本端串口和驱动没问题，收不回就别急着怀疑监护仪。
2.2 通信端口设置与协议版本兼容矩阵
端口参数在手册里有单独一节，通常是一张表：波特率、数据位、停止位、校验方式、流控。医疗设备常见的组合是 19200 或 9600、8 数据位、1 停止位、无校验、无流控，但这不是可以想当然的事，必须以手册那张表为准。二次开发时我一般会把这组参数做成配置项而不是写死在代码里，因为同一系列设备不同固件版本改过默认值的先例并不少见。下面这段是 Python 下按手册参数打开串口的写法：
import serial def open_monitor_port(port: str, baudrate: int = 19200) -> serial.Serial: """按手册 Communication Port Settings 表打开串口。 port: 系统设备名，Windows 下形如 COM3，Linux 下形如 /dev/ttyUSB0 baudrate: 以手册表格为准，常见 9600 / 19200 / 38400 """ ser = serial.Serial( port=port, baudrate=baudrate, bytesize=serial.EIGHTBITS, # 数据位，按手册表核对 parity=serial.PARITY_NONE, # 校验位，按手册表核对 stopbits=serial.STOPBITS_ONE, timeout=1, # 读超时，避免采集线程被永久阻塞 rtscts=False, # 手册未要求硬件流控时保持关闭 xonxoff=False # 同上，软件流控也要关掉 ) ser.reset_input_buffer() # 丢掉打开瞬间的残留字节 return ser这段代码里真正需要改的只有port和baudrate两个入参，其余位宽和校验参数是照着手册填的。timeout=1是给读操作设上限，采集线程读到一秒还没数据就返回，便于上层做心跳判断；reset_input_buffer()是为了清掉串口刚打开时缓冲区里可能存在的半截帧，否则第一包解析很容易报错。
端口打开之后别急着请求业务数据，先读协议版本号。手册给出的版本号格式是「主版本.次版本.修订号」三段式，主版本变化意味着报文结构或字段定义有破坏性调整，次版本是新增能力，修订号是修错。紧接着的兼容性矩阵把几种机型、若干固件版本与协议版本对应起来，明确哪些版本之间可以共用同一套解析逻辑。我的做法是把版本号当作解析器的分派键：连接建立后先发一条版本查询命令，拿到字符串再决定加载哪一版字段映射表。
def pick_parser(revision: str) -> str: """根据版本号选择字段映射表；兼容矩阵见手册第 9-10 页那几张表""" major, minor, patch = (int(x) for x in revision.split(".")) if major >= 3: return "parser_v3" # 主版本 3 起字段布局有调整 if major == 2 and minor >= 4: return "parser_v24" return "parser_legacy"版本号的三个分量拆开做整数比较，比字符串比较可靠——字符串比较会把 "2.10" 排在 "2.9" 前面，这类错误在字段分派上会直接导致解析全乱。patch拿来做日志记录就够了，它不改变解析路径。兼容矩阵的用法不是背下来，而是遇到「同一份代码换个固件版本就不对」时，回来查这张表，确认是不是跨了主版本。
注意：版本查询命令本身在不同协议版本下的响应格式也可能不同，第一次对接陌生固件时，建议先用串口助手手工发一次，把原始字节贴到日志里存档，后面解析出问题时有得比对。
3. ASCII 协议拆解：记录类型、字段含义与解析代码
两套协议里，ASCII 协议是给人看的：报文全是可打印字符，抓包工具里直接能读，调试阶段基本靠它把链路跑通。代价是传输效率低，所以原始 EEG 这种高采样率数据不会走 ASCII，它更适合拿处理后的指标值和设备状态。手册第 13 到 31 页都在讲这套东西，结构上是「命令表 + 记录类型」两部分。
3.1 通用记录格式与头部记录
通用记录格式定义了每条记录的骨架：一个记录类型标识、若干字段、字段之间用固定分隔符隔开，整条记录以回车换行结束。不同记录类型的字段个数和顺序不一样，但都遵守这个骨架，所以解析器可以先按行切分，再按类型分派，最后按位置取字段。这种「先分帧再分派」的顺序很重要，反过来的话遇到一包数据里粘了多条记录就会解析失败。
头部记录（Header Record）是连接建立后最先拿到的东西，里面是设备与通道的元信息：设备标识、软件版本、通道数量与配置、传感器类型。双侧传感器场景下，通道 1 和通道 2 分别对应左右两侧，通道 12 是另一路派生数据，手册在「监护数据的一般显示指引」一节里对这三路的关系做了说明。二次开发时把头部记录的内容落到一张设备信息表里，后面所有数据记录都要靠通道编号去关联传感器位置，头部没解析清楚，后面的数值就不知道该算左边还是右边。
def parse_header(line: str) -> dict: """解析头部记录，形如 'H|<device_id>|<sw_ver>|<channels>|<sensor_type>'""" parts = [p.strip() for p in line.split("|")] return { "record": "header", "device_id": parts[1], "software_version": parts[2], "channels": [int(c) for c in parts[3].split(",")], "sensor_type": parts[4], # 单侧 / 双侧 / 演示传感器 }字段按|切分之后逐个strip()，是因为有些设备会在分隔符两侧补空格，不处理的话字符串比较会莫名失败。通道列表转成整数列表，是为了后面拿通道号去查传感器位置时不用再做类型转换。传感器类型这个字段建议原样保留成字符串而不是映射成枚举，因为手册里列过演示用的传感器类型，枚举漏一项就会抛异常。
3.2 数据、阻抗、错误、事件四类记录
数据记录（Data Record）是周期推送的主力，内容包括 BIS 值、信号质量指数（SQI）、肌电活动（EMG）、爆发抑制计数（Burst Count）、光谱边缘频率等处理后的变量。BIS 值一般在 0 到 100 之间，SQI 表示信号质量，EMG 反映肌电干扰强度，爆发抑制计数用于判断麻醉深度的爆发抑制比例。这些字段的单位和取值范围在附录 B 里有逐条定义，写解析器时把那页翻出来照着做，比凭直觉猜靠谱。
| 记录类型 | 触发方式 | 关键字段 | 典型用途 |
|---|---|---|---|
| 头部记录 | 连接后自动或请求后返回 | 设备标识、固件版本、通道配置 | 建立设备档案、选解析器 |
| 数据记录 | 周期推送 | BIS、SQI、EMG、爆发抑制计数 | 实时趋势、术中监测 |
| 阻抗记录 | 需先下发使能命令 | 各电极阻抗值 | 电极贴附质量判断 |
| 错误记录 | 需先下发使能命令 | 错误码、发生通道 | 电极脱落、传感器异常告警 |
| 版本号记录 | 请求后返回 | 协议版本字符串 | 解析器分派 |
| 事件记录 | 需先下发使能命令 | 事件类型、时间戳 | 术中操作标记回放 |
这张表里最容易被忽略的是「触发方式」那一列：头部记录和数据记录是主动来的，而阻抗、错误、事件三类记录默认不推，必须先在连接建立阶段把对应的开关命令发下去。很多人接上设备发现只有 BIS 数值没有阻抗，就是卡在这一步。
3.3 用 Python 把一条数据记录拆成字段字典
数据记录字段多、位置固定，适合用一个位置映射表加一个解析函数。下面这段把常见字段的偏移集中在一处声明，未来换协议版本只改映射表，不改解析逻辑：
# 字段位置映射：键是字段名，值是在 split 结果里的下标 DATA_FIELDS = { "bis": 1, # 脑电双频指数，0-100 "sqi": 2, # 信号质量指数，0-100 "emg": 3, # 肌电活动强度 "burst_count": 4, # 爆发抑制计数 "sr": 5, # 抑制比 "sef": 6, # 光谱边缘频率 } def parse_data_record(line: str) -> dict | None: """解析一条数据记录；字段缺失或数值非法时返回 None 并交由上层记日志""" parts = [p.strip() for p in line.split("|")] if len(parts) < 7: return None out = {"record": "data"} for name, idx in DATA_FIELDS.items(): raw = parts[idx] if raw in ("", "--", "N/A"): out[name] = None # 占位符表示当前无有效值，不能当 0 处理 continue try: out[name] = float(raw) except ValueError: return None # 字段被污染，整条记录丢弃，避免脏数据入库 return out映射表把「字段名 → 下标」显式写出来，好处是排查时一眼能看出第 3 个字段是 EMG 还是 SQI，不用去数split结果。占位符的判断单独提出来，是因为设备在信号无效时会填--或空串，如果直接float()会抛异常，如果当成 0 又会把「无数据」误判成「数值为零」，在趋势图上表现为突然掉底，这类假数据比缺数据更难排查。except ValueError里整条丢弃而不是部分保留，是为了保证入库的每条记录都是完整的，缺字段的记录宁可不要。
提示：ASCII 协议的字段顺序在兼容矩阵里跨主版本变过，把
DATA_FIELDS和版本号绑在一起存成配置，比在代码里写 if-else 好维护。
4. 二进制协议拆解：三层包结构、命令集与丢包处理
需要原始 EEG 波形、需要更高吞吐的时候，就得换到二进制协议。手册从第 32 页开始讲这套东西，结构上分三层：物理层管字节流怎么切帧，路由层管长度、序号和命令字，应用层管负载里每个字节是什么。把这套分层理解透，后面看几十条命令就不用死记，因为它们的差别只在应用层负载，外层封装是一致的。
4.1 Layer 1/2/3 的职责划分与包结构
物理层（Layer 1）解决的是「一长串字节流里，哪几个字节属于同一包」。这一层通常靠帧头字节和长度字段共同界定，部分实现还会用转义字符处理负载里恰好出现帧头字节的情况。路由层（Layer 2）在帧头之后给出包长度、包序号和命令码，包序号是后面做丢包检测的依据。应用层（Layer 3）才是真正的业务负载，不同命令码对应不同的结构体定义，手册附录 A 把用到的结构体挨个列了一遍。
| 层级 | 字段 | 作用 | 二次开发关注点 |
|---|---|---|---|
| Layer 1 | 帧头、长度、转义 | 切分字节流 | 转义还原别漏，否则长度算错 |
| Layer 2 | 包序号、命令码 | 路由与分发 | 序号回绕、重复包去重 |
| Layer 3 | 业务负载 | 数据本体 | 按命令码查结构体，注意字节序 |
字节序是这一层最容易翻车的地方。手册在结构体定义里会标注多字节字段的排列顺序，解析时struct的格式串必须和它一致，小端写成大端，长度字段会变成一个天文数字，然后解析器就在缓冲区里一直等一个永远凑不齐的包。
4.2 外部设备到监护仪的命令集
下行命令有二十多条，按用途可以分成四组，分组之后就不难记：
| 分组 | 代表命令 | 说明 |
|---|---|---|
| 数据流开关 | SEND_RAW_EEG / STOP_RAW_EEG、SEND_SCREEN_EEG / STOP_SCREEN_EEG、SEND_PROCESSED_VARS / STOP_PROCESSED_VARS | 打开或关闭某类数据的持续推送 |
| 消息使能 | TURN_ON_IMPED_MSG、TURN_ON_ERROR_MSG、TURN_ON_SEND_EVENT、TURN_ON_CURRENT_ERROR | 让设备开始推阻抗、错误、事件 |
| 分页拉取 | SEND_EEG_SNIPPET、SEND_NEXT_EEG_SNIPPET_PKT、SEND_BIS_HISTORY、SEND_NEXT_HISTORY_PKT、SEND_NEXT_BIG_HISTORY_PKT | 历史数据不是一次给完，要逐包请求 |
| 信息查询 | SEND_REVISION_INFO、GET_TIME_DATE、SEND_PROCESSED_VARS_LABELS | 版本、时间、变量标签表 |
分页拉取这一组特别值得说。历史数据在设备侧是分块存的，第一包给的是头部（记录条数、时间范围、块大小），后面要靠SEND_NEXT_HISTORY_PKT一包一包往回拉，每拉一包更新一次游标。如果不实现这个状态机，只发第一条命令，你只会拿到一个头部，然后就没有然后了——这是新手最常见的「历史记录读不出来」的原因。
import struct # 命令码以自己手上那份手册的命令表为准，这里仅示意结构 CMD_SEND_PROCESSED_VARS = 0x05 CMD_GET_TIME_DATE = 0x1A def build_packet(cmd: int, seq: int, payload: bytes = b"") -> bytes: """按路由层格式打包：长度(2B, 小端) + 命令(1B) + 序号(1B) + 负载""" body = struct.pack("<BB", cmd, seq) + payload return struct.pack("<H", len(body)) + body def next_seq(seq: int) -> int: """序号是单字节，255 之后回绕到 0""" return (seq + 1) & 0xFFbuild_packet里先算body长度再拼外层长度字段，顺序不能反，因为长度字段描述的是它后面所有字节的总数。struct.pack("<BB", ...)的<表示小端、无对齐填充，和手册结构体定义的排列对应；如果手册标注的是大端，这里要换成>。序号回绕用按位与实现，比取模运算更直观，也避免负数输入时出问题。
4.3 上行消息与丢包检测
监护仪往外部设备发的消息以M_和SER_开头，前者是持续推送的数据流，后者多是对请求的应答。常见的几条：M_DATA_RAW是原始 EEG 采样点，M_DATA_SCREEN是屏幕显示用的降采样版本，M_PROCESSED_VARS是处理后的指标值，SER_IMPED_MSG和SER_ERROR_MSG是阻抗与错误应答，SER_REVISION_INFO是版本信息，SER_BIS_HISTORY_HEADER与SER_BIS_HISTORY_DATA是历史数据的头和体，M_TIME_DATE是设备时间。
手册里专门用一节讲了某种桥接形态下数据包被丢弃的情况，大意是中间环节做缓冲时可能整包丢掉，接收端看到的序号会跳变。这意味着采集程序不能假设「序号一定连续」，而要显式检查空洞：
def check_gap(last_seq: int | None, seq: int) -> int: """返回跳过的包数；last_seq 为 None 表示首包，不判定""" if last_seq is None: return 0 expected = (last_seq + 1) & 0xFF return (seq - expected) & 0xFF # 调用侧：把跳包数累计到指标里，超过阈值就告警并触发一次重同步 gap = check_gap(last_seq, pkt_seq) if gap: stats["dropped"] += gap跳包数用无符号减法再按位与计算，能正确处理序号从 255 回绕到 0 的情况，直接做seq - last_seq - 1在回绕时会得到负数。stats["dropped"]这个累计值建议暴露到监控指标上，现场出现「趋势图有断点」时，先看这个数，比翻日志快得多。
4.4 原始数据换算：从 ADC 码值到微伏
原始 EEG 消息里的采样点是整数码值，不是微伏。手册的 Raw Data Conversion 一节给了换算方法，核心是参考电压、放大器增益和位深三个参数，不同传感器类型的系数还不一样。具体公式和系数照手册抄，这里只强调两点：一是采样点是有符号数，解析时格式串要带符号位，否则负向波形会变成几万的巨大正值；二是换算前先判断无效值标记，设备在导联脱落时会填一个特定的极值，不剔除的话换算出来的波形会有一个巨大的尖峰。
5. 联调避坑：五类现场故障的现象、原因与处置
这一章是几次对接攒下来的。每一条都按「看到什么 → 为什么 → 怎么办」写，遇到类似现象可以直接对照着查。
5.1 现象：串口打开后一个字节都没有
最常见的原因就是线序，直通线接在两台 DTE 设备之间，双方的 TX 对着 TX，谁也收不到。其次是端口参数不对，比如设备是 19200 而程序按 9600 打开，某些串口芯片在参数不匹配时干脆一个字节都不上报。处置顺序是：先做 TX/RX 短接回环，确认本端正常；再拿手册引脚表逐脚核对线缆；最后把波特率和校验位逐个组合试一遍。如果三步都过了还是没有数据，检查设备侧是不是需要先收到某条命令才开始推流——部分型号上电后处于静默状态，要主动发一条开启命令才肯说话。
5.2 现象：收到的全是乱码或者问号
乱码说明有字节进来但解不对。第一嫌疑是波特率偏差，第二是校验位和停止位不一致，第三是拿 ASCII 解析器去解二进制流。区分方法很简单：把原始字节按十六进制打印出来看，如果首字节是可打印字符且长度规整，多半是 ASCII；如果大量出现 0x00 到 0x1F 之间的控制字节，那就是二进制。处置上，先固定波特率用串口助手抓一段存成文件，离线用两种解析器各跑一遍，哪种能解出合理字段就用哪种，别在线反复试，容易把设备搞进异常状态。
5.3 现象：数据每隔一段时间缺一块
这通常不是丢包，而是发送端本身就不保证连续。设备的推送是周期性的，采集端读缓冲区的节奏如果跟不上，操作系统缓冲区满了会覆盖旧数据。处置办法一是提高读取频率、把读线程和业务处理线程分开，中间用队列缓冲；二是把单次读的字节数调大，减少系统调用次数。如果确认是链路层丢包（序号有跳变），那就按 4.3 节的跳包检测加上告警，不要指望重传——这套协议里没有应用层重传机制，丢了就是丢了，能做的只有记录和补采历史。
5.4 现象：BIS 数值偶尔出现离谱数字
先查字段宽度和符号位。BIS 本身是 0 到 100 的整数，如果解析出来是几万或者负数，八成是把相邻两个字节当成一个字段读了，或者字节序反了。再查占位符，信号无效时设备可能填一个约定好的极值（比如全 F），直接当数值用就会画出异常尖峰。处置上给每个字段加范围校验，超出物理范围的值统一置空并计数，计数异常升高时回看原始十六进制报文，比对结构体定义里的偏移，一般十分钟内能定位。
5.5 现象：阻抗和错误消息始终收不到
不是设备坏了，是没使能。这两类消息默认关闭，连接建立后必须下发TURN_ON_IMPED_MSG和TURN_ON_ERROR_MSG。处置上把「连接建立后的初始化序列」固化成一个函数：开流控、读版本、下发所有需要的使能命令、最后再开数据流。顺序也有讲究，先开数据流再使能消息，某些固件会把后来的使能命令当成异常丢弃。
注意：初始化序列里每发一条命令都留 100 毫秒左右的间隔，设备固件处理命令是串行的，发太快会被合并或者直接忽略。
6. 二次开发：把手册改造成可回放的采集服务
手册是静态的，落到工程里得有一个能跑起来的骨架。我一般把采集端拆成五层：传输层负责串口读写和断线重连，编解码层负责按协议版本选解析器、处理粘包拆包，模型层把不同记录类型归一成统一的观测对象，持久化层写时序库或者本地文件，对外接口层再按需转成内部服务接口或者文件导出。这五层里最容易写乱的是编解码层，因为它同时要处理 ASCII 和二进制、要按版本分派、还要维护历史拉取的状态机——所以它必须是独立的、可被单元测试直接驱动的模块，而不是散落在读线程里的一堆 if。
| 模块 | 职责 | 关键函数 | 可测性 |
|---|---|---|---|
| 传输层 | 串口打开、读写、重连 | open_monitor_port/read_bytes | 可用回环口测试 |
| 编解码层 | 分帧、版本分派、字段解析 | pick_parser/parse_data_record/build_packet | 纯函数，易单测 |
| 模型层 | 归一化观测对象 | to_observation | 输入输出确定 |
| 持久化层 | 落库、补采 | write_batch/backfill_history | 可注入假存储 |
| 接口层 | 对外暴露 | query_trend/export_csv | 集成测试 |
改造时最值得先做的一件事是把「录制回放」搭起来。做法很简单：传输层加一个开关，打开时把收到的原始字节带时间戳写进文件；编解码层接受一个「字节来源」抽象，既可以是串口，也可以是录制文件。这样一来，现场抓一段数据回来，就能在办公室反复跑解析器，改一版字段映射验证一版，不用每次都占着设备。验证方法上，我习惯做三组对照：一是回环自测确认传输层；二是拿录制文件跑解析，人工核对前十条记录的每个字段；三是让解析结果和监护仪屏幕上显示的数值对一遍，BIS 差 1 以内、SQI 差 2 以内，基本就说明偏移和单位都对上了。
历史数据那条路要单独验。它涉及分页状态机，容易出的问题是游标没有推进导致死循环、或者最后一页判断错导致多拉一包超时。验证办法是先把历史条数读出来，再统计实际收到的记录数，两个数对上才算通过。别小看这一步，我曾经在一条没有结束标志的流上写了while True，跑了一晚上把磁盘写满了，从那以后每次做分页拉取，我都会在循环里强制加一个「最大包数」上限和一条进度日志，宁可少拉几包，也不能让程序无边界地转下去。希望这份拆解能帮你少走几段弯路。
本文还有配套的精品资源，点击获取
