一种基于信号的仪器驱动实现方法
【技术领域】
[0001]本发明属于测试测量(Test and Measurement, T&M)领域，具体来说是一种构建自动测试系统(Automatic Test System, ATS)的仪器驱动程序的实现方法。
【背景技术】
[0002]为了避免手动操作的低效，ATS需要对测试仪器进行程序控制，这就需要仪器驱动程序作为系统软件与具体仪器之间的中介，执行控制命令、传递状态参数并返回结果数据。
[0003]随着被测设备或系统(Unit Under Test, UUT)越来越复杂，待获取的测试参数和要执行的测试过程越来越繁多，使用的测试仪器也就相应地越来越复杂和繁多，因此越来越要求ATS具有测试仪器可互换、测试软件可移植、测试系统可扩展、系统组件可复用、测试程序集互操作等各种特性。这些要求中，仪器驱动程序与测试仪器可互换特性直接相关，并对其它特性有重要影响。
[0004]为了满足这些要求，ATS软件和仪器驱动往往需要遵循一定的开发风格。根据出发点的不同，有如下三种各具特点的风格，每种都有相关的标准支持:
O从测试设备出发，基于仪器的测试。这种风格简单直观，直接将测试需求分配到仪器提供的API (Applicat1n Programming Interface)上即可实现，因此应用最广泛。IVI (Interchangeable Virtual Instrument)标准是其典型代表。缺点是软件很容易与具体仪器绑定，从而损害设备互换性和软件移植性。
[0005]2)从测试领域出发，基于功能的测试。这特别适合那些有标准规定测试过程的测试领域，譬如电磁兼容测试。IV1-MSS (Measurement and Stimulus Subsystems)标准是其典型代表。但现实世界中非标准测试很多，造成IV1-MSS标准不可能、也没有规定具体的功能接口，在不同ATS间不可能互操作测试程序集。另外，对软件人员要求较高，因此应用不够广泛。
[0006]3)从被测对象出发，基于信号的测试。由于信号种类有限，可以准确地描述，并且不涉及具体的测试设备，所以设备互换性、测试程序集互操作性等特性都很好，超过了前面两种类型。ATLAS (Abbreviated Test Language for All Systems)标准是其典型代表，很多大型ATS都用到了 ATLAS。缺点是开发过程复杂，需要昂贵的专有工具，所以应用也不广。
[0007]IEEE针对当前ATS的需求定义了 1671和1641标准。IEEE 1671行业标准同时是IEC 61671国际标准，又称ATML (Automatic Test Markup Language)，作用是规定各种对象的信息交换格式；IEEE 1641标准又称STD (Signal and Test Definit1n)，作用是以信号为基础对测试过程进行描述和建模，是对ATLAS的继承和发展。这两个标准相互关联，ATML引用STD的内容作为测试描述的手段；STD使用符合ATML的文档作为需求来源。合理地利用、高效地实现这两项标准可以达到互换性、移植性、扩展性、复用性、互操作性等目标。
[0008]参见图1，STD 标准包括 SML(Signal Modeling Language)、BSC(Basic SignalComponent)、TSF(Test Signal Framework)和 TR(Test Requirement)等四层。对开发ATS的大多数用户来说，下层的SML和BSC固定不变，要做的工作是在TR和TSF两层建立概念模型，并结合仪器驱动程序将其转换成可实际运行的测试程序。TSF层描述对信号执行的操作，可以使用 IDL (Interface Definit1n Language)和 XML (extensible MarkupLanguage)两种描述方式；TR层描述信号需求，可以使用IDL、XML和TPL(Test ProcedureLanguage)等三种描述方式。
[0009]IDL是一种应用很久的软件开发技术，有很多流行的开发工具支持，但它也有很大缺点。IDL自身只描述接口而不描述过程，适合描述TSF层的信号库，而不能描述含有过程信息的测试需求，所以TR层的测试需求隐藏在使用IDL调用的特定编程语言的程序代码中。这既损害了测试软件的可移植性，又使这种方法不太适合作为高层次的需求描述工具。欧洲企业EADS率先推出了使用IDL的测试软件NewwaveX SD，提供了信号开发环境和基于信号的测试平台。
[0010]TPL是STD标准自身提出的测试需求描述工具，也是早期版本中唯一的TR层技术。TPL是与具体编程语言无关的中立技术，用注释的方式嵌入程序代码中，所以需要对其进行预处理、转换成编程语言语句后才能编译成可执行代码。这种方式的实现过程比较难，目前尚无知名的商业性开发工具。
【发明内容】
[0011]本发明的目的在于在提供一种基于信号的仪器驱动实现方法，其全部环节都使用XML技术，采用了与NewwaveX SD不同的解决方案。
[0012]本发明的技术解决方案是:
一种基于信号的仪器驱动实现方法，其特殊之处在于:该方法在TSF层使用XML描述信号库，然后将信号库转换成可调用运行的程序库代码；在TR层引入ATML标准，使用XML描述测试需求，然后将其转换成调用TSF信号库的代码；在将TR层描述转换成代码的过程中，调用了仪器驱动程序。
[0013]上述仪器驱动程序分为资源管理器和仪器驱动组件两层；所述上层的资源管理器是单一的大对象，处理用信号形式描述的测试需求，并将其转换成具体的仪器驱动组件的调用；所述下层的仪器驱动组件是很多功能较单一的小对象，作用是封装不同接口、不同类型的仪器功能，并提供统一的信号调用组件。
[0014]上述基于信号的仪器驱动实现方法，其特殊之处在于，该方法具体包括:
1)编辑XML格式的TSF信号库；
STD标准为TSF信号库提供了 XML Schema,所以使用通用的XML工具即可对其进行编辑；提供了配套的图形化TSF信号库编辑工具，导入、导出合格的TSF信号库；
2)将TSF信号库转换成接口代码；
将XML格式的TSF信号库转换成C#库代码，首先需要将其序列化成C#描述符对象，然后据此利用代码生成技术输出成C#接口代码文件以及相应的项目配置文件；
3)编辑XML格式的测试需求；
ATML标准为测试描述提供了 XML Schema，其中很大一部分是测试需求，所以使用通用的XML工具即可对其进行编辑；提供了配套的图形化流程配置编辑工具，导入、导出合格的测试描述；
4)将测试需求转换成库调用； 将XML格式的测试描述转换成C#代码，首先需要将其中的测试需求序列化成C#描述符对象，然后据此利用代码生成技术输出成C#代码文件以及相应的项目配置文件；这个过程需要糅合TSF接口代码和资源管理器调用代码。
[0015]上述资源管理器包括:
O信息注册；仪器驱动组件将自身信息注册在这个双方都知道的信息集散地(Repository)，程序执行时能够发现、启动并调用它们来执行测试，这相当于操作系统中的注册表;
2)能力综合；资源管理器能查询注册于其中的所有组件信息，并从分散的组件信息归纳综合出系统资源当前具有的测试能力；
3)匹配分析；当某种测试需求信号被提出时，资源管理器进行分析处理，并与资源测试能力进行匹配比较，给出最佳的匹配资源；
4)会话管理；测试执行时与仪器交互，为了降低耦合性并不直接操控仪器，而是将其交给资源管理器处理；
5)调用转换；上层程序使用信号语言描述需求，下层仪器只能靠API调用驱动，因此必须实现从信号到函数调用的转换。
[0016]上述仪器驱动组件是具体的仪器驱动实现代码，需要将仪器供应商以API形式提供的仪器测量功能封装成信号访问接口以便调用。
[0017]上述A