用Rust手写LIS模拟器：ASTMn/HL7报文与TCP/串口联调实践

做 LIS（实验室信息系统）对接测试时，最烦的不是写解析代码，而是找一台能持续配合“假装出结果”的仪器。真实的检验仪器要么数量少、要么正在跑业务，不可能随时给你反复发送样本结果、异常报警和质控数据。这次我们来看一个可以借 Rust 手工打造的东西：LIS 模拟器——用 Rust 程序模拟检验仪器或模拟 LIS 服务端，把 ASTMn/HL7 格式的报文、TCP 连接、串口通信、批量结果上报放到本地可控环境里跑通。

先给核心结论：这个方案不依赖 GPU、不做模型推理，显存占用为 0，只要 CPU 正常就能跑；程序以单个二进制文件发布，跨平台能力好；开发阶段用 cargo run 启动，后续可以套 Tauri 桌面壳做可视化控制台；通信层支持 TCP/串口模拟，业务层提供 REST API 和批量任务接口，方便接到自动化测试脚本里。对正在做 IVD 仪器对接、LIS 接口改造、HL7 报文联调，或者刚入门 Rust 想找个真实项目练手的人来说，本篇可以直接照着抄。

文章会按“核心能力速览 -> 场景边界 -> 环境准备 -> 部署启动 -> 功能验证 -> API 与批量 -> 性能观察 -> 排错 -> 最佳实践”的顺序展开，代码以简化版 LIS 模拟器为模板，实际协议表和字段分隔符需要根据目标仪器文档调整。

1. 核心能力速览

先给一张速览表，把 LIS 模拟器的核心规格列清楚。以下数据基于一个“通用 Rust LIS 模拟器实现方案”整理，具体仓库如果没有单独说明，则按本机实际编译运行结果为准。

这套方案最大的优势是“没有硬件门槛”：不需要高性能 GPU，不需要 CUDA 环境，不需要为了跑一个模拟器去准备专用测试机。Rust 编译出来的原生程序启动速度也快，适合在 CI 流水线里拉起、跑完测试、直接销毁。

2. 适用场景与使用边界

2.1 适合谁

第一个场景是 IVD 仪器厂商的软件工程师。仪器通过串口或 TCP 把检测结果发给 LIS，LIS 再回传测试指令。开发调试阶段，LIS 真实环境往往在客户现场，这时候本地跑一个 LIS 模拟器，就能把“仪器端发数据”这半边完整测通。

第二个场景是医院信息科或集成商工程师。项目上线前需要在隔离环境验证 LIS 能否正确接收仪器消息，真实仪器数量不够或不好申请时，模拟器可以在测试环境里批量发样本结果、质控数据、异常结果，用可控报文把 LIS 的处理逻辑跑出边界。

第三个场景是 Rust 学习者。LIS 模拟器是一个非常适合练手的网络程序：涉及 TCP 监听、串口读写、字节流解析、异步并发连接、线程间通信，难度适中，又能接触 ASTMn、HL7 这类真实工业协议，比做一遍 TODO 应用有价值得多。

2.2 能解决什么问题

• 解决“真实仪器不好找”的问题。模拟器可以稳定在本地提供端口，随时发送指定格式的报文。
• 解决“报文不好造”的问题。通过配置 JSON 或直接调 REST 接口，快速生成指定样本号、指定项目代码、指定异常标志的结果消息。
• 解决“边界不好测”的问题。可以主动注入缺失字段、错误校验和、超长文本、乱序帧，让 LIS 的容错逻辑暴露出来。
• 解决“回归不好做”的问题。把历史上出现过的疑难报文录下来，批量回放，每次发版后自动跑一轮。

2.3 不适合什么场景

• 不适合直接当生产 LIS 使用。模拟器的目标是制造可控报文，不包含真实的检验业务流程、计费逻辑和报告审核功能。
• 不适合协议完全未知的项目。如果连仪器的串口参数（波特率、数据位、校验位）和报文分段规则都没拿到，模拟器无法凭空猜测口径。
• 不适合处理真实患者数据。测试模拟器请使用虚构数据，任何来自真实系统的患者信息进入模拟环境前都必须完成脱敏并取得授权。

2.4 使用边界与合规提醒

ASTMn/HL7 消息通常承载患者姓名、样本编号、检验项目、诊断相关信息，属于敏感医疗数据。模拟器的开发和测试过程中，只应使用虚构样本，严禁将真实患者数据直接灌入模拟环境；调试日志里的患者标识字段同样要做脱敏。涉及真实仪器协议文档的复制、逆向、二次分发时，需要先确认授权范围。模拟器只用于开发自测和项目交付阶段的联调，不应绕过生产系统的合法权限控制。

3. 环境准备与前置条件

3.1 Rust 工具链安装

这是所有步骤的地基。Rust 官方推荐通过 rustup 安装工具链，它会同时安装 rustc、cargo、rustfmt 等常用组件。

Linux / macOS 下执行：

bash复制curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source "$HOME/.cargo/env"

Windows 用户到官网下载 rustup-init.exe，双击后按提示选择默认配置即可。安装完成后验证：

bash复制rustc --version
cargo --version

输出类似 rustc 1.xx.0、cargo 1.xx.0，就说明环境 OK。Rust 版本更稳妥的做法是安装当前 stable 版本，避免旧版本与 Tokio、Axum 等依赖的 MSRV 不匹配。

在资源受限的嵌入式 Linux（比如工控机）上，如果目标平台没有官方预编译包，也可以通过 rustup target add 安装对应交叉编译目标链，在开发机上完成交叉编译后拷贝二进制过去运行。

3.2 操作系统与权限准备

从经验角度看，开发调试首选 Linux，串口权限和网络调试工具都方便。Windows 下建议装一个串口驱动并注意 COM 端口编号；macOS 下注意基于 BSD 的设备路径风格，如 /dev/cu.usbserial-xxx。

如果模拟器要读写实体串口，Linux 下当前用户需要加入 dialout 组：

bash复制sudo usermod -aG dialout $USER

重新登录后检查权限：

bash复制ls -l /dev/ttyUSB0

否则打开串口时会碰到 Permission denied。纯 TCP 模式不需要串口权限，直接监听指定端口即可。

3.3 项目依赖选择

建议使用官方维护或社区活跃度较高的 crate：

以上依赖可以在 Cargo.toml 中按需引入。串口功能建议做成 feature 开关，纯 TCP 模式下不需要拉入串口相关系统库。

4. 安装部署与启动方式

4.1 创建项目

先用 Cargo 创建新项目：

bash复制cargo new lis_simulator
cd lis_simulator

编辑 Cargo.toml，加入基础依赖：

toml复制[package]
name = "lis_simulator"
version = "0.1.0"
edition = "2021"

[dependencies]
tokio = { version = "1", features = ["full"] }
serde = { version = "1", features = ["derive"] }
serde_json = "1"
axum = "0.8"
bytes = "1"
tracing = "0.1"
tracing-subscriber = "0.3"
chrono = { version = "0.4", features = ["serde"] }
nom = "7"

[features]
serial = ["dep:serialport"]

[dependencies.serialport]
version = "4"
optional = true

serial 是可选的 feature，默认编译时不包含串口依赖，这样在 CI 环境下可以保持最小编译。

4.2 最小 TCP 服务骨架

在 src/main.rs 里写一个最小可运行的服务端骨架：监听 TCP 端口，每个客户端连接交给一个异步任务处理。

rust复制use tokio::net::TcpListener;
use tokio::io::{AsyncBufReadExt, BufReader};
use tracing::info;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    tracing_subscriber::fmt::init();

    let addr = "127.0.0.1:9500";
    let listener = TcpListener::bind(addr).await?;
    info!("LIS Simulator listening on {}", addr);

    loop {
        let (socket, peer_addr) = listener.accept().await?;
        info!("client connected: {}", peer_addr);

        tokio::spawn(async move {
            let mut reader = BufReader::new(socket).lines();
            while let Ok(Some(line)) = reader.next_line().await {
                info!("received line: {}", line);
                // 这里把 line 交给协议解析模块处理
            }
        });
    }
}

启动方式：

bash复制cargo run

看到 LIS Simulator listening on 127.0.0.1:9500 就说明服务已经起来了。

需要注意，这里为了快速演示使用 \n 分行读取。真实 ASTMn/HL7 报文可能是 TCP 字节流里连续的多帧数据，不能简单按行切割，后面解析部分需要用帧起始符和帧结束符做状态判断。

4.3 ASTMn 消息解析骨架

ASTM E1381/E1394 是实验室仪器通信常见的帧格式。真实协议里帧由 STX 起始，中间字段用 | 分隔，结尾带 ETB/ETX 和单个校验字节。不同厂商会有自定义扩展，实际项目中一定要以仪器协议手册为准。

下面给一个用 nom 解析简化 ASTM 帧的骨架：

rust复制use nom::{
    bytes::complete::{tag, take},
    combinator::map_res,
    sequence::{delimited, preceded},
    IResult,
};

/// 简化版 ASTM 帧：STX + 文本 + ETX + 校验
fn parse_astm_frame(input: &[u8]) -> IResult<&[u8], &[u8]> {
    let stx = "\x02".as_bytes();
    let etx = "\x03".as_bytes();
    let text = delimited(
        tag(stx),
        take_until_bytes(etx),
        tag(etx),
    );
    text(input)
}

fn take_until_bytes(byte: &[u8]) -> impl Fn(&[u8]) -> IResult<&[u8], &[u8]> + '_ {
    move |input: &[u8]| {
        if let Some(pos) = input.windows(byte.len()).position(|w| w == byte) {
            Ok((&input[pos..], &input[..pos]))
        } else {
            Err(nom::Err::Error(nom::error::Error::new(input, nom::error::ErrorKind::TakeUntil)))
        }
    }
}

fn main() {
    let frame = b"\x02LIS|1|P|1^cbc||20250112103000\r\x03F0";
    match parse_astm_frame(frame) {
        Ok((_, text)) => println!("parsed text: {:?}", String::from_utf8_lossy(text)),
        Err(e) => println!("parse error: {:?}", e),
    }
}

这一层解析不用一步到位，先把“能从字节流里找到一帧文本”跑通，后续再慢慢加记录类型、字段编号和校验逻辑。

4.4 启动脚本建议

开发模式直接 cargo run。需要长期跑批量任务时，建议编译 release 版本：

bash复制cargo build --release
./target/release/lis_simulator --host 127.0.0.1 --port 9500 --config ./config/simulator.json

如果模拟器需要指定配置文件目录，可在启动参数里加 --config，让业务配置与代码分离。端口冲突时会提示 bind 错误，换一个端口即可。

5. 功能测试与效果验证

5.1 启动自测

先用最直接的方式确认服务活着。服务启动后，在另一个终端用 nc 或 telnet 连一下：

bash复制printf '\x02LIS|1|P|1^cbc||20250112103000\x03F0\r' | nc -w 3 127.0.0.1 9500

如果服务端日志打印出了接收到的字节，说明 TCP 链路正常。没有输出就检查防火墙、端口占用和绑定地址。

5.2 模拟仪器向 LIS 发送样本结果

这是最常用的测试场景之一。模拟器作为“仪器端”时，需要主动向 LIS 的地址发起 TCP 连接并发送报文。可以先写一个简单测试脚本：

rust复制use tokio::io::AsyncWriteExt;
use tokio::net::TcpStream;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let mut stream = TcpStream::connect("127.0.0.1:9600").await?;
    let frame = b"\x02LIS|1|O|1^cbc^1||166001||20250112103000||||||||||||||\x03F0\r";
    stream.write_all(frame).await?;
    stream.flush().await?;
    println!("frame sent");
    Ok(())
}

判断成功的标准是：LIS 端（真实 LIS 或模拟的 LIS 服务端）返回了应答帧，且样本号 166001、项目编码 cbc 被正确解析出来。

5.3 模拟 LIS 向仪器下发测试指令

反过来，模拟器也可以扮演 LIS。真实仪器会主动连接上来，发查询命令，模拟 LIS 则返回测试请求。这里测试的重点是：

• 是否能识别仪器发来的握手帧。
• 是否能根据样本号查表并返回正确的测试项目。
• 仪器断连后是否能正常处理半包数据。

这类测试建议准备一张样本-项目映射表：

json复制{
  "166001": ["cbc", "alt", "ast"],
  "166002": ["glu", "hbA1c"],
  "error_case": []
}

仪器端报 166001 时，模拟器回应三个项目；报 error_case 时，模拟器回一个错误帧，以此来验证真实仪器端的异常处理。

5.4 长连接稳定测试

长时间占用连接最容易暴露内存泄漏和缓冲区问题。测试方法是启动模拟器后，用脚本保持连接并每隔 30 秒发送一帧，持续数小时，观察内存占用是否持续上涨。Rust 侧如果使用 tokio::spawn 为每个连接创建独立任务，连接断开后任务需要正常退出，不能留下悬挂任务。

5.5 错误帧注入测试

LIS 模拟器一个比真实仪器好用很多的地方，就是可以主动制造错误。建议做这几类注入：

5.6 判断测试是否通过的通用标准

• 服务进程稳定，无 panic，无不可恢复错误。
• 日志里能明确看到“收到帧 -> 解析成功 -> 应答帧已发送”的完整链路。
• 异常帧不会拖挂后续连接的处理，后续正常帧仍能解析成功。
• 长时间运行后内存曲线平稳，没有持续增长。

如果测试中模拟器出现解析错误，优先检查帧起始符、帧结束符、校验位三个位置，不要直接怀疑业务逻辑。

6. 接口 API 与批量任务

6.1 为什么需要 API

纯命令行方式适合手动测试，自动化回归时需要脚本能远程控制模拟器。在模拟器进程里启动一个 HTTP API，就能让测试脚本动态下发模拟行为，不用每次改代码重新编译。

6.2 REST API 设计模板

以下是通用接口骨架，真实项目里按需求裁剪。

在 main 函数里挂载 Axum：

rust复制use axum::{
    routing::{get, post},
    Router,
    Json,
    extract::State,
};

#[derive(Clone)]
struct AppState {
    // 这里放共享状态：连接池、消息队列、配置
    batch_tasks: Vec<BatchTask>,
}

#[derive(serde::Serialize, serde::Deserialize)]
struct SendFrameRequest {
    target: String,
    frame: String,
}

#[derive(serde::Serialize)]
struct HealthResponse {
    status: String,
    version: String,
}

async fn health(State(_state): State<AppState>) -> Json<HealthResponse> {
    Json(HealthResponse { status: "ok", version: env!("CARGO_PKG_VERSION").to_string() })
}

async fn send_frame(
    State(state): State<AppState>,
    Json(req): Json<SendFrameRequest>,
) -> Json<serde_json::Value> {
    // 根据 req.target 选择连接池里的连接发送帧
    tracing::info!("send frame to {}: {}", req.target, req.frame);
    Json(serde_json::json!({ "ok": true }))
}

#[tokio::main]
async fn main() {
    let state = AppState { batch_tasks: Vec::new() };
    let app = Router::new()
        .route("/health", get(health))
        .route("/api/frame/send", post(send_frame))
        .with_state(state);

    let listener = tokio::net::TcpListener::bind("127.0.0.1:8800").await.unwrap();
    tracing::info!("API server on 127.0.0.1:8800");
    axum::serve(listener, app).await.unwrap();
}

6.3 curl 调用示例

启动后直接 curl 调用：

bash复制curl http://127.0.0.1:8800/health

返回：

json复制{"status":"ok","version":"0.1.0"}

发送一帧：

bash复制curl -X POST http://127.0.0.1:8800/api/frame/send \
  -H "Content-Type: application/json" \
  -d '{"target":"lis","frame":"\u0002LIS|1|P|1^cbc||20250112103000\u0003F0\r"}'

注意 \u0002 在 JSON 字符串里表示 STX 字符，\u0003 表示 ETX，真实项目中要按协议文档正确转义。

6.4 批量任务设计

批量任务的典型需求是：一次性生成 1000 条样本结果，以固定速率发送给 LIS，验证 LIS 在高压下的处理能力。

配置示例：

json复制{
  "task_id": "batch_1000",
  "count": 1000,
  "interval_ms": 10,
  "start_sample_no": 100001,
  "project_code": "cbc",
  "target": "lis",
  "prefix": "demo"
}

用 Python 脚本调 API 启动：

python复制import requests
import json

payload = {
    "task_id": "batch_1000",
    "count": 1000,
    "interval_ms": 10,
    "start_sample_no": 100001,
    "project_code": "cbc",
    "target": "lis",
    "prefix": "demo"
}

resp = requests.post(
    "http://127.0.0.1:8800/api/batch/run",
    json=payload,
    timeout=5
)
print(resp.status_code)
print(resp.json())

查询任务状态：

bash复制curl http://127.0.0.1:8800/api/batch/status?task_id=batch_1000

批量任务的工程建议：

• 批量任务必须有独立状态机：待执行、执行中、完成、失败。
• 每批次要记录已发送数量和失败数量。
• 大批量任务要有并发限制，控制 interval_ms 不能为 0，否则会把接收端压垮。
• 失败帧要落盘，方便后续重放和分析。
• 任务日志单独文件保存，避免和主日志混在一起。

7. 资源占用与性能观察

LIS 模拟器的资源观察方式和 AI 模型完全不同。不需要看显存，重点关注 CPU、内存、连接数和文件描述符。

7.1 网络连接数

模拟器每接受一个连接，就要创建一个异步任务。看当前连接数：

bash复制ss -tn | grep 9500 | wc -l

如果连接数异常上涨，优先排查业务方是否有未关闭连接的问题。模拟器自身要做好优雅退出：连接断开时清理缓冲区，释放相关状态。

7.2 内存观察

Linux 下用 /proc 或者 top 都能看到进程内存。Rust 程序常见的内存上涨原因是：

• 解析器错误分支没有回收字节缓冲。
• 异步任务里持有大对象没有及时 drop。
• 消息记录无限写入内存，没有做队列上限。

解决方式是为接收缓冲区设置上限，日志按大小滚动，批量任务结果定时写盘并清理内存中的数据。

7.3 消息吞吐量受什么影响

• frame_size：帧越长，解析耗时越高。
• interval_ms：发送间隔越小，吞吐越高，但也越容易丢帧。
• 并发连接数：超过 CPU 核心数后，提升有限，反而增加上下文切换。
• 日志级别：debug 日志会把每帧内容都打印出来，吞吐量明显下降。正常跑批量任务时建议 info 级别。

如果想预估模拟器在目标机器上的吞吐上限，可以启动一个空服务，用脚本递增 count 和并发数做压测。实际测试前先观察 CPU 是否跑满，再调整发送速率。

7.4 是否需要 GPU

答案是明确不需要。LIS 模拟器处理的是字节流和网络事件，不涉及图像、语音、深度学习推理，整个运行过程只依赖 CPU 和内存。这也是它在工控机、CI 容器、云主机上都能跑的原因。

7.5 降低占用的做法

• 使用 tokio::spawn 而不是每连接起一个系统线程。
• 禁止无限追加日志文件，日志按大小轮转。
• 长时间空闲的连接设置读超时，自动回收。
• 批量任务使用异步定时器 tokio::time::interval，不要让线程阻塞等待。

8. 常见问题与排查方法

排查 LIS 模拟器问题时，最关键的动作是“先把原始字节打出来看一眼”。很多协议联调问题最后都归结为：帧头多了一个 \0，字段分隔符多了一位，或者校验位计算方式不同。不要靠猜，直接把十六进制字节打出来对比协议文档。

9. 最佳实践与使用建议

9.1 代码结构拆分

不要把协议解析、TCP 服务、API 服务和业务配置全部塞进 main.rs。建议至少拆成这些模块：

text复制src/
  main.rs        # 启动入口，加载配置，拉起 TCP 和 HTTP 服务
  config.rs      # 环境变量/JSON 配置加载
  protocol/      # ASTMn、HL7 解析与构造
  transport/     # TCP 服务端、TCP 客户端、串口读写
  api/           # Axum 路由与批量任务状态管理
  tasks/         # 批量发送、定时回放、消息队列

9.2 配置与代码分离

样本号前缀、项目编码表、端口号、发送间隔都放到配置文件里。改测试参数时只改 JSON，不动代码。

json复制{
  "port": 9500,
  "api_port": 8800,
  "log_dir": "./logs",
  "sample_prefix": "DEMO",
  "protocol": "astm_e1394"
}

9.3 保留最小可运行配置

每一次功能迭代都保留一个最小可运行版本，避免改到一半跑不起来。建议把已验证通过的协议配置打 tag，比如 v0.1.0-minimal-tcp，需要时可以快速回退。

9.4 批量任务加日志和失败重试

批量任务不要只记录成功数量。每一条发送失败的帧都应有独立的错误记录，至少要包含时间戳、目标连接、原始帧和失败原因。重试逻辑要做次数限制，不能无限重试。

9.5 API 服务限制访问范围

模拟器的 API 只应该在受控测试环境开放。不要直接绑定 0.0.0.0:8800 暴露在公网。本机联调时用 127.0.0.1，局域网联调时按目标网段设定防火墙规则。

9.6 合规与隐私内嵌到流程

模拟器代码和测试脚本中统一使用虚构数据，不复制真实患者信息。如果项目确实需要保留一份样本用于复现线上问题，必须先做字段级脱敏，再进入模拟环境。涉及仪器协议文档和厂商 SDK 时，以合法授权为前提。

9.7 建立回归测试集合

把联调过程中遇到的所有难解析帧存成测试用例文件。每次改协议解析代码后，跑一遍全量用例，避免修了一个帧又弄坏另一个帧。Rust 侧可以直接用 cargo test 组织这些用例。

10. 总结与下一步

用 Rust 写 LIS 模拟器的核心价值是：把仪器对接中“最难复现的那部分报文交互”变成可编程、可批量、可回归的本地测试能力。它的门槛很低，不需要 GPU，不依赖特定硬件，一个 cargo run 就能在开发机上拉起 TCP 服务，再通过 Axum 暴露 REST 接口，由测试脚本控制整个模拟过程。

最先应该验证的功能是 TCP 端到端收发：模拟器监听端口，测试脚本发一帧 ASTMn 报文，看日志是否完整打印出解析后的字段。这一步跑通，后面的批量任务、错误注入、断线重连都有地基。最容易踩的坑是协议细节：字节流粘包、STX/ETX 转义、校验位算法、字段分隔符口径，任何一处和真实仪器不一致，都会表现为“明明发了帧，对方就是没反应”。

如果你已经在做 LIS/IVD 相关开发，下一步可以把这个模拟器扩展成一套支持录放比的测试工具：真实仪器来一帧报文，模拟器记录下来，再自动化回放给 LIS 看处理结果。这个方向比从零造协议高效得多，也是把“模拟器”从玩具变成工程工具的关键一步——建议收藏备用，等真正接到仪器联调任务的时候会想起来用上。