DICOM医学图像处理:全面分析DICOM3.0标准中的通讯服务模块

背景:

        最近在做关于PACS终端与RIS系统之间进行worklist查询的相关调试工作,因此又重新对DICOM3.0标准中关于网络传输的部分进行了阅读,在此将本周的工作进行一下总结,以加深对DICOM3.0标准的认识,从底层更加清晰的了解worklist查询、C-STORE、C-FIND等各种服务。

要点:

1)名词简称

        该部分中会出现很多的常见名词的缩写,因此为了更好的理解其含义,先给出各个名词所对应的全称,这里没有用中文进行翻译原因有二,其一是因为英文很简单,而且表意很清楚,其二是因为目前DICOM3.0标准还没有官方的中文版,所以我也不敢造次进行翻译。  

        常见的简称及其全称如下:

ACSE:Association Control Service Element

AE:Application Entity

CMIS:Common Management Information Service

CMISE:Common Management Information Serivce Element

DICOM:Digital Imaging and Communications in Medicine

DIMSE:DICOM Messsage Service Element

DIMSE-C:DICOM Message Service Element-Composite

DIMSE-N:DICOM Message Service Element-Normalized

HL7:Health Level 7

OSI:Open Systems Interconnection

PDU:Protocol Data Unit

PDV:Protocol Data Value

SOP:Service Object Pair

TCP/IP:Transmission Control Protocol/Internet Protocol

DUL:Dicom Upper Layers

2)DICOM网络通信模型

        DICOM网络服务是建立在传统OSI七层模型之上的端到端的通讯服务,包括服务端和客户端。其基本的通讯服务模型如下图所示:

        与传统的OSI七层模型对比一下,可以看出DICOM3.0标准中所描述的DICOM网络通讯服务所包含的并非是OSI七层中简单的某一层,而是对从传输层/网络层向上的各层都分别进行了详细的描述和定义。下一节我会针对DICOM3.0标准的几个部分分别来详细介绍一下DICOM网络通讯服务的各个层,或者说各个模块。

3)DICOM3.0标准对DICOM网络通信的描述

         下面直接给出DICOM3.0标准中的几个附图,首先从整体上对DICOM3.0标准有一个把握,如下所示:

        从右图可以看出DICOM通讯模型是建立在TCP/IP层之上的,最底层的是DICOM Upper Layer Protocol,该部分主要负责与TCP相对接,在此之上就是DICOM3.0标准给出的DICOM通讯模型,与上一节中的OSI七层模型相比可知,DICOM通讯模型涵盖了会话层(Session)、表示层(Presentation)和应用层(Application)会话层(Session)主要负责为通讯双方制定通信方式,并创建、注销会话。该部分对应的是DICOM3.0标准中的第8部分,即ACSE(Association Control Service Element)表示层(Presentation)能为不同的客户端提供数据和信息的语法转换内码,使系统能解读成正确的数据。同时,也能提供压缩解压、加密解密。与之相对应的是DIMSE服务,即DICOM3.0标准的第7部分,该部分给出了众多服务(C-STORE、C-FIND、C-GET、C-MOVE、C-ECHO)的编码格式。

        左图是右图中DICOM Upper Layer Service以上服务内部结构的细化,从中也可以看出与之相对应的DICOM3.0的各个部分。下面给出一个更全面的结构示意图:

        上图中在简单的对DICOM3.0标准中的截图进行组合后,也给出了DCMTK源码库中与各个层相对应模块的名称,从名称简写上也可以看出整个DICOM网络通信是如何完成的。其中与DICOM通信服务相关的几个文件有dimse.h、assoc.h、dul.h(顺序按照OSI七层模型从上到下),其中dimse.h文件中给出了DIMSE层的各种信息的结构体(如T_DIMSE_Message、T_DIMSE_C_EchoRQ、T_DIMSE_C_EchoRSP等)以及各种服务的函数(如DIMSE_echoUser、DIMSE_sendEchoResponse、DIMSE_storeUser、DIMSE_storeProvider等)。dimse.h文件中定义的各类服务函数,都会有一个关于网络连接的参数T_ASC_Association *assoc,如下图:

        从参数类型就可以猜出该类型定义在assoc.h文件中(如下图),assoc.h文件的备注指出该文件为DICOM网络应用提供了连接管理(association management),文件中定义的所有结构都是为了支持连接建立的(如表示上下文、抽象语义、传输语义、最大PDU长度等等)。同时文件中也指出了其中的函数利用的是DICOM Upper Layer的服务来实现的。而T_ASC_Association结构就代表一次活动链接。

        既然assoc.h头文件已经指明了该模块是在Dicom Upper Layer基础上实现的,因此可以猜到链接的各类函数的源代码实现中必定调用了dul.h文件中的函数,此处已ASC_initializeNetwork函数为例,如下图所示,该函数内部直接调用了DUL_InitializeNetwork函数,想必如果按照上面我们的分析,继续追踪下去的话,一定就会出现TCP层的函数,即我们常用的套接字socket函数(如果读者喜欢可自行查看dul.h中函数的源代码,例如DUL_initializeNetwork函数中通过initializeNetworkTCP函数直接使用了socket的常见操作函数,如socket建立套接字函数setsockopt设置套接字函数bind绑定套接字函数 等等)

        至此通过查看DCMTK开源库源码,使得我们对上面的整体结构图有了更直观的认识,从而对DICOM3.0标准也有了更好的了解。

实际工程测试:

        在查看完DCMTK源码设计后,为了更真实的感受和掌握DICOM网络通讯的过程,此处以常见的PACS与RIS系统之间的worklist查询服务和DICOM的C-STORE图像存储服务为例,对服务端与客户端通讯的真实数据包进行抓取分析,从而更好、更直观的认识DICOM通讯服务。

1)测试工具:

        为了仿真DICOM的通讯模型,自然需要构造服务和客户两端,DCMTK开源库的bin中给我们提供了很好的工具。此处选用的工具分两类

服务端客户端
wlmscpfs.exefindscu.exe
storescp.exestorescu.exe

        另外为了与DICOM3.0中对DICOM网络服务的各种结构(如DIMSE、PDU)和指令(A-ASSOCIATION、C-FIND)的详细介绍进行对比,将本地模拟的服务端与客户端的通讯数据包进行了抓取,利用的本地回路抓包工具室RawCap.exe,将抓取的数据包存成pcap文件,然后利用Wireshark工具强大的统计分析功能进行直观的对比分析。

本地回路抓包工具RawCap.exe
数据包分析查看工具Wireshark

2)worklist查询服务的通讯过程分析

第一步,启动本地回路抓包工具,RawCap.exe 5 dumpfile.pcap(可以利用RawCap.exe -h来查看RawCap.exe工具的使用)

第二步,启动worklist服务端程序,wlmscpfs.exe –d 104 –dfp wlistdb >worklist-server.txt(利用shell的重定向将调试信息保存到worklist-server.txt中)

第三步,启动workist查询客户端程序,findscu.exe –d 127.0.0.1 104 testqry.wl –aec OFFIS >worklist-client.txt(testqry.wl文件是上一篇博文http://blog.csdn.net/zssureqh/article/details/38775315中测试使用的,其中设定了PatientID=123456)

然后等待整个通讯过程截止,RawCap.exe会得到一个名为dumpfile.pcap的数据包文件,另外也会得到服务端和客户端的两个调试信息文本文件,分别是worklist-server.txt和worklist-client.txt。

        注意有些时候利用重定向将调试信息输出到文本文件会发生中断错误,因此也可以直接将结果显示到console窗口,然后将其手动拷贝存储到相应的文件中。我在本机的操作如下图所示:

        至此整个数据抓取和信息记录的任务就完成了,接下来就是我们的分析阶段了。

        首先直接使用文本编辑器打开两个调试信息文本文件,我在本地的结果如下图所示:

        调试信息中也基本给出了我们想要的数据,例如A-ASSOCIATE-AC、A-ASSOCIATE-RQ、DIMSE MESSAGE等。上图中的边缘附件的黄色箭头示意的是两端(即两个DICOM AE)进行真实交流时数据流流过的各层的顺序,这与OSI中的类似。途中红色矩形框表示的1、2、3、4等是DICOM协议层(association)的交互顺序,从数据中可以看出association层对一些底层结构(如PDU、PDV)进行了约定;蓝色框标示的是DIMSE协议层,该层主要定义的是DICOM的各种服务,如C-STORE、C-FIND等。

        然后,我们利用Wireshark工具打开dumpfile.pcap数据包文件。

        利用Protocol的筛选,我们只观察DICOM协议的相关数据包(有兴趣的可以将整个过程的所有数据包分析一下)。如上图所示,可以清晰的看到findscu客户端与worklist服务端的交互过程。双击其中的第一条交互信息,如下图所示:

        此图中可以清晰的看到完整的association层的数据包,如图总红色圆圈所示,01类型代表的正是ASSOCIATE-RQ PDU 类型,而随后紧跟着的就是DICOM3.0第8部分Table 9-11中约定的各个字段。

3)C-STORE服务提供者(SCP)、使用者(SCU)通讯过程分析

        该部分的测试流程与2)中worklist查询的测试流程是相同的。

第一步,启动本地回路抓包工具,RawCap.exe 5 dumpfile.pcap(可以利用RawCap.exe -h来查看RawCap.exe工具的使用)

第二步,启动storescp服务端程序,storescp.exe -d 104 -aet OFFIS >storescp.txt(利用shell的重定向将调试信息保存到storescp.txt中)

第三步,启动storescu请求客户端程序,storescu.exe –d 127.0.0.1 104 –f test.dcm –aec OFFIS >storescu.txt(test.dcm是一个标准的dcm文件)

然后等待整个通讯过程截止,RawCap.exe会得到一个名为dumpfile.pcap的数据包文件,另外也会得到服务端和客户端的两个调试信息文本文件,分别是storescp.txt和storescu.txt。

        分析过程也与2)中相同,此处就不细说了,只给出结果图。

【备注】:

        正是利用上述工具,解决了上一篇博文利用fo-dicom发送C-Find查询Worklist失败的问题。具体的排查过程就是先利用DCMTK开源工具包进行模拟,然后利用工具抓取数据包分析结果,在确定无误的情况下,转而转到fo-dicom环境下,同样抓取数据包分析错误原因。然后单步调试到fo-dicom开源库的C-FInd发起函数CreateWorklistQuery中,确定了问题出现的原因。具体的链接可以参见我的Github:https://github.com/zssure-thu/fo-dicom。该分支中我暂时记录了此次修改的代码,等待后续进一步确认。


博文中的具体文件已经上传到CSDN,链接为:http://download.csdn.net/detail/zssureqh/7870789


后续专栏文章预告:

1)storescp.exe与sotrescu.exe的源码剖析:学习C-STORE请求

2)Dcmtk与fo-dicom保存文件的不同设计模式:单线程VS多线程

3)wlmscpfs.exe与findscu.exe的源码剖析:学习C-FIND请求

作者:zssure@163.com

时间:2014-09-06 0:55

zssure CSDN认证博客专家 视觉/OpenCV Python PyTorch
从不抽烟,应酬时喝酒,早睡早起。一个喜欢折腾自己的人,一个连续创业的劳动者,做过很多事,想过很多事,看破不说破是自省,看破也说破是成长。
相关推荐
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
实付 99.00元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值