本项目是专为医院设备管理场景设计的 Near-Miss（险肇事件）自动识别与报告生成系统。它不依赖人工巡检或故障后分析，而是从设备原始日志中实时捕获五类典型异常信号，告警频率突增、部件寿命超限、环境参数偏离、非计划停机频繁、错误码集中爆发，并将这些冷数据转化为设备“自述”口吻的可读报告。面向设备科工程师、后勤保障人员、信息科及一线运维团队，提供文本、JSON 与 HTML 三种交付形态；通过 CLI 命令行驱动，支持单文件、多文件 glob 批量、标准输入管道（含与 jq 协同）、时间/设备/严重度多维过滤，以及每日/每周周期性摘要；底层采用 Python 构建，核心依赖 Pandas 做时序聚合、PyYAML 管理规则、Jinja2 渲染模板、Chart.js 实现轻量前端可视化。

定位与能力范围

我们不做通用日志平台，也不做设备资产台账系统。本项目的边界非常清晰：只处理已有结构化设备日志（JSON 格式），只聚焦“尚未故障但已亮红灯”的 Near-Miss 信号，只服务“想提前动手”的设备管理角色。它不采集传感器原始流数据，不对接 PACS 或 HIS，不替代 CMMS（计算机化维护管理系统），而是作为一道轻量前置哨兵，在故障发生前把关键线索打包成一份人能看懂、部门能行动的报告。

这套逻辑成立的前提，是我们把“异常”定义得足够医疗现场化。比如“停机频率异常”不是简单统计开关次数，而是识别 10 分钟内反复启停 ≥3 次，这往往是电源模块老化或散热失衡的早期征兆；“错误码聚集”也不是罗列报错，而是检测 30 分钟内出现 ≥5 种不同错误码，说明底层固件或通信链路已进入紊乱状态。所有检测器都按临床工程实际维护节奏校准，阈值可调、窗口可配、规则可覆盖，拒绝一刀切。

核心功能

系统围绕“检测—理解—传达”三步闭环展开，每一步都针对医院现场痛点做了取舍：

• 五类医疗设备专属异常检测器：AlertFrequencyDetector（告警频率）、ComponentWearDetector（部件寿命）、EnvironmentAnomalyDetector（温湿度）、PowerCycleDetector（停机频率）、ErrorCodeClusterDetector（错误码聚集）。每一类都内置符合国标与厂商建议的默认基线，如部件寿命以 8000 小时为临界点，温湿度偏差容忍 ±5°C / ±15%。

• 设备自述风格报告：拒绝“告警 ID:E001 频次超标”这类工程师黑话。报告会写成：“我是 CT 设备 DEVICE_001，过去 24 小时触发告警 15 次（正常值应 ≤8 次），主要集中在球管冷却模块，建议 48 小时内检查散热风扇与冷却液流速”。这种表达让护士长、科室主任也能一眼抓住重点。

• 三模态输出适配不同使用场景：

• text

   模式：终端直出，适合值班工程师快速扫读；

• json

   模式：结构化字段完整（含 severity、device_id、detector_name、evidence、suggestion），便于接入钉钉/企业微信机器人或 CMMS 接口；

• html 模式：内嵌 Chart.js 可视化看板，自动聚合各设备风险等级分布、TOP5 异常类型、时间趋势图，支持离线打开，适合晨会投影汇报。

• 规则即配置，无需改代码：全部检测逻辑由 YAML 规则文件驱动。修改 data/default_rules.yaml 中任意阈值，下次运行即生效。支持部分覆盖，你只需写想调整的字段，其余沿用默认值。

检测器	判定逻辑	典型阈值示例
AlertFrequencyDetector	单设备单位时间告警次数超限	8 次/24 小时
ComponentWearDetector	部件累计运行时长占推荐维护周期比例超限	≥80%（即 8000 小时 / 10000 小时）
EnvironmentAnomalyDetector	温度或湿度连续超出设定安全区间	温度 <18°C 或 >26°C，湿度 <30% 或 >70%
PowerCycleDetector	单位时间内非计划启停次数异常	≥5 次/12 小时
ErrorCodeClusterDetector	短时内高频出现多种错误码	3 种错误码/6 小时

使用与配置

上手极简：只要你会用命令行和 JSON，5 分钟就能跑通第一条报告。不需要部署服务、不依赖数据库、不修改现有 IT 架构。

pip install -r requirements.txt
python cli.py --logs data/sample_logs.json --rules data/default_rules.yaml --format text

真正体现灵活性的是它的输入与过滤能力。你不必等日志归档完毕才启动分析：

• 支持 --logs "data/*.json" 批量处理整目录；

• 支持 --logs - 从管道读取，可直接接 curl、jq、tail -f；

• 支持正则过滤设备：--device-filter 'MONITOR_.*'；

• 支持严重度分级筛选：--severity-filter CRITICAL,WARNING；

• 支持时间切片：--since "2026-04-26T00:00:00" --until "2026-04-26T23:59:59"；

• 支持组合过滤：一条命令同时限定设备、时间、严重度。

例如，你想每天早八点自动生成 ICU 监护仪的昨日风险摘要，只需在 crontab 写：

0 8 * * * cd /path/to/project && python cli.py --logs "data/icu_*.json" --rules data/icu_rules.yaml --since "$(date -d 'yesterday' +\%Y-\%m-\%dT00:00:00)" --until "$(date -d 'today' +\%Y-\%m-\%dT23:59:59)" --format html --output /var/www/reports/icu_daily.html

数据与扩展

系统对输入数据格式有明确约定，但不过度约束源头。日志必须是 JSON 数组，每条记录至少包含 device_id、timestamp 两个字段，其余字段按需提供：

{
  "device_id": "DEVICE_001",
  "timestamp": "2026-04-26T10:00:00",
  "alert_count": 15,
  "component_hours": 8500,
  "temperature": 28.5,
  "humidity": 75,
  "power_status": "on",
  "error_codes": ["E001", "E002"]
}

设备台账（YAML）为可选项，用于补全设备元信息，使报告更完整：

DEVICE_001:
  name: "GE Optima CT660"
  type: "CT scanner"
  department: "Radiology"
  manufacturer: "GE Healthcare"

规则配置也完全开放。data/custom_rules.yaml 是为你准备的副本，改完直接传入 --rules 参数即可生效，无需重启、无需编译。所有阈值均为浮点数或整数，无隐藏逻辑，所见即所得。

工程结构

项目采用清晰分层架构，每个模块职责单一，便于医院信息科二次开发或对接自有系统：

模块	路径	职责
数据模型	src/models.py	定义 DeviceLog、DetectionResult 等核心数据结构，强类型约束
日志解析器	src/log_parser.py	统一读取 JSON 日志，做基础清洗、时间标准化、缺失字段填充
规则引擎	src/rules_engine.py	加载 YAML 规则，实例化各检测器，执行批量扫描与结果聚合
报告生成器	src/report_generator.py	根据 format 参数调用对应模板（text/jinja/json/jinja/html/jinja）
CLI 入口	cli.py  和 src/cli.py	命令行参数解析、流程编排、输出分发

整个 src 下无硬编码路径、无绝对 URL、无外部 API 密钥，所有外部依赖均通过参数或配置注入，确保在医院内网离线环境稳定运行。

限制与说明

我们坦诚说明当前能力边界，避免误用：

• 不支持非结构化日志（如纯文本 syslog），必须是合法 JSON；

• 不支持实时流式处理（如 Kafka、MQTT），仅处理静态文件或管道输入的完整 JSON 流；

• HTML 看板为静态页面，无后端交互，图表数据在生成时已固化；

• 多设备聚合统计基于内存计算，单次处理日志量建议控制在 10 万条以内（Pandas 性能友好阈值）；

• “设备自述”文案为模板化生成，未接入 LLM，不生成自由文本，确保每句话可追溯、可审计。

这些限制不是技术短板，而是我们主动选择的克制，只为守住“轻、稳、准”三个字：轻到单机可运行，稳到内网可离线，准到每条预警都有明确数据依据与处置建议。

项目地址：
https://github.com/nexorin9/equipment-nearmiss-reporter