简介Conquest DICOM Server 是一款开源的 DICOM 服务器测试工具适合医疗影像领域的开发人员、系统集成工程师和运维人员使用。该工具以 DICOM SCP 身份运行能够接收并处理来自 PACS 或其他设备的 DICOM 请求支持工作列表查询可用来模拟真实临床环境中的影像交换与预约流程辅助验证网络通信的正确性。压缩包大小 22.28MB里面包含可执行程序、批处理脚本、DICOM 字典、匿名化脚本、动态链接库等多种文件类型分别覆盖服务器启动、自动更新与安装、消息解析、患者数据脱敏以及核心协议处理等关键环节并提供控制台交互和网关连接能力方便监控状态与跨设备联动。该资源已有 710 人学习浏览。借助这些文件读者可以快速搭建本地 DICOM 测试环境检查新设备或新软件的兼容性通过日志分析评估服务器性能在异构 PACS 间迁移数据时充当中间代理同时利用匿名化脚本保护患者隐私。尤其适合系统上线前的联调与验收测试。掌握这套工具后开发 DICOM 应用或管理医疗影像系统都会更加高效、准确。 做医学影像相关的开发最烦的事情不是功能实现而是缺一台能随时“折腾”的 DICOM 服务端。对接医院真实 PACS 成本高、权限严不可能让你随便发几张测试图、跑几个查询。dicomserver测试工具里我常用的一台靶机就是 ConquestDICOMServer。它轻量、免费、单文件就能跑起来非常适合用来模拟 PACS 行为、验证 C-STORE/C-FIND/C-MOVE 流程或者给 DICOM 工作站做联调测试。如果你也在找一套能快速部署、又足够接近真实 DICOM 服务的测试环境这篇文章可以直接参考。1. 为什么我拿 Conquest 当 DICOM 测试的靶机先说说我的使用场景平时开发 DICOM 客户端、写图像传输脚本、调试 RIS 或工作站对接最需要的是一个能自主控制的 SCPService Class Provider服务端。真实 PACS 不能随便动DCMTK 自带的storescp只能做最简单的接收功能不够。Conquest 这个老牌开源项目在测试场景里就特别顺手。Conquest 的核心能力不复杂但它把最常用的 DICOM 服务都覆盖了C-ECHO验证网络和 AE 连接是否通C-STORE接收客户端推过来的 DICOM 文件C-FIND按患者、检查、序列等层级查询数据C-MOVE把存储的 DICOM 文件推送到指定的接收端数据库索引默认支持 dbase、SQLite、MySQL可以按 PatientID、StudyDate 等条件检索我选 Conquest 最重要的一点是“可摧毁性”。测试环境里的服务端必须经得起反复清空数据、改配置、重启甚至删掉重装。Conquest 的数据目录和配置文件都是独立的删了不影响系统重来一遍也就几分钟。这一点在联调阶段被坑过的人都知道有多重要。和其他常见 DICOM 服务端相比Conquest 的定位很明确候选方案优点测试场景里的不足Conquest DICOM Server轻量、单包部署、配置简单、功能全界面朴素高级查询需要手动配置OrthancREST API 强、DICOMweb 支持好部署稍重DICOM 传统服务配置不够直观DCMTK storescp/storecu命令行灵活适合跑单条命令没有数据索引无法做 C-FIND 级联测试dcm4chee / dcm4che完整的企业级 PACS 组件依赖容器和数据库启动慢测试杀鸡用牛刀所以我的结论很直接如果只搭一个“够用又可控”的测试靶机Conquest 是性价比最高的选择。2. 从零搭起 Conquest DICOM Server 测试环境2.1 安装包选型和目录规划Conquest 的官网提供 Windows、Linux 和 macOS 版本测试环境建议直接用二进制发行版。Windows 下解压 zip 到一个路径里比如C:\Conquest注意路径里尽量不要带空格和中文。Linux 下可以下载 tar.gz 包解压后放在/opt/conquest或用户目录下。解压出来的文件里核心是dgate.exe/dgate服务进程负责监听 DICOM 端口dicom.ini主配置服务端口、AE Title、数据库类型都在这里dgate.log运行日志测试排查全靠它data/目录默认接收和索引 DICOM 文件的地方如果准备长期跑建议把数据目录单独建出来比如data目录放到独立磁盘或专门分区方便后期清理和备份。这个习惯在测试机上也值得保留因为反复初始化数据库时数据目录越干净越好。2.2 dicom.ini 里的关键修改项第一次启动前必须改dicom.ini。直接双击运行是能起来但不改配置的话数据库类型、AE Title、端口可能都不符合你的测试计划。我通常先改这几个关键项# 数据库类型测试环境推荐 SQLite稳定且方便备份 DatabaseType sqlite # 服务监听端口默认 5678被占用的时候自己换 TCPPort 5678 # 本服务的 AE Title客户端连过来时要用 MyACRNema DICOM # 数据库文件存放路径 SQLiteDatabase data\conquest.db重点解释一下DatabaseType。Conquest 默认使用 dbase 格式老项目里很常见但 dbase 在数据量大了之后稳定性一般而且索引文件散落。换成 SQLite 之后整个索引就是一个conquest.db文件测试时想备份或者清空都特别方便。第一次切换后需要清空数据目录初始化一个新的数据库否则可能报错。MyACRNema就是本服务器对外暴露的 AE Title默认是DICOM。很多客户端工具默认 AE Title 也是大写这里保持大写最简单避免因为大小写不一致连不上。2.3 启动服务并确认端口监听Windows 下可以直接双击dgate.exe也可以注册成 Windows 服务。注册服务的命令是dgate -install然后到服务管理器里启动Conquest DICOM Server服务就行。如果只是临时测试前台运行更直观日志直接打在控制台方便一边发数据一边看。Linux 下直接执行./dgate如果报缺库先确认 32 位兼容库是否装上。启动后检查端口ss -lntp | grep 5678能看到监听就说明服务起来了。再用dgate.log确认数据库初始化是否正常日志里通常会有类似“SQLite database opened”的信息。3. 用 DCMTK 命令行工具把 Conquest 各项服务打一遍3.1 C-ECHO先确认链路通不通不管调试什么 DICOM 服务我都习惯先用 C-ECHO 打头阵。C-ECHO 不发真实图像数据只交换一个 DIMSE 消息能通就说明 IP、端口、AE Title 都配对成功了。DCMTK 里用echoscuechoscu -v -aet TESTC 127.0.0.1 5678注意这里-aet是客户端自己的 AE Title可以随便起但不能为空。Conquest 默认不校验客户端 AE Title所以TESTC这种名字也能通过。如果加了-aec指定服务端 AE Title就必须跟dicom.ini里的MyACRNema完全一致。连接超时或者被拒绝时先别急着调客户端。我一般按这个顺序排查端口监听是否正常ss -lntp或netstat -anoWindows 防火墙是否拦截了 5678Conquest 是否真的在运行日志最后一行有没有报错3.2 C-STORE验证图像能不能收C-ECHO 通了标志链路没问题。接着就要验证最核心的 C-STORE——把 DICOM 文件推给 Conquest。测试前需要一张 DICOM 文件。最简单的办法是用 DCMTK 自带的dcmdata工具转换一张普通图片或者从之前测试数据里拿一张。手头没有数据时可以用storescp配合dump2dcm手工造一个最小 DICOM 文件但更快的办法是直接下载公开的样例数据。发送命令storescu -v -aet TESTC -aec DICOM 127.0.0.1 5678 test.dcm看到C-STORE返回 Success 状态码就说明 Conquest 已经接受了这份文件。想知道对方到底落没落盘可以去data目录看有没有生成新的 DICOM 文件或者看dgate.log里有没有对应的存储记录。我见过不少人在这里犯迷糊C-STORE 返回成功后敲命令的终端就丢下不管了从来不看日志。但测试过程中客户端收到 Success 只能说明服务端协议层处理了数据库索引是否建立成功、文件是否写完整都要靠服务端日志确认。养成每次发送后扫一眼日志的习惯能少踩很多隐蔽的坑。3.3 C-FIND验证数据被正确索引光能收图还不够一个 PACS 系统还得能被查询。C-FIND 是验证数据索引是否建好的最直接方式。Conquest 默认允许 C-FIND 查询但需要按层级指定查询条件。用 DCMTK 的findscu发一个按 STUDY 级别的查询findscu -v -S -aet TESTC -aec DICOM \ -k QueryRetrieveLevelSTUDY \ -k StudyDate \ -k StudyInstanceUID \ 127.0.0.1 5678返回结果里能看到 Conquest 把已存储的研究信息列出来说明数据库索引工作正常。如果查询结果为空先确认是不是发了 IMAGE 级别的查询但数据里没有对应的 SOP Instance UID也可以直接在 Conquest 自带的 GUI 里搜一下患者看看数据到底在不在库里。C-FIND 在真实 PACS 场景里非常依赖 AE Title 和权限配置。Conquest 测试环境里默认全放行能省不少事但也意味着某些权限相关的边界问题在 Conquest 上复现不出来。如果是为对接真实 PACS 做预研这一点心里要有数。3.4 C-MOVE验证服务端能否主动推图C-MOVE 是查询-取回流程里的关键动作。客户端向 Conquest 发一个 C-MOVE 请求Conquest 随后主动向目标 AE 发起 C-STORE把匹配的图像推送到指定接收端。这个动作比 C-STORE 复杂因为需要一个“接收端 SCP”在那边老老实实等着。我通常的做法是同时开两个终端终端 A 起一个storescp作为接收端storescp -v -aet RECEIVER 11112终端 B 发 C-MOVE 请求movescu -v -aet TESTC -aec DICOM -aem RECEIVER \ -k QueryRetrieveLevelSTUDY \ -k StudyInstanceUID1.2.3.4.5 \ 127.0.0.1 5678注意-aem RECEIVER必须和storescp里的-aet RECEIVER一致。C-MOVE 的语义就是Conquest 收到这个请求后会把匹配的数据主动推给 AE Title 为RECEIVER的那台机器。如果接收端没起或者 AE Title 对不上Conquest 日志里会明确报错。这里常见的问题是很多人忘了 ConQuest 的 C-MOVE 需要目标 AE 被识别。有的 PACS 会有“已知 AE”白名单Conquest 测试环境虽然放开但也需要接收端先跟 Conquest 建立过联系或在配置中注册。如果 movescu 报 “Unknown AE Title”就去dicom.ini里检查KnownAETitles是否配置正确。4. Conquest 配置与测试中容易踩的暗坑4.1 AE Title 大小写与空格的幽灵问题AE Title 是 DICOM 协议里最基础也最容易被忽略的字段。规定是大小写敏感且不能包含空格。Conquest 在匹配 AE Title 时比较严格dicom和DICOM会被当成两个完全不同的实体。我在迁移测试环境时踩过一次旧的初始化脚本里用的是DICOM_SERVER换了新服务器后配置写成DICOM客户端没改结果 C-ECHO 一直超时。排查半天才发现是 AE Title 不一致。所以建议测试环境里把所有 AE Title 统一定义客户端、服务端、自动化脚本里都用同一个字符串常量不要手敲。4.2 换数据库类型后旧数据不生效前面推荐了 SQLite但如果你是从默认 dbase 切换过去的最典型的坑就是服务起来了但查不到之前收的图像。原因很简单数据库类型变了Conquest 需要重新初始化数据索引旧数据不会自动迁移。解决办法不是手动搬文件而是停掉 dgate清空data目录或备份后删掉启动服务让它用 SQLite 重新建库用 C-STORE 重新发一遍测试数据如果不想丢掉旧数据就得用 Conquest 自带的导入/导出功能把 DICOM 文件重新索引。测试环境里重发的成本很低直接清库反而最省事。4.3 端口和防火墙的组合拳很多刚接触的人 C-ECHO 连不上第一反应是配置错了。其实八成是防火墙或者端口占用。Windows 上跑 Conquest服务装好后要额外放行端口。更隐蔽的是某些安全软件会拦截 dgate.exe 进程的网络通信服务看着在跑端口也监听但外面的请求就是进不来。遇到这种情况直接看 dgate.log如果只有连接接受记录、没有完整 DIMSE 交互那多半是网络层问题。Linux 下相对好排查tcpdump -i lo port 5678直接抓本地回环包几秒钟就能确认请求有没有到服务进程。4.4 日志级别别开太低Conquest 的dgate.log在测试阶段是最好的调试工具。默认日志级别有时太简略看不到 C-STORE 存储细节。可以适当调高日志级别比如在配置里把日志设置为显示 DIMSE 消息和数据库操作记录。日志级别开高会带来一个问题大量并发压测时日志写入会拖慢性能。所以我的习惯是功能验证阶段开高压测之前调回默认。5. 进阶玩法把 Conquest 融入自动化回归测试命令行工具手动验证是一层如果团队里有自动化测试需求Conquest 完全可以当固定靶机配合脚本做 DICOM 全流程回归。我目前的测试框架里就用 Bash 脚本封装了 echoscu、storescu、findscu、movescu 四个阶段第一步C-ECHO 验证服务在线第二步C-STORE 推送一组测试 DICOM 文件第三步C-FIND 查询这批 StudyInstanceUID断言返回条数第四步C-MOVE 将数据拉到本地临时目录用dcmftest检查拉取文件的完整性每个阶段都可以用脚本判断返回值任何一个失败就直接终止并输出日志。这样每次代码改动后跑一遍能快速发现网络配置、数据库索引之类的回归问题。Conquest 的服务端日志在自动化里也很重要。脚本跑完后我会自动 grepdgate.log里的 ERROR 和 Warning 关键词全部为空才算通过。这样即使 DICOM 协议层面返回成功服务端内部如果有异常也能被捞出来。这套流程看着简单但对保证 DICOM 对接质量非常有效。我现在每接一个新影像系统都会先拿 Conquest 跑一遍这套回归脚本确认基础链路没问题再去和真实设备联调能省下大把来回排查的时间。如果你也是刚接触 DICOM 测试建议先照着前面的步骤把 Conquest 搭起来用 DCMTK 把 C-ECHO、C-STORE、C-FIND、C-MOVE 各跑一遍。这四个流程通了你对 DICOM 服务端的工作机制也就有了一个直观的整体认识。本文还有配套的精品资源点击获取