ConquestDICOMServer：本地 DICOM SCP 测试环境搭建与避坑

简介Conquest DICOM Server 是一款开源的 DICOM 服务器测试工具面向医疗影像软件开发者、PACS 管理员及系统集成测试人员可作为 DICOM SCP 接收和存储影像、响应工作列表查询用于模拟真实设备、验证网络通信与排查集成问题。资源包约 22.28MB内含服务器主程序 ConquestDICOMServer.exe、控制台脚本 console.bat、自动更新与 Web 安装脚本、CqDicom.dll 核心库、dgate.dic 字典、数据匿名化脚本以及 7za.exe 等工具覆盖服务启动、配置维护、数据处理与归档场景。目前已有 716 人学习借助这套工具可以低成本搭建测试环境掌握 DICOM 图像收发、工作列表调试、匿名化处理和跨 PACS 数据迁移的实践方法从安装脚本到匿名化配置一应俱全便于按需调用也可通过日志观察评估服务器负载为医疗系统上线前的兼容性与性能验证提供参考。1. 为什么我建议拿 ConquestDICOMServer 当 DICOM 测试工具用做过 PACS 对接或者影像设备联调的人一定对测试 DICOM 传输这件事不陌生。手里没有一套稳定可控的 DICOM SCP 服务端联调就是一场灾难设备厂商的测试环境说关就关医院 PACS 那边的 SCP 端口你也不能随便乱发假数据去撞出了问题连是谁的锅都说不清楚。ConquestDICOMServer 在 DICOM 测试工具这个圈子里算是一个绕不开的名字它本身是一套开源的 DICOM SCP 服务支持存储、查询、Retrieve同时也自带 Worklist 服务能力。对做医学影像集成、PACS 测试、设备调试的人来说它就是那个能让你随时在本地搭一个 DICOM 节点、随便收发数据、测完就删的沙盒。这个工具解决的核心问题是你不需要依赖厂商环境也不用在真实的 PACS 上做破坏性测试自己花十几分钟就能起一个像模像样的 DICOM SCP并且支持完整的 Storage 和 Worklist 流程。适合三类人一类是医院信息科的工程师需要在接入新设备前验证 C-FIND/C-STORE 流程一类是厂商实施人员需要复现客户环境里的传输异常还有一类是做 PACS 研发、写 DICOM 解析代码的开发者需要一个行为可控的服务端来配合打点调试。我最早接触 Conquest 是在一批超声设备的数据迁移项目里当时用它把不同厂商设备的 DICOM 文件做了大量吞吐测试发现这个轻量级 SCP 的稳定性和日志完整度都比想象中好才真正把它当成一个正经测试工具来用。需要提醒的是它毕竟不是一个商业级 PACS不适合拿去做海量高并发压力测试但在联调验证这个尺度上它非常能打。2. 从下载到跑起来ConquestDICOMServer 的最小可用配置2.1 装之前必须先想清楚你要拿它当 SCP 用还是当 Worklist 服务用ConquestDICOMServer 这个工具支持多进程架构一旦跑起来它可以同时承担 DICOM SCP 存储服务、Worklist SCP以及 Web Server 三个角色。很多人第一次接触它容易把它当成一个单纯的 DICOM 文件收发工具来看这会在后面的配置上走不少弯路。如果你只是做 Storage 测试核心是配置好 SCP 的端口和 AE Title如果你要测 Worklist那就需要额外配置数据库和 HL7 接口。先搞清楚一个基本概念DICOM 是医学数字影像通信标准SCP 是服务类提供方Service Class Provider也就是接收请求的一方。你日常用 Conquest 时大部分工作发生在它作为一个 SCP 角色接收来自设备或测试工具的 C-STORE 请求时。所以你测试工具里填的目标 AE Title 和目标端口必须和 Conquest 的 dgatesop 配置完全对上否则你发出去的 C-STORE 请求直接就被拒了。2.2 下载与目录文件别看文件多关键就那三个首先去官方源下载 Windows 版如果你是 Linux 环境有对应的源码包可以自己编译但日常测试用 Windows 可执行包最省事。解压后你不需要关心所有文件只需要记住三个核心东西dgate.exe这是 Conquest 的主服务进程所有 DICOM 服务都靠它跑测试时你要先保证这个进程存活。dgatesop.lst这个文件里存的是 SCP 配置等会真正要动的就是它里面定义了端口、AE Title、存储目录。dicom.ini主配置文件数据库类型、日志路径、网络绑定地址都在这里写。# 注意以下命令在 Windows 的 DOS 窗口里执行 cd D:\Conquest-DICOM-Server # 第一次启动时先手动跑一下主进程看有没有缺库报错 dgate.exe我第一次解压后就直接双击 dgate.exe结果报了一个数据库连接错误原因是没有初始化数据库。Conquest 用的是 SQLite 作为默认数据库但第一次使用你需要允许它自动创建数据库文件。注意第一次启动最好是手动运行 dgate.exe 而不是做成 Windows 服务因为手动运行你能直接看到初始化日志。如果初始化失败你做成服务排错起来就非常被动。2.3 修改 dicom.ini端到端的最小配置模板dicom.ini 是 Conquest 启动时第一个读取的文件里面很多参数你暂时不用动但有几个直接决定了你测试能不能通。以我经常用来做测试的一套配置为例[ssc] ServerType SQLite LocalAET CONQUESTSRV TCPPort 5678 TCPPortWorklist 5679 ProcessorThreads 8 RootDirectory D:\Conquest-DICOM-Server\Data这里的LocalAET是这台测试服务器的 AE TitleTCPPort是主存储服务的端口TCPPortWorklist是 Worklist 服务端口。在实际测试中我习惯把 Worklist 端口和主端口分开这样测 C-FIND 时不会和 C-STORE 请求互相干扰。你可能注意到了我用的是 5678 而不是常见的 104因为很多测试环境里 104 需要管理员权限而 5678 这种高位端口不受限制。修改完 ini 之后保存退出再把 dgate.exe 重新运行一遍。这次如果看到日志里出现类似Listening on port 5678的信息那说明 Conquest 的 SCP 服务已经起来了。这个时候你的 DICOM 测试工具里目标 AE Title 就要写成CONQUESTSRV端口写5678。2.4 建库与目录准备不准备好这些测试中段容易翻车Conquest 的存储逻辑是每个接入的 Calling AE Title 对应一个独立的子目录文件按 Study 组织。如果你没有为测试创建的 AE Title 预先建好目录它会自动在 RootDirectory 下创建。这个机制对临时测试很方便但有个坑如果你测试时频繁更换 AE Title磁盘上会留下大量垃圾目录。所以我的习惯是在测试之前先手动把目录结构建好mkdir D:\Conquest-DICOM-Server\Data\TESTSRC mkdir D:\Conquest-DICOM-Server\Data\TESTDST这里TESTSRC模拟发送端设备TESTDST是接收端。然后用文本编辑器打开 dgatesop.lst添加对应的 SCP 定义。dgatesop.lst 里每一行的格式是# AE Title, 描述, 主机名/IP, 端口 TESTSRC, 模拟超声设备, ANY, 5678 TESTDST, 模拟PACS归档, ANY, 5678逻辑就是当测试工具用TESTSRC这个 AE Title 发数据过来Conquest 就把数据存到对应目录。主机名写 ANY 表示不做 IP 过滤这在局域网测试里很常用但如果你面对的是公网环境建议写成具体的 IP 地址否则随便一台机器都能往里发数据。3. 三种实操场景从存储曲线到 C-FIND 查询再到 Worklist 验证3.1 场景一用 Conquest 做 C-STORE 接收的整条链路测试这是最基本的测试场景。你的被测设备或者 DICOM 测试工具比如 dcm4che 的 storescu向 Conquest 发送 DICOM 文件Conquest 作为 SCP 接收并落盘。跑通这条链路证明你的设备端 C-STORE 的 AE Title、IP、端口设置没有错位。在 Windows 上测试我会用 dcm4che 工具包里的 storescu 命令它跑在同一个局域网内往 Conquest 上发文件# 用 dcm4che 的 storescu 向 Conquest 的 SCP 发送一副 CT 图像 storescu -c CONQUESTSRV127.0.0.1:5678 -aec CONQUESTSRV D:\testdata\ct_slice.dcm这行的核心参数是-c后面的CONQUESTSRV127.0.0.1:5678CONQUESTSRV 是目标 AE Title127.0.0.1 是 Conquest 所在机器地址,5678 是端口。-aec指定请求的 Calling AE Title如果 Conquest 在 dgatesop.lst 里对 Calling AE 做了限制这里的值必须匹配。发送成功后从 Conquest 日志里能看到类似C-STORE received的记录同时到 Data 目录下去看应该多了一个按 Study UID 命名的文件夹里面就是接收到的 dcm 文件。如果 C-STORE 发不出去或者被拒绝第一个要查的就是-aec这个参数。很多厂商设备里配置的 AE Title 是固定不能改的如果你在 Conquest 那边限制了合法的 AE Title 列表你的测试请求头里带着一个不在名单里的名字直接被拒。逻辑上 Conquest 的 SCP 服务和设备端的 Store SCU 是握手关系两边 AE Title 必须互相认识。3.2 场景二验证 C-FIND 查询从服务端查回已有 Study 信息存储测试通过之后你需要验证查询能力也就是 C-FIND。这时候 Conquest 不只是接收文件还要能回应 Query 请求。查询测试的意义在于你不仅能发数据过去还能验证数据是否可被检索到。常用的测试工具是 dcm4che 的 findscu# 在 Query Retrieve LevelPATIENT, 查所有患者 findscu -c CONQUESTSRV127.0.0.1:5678 -m QueryRetrieveLevelPATIENT -m PatientName* -aec CONQUESTSRV这里-m是匹配关键字。PatientName*表示通配所有患者。正常情况下findscu 会把前一步存进去的那条记录的患者信息列出来。如果查不出来常见原因是发送 C-STORE 时文件里的 PatientName 是空的或者在存储时被 Conquest 过滤掉了。遇到查不出数据的情况先在 Conquest 的查询工具界面里直接搜一下患者姓名如果里面能看到数据但 findscu 查不出来那就是查询匹配级别的问题把-m QueryRetrieveLevelPATIENT改成-m QueryRetrieveLevelSTUDY再试一次。C-FIND 这块要记住Conquest 的查询是精确匹配和通配符配合的。你从工具里发PatientName空字符串它不会返回全部记录要用*。这是很多新手第一次测 C-FIND 时最容易翻车的地方。3.3 场景三Worklist 测试工作量清单的完整闭环如果你的设备要做 Worklist 查询比如 DR/超声设备开机后自动去影像服务器拉检查清单Conquest 的TCPPortWorklist就派上用场了。Worklist 不是查“已存在的影像”而是查询“今天安排了哪些检查”。设备端用 C-FIND 到 Worklist SCP查询条件是 Accession Number、Patient ID 或者 Requested Procedure ID。Conquest 的 Worklist 数据来源有两种一种是把预约信息直接写进数据库另一种是通过外接 HL7 接口接收后者需要额外配置。对测试工具来说最直接的验证手段是把一条 DICOM Modality Worklist 记录通过工具直接写进 Conquest 数据库然后用设备端去拉取。Windows 下有一个自带的命令行辅助# 在 Conquest 安装目录找到 dgate.exe 同目录下的 dgate --lx 工具, 用于往数据库里写测试 Worklist dgate --lx C:\testwl\worklist.xml这行命令的意思是让 Conquest 读取一个 XML 定义的患者预约信息写入数据库的 Worklist 表。你需要先构造好 XML 文件里面至少包含ScheduledStationAETitle、PatientID、PatientName、RequestedProcedureID这几个 Tag。写完以后用测试工具向 Worklist 端口 5679 发起 C-FIND能查到这条记录Worklist 验证就闭环了。但这是最容易出问题的一环因为你查不到记录时几乎无法确定是设备端查询参数不对还是数据写入格式不对。我的建议是先查设备端发出来的 C-FIND 请求内容把里面的 Query 条件抄出来再对照 XML 里的值看看是不是 ScheduledStationAETitle 带空格之类的细节差异。4. 避坑与常见问题排查我踩过的 Conquest 测试工具坑4.1 报错 Connection Refused但 Conquest 明明启动了现象你从测试工具里发 C-STORE 请求报 Connection Refused端口不可达但检查 Conquest 进程它确实在运行。原因90% 的情况是你改完 dicom.ini 之后没有重启进程。Conquest 这个工具和大部分服务不太一样它修改端口和 AE Title 后不会自动热加载必须重启 dgate.exe。剩下的 10% 是端口绑定地址问题如果你在 dicom.ini 里写死了绑定 IP而测试工具访问的是另一个 IP就会拒绝。解决先关掉 dgate.exe 进程再重新启动然后去日志确认是否显示端口监听地址。我一般在启动后用 netstat 再看一眼端口占用netstat -an | findstr 5678如果看到 LISTENING 状态说明端口确实在监听这时候再回头检查测试工具里的目标地址到底是不是 127.0.0.1。4.2 文件能发成功但 Data 目录里找不到接收的文件现象测试工具提示 C-STORE 已经成功但你去 RootDirectory 指定的目录下翻没有看到新的子目录和 DICOM 文件。原因Conquest 存储文件时不直接按 RootDirectory 存放而是按 Calling AE Title 再套一层目录。如果你的测试工具 -aec 值写的是CONQUESTSRV而 dgatesop.lst 里定义的接收 AE 是TESTDST数据会被存到名为 CONQUESTSRV 的目录下而不是你以为的 TESTDST。解决很简单去 RootDirectory 下找找有没有跟测试工具 AE Title 同名的文件夹。你不能用“我认为应该在哪”来推测日志里每一条 C-STORE received 后面都会带着存储路径直接看日志最省事。4.3 SCP 能收到文件但 C-FIND 一查就返回空明明数据已经存在了现象你通过 storescu 成功发了一张图进去用 findscu 查询结果一条匹配都没有。原因这里要看查询级别和匹配值。Conquest 的数据库索引是基于 Patient ID、Patient Name、Study Date 这些标准 Tag 的如果你发送的 DICOM 文件里这些 Tag 本身就是空的索引建不起来后面无论你怎么查都是空结果。这就是典型的“脏数据进查不出来”的翻车场景。解决回到源头看那个 dcm 文件是不是自带完整 Patient 信息。用一个命令先确认你要发的文件里面有哪些属性dcmdump -P D:\testdata\ct_slice.dcm | findstr Patient如果发现 PatientName 是空直接从别的数据源重新导出再测。临时的办法是改文件后重新发送但我不建议在测试里用这种歪路子因为查出来的数据和真实场景不一致很容易给你一个假阳性结论。4.4 Worklist 测试时设备能连上但迟迟不返回预约清单现象设备端显示 Worklist 连接成功但查询后返回无记录或者设备直接卡住直到超时。原因第一没有往 Conquest 的 Worklist 表里预填任何数据。Worklist 不像 C-STORE 自动收数据它需要你先写数据进去查询才有返回。第二Worklist 端口和存储端口搞混了设备查 Worklist 应该连 5679连成 5678 端口之后Conquest 拿到的 Mismatch返回空列表是很正常的事情。解决再次核对设备设置里的端口确认指向TCPPortWorklist指定的值。另外用 Worklist 日志来看Conquest 的日志里会记录 C-FIND 请求的整个 DICOM 消息你从中能看到设备端查询时用的ScheduledStationAETitle到底是什么值再回填到 XML 数据里保证两者一致。4.5 测试中途 dgate.exe 突然退出数据库日志报 disk I/O error现象存储测试跑了一段时间dgate.exe 进程自动消失重启后提示数据库文件已损坏。原因这个我遇到过几次大部分是机器的杀毒软件在后台扫描RootDirectory和 Conquest 的 SQLite 数据库写入起了冲突。Conquest 默认把数据库和接收的 DICOM 文件放在同一个目录杀毒软件频繁访问这个目录而 SQLite 写入时文件锁被干扰就会造成异常退出。解决把RootDirectory改成杀毒软件排除目录或者干脆把测试环境放到不装杀毒软件的内部虚拟机里跑。这个操作对于长期压力测试尤其重要别等跑出几十个 G 的数据后才发现进程早就没了。5. 把 Conquest 从手工测试工具变成自动化测试基座5.1 用命令行参数实现半自动化存储收发验证前面的操作都是手工一条条发命令但实际上 Conquest 停掉再用 dgate.exe 重新启动时本身支持命令行参数这为自动化脚本留了空间。如果你在 CI 环境里做每日集成测试可以这样写一个批处理脚本echo off REM 重启 Conquest 并等待端口就绪 taskkill /IM dgate.exe /F timeout /t 3 /nobreak nul start /B D:\Conquest-DICOM-Server\dgate.exe echo 等待 Conquest 启动... for /L %%i in (1,1,30) do ( netstat -an | findstr 5678 nul if not errorlevel 1 ( echo Conquest 已就绪 goto READY ) timeout /t 1 /nobreak nul ) :READY echo 开始发送测试数据... storescu -c CONQUESTSRV127.0.0.1:5678 -aec CONQUESTSRV D:\testdata\batch01\*.dcm从这个脚本里你可以看到两个关键点一是启动了延迟探查机制等端口真正在监听再去发数据避免测试工具连空窗期二是批量发送所有 dcm 文件而不是一个个手工输。对于一天要重复跑几十遍回归的人来说这个自动化能省下大量等待时间。5.2 利用日志文件辅助自动断言Conquest 的日志系统在测试自动化中价值非常高。每一条 C-STORE、C-FIND 记录都写在了 dgate.log 文件里。我之前写过一个简单的自动化校验逻辑发送完成后去 dgate.log 里统计新一轮日志中的C-STORE received行数如果数量和发送的文件数量一致则判定测试通过。这个验证思路绕开了“文件是否真落盘”这个可能被缓存欺骗的检查直接看服务端的业务日志更可靠。5.3 清理测试数据的方法测试做多了Conquest 的数据库会积累大量垃圾数据。如果不清理查询测试会越来越慢还会影响后续测试结果的判定因为旧数据的干扰会让 C-FIND 返回结果里混进来一堆无关记录。我一般用两种方式清理。简单方式是直接在 Conquest 的 Web 界面里选中所有记录删除适用于数据量少的情况。数据量大时我直接把整个数据库文件删掉让它重新初始化再把 Data 目录里的子目录一并清空。需要注意的是删除数据库之前一定要先关掉 dgate.exe否则你删了文件进程打开句柄还在Windows 会报文件占用。从那以后我每次自动化测试跑完都强制走一遍进程检查、数据清理和端口状态确认这三步再开始下一轮测试。这样做下来Conquest 这个测试工具基本没有再因为环境残留的问题给我出过假结果。说到底DICOM 联调这件事比的不是谁的工具多而是谁能在最短时间内复现问题、定位问题。希望这些用法能帮你在下次医院项目联调时少熬几个夜。本文还有配套的精品资源点击获取