金鹏飞, 李晓明

(浙江理工大学机械工程学院, 浙江 杭州 310018)

1 引言(Introduction)

模块化、通用化、可扩展是虚拟仪器[1]的重要特征,一台虚拟仪器系统的不同功能模块可能是由不同的仪器厂家生产的。如果想确保市场上各种各样不同功能、不同厂家生产的仪器模块能够相互组合成为一台完整的仪器系统并能正常运行,那么对这些仪器模块进行管理就起到了关键性的作用。虽然各类管理软件产品类型及数量众多,但是仍主要采取各自的体系架构,在技术内部融合及接口一致性处理方面面临的技术难度比较大[2-5]。

针对上述问题,杨浩前的研究实现了设备资源的自我控制和自我管理,使用户摆脱了烦琐的底层硬件接口驱动命令,但是杨浩前的方案却没有包含所有的数据类型,并且在数据传输的过程中会出现中断的错误[6];赵俊设计的IVI(互换虚拟仪器)设备驱动分成仪器类驱动和专用驱动两层,更改函数时,只需要改变其配置文件,而不需要改变上层程序,但是赵俊的方案没有实现相同仪器间的互换,没有实现各个仪器之间的通用[7]。为了解决上述设备管理器方案中存在的缺点,本文设计出一种资源管理器的方案,包括资源管理器的功能,前端模块[8]资源的设计和与之对应的XML[9]配置文件,以及前端模块和主机模块的通信协议,实现了半实物仿真的标准化和通用化[10]。

2 资源管理器的设计内容(Design content of resource manager)

本文研究的内容是通用半实物仿真平台资源管理的设计。这些资源的主要目的是作用于大部分前端设备。其中,需要实现的功能包含设备树的自动生成、设备运行状况的实时监测和前端设备的管理。通过该资源管理系统可以在开发平台对前端硬件进行查看、监测数据文件传输及更新前端设备。因此,需要一套符合整个管理软件开发平台的前端设备管理器,用于在开发时对当前所连接的前端设备进行管理和状态监控。基于此,课题的研究内容主要包括以下两点。

(1)前端模块管理功能:本系统具备硬件模块化的特点,主机模块是系统的控制中心。管理软件运行于主机模块之上,对前端模块进行控制,与前端模块进行信息交互,实现平台的测试测量和监测功能。该管理软件还需要对当前系统内的前端模块及其运行状态信息进行管理。

(2)状态记录功能:系统中存在很多的特性或状态需要量化表达。这些状态有些用于前端模块的管理,例如模块的ID、生产厂家ID等;有些状态用于配置硬件参数,控制平台系统的运行,例如与总线相关的前端模块地址滤波器值及基本时间周期值等;有些状态与总线等硬件状态密切相关;有些状态仅用于底层的功能调整或者表达软件的运行状态;有些状态表征系统的运行状态,需要实时更新获取,例如某个前端模块的总线丢帧情况等。因此,需要建立一套标准机制记录整个系统的状态运行参数。

3 资源管理器的实现(Implementation of resource manager)

3.1 前端模块的建模

对于以上需要实现的功能,整个资源管理器中关键的部分就是对其设备的管理,而设备管理器系统中最主要管理的对象之一就是形形色色的前端模块。因此,针对该系统建立了相应的模型图,如图1所示。

图1 设备管理器前端模型Fig.1 Front-end model of the device manager

前端模块[10]是组合式仪器平台里的一个组成部分,由DSP(数字信号处理)控制板、总线板和外部接口模块组成,其中总线板实现了前端模块与主机及其他前端模块之间的通信,总线板里的总线是系统内置的仪器总线;DSP控制板主要是一个DSP控制系统,包括DSP和存储系统等;外部接口模块是前端模块与被测实物之间的信号交流接口,例如RS232[11]、1553B总线接口[12]及CameraLink接口[13]等。

3.2 前端模块资源的设计

前端模块资源用户管理前端应用扩展模块的属性信息和状态,记录模块的属性状态,提供获取和配置属性状态的接口。需要针对前端模块的硬件特征和测试系统的软件特征,抽象模块特性,在总线驱动中量化表达。对属性特征进行分类,不同类型的属性有着不同的获取和配置方式。结合前端模块的特性,将属性分为静态属性和动态属性,静态属性包含前端模块的厂家ID等所有前端模块都具有的属性,而动态属性是某些前端模块独有的,就需要专门的代码实现,进而实现资源管理的通用化。现阶段对前端模块资源属性的分类见表1。

表 1 前端模块属性分类表Tab.1 Classification table of front-end module property

3.2.1 XML的设计

通用化设计的标准就是设计有标准的接口,能够让所有的其他组件在使用这个数据传输组件时,只要根据标准的接口进行设计就能完成数据的传输。那么,对于各式各样的组件,传输的数据格式和要求是不一样的,那么至于这些参数的传入就可以使用XML文档进行配置[9-10]。XML可配置的参数有数据类型、数据属性、输入端口及输出端口等。本文用XML语言描述前端模块提供的资源与功能,包括基础属性、配置参数、命令列表、通道列表。因此,为了实现数据标准化,设计了对应的XML文档,具体实现代码(节选)如下:

16路输出口、32路输入口

3.2.2 JavaBean的设计

数据经过XML文档传输之后会被相应的解析器解析,而数据经过解析后应该有其进行标识,这样可以在之后的数据处理中提供映射。基于此,设计了对应的JavaBean作为数据的载体,解析数据字段表述见表2。

表 2 解析数据字段表述表Tab.2 Parsing data field description table

3.3 前端模块与主机模块的通信协议设计

3.3.1 协议需求分析

为了满足以上两种工作模式的需求,设计了前端设备与应用软件之间的传输层协议。该协议主要是根据传输的数据类型与功能指定的。传输的内容大致可以分为两大类(图2):一是工作模式,这种模式下可以与主机模块一对一地通信、进行模块注册、接收资源查询和配置命令、接收状态查询命令、接收DSP应用安装命令及接收DSP程序信息查询命令。二是用户模式,在该模式下能接收消息日志、数据和退出用户模式的命令。当前端模块执行DSP程序后会自动进入用户模式。

图2 数据传输图Fig.2 Data transmission diagram

3.3.2 通信协议的制定

通信协议的数据链路层帧结构如图3所示,主要包含仲裁场和数据场。仲裁场的功能是首先根据数据的优先级进行判断,然后判断该数据是否可以被接收。数据场主要是发送数据,用户在数据场中可以撰写自己需要的协议,之后形成TLV(Tag、Length、Value)格式。对于在前端模块上传输的数据,将仲裁场定义为数据帧头,将数据场定义为数据体。数据的数据场是一个长度为1 024字节的字符数组,消息的数据场是由3个无符号整型数构成的,长度为12字节。

图3 总线数据链路层帧结构Fig.3 Layer frame structure of bus data link

根据资源管理器分析的协议需求和通信特性,将不同功能、不同类型的数据和消息按照不同的通信方式和优先级发送。针对前端模块的应用情况,对仲裁场和数据场进行定义。对仲裁场的定义如图4所示,图4中的type部分是提供给用户的应用软件使用的,实现了通用化和标准化。

图4 消息和数据仲裁场协议Fig.4 Message and data arbitration field protocol

根据仲裁场中的协议规定,数据和消息的优先级主要是依靠协议中的前7位来决定(31—25位)。在仲裁场的协议中,信息的类别class和优先程度degree共同影响着数据的优先权。尽管低位的值可能会对优先权产生影响,但它的影响力不及高位的值,因此最后选择前7位作为重要的评估标准。数据信息的优先传输级一般来自数据信息大类class,但是通过改变degree的方式,也能够有效地调整默认数据类型的优先程度。将数据信息大类class和degree创新性地结合起来,促使它们之间的关系变得平衡,从而取得最佳的效果。class的取值范围能够从0到F不等,它能够支持16种消息类型和16种数据类型,这样能够允许低优先级的数据类型在某些情况下,具有更高的优先权,从而使数据传输更为便捷,更具有层次感。

仲裁场中的under字段用来判断通信是上位机管理软件(上层)还是虚拟仪器嵌入式系统(底层)。1代表底层通信,0代表上层通信。tag用来指定底层通信中的指令类型,type用来指定上层通信中的指令类型。用户可以在type中根据自身的需求,设置对应的协议。instr_addr(10—6位)和sessn_id(5—1位)分别是底层通信和上层通信的地址,取值范围是0—F(Hex)。retry用来显示数据的发送是否发生了丢帧,正常情况下数字为0,当从0变成1时,就表示出现了丢帧,前端模块通信就会对数据丢帧进行检测。如果检测后发现有数据丢失或者出现错误,前端模块驱动会自动进行重发。

数据场的具体设计如图5所示。其中,包含关于消息的数据和前端模块采集的数据。消息总线数据场的首半个字节为消息长度,其余为消息内容;数据总线数据场的前两个字节为数据长度,其余为数据内容。在数据内容的最后会跟着一个编号,它是一个递增数,用于丢帧检测。每当数据传输成功后,这个编号就会自动加1,当接收端接收到的数据是断断续续的,说明出现了数据丢失,就需要通知发送端重新发送丢失的数据帧。

图5 消息和数据总线数据场协议Fig.5 Message and data bus data field protocol

3.3.3 通信协议的设计

设备管理器连接到主机模块,通过主机模块接口调用VISA(虚拟仪器软件结构)接口,连接到前端模块进行获取。需要与前端模块通过仪器总线进行交互,按照前文对协议进行分析和制定,前端模块与主机通信协议节选见表3。

表 3 前端模块与主机通信协议节选Tab.3 Excerpts from the communication protocol between the front-end module and the host

4 实例演示(Example demonstration)

本文所提软件是基于浙江大学课题组研发的通用测试仪器系统,实物如图6所示。

图6 仪器系统实物图Fig.6 Physical diagram of instrument system

通过前端模块和上位机软件进行通信后,运行上位机管理软件,可以实时展示前端设备的数据,能够对前端设备进行管理。如图7所示,界面左侧能够显示前端设备的可用状态,界面右侧是对单个前端设备具体信息和数据的展示,界面的下方是日志的输出。

图7 上位机管理软件界面展示Fig.7 PC management software interface display

5 结论(Conclusion)

本文分析了资源管理器技术的研究现状,针对浙江大学课题组研发的多功能仪器组件前端设备的复杂性,设计相对应的资源管理器方案。对前端模块进行抽象建模,设计前端模块的资源管理应用程序,并模拟实际测试案例,验证通用半实物仿真资源管理器及通信协议标准化方案的可行性,可以实现软件中关于各种前端模块中设备树的自动生成、IO通信、属性管理、事件通知等全部功能,满足了资源管理器的应用需求。最重要的是,本设计方案只要配置对应的XML文档,就可以对前端模块即插即用,应用程序开发非常简单,具备标准化、通用性、避免软件重复开发的特点。