尧图网站建设 
简介本资源是面向医疗影像系统开发者、PACS集成工程师及DICOM协议学习者的Conquest DICOM Server测试工具包专用于模拟DICOM SCP服务、验证设备通信、调试工作列表Worklist功能及开展数据匿名化实践。压缩包共含10个核心文件涵盖可执行程序ConquestDICOMServer.exe、DgateServ.exe、控制台启动脚本console.bat、自动化部署批处理aupdate.bat、atestinstallweb.bat、DICOM字典dgate.dic、核心动态库CqDicom.dll、匿名化脚本anonymize_script.cq及7-Zip命令行工具7za.exe完整支撑服务器部署、运行监控、安全合规测试全流程。资源大小22.28MB结构精炼、开箱即用已获718人下载学习。读者可直接部署本地DICOM服务环境快速开展SCP接收测试、Worklist查询验证、患者数据脱敏实操并结合dgate.dic与CqDicom.dll深入理解DICOM协议解析与网关交互机制。1. Conquest DICOM Server 不是“装上就能用”的黑匣子它本质是一个可调试、可观测、可验证的 DICOM 网络服务沙箱很多刚接触医学影像系统的工程师第一反应是下载 ConquestDICOMServer双击Conquest.exe看到控制台弹出几行日志就以为“DICOM Server 跑起来了”。结果一连 PACS 工作站就报 AE Title 不匹配一发 C-STORE 就提示 Association rejected一查 log 文件全是no matching presentation context——不是配置错而是根本没理解它在扮演什么角色。Conquest DICOM Server 的核心价值从来不是“替代生产级 PACS”而是作为本地可控的 DICOM 协议行为观测器 AE Title 拓扑验证器 影像流转路径压力探针。它让你在不依赖医院 PACS 权限、不触碰临床数据的前提下实打实看到 C-ECHO 怎么握手、C-FIND 查询时 SOP Class UID 怎么协商、C-MOVE 的 Move Destination 是如何被解析并触发二级 association 的。适合三类人刚学 DICOM 协议的影像信息科新人、需要对接第三方设备如超声、内镜、AI 推理引擎的集成工程师、以及负责 DICOM 网络故障定位的运维人员。它不解决“怎么存十年影像”但能立刻告诉你“为什么这台新买的 CT 死活连不上”。2. 从零启动一个可验证的 Conquest DICOM Server 实例最小化配置与协议层自检闭环Conquest 的配置看似简单一个dicom.ini但绝大多数翻车都源于“跳过协议层验证直接写业务逻辑”。我们不追求一步到位配成生产环境而是先构建一个能自我证明协议栈通路完整的最小实例。关键在于让 Conquest 同时扮演 Server 和 Client 角色用它自己的工具完成端到端闭环测试。2.1 下载与基础目录结构固化Windows / Linux 通用Conquest 官方提供预编译二进制包非源码编译最新稳定版为v1.5.0d截至 2024 年中。注意不要下载 GitHub 上标为 “Conquest-1.5.0e” 的测试版其 TLS 配置存在已知 handshake timeout 漏洞会导致 C-GET 失败率陡增。解压后你会看到以下核心文件Linux 用户请确认conquest可执行文件有x权限ConquestDICOMServer/ ├── dicom.ini ← 主配置文件必须存在且可写 ├── conquest.exe (Win) / conquest (Linux) ← 主程序 ├── dgate.exe (Win) / dgate (Linux) ← DICOM 网关进程实际处理网络请求 ├── tools/ ← 自带测试工具集重点 │ ├── dcmqrscp ← 模拟 Query/Retrieve SCP用于接收 C-FIND/C-MOVE │ ├── dcmqrscu ← 模拟 Query/Retrieve SCU用于发起查询 │ ├── storescu ← 模拟 Storage SCU用于发送 C-STORE │ └── echoscu ← 最轻量 C-ECHO 测试工具必用 └── logs/ ← 日志默认输出目录需确保进程有写权限提示首次运行前请手动创建logs/目录并确保dicom.ini与conquest位于同一级路径。Conquest 不会自动创建缺失目录静默失败是常见坑点。2.2dicom.ini的最小可行配置只保留 5 行拒绝过度配置新手常犯错误直接拷贝网上“全功能配置”结果因MaxAssociations100与Timeout30冲突导致连接池耗尽。我们从最精简的 5 行开始每行都对应一个协议层能力验证点[CONQUESTSRV1] DicomPort 5678 OurAETitle CONQUESTSERVER RemoteAETitle TESTSCU MoveDestination CONQUESTSERVER说明DicomPort 5678显式指定监听端口避免 Windows 下 1024 以下端口需管理员权限的麻烦OurAETitle CONQUESTSERVER本机对外宣称的 AE Title必须全大写、无空格、≤16 字符DICOM 标准硬性限制RemoteAETitle TESTSCU声明“我默认信任这个 AE Title 发起的请求”这是 C-STORE 接收白名单的起点MoveDestination CONQUESTSERVER当收到 C-MOVE 请求时把目标设为自己即本机存储这是验证 Move 流程是否走通的关键开关[CONQUESTSRV1]是 Section 名Conquest 强制要求存在且必须与可执行文件名中的CONQUESTSRV1一致若你重命名了conquest.exe此处必须同步改。注意此配置下 Conquest不启用数据库即不写入 SQLite 或 PostgreSQL所有接收到的影像临时存于IMAGES/子目录便于快速验证文件落地。生产环境才需开启DBType sqlite。2.3 用echoscu完成首条协议链路验证C-ECHO 是唯一可信的“心跳”启动服务器# Windows conquest.exe # Linux ./conquest观察控制台输出应出现类似Starting Conquest DICOM Server v1.5.0d on port 5678的日志且无ERROR: cannot bind to port报错。此时打开另一个终端执行 C-ECHO 测试这才是真正检验网络层和 AE Title 协商是否成功的动作# Linux/macOSWindows 用户请用 Git Bash 或 WSL ./tools/echoscu -aet CONQUESTSERVER -aec TESTSCU localhost 5678成功返回应为ECHO SUCCESS: 1/1失败典型现象及原因Association Rejected→RemoteAETitle在dicom.ini中未配置为TESTSCU或大小写不一致DICOM 区分大小写Connection refused→conquest进程未运行或防火墙拦截了 5678 端口Windows Defender 默认拦截No response received→echoscu的-aet参数值CONQUESTSERVER与dicom.ini中OurAETitle不完全一致多一个空格、少一个字母都会失败。血泪经验永远先跑通echoscu再碰storescu。C-ECHO 是 DICOM 协议的“TCP ping”它通过了才代表 TCP 层、AE Title、端口、防火墙四者全部对齐。跳过这步直接发图90% 的问题都卡在这里。3. 用storescu发送真实 DICOM 文件并验证落地从协议握手到文件写入的全链路观测C-ECHO 通过只是“通电”而storescu才是“通电后点亮灯泡”。这一步要亲眼看到一张.dcm文件从你的磁盘经 DICOM 协议封装、网络传输、Conquest 解析、最终以原始格式落盘。这是验证 Conquest 是否真正具备 Storage SCP 能力的黄金标准。3.1 准备一张合规的测试 DICOM 文件别用随便截图保存的.dcm必须是符合 DICOM Part 10 标准的文件。推荐两种来源官方测试集从 DICOM Library 下载CT-MONO2-16-ankle.dcm体积小、无隐私、广泛验证自生成用 Python 的pydicom创建最小合法文件代码见下确保SOPClassUID和TransferSyntaxUID符合 Conquest 默认支持列表隐式 VR Little Endian。# generate_test_dcm.py import pydicom from pydicom.dataset import Dataset, FileDataset from pydicom.uid import ExplicitVRLittleEndian, ImplicitVRLittleEndian file_meta Dataset() file_meta.MediaStorageSOPClassUID 1.2.840.10008.5.1.4.1.1.2 # CT Image Storage file_meta.MediaStorageSOPInstanceUID 1.2.3.4.5.6.7.8.9.0.1.2.3.4.5.6.7.8.9.1 file_meta.ImplementationClassUID 1.2.3.4.5.6.7.8.9.0.1.2.3.4.5.6.7.8.9.2 file_meta.TransferSyntaxUID ImplicitVRLittleEndian # ← 关键Conquest 默认只接受此语法 ds FileDataset(test_ct.dcm, {}, file_metafile_meta, preambleb\0 * 128) ds.is_implicit_VR True ds.is_little_endian True ds.PatientName Test^Patient ds.StudyInstanceUID 1.2.3.4.5.6.7.8.9.0.1.2.3.4.5.6.7.8.9.3 ds.SeriesInstanceUID 1.2.3.4.5.6.7.8.9.0.1.2.3.4.5.6.7.8.9.4 ds.SOPInstanceUID 1.2.3.4.5.6.7.8.9.0.1.2.3.4.5.6.7.8.9.5 ds.save_as(test_ct.dcm) print(Generated test_ct.dcm with Implicit VR Little Endian)运行后生成test_ct.dcm用dcmdump test_ct.dcm | head -n 5验证输出含xfer: 1.2.840.10008.1.2即 Implicit VR Little Endian。3.2 执行 C-STORE 并实时监控日志与文件系统在 Conquest 运行状态下执行./tools/storescu -aet CONQUESTSERVER -aec TESTSCU localhost 5678 test_ct.dcm观察两个地方Conquest 控制台应打印类似C-STORE: Received CT Image Storage from TESTSCU, instance 1.2.3.4.5.6.7.8.9.0.1.2.3.4.5.6.7.8.9.5文件系统检查IMAGES/目录下是否生成了IMAGES/1.2.3.4.5.6.7.8.9.0.1.2.3.4.5.6.7.8.9.5即 SOP Instance UID 命名的文件。逻辑说明storescu的-aet是你本地 SCU 声称的 AE Title必须与dicom.ini中RemoteAETitle一致-aec是你要连接的目标 SCP 的 AE Title必须与OurAETitle一致。参数顺序不能颠倒否则报No presentation context for CT Image Storage—— 这是因为 Conquest 默认只 advertise CT、MR、US 等常用 SOP Class不支持你随意指定。3.3 验证落地文件的 DICOM 合规性用dcmdump确认“原样保存”进入IMAGES/目录对刚生成的文件执行dcmdump IMAGES/1.2.3.4.5.6.7.8.9.0.1.2.3.4.5.6.7.8.9.5 | grep -E (SOPClassUID|SOPInstanceUID|TransferSyntaxUID|PatientName)输出应与原始test_ct.dcm完全一致。如果TransferSyntaxUID变成了1.2.840.10008.1.2.1Explicit VR说明 Conquest 在存储时做了语法转换 —— 这是配置项ConvertToLittleEndian yes导致的属于正常行为但需知晓其存在。4. Conquest DICOM Server 常见问题排查5 条真实踩坑记录与根因修复Conquest 的日志logs/conquest.log是唯一真相源。以下问题均来自一线集成现场按发生频率排序每条包含可复现现象、底层协议原因、精准修复动作。4.1 现象C-STORE 成功但IMAGES/下无文件conquest.log中有ERROR: cannot create directory原因Conquest 尝试在IMAGES/下按 StudyInstanceUID 创建子目录如IMAGES/1.2.3.../但当前用户对IMAGES/目录无写权限或路径含中文/空格Windows 下尤其敏感。解决Linuxchmod 755 IMAGES/ chown $USER:$USER IMAGES/Windows右键IMAGES/→ 属性 → 安全 → 编辑 → 给当前用户“完全控制”权限强制规避在dicom.ini中添加ImageRoot C:/conquest_images绝对路径且确保该路径纯英文、无空格、已手动创建。4.2 现象echoscu返回Association Rejected: No reason given但conquest.log显示Rejecting association: no matching presentation context原因echoscu请求的SOP Class默认为 Verification SOP Class未被 Conquest advertise。Conquest 默认只 advertise 存储类CT、MR 等不 advertise Verification。解决在dicom.ini中显式添加[CONQUESTSRV1] # ... 其他配置 VerificationSOPClass 1.2.840.10008.1.1然后重启 Conquest。此行告诉 Conquest“我也支持 Verification SOP Class”C-ECHO 才能协商成功。4.3 现象storescu发送多张图时部分失败并报Association Abortedconquest.log有Too many associations原因Conquest 默认MaxAssociations 1单连接单请求而storescu默认并发发送尤其传多张图时。当第二张图尝试建立新 association 时被拒绝。解决在dicom.ini中增加[CONQUESTSRV1] # ... 其他配置 MaxAssociations 10 Timeout 60Timeout必须同步增大否则高并发下 association 未及时释放仍会触发上限。4.4 现象从 PACS 收到 C-MOVE 请求Conquest 日志显示C-MOVE: destination CONQUESTSERVER not found原因MoveDestination CONQUESTSERVER配置正确但 Conquest 未启动dgate进程它才是实际处理 C-MOVE 的组件。conquest.exe只是主控dgate才是网络工作线程。解决Windows任务管理器中确认dgate.exe进程存在Linuxps aux | grep dgate若不存在手动启动./dgate 后台运行或修改启动脚本确保dgate与conquest同时拉起。4.5 现象dcmqrscu查询返回0 results但确认 PACS 上有该患者conquest.log无任何查询相关日志原因dcmqrscu的-kkey参数未正确传递 PatientID 或 StudyDate。Conquest 严格按 key 匹配空值或格式错误如StudyDate20240101写成2024-01-01会导致无结果。解决用dcmdump查看 PACS 返回的原始 Study 数据严格复制其PatientID和StudyDate格式./tools/dcmqrscu -aet CONQUESTSERVER -aec REMOTEPACS ip 104 \ -k PatientID123456 \ -k StudyDate20240101 \ -k ModalitiesInStudyCT注意-k参数必须成对出现且两侧不能有空格这是 DICOM 查询语法铁律。5. 进阶技巧用 Conquest 模拟真实 PACS 故障场景提前暴露下游系统脆弱点Conquest 的最大隐藏价值不是“它能做什么”而是“它能故意不做什么”。在真实项目交付前我一定会用它做三类破坏性测试因为 80% 的下游系统尤其是国产 AI 推理引擎、第三方阅片平台在异常网络条件下会静默崩溃而 Conquest 是唯一能低成本、可重复构造这些异常的工具。5.1 构造“慢响应 PACS”验证下游超时机制是否健壮很多系统硬编码timeout5s但真实 PACS 在负载高时 C-FIND 可能耗时 15s。Conquest 可通过DelayQueryResponse模拟[CONQUESTSRV1] # ... 其他配置 DelayQueryResponse 12000 ; 单位毫秒此处设为 12 秒然后用dcmqrscu发起查询观察下游是否正确抛出TimeoutException并重试还是直接卡死、内存泄漏、进程僵死如果是后者立刻推动下游团队修复——这比上线后半夜被报警叫醒成本低百倍。5.2 构造“断连 PACS”测试下游的重连与状态恢复能力Conquest 支持在特定条件下主动断开 association。在dicom.ini中加入[CONQUESTSRV1] # ... 其他配置 DropAssociationAfter 3 ; 第 3 次 C-STORE 后主动断连启动后用storescu连续发 5 张图。第 3 张成功后 connection 断开第 4、5 张应触发下游的重连逻辑。检查其日志是否出现Reconnecting to CONQUESTSERVER...而非直接报错退出。5.3 构造“脏数据 PACS”暴露下游 DICOM 解析库的鲁棒性缺陷真实 PACS 常返回TransferSyntaxUID错误、PixelData缺失、SOPInstanceUID重复等脏数据。Conquest 可通过ModifyOnStore注入[CONQUESTSRV1] # ... 其他配置 ModifyOnStore yes ModifyScript modify_dcm.lua编写modify_dcm.luaConquest 内置 Lua 支持-- modify_dcm.lua故意损坏 TransferSyntaxUID if ds then ds.TransferSyntaxUID 1.2.3.4.5.6.7.8.9.999 -- 无效 UID end当下游系统加载这张“脏图”时健壮的库如pydicom2.3会捕获InvalidDicomError并跳过脆弱的库某些 C 封装的 SDK直接 segfault。这就是上线前必须掐掉的雷。我的习惯是每次对接新设备或新软件先用 Conquest 跑完这三类测试把它们的异常处理日志截图存档。合同里写的“7×24 小时可用性”底气就来自这些凌晨三点构造出来的失败场景。希望帮到你。本文还有配套的精品资源点击获取 Conquest DICOM Server 配置与协议验证实战指南
简介本资源是面向医疗影像系统开发者、PACS集成工程师及DICOM协议学习者的Conquest DICOM Server测试工具包专用于模拟DICOM SCP服务、验证设备通信、调试工作列表Worklist功能及开展数据匿名化实践。压缩包共含10个核心文件涵盖可执行程序ConquestDICOMServer.exe、DgateServ.exe、控制台启动脚本console.bat、自动化部署批处理aupdate.bat、atestinstallweb.bat、DICOM字典dgate.dic、核心动态库CqDicom.dll、匿名化脚本anonymize_script.cq及7-Zip命令行工具7za.exe完整支撑服务器部署、运行监控、安全合规测试全流程。资源大小22.28MB结构精炼、开箱即用已获718人下载学习。读者可直接部署本地DICOM服务环境快速开展SCP接收测试、Worklist查询验证、患者数据脱敏实操并结合dgate.dic与CqDicom.dll深入理解DICOM协议解析与网关交互机制。1. Conquest DICOM Server 不是“装上就能用”的黑匣子它本质是一个可调试、可观测、可验证的 DICOM 网络服务沙箱很多刚接触医学影像系统的工程师第一反应是下载 ConquestDICOMServer双击Conquest.exe看到控制台弹出几行日志就以为“DICOM Server 跑起来了”。结果一连 PACS 工作站就报 AE Title 不匹配一发 C-STORE 就提示 Association rejected一查 log 文件全是no matching presentation context——不是配置错而是根本没理解它在扮演什么角色。Conquest DICOM Server 的核心价值从来不是“替代生产级 PACS”而是作为本地可控的 DICOM 协议行为观测器 AE Title 拓扑验证器 影像流转路径压力探针。它让你在不依赖医院 PACS 权限、不触碰临床数据的前提下实打实看到 C-ECHO 怎么握手、C-FIND 查询时 SOP Class UID 怎么协商、C-MOVE 的 Move Destination 是如何被解析并触发二级 association 的。适合三类人刚学 DICOM 协议的影像信息科新人、需要对接第三方设备如超声、内镜、AI 推理引擎的集成工程师、以及负责 DICOM 网络故障定位的运维人员。它不解决“怎么存十年影像”但能立刻告诉你“为什么这台新买的 CT 死活连不上”。2. 从零启动一个可验证的 Conquest DICOM Server 实例最小化配置与协议层自检闭环Conquest 的配置看似简单一个dicom.ini但绝大多数翻车都源于“跳过协议层验证直接写业务逻辑”。我们不追求一步到位配成生产环境而是先构建一个能自我证明协议栈通路完整的最小实例。关键在于让 Conquest 同时扮演 Server 和 Client 角色用它自己的工具完成端到端闭环测试。2.1 下载与基础目录结构固化Windows / Linux 通用Conquest 官方提供预编译二进制包非源码编译最新稳定版为v1.5.0d截至 2024 年中。注意不要下载 GitHub 上标为 “Conquest-1.5.0e” 的测试版其 TLS 配置存在已知 handshake timeout 漏洞会导致 C-GET 失败率陡增。解压后你会看到以下核心文件Linux 用户请确认conquest可执行文件有x权限ConquestDICOMServer/ ├── dicom.ini ← 主配置文件必须存在且可写 ├── conquest.exe (Win) / conquest (Linux) ← 主程序 ├── dgate.exe (Win) / dgate (Linux) ← DICOM 网关进程实际处理网络请求 ├── tools/ ← 自带测试工具集重点 │ ├── dcmqrscp ← 模拟 Query/Retrieve SCP用于接收 C-FIND/C-MOVE │ ├── dcmqrscu ← 模拟 Query/Retrieve SCU用于发起查询 │ ├── storescu ← 模拟 Storage SCU用于发送 C-STORE │ └── echoscu ← 最轻量 C-ECHO 测试工具必用 └── logs/ ← 日志默认输出目录需确保进程有写权限提示首次运行前请手动创建logs/目录并确保dicom.ini与conquest位于同一级路径。Conquest 不会自动创建缺失目录静默失败是常见坑点。2.2dicom.ini的最小可行配置只保留 5 行拒绝过度配置新手常犯错误直接拷贝网上“全功能配置”结果因MaxAssociations100与Timeout30冲突导致连接池耗尽。我们从最精简的 5 行开始每行都对应一个协议层能力验证点[CONQUESTSRV1] DicomPort 5678 OurAETitle CONQUESTSERVER RemoteAETitle TESTSCU MoveDestination CONQUESTSERVER说明DicomPort 5678显式指定监听端口避免 Windows 下 1024 以下端口需管理员权限的麻烦OurAETitle CONQUESTSERVER本机对外宣称的 AE Title必须全大写、无空格、≤16 字符DICOM 标准硬性限制RemoteAETitle TESTSCU声明“我默认信任这个 AE Title 发起的请求”这是 C-STORE 接收白名单的起点MoveDestination CONQUESTSERVER当收到 C-MOVE 请求时把目标设为自己即本机存储这是验证 Move 流程是否走通的关键开关[CONQUESTSRV1]是 Section 名Conquest 强制要求存在且必须与可执行文件名中的CONQUESTSRV1一致若你重命名了conquest.exe此处必须同步改。注意此配置下 Conquest不启用数据库即不写入 SQLite 或 PostgreSQL所有接收到的影像临时存于IMAGES/子目录便于快速验证文件落地。生产环境才需开启DBType sqlite。2.3 用echoscu完成首条协议链路验证C-ECHO 是唯一可信的“心跳”启动服务器# Windows conquest.exe # Linux ./conquest观察控制台输出应出现类似Starting Conquest DICOM Server v1.5.0d on port 5678的日志且无ERROR: cannot bind to port报错。此时打开另一个终端执行 C-ECHO 测试这才是真正检验网络层和 AE Title 协商是否成功的动作# Linux/macOSWindows 用户请用 Git Bash 或 WSL ./tools/echoscu -aet CONQUESTSERVER -aec TESTSCU localhost 5678成功返回应为ECHO SUCCESS: 1/1失败典型现象及原因Association Rejected→RemoteAETitle在dicom.ini中未配置为TESTSCU或大小写不一致DICOM 区分大小写Connection refused→conquest进程未运行或防火墙拦截了 5678 端口Windows Defender 默认拦截No response received→echoscu的-aet参数值CONQUESTSERVER与dicom.ini中OurAETitle不完全一致多一个空格、少一个字母都会失败。血泪经验永远先跑通echoscu再碰storescu。C-ECHO 是 DICOM 协议的“TCP ping”它通过了才代表 TCP 层、AE Title、端口、防火墙四者全部对齐。跳过这步直接发图90% 的问题都卡在这里。3. 用storescu发送真实 DICOM 文件并验证落地从协议握手到文件写入的全链路观测C-ECHO 通过只是“通电”而storescu才是“通电后点亮灯泡”。这一步要亲眼看到一张.dcm文件从你的磁盘经 DICOM 协议封装、网络传输、Conquest 解析、最终以原始格式落盘。这是验证 Conquest 是否真正具备 Storage SCP 能力的黄金标准。3.1 准备一张合规的测试 DICOM 文件别用随便截图保存的.dcm必须是符合 DICOM Part 10 标准的文件。推荐两种来源官方测试集从 DICOM Library 下载CT-MONO2-16-ankle.dcm体积小、无隐私、广泛验证自生成用 Python 的pydicom创建最小合法文件代码见下确保SOPClassUID和TransferSyntaxUID符合 Conquest 默认支持列表隐式 VR Little Endian。# generate_test_dcm.py import pydicom from pydicom.dataset import Dataset, FileDataset from pydicom.uid import ExplicitVRLittleEndian, ImplicitVRLittleEndian file_meta Dataset() file_meta.MediaStorageSOPClassUID 1.2.840.10008.5.1.4.1.1.2 # CT Image Storage file_meta.MediaStorageSOPInstanceUID 1.2.3.4.5.6.7.8.9.0.1.2.3.4.5.6.7.8.9.1 file_meta.ImplementationClassUID 1.2.3.4.5.6.7.8.9.0.1.2.3.4.5.6.7.8.9.2 file_meta.TransferSyntaxUID ImplicitVRLittleEndian # ← 关键Conquest 默认只接受此语法 ds FileDataset(test_ct.dcm, {}, file_metafile_meta, preambleb\0 * 128) ds.is_implicit_VR True ds.is_little_endian True ds.PatientName Test^Patient ds.StudyInstanceUID 1.2.3.4.5.6.7.8.9.0.1.2.3.4.5.6.7.8.9.3 ds.SeriesInstanceUID 1.2.3.4.5.6.7.8.9.0.1.2.3.4.5.6.7.8.9.4 ds.SOPInstanceUID 1.2.3.4.5.6.7.8.9.0.1.2.3.4.5.6.7.8.9.5 ds.save_as(test_ct.dcm) print(Generated test_ct.dcm with Implicit VR Little Endian)运行后生成test_ct.dcm用dcmdump test_ct.dcm | head -n 5验证输出含xfer: 1.2.840.10008.1.2即 Implicit VR Little Endian。3.2 执行 C-STORE 并实时监控日志与文件系统在 Conquest 运行状态下执行./tools/storescu -aet CONQUESTSERVER -aec TESTSCU localhost 5678 test_ct.dcm观察两个地方Conquest 控制台应打印类似C-STORE: Received CT Image Storage from TESTSCU, instance 1.2.3.4.5.6.7.8.9.0.1.2.3.4.5.6.7.8.9.5文件系统检查IMAGES/目录下是否生成了IMAGES/1.2.3.4.5.6.7.8.9.0.1.2.3.4.5.6.7.8.9.5即 SOP Instance UID 命名的文件。逻辑说明storescu的-aet是你本地 SCU 声称的 AE Title必须与dicom.ini中RemoteAETitle一致-aec是你要连接的目标 SCP 的 AE Title必须与OurAETitle一致。参数顺序不能颠倒否则报No presentation context for CT Image Storage—— 这是因为 Conquest 默认只 advertise CT、MR、US 等常用 SOP Class不支持你随意指定。3.3 验证落地文件的 DICOM 合规性用dcmdump确认“原样保存”进入IMAGES/目录对刚生成的文件执行dcmdump IMAGES/1.2.3.4.5.6.7.8.9.0.1.2.3.4.5.6.7.8.9.5 | grep -E (SOPClassUID|SOPInstanceUID|TransferSyntaxUID|PatientName)输出应与原始test_ct.dcm完全一致。如果TransferSyntaxUID变成了1.2.840.10008.1.2.1Explicit VR说明 Conquest 在存储时做了语法转换 —— 这是配置项ConvertToLittleEndian yes导致的属于正常行为但需知晓其存在。4. Conquest DICOM Server 常见问题排查5 条真实踩坑记录与根因修复Conquest 的日志logs/conquest.log是唯一真相源。以下问题均来自一线集成现场按发生频率排序每条包含可复现现象、底层协议原因、精准修复动作。4.1 现象C-STORE 成功但IMAGES/下无文件conquest.log中有ERROR: cannot create directory原因Conquest 尝试在IMAGES/下按 StudyInstanceUID 创建子目录如IMAGES/1.2.3.../但当前用户对IMAGES/目录无写权限或路径含中文/空格Windows 下尤其敏感。解决Linuxchmod 755 IMAGES/ chown $USER:$USER IMAGES/Windows右键IMAGES/→ 属性 → 安全 → 编辑 → 给当前用户“完全控制”权限强制规避在dicom.ini中添加ImageRoot C:/conquest_images绝对路径且确保该路径纯英文、无空格、已手动创建。4.2 现象echoscu返回Association Rejected: No reason given但conquest.log显示Rejecting association: no matching presentation context原因echoscu请求的SOP Class默认为 Verification SOP Class未被 Conquest advertise。Conquest 默认只 advertise 存储类CT、MR 等不 advertise Verification。解决在dicom.ini中显式添加[CONQUESTSRV1] # ... 其他配置 VerificationSOPClass 1.2.840.10008.1.1然后重启 Conquest。此行告诉 Conquest“我也支持 Verification SOP Class”C-ECHO 才能协商成功。4.3 现象storescu发送多张图时部分失败并报Association Abortedconquest.log有Too many associations原因Conquest 默认MaxAssociations 1单连接单请求而storescu默认并发发送尤其传多张图时。当第二张图尝试建立新 association 时被拒绝。解决在dicom.ini中增加[CONQUESTSRV1] # ... 其他配置 MaxAssociations 10 Timeout 60Timeout必须同步增大否则高并发下 association 未及时释放仍会触发上限。4.4 现象从 PACS 收到 C-MOVE 请求Conquest 日志显示C-MOVE: destination CONQUESTSERVER not found原因MoveDestination CONQUESTSERVER配置正确但 Conquest 未启动dgate进程它才是实际处理 C-MOVE 的组件。conquest.exe只是主控dgate才是网络工作线程。解决Windows任务管理器中确认dgate.exe进程存在Linuxps aux | grep dgate若不存在手动启动./dgate 后台运行或修改启动脚本确保dgate与conquest同时拉起。4.5 现象dcmqrscu查询返回0 results但确认 PACS 上有该患者conquest.log无任何查询相关日志原因dcmqrscu的-kkey参数未正确传递 PatientID 或 StudyDate。Conquest 严格按 key 匹配空值或格式错误如StudyDate20240101写成2024-01-01会导致无结果。解决用dcmdump查看 PACS 返回的原始 Study 数据严格复制其PatientID和StudyDate格式./tools/dcmqrscu -aet CONQUESTSERVER -aec REMOTEPACS ip 104 \ -k PatientID123456 \ -k StudyDate20240101 \ -k ModalitiesInStudyCT注意-k参数必须成对出现且两侧不能有空格这是 DICOM 查询语法铁律。5. 进阶技巧用 Conquest 模拟真实 PACS 故障场景提前暴露下游系统脆弱点Conquest 的最大隐藏价值不是“它能做什么”而是“它能故意不做什么”。在真实项目交付前我一定会用它做三类破坏性测试因为 80% 的下游系统尤其是国产 AI 推理引擎、第三方阅片平台在异常网络条件下会静默崩溃而 Conquest 是唯一能低成本、可重复构造这些异常的工具。5.1 构造“慢响应 PACS”验证下游超时机制是否健壮很多系统硬编码timeout5s但真实 PACS 在负载高时 C-FIND 可能耗时 15s。Conquest 可通过DelayQueryResponse模拟[CONQUESTSRV1] # ... 其他配置 DelayQueryResponse 12000 ; 单位毫秒此处设为 12 秒然后用dcmqrscu发起查询观察下游是否正确抛出TimeoutException并重试还是直接卡死、内存泄漏、进程僵死如果是后者立刻推动下游团队修复——这比上线后半夜被报警叫醒成本低百倍。5.2 构造“断连 PACS”测试下游的重连与状态恢复能力Conquest 支持在特定条件下主动断开 association。在dicom.ini中加入[CONQUESTSRV1] # ... 其他配置 DropAssociationAfter 3 ; 第 3 次 C-STORE 后主动断连启动后用storescu连续发 5 张图。第 3 张成功后 connection 断开第 4、5 张应触发下游的重连逻辑。检查其日志是否出现Reconnecting to CONQUESTSERVER...而非直接报错退出。5.3 构造“脏数据 PACS”暴露下游 DICOM 解析库的鲁棒性缺陷真实 PACS 常返回TransferSyntaxUID错误、PixelData缺失、SOPInstanceUID重复等脏数据。Conquest 可通过ModifyOnStore注入[CONQUESTSRV1] # ... 其他配置 ModifyOnStore yes ModifyScript modify_dcm.lua编写modify_dcm.luaConquest 内置 Lua 支持-- modify_dcm.lua故意损坏 TransferSyntaxUID if ds then ds.TransferSyntaxUID 1.2.3.4.5.6.7.8.9.999 -- 无效 UID end当下游系统加载这张“脏图”时健壮的库如pydicom2.3会捕获InvalidDicomError并跳过脆弱的库某些 C 封装的 SDK直接 segfault。这就是上线前必须掐掉的雷。我的习惯是每次对接新设备或新软件先用 Conquest 跑完这三类测试把它们的异常处理日志截图存档。合同里写的“7×24 小时可用性”底气就来自这些凌晨三点构造出来的失败场景。希望帮到你。本文还有配套的精品资源点击获取