第二章 虚拟仪器系统软件结构与模型
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
第二章虚拟仪器系统软件结构与模型
VXI即插即用规范的提出,为虚拟仪器系统的建立提出了原则性的理论依据,而为
了进行高效、简捷的虚拟仪器系统集成,剖析系统软件结构是首要步骤。
本章从软
件结构学出发,讨论了多种软件结构范式,并根据虚拟仪器系统框架定义,提出了
虚拟仪器系统软件结构与三种结构模型,为虚拟仪器模块设计与虚拟仪器系统集成
提供理论基础。
2.1 软件结构
随着计算机系统规模与复杂度的不断扩大,设计与规划整个软件系统结构变得比选
择组成模块数据结构或算法更为关键,软件结构学作为程序工程学的一个重要分支
学科,也越来越受到软件工程师的关注,对于各类计算机系统的软件结构的研究方
兴未艾。
关于系统的软件结构,Roger S.Pressman作了一个较经典的定义:
Software architecture alludes to the overall structure of the software and the ways in which that structure provides conceptual integrity for a
system.
软件结构是指软件的总体组成结构及系统结构化的集成方法。
从抽象意义上说,软件结构包括系统中所含元件描述、元件间的相互关系以及系统
元件的组织范式三部分,设计一个系统的软件结构,往往先选择好符合系统需求的
系统元件的组织范式,再自上而下地细化设计各个元件及其相互间的关系,在软件
设计中关系即为软件接口。
一个合理的组织范式的选定,为系统有效的集成提供了
基础,也为系统级的软件重用(Software Reusability)提供了可能,也是进行软
件系统设计的首要步骤。
Mary Shaw和David Garlan解析了多种系统软件结构
范式
,现简要分析如下:
1、分层式系统(Layered Systems)范式:在这种范式中,系统是层次性结构组
成的,结构中的每一层作为系统组成元件既为上一层提供服务,同时又向下一层提
出服务请求。
分层式系统范式结构紧凑明确,可重用性强,适用于易进行系统层次
化分解的软件设计中。
操作系统软件的基本范式即为分层式结构。
分层式系统范式
基本框图如图2.1所示。
图2.1 分层式系统范式基本框图
2、数据抽象和面向对象组织(Data Abstraction and Object-Oriented Organization)范式:在这种范式中,所有的系统元件均是对象,对象间的数据交
互通过调用封装了的对象操作进行。
面向对象组织范式充分表现了元件模块化的特
点,软件重用性强,但要求被交互的对象之间有明确的操作函数或过程接口,相对
系统分析与设计工作量较大。
面向对象的程序设计方法往往采用面向对象的组织范
式,首先定义对象类与对象,再针对具体对象进行分解操作。
面向对象组织范式基
本框图如图2.2所示。
图2.2 面向对象组织范式基本框图
3、管道和过滤器 (Pipes and Filters) 范式:在这种范式中,各个输入、输出
及处理元件表现为过滤器,而元件间的接口表现为管道,管道承担了过滤器之间的
连接。
管道和过滤器范式采用的是线性拓朴结构,要求经管道互连的过滤器的数据
格式与类型相一致,因此适用于结构比较简单的软件系统,最典型的例子即是批处
理系统、UNIX系统的管道技术。
管道和过滤器范式基本框图如图2.3所示。
图2.3 管道和过滤器范式基本框图
4、知识库范式(Repositories):在这种范式中,系统元件由两部分组成,一部
分是表示当前数据状态的中央数据结构,另一部分则是对中央数据结构进行存取的
操作元件集。
当在系统中以操作元件集作为数据触发时,中央数据结构即表现为数
据库,知识库范式即为数据库系统范式;当中央数据结构在系统中操作触发时,它
表现为黑板形式,操作元件表现为知识源,这样系统即是由知识驱动的知识库专家
系统。
具体专家系统软件的设计一般采用知识库范式。
知识库范式基本框图如图2.4所示。
图2.4 知识库范式基本框图
5、过程控制范式(Process Control):这种范式基于过程控制循环,主要表现
为开环控制范式与闭环控制范式两类,主要用于工业自动化系统中。
闭环控制范式
基本框图如图2.5所示。
另外,还有一些软件结构范式也是比较常用的,如基于事件(Event-Based)范式
、解释机(Interpreters)范式、分布式处理系统(Distributed process system)范式、主程序/子程序组织(Main program/subroutine organizations)范式、状态迁移系统(State transition systems)范式及特定领域软件结构(Domain-specific software architecture)范式等。
图2.5 闭环控制范式基本框图
软件结构范式概念的提出与模型的确立,为系统软件的设计确定了基本框架。
系统
软件设计工作是从首先确定结构范式开始,进而细化范式中每一元件的设计工作,
并着重关注元件之间的接口交互,使系统软件设计生成一个可操作、可管理、可维
护、可重用的过程。
应当看到,一个系统软件的实现并不一定只有一种范式可循,在许多情况下,多种范式是可以异殊同归的。
此外,一个系统软件模型往往也不是
一种范式的简单复本,而是多个范式的混合体,称为混合型结构(Heterogeneous Architecture)。
2.2 虚拟仪器系统软件结构
从第一章描述可知,虚拟仪器系统是集计算机系统与仪器系统为一体,而将研究重
点关注到虚拟仪器系统的软件系统部分,它是一个典型的计算机软件系统,因此,它的分析与设计也应该符合软件结构学的要求。
为了有效地实现虚拟仪器系统软件
设计,先必须分析系统中所包含的元件形式与接口形式,进而提出符合一般虚拟仪
器系统软件设计的基本范式,再将范式中的各个元件进行具体细化分析,为虚拟仪
器系统软件设计奠定理论基础。
在第一章中,已经简单讨论了虚拟仪器系统组成(见图1.2),为了确保组成虚拟
仪器系统的各硬件模块与软件模块的互操作性,VPP规范提出了系统框架的概念。
系统框架并非是真正的物理实体,实质是虚拟仪器系统集成的综合方法与要求。
系
统框架内部定义与描述的系统元件,则是组成一个完整的虚拟仪器系统的必要部件。
根据硬件平台(PC平台与工作站平台)、操作系统及语言风格的不同,目前VPP
规范总共规定了十种系统框架。
其中五种基本框架分别以其支持的操作系统命名,
分别为WIN、WIN95、WINNT、HP-UX、SUN系统框架,各自支持微软公司的DOS
操作系
统、WIN95操作系统、WINNT操作系统、HP公司的UNIX操作系统、SUN公司的工作站
操作系统,并在此基础上,又分别派生出只采用NI公司的LabView图形化平台环境
的G语言系统框架,各在原基本框架名字前加上前缀G,即为GWIN、GWIN95、GWINNT、GHP-UX、GSUN五种派生框架。
VPP系统框架类型如表2.1所示。
表2.1 虚拟仪器系统框架类型
这十种系统框架分别代表了十种VPP系统构成的不同风格,相互之间既有相同点,
也存在着各自特点。
这十种框架结构也分别代表了当今流行的五种操作系统与两种
语言(文本式语言和图形化式语言)风格。
当新的一种操作系统或语言风格成熟后
,VPP规范也必将会考虑将之相对应的新的系统框架的规范标准,因此,虚拟仪器
系统框架的类型有着鲜明的时间性,但其关键的建构理论却有相当的稳定性。
组建一个VPP系统,首先应根据实际需要与条件制约,选择一个合适的系统框架,然后再在这个框架范围内选择必要的组成元件。
在组建系统或设计模块时,必须完
全符合一种以上系统框架的所有规范要求(有时模块设计可以同时满足多种框架规
范),否则该产品将不是合格的VPP产品。
在VPP-2规范中,定义与描述了组成一个完整的VPP系统的所有框架元件,其中包括
:
1、 VXI主机箱:VPP规范要求VXI系统中的主机箱设计除必须符合VXI总线规范标准
外,还应提供用于自动计算VXI系统功率与致冷要求的知识库文件。
2、 VXI零槽/资源管理器(包括嵌入式或外挂式计算机系统):VXI零槽/资源管理
器的设计必须符合VXI总线规范。
目前,外挂式计算机接口除了GPIB接口、MXI 接口
、还有IEEE1394高速串行接口,且后者具有较大的性价比优势。
3、仪器模块:VPP系统框架的仪器模块类型可以包括VXI仪器、GPIB仪器、串行接
口仪器等。
4、仪器硬件接口:实现计算机与仪器模块之间的数据与信息通讯。
VPP系统框架
应支持VXI消息基器件的字串行协议、寄存器基器件的寄存器级通信协议、GPIB 仪
器的IEEE488.1/IEEE488.2标准、RS232仪器的串行通信协议以及其它用于计算机与
仪器通信的协议标准。
5、操作系统:十种系统框架分别支持五种不同的操作系统,分别与各自的框架名
相对应。
6、 I/O接口软件:VISA作为一个I/O接口软件,为不同供应厂家的软件模块运行于
同一个平台提供了统一的基础,理论上,VISA库的源程序是唯一的,而不同的系统
框架要求提供不同的VISA API接口。
7、仪器驱动程序:每个仪器模块都有各自的仪器驱动程序,不同的系统框架要求
提供不同文件形式的仪器驱动程序。
仪器驱动程序不仅包含C源代码,也包含功能
面板(FP)文件、动态链接库及VB原型文件等多种形式。
8、软面板:作为一个图形化的仪器用户界面,软面板在第一次进行系统集成时,可用于仪器通信与功能自检,而在进行仪器操作时,它又可以作为仪器功能与操作
的学习工具。
仪器软面板是基于仪器驱动程序的一个独立运行的应用程序。
9、知识库文件及帮助文件:每个仪器模块必须提供用于系统配置的知识库文件与
相关的帮助文件。
10、安装盘:为了减少系统集成的时间与精力,VPP规范要求每个仪器模块必
须提供一个标准格式的安装盘,以方便系统集成人员与最终用户。
11、应用程序开发环境:VPP规范对于应用程序的开发环境提供了一个可选择的范
围,应用程序开发人员可以根据自己的爱好与实际需要,选择一个合适的应用程序
开发环境。
12、应用程序:根据自动测试任务的需要,在选定的开发环境中开发系统应用程
序。
在系统框架中定义的各元件中,VXI主机箱、VXI零槽/资源管理器、仪器模块及仪
器硬件接口构成了虚拟仪器系统硬件结构,其对于每类系统框架都是通用的(需要
说明的是,由于VPP规范中定义的仪器类型不仅仅指VXI总线仪器,如果在自动测试
系统中不包括VXI总线仪器,则虚拟仪器系统硬件结构中只需要包括特定仪器模块
与仪器硬件接口而无需包括VXI主机箱与零槽控制器。
换句话说,VXI主机箱与VXI
零槽/资源管理器在虚拟仪器系统并非是必要的)。
而操作系统、I/O接口软件、仪
器驱动程序、软面板、知识库文件、帮助文件、安装盘、应用程序开发环境与应用
程序构成了虚拟仪器系统的软件部分,对它的定义与描述每个系统框架都有各自的
特点。
在这些模块中,I/O接口软件、仪器驱动程序与应用程序的应用与开发是最
为关键的,它们自下而上构成了虚拟仪器系统软件结构。
其中,I/O接口软件以动
态链接库或静态库形式以供仪器驱动程序调用,仪器驱动程序也以动态链接库或静
态库形式供应用程序调用,并结合功能面板文件形式,可为图形化应用程序实现仪
器操作调用。
因此,虚拟仪器系统软件结构的范式基本满足层次式系统范式的范畴
,但与层次式系统范式不同的是,后者在上下层元件之间进行数据与信息的传递,而本范式传递的封装形式的函数集本身,故将之定义为函数化层次式系统(Function Layered System)范式,基本结构框图见图2.6。
图2.6 虚拟仪器系统软件结构基本范式
2.3 虚拟仪器系统软件结构模型
虚拟仪器系统软件结构基本范式是针对所有虚拟仪器系统而提出的,事实上,虚拟
仪器系统的规模是有大有小,系统设计人员的任务也是不一样的,如何使不同目的
的系统设计人员都能高速、方便地进行系统与元件的设计,本章在虚拟仪器系统软
件结构基本范式的基础上,提出了虚拟仪器系统软件结构的三个模型。
第一个模型称为微模型(Micro-Model),又称为仪器模块模型,它是针对单个仪
器模块的软件开发而提出来的,在这个微化的系统中,只存在着一个虚拟仪器,因
此系统软件设计也就成为仪器模块软件元件的设计,主要适用于虚拟仪器的开发人
员,图2.7所示即为微模型框图。
图2.7 虚拟仪器系统软件结构微模型框图
将其表示为公式形式,即为:
其中,IO表示为I/O接口软件,DR表示为驱动程序,SF表示为软面板,在这个模型
中,软面板作为一个独立运行的应用程序存在,通过调用驱动程序实现对于仪器的
操作与测试。
第二个模型称为标准模型(Standard-Model),是针对典型的自动测试系统提出的
,在这个系统中包含有多个不同的仪器模块,通过计算机应用程序进行数据的输入
、输出与处理,图2.8所示即为标准模型框图。
将其表示为公式形式,即为:
其中,IO表示为I/O接口软件,DSi表示为相应虚拟仪器驱动程序,AP表示为自动测
试应用程序,可以在文本语言环境下开发(调用多个驱动程序的动态链接库),也
可以在图形化环境下开发(调用多个驱动程序的动态链接库与功能面板文件)。
在
这个模型中,仪器软面板不再出现,而代之以包含多个仪器操作的自动测试系统应
用程序。
这个模型适用于典型虚拟仪器系统集成人员,是一个单机版本。
图2.8 虚拟仪器系统软件结构标准模型框图
第三种模型称为扩展模型(Extend-Model),又称为网络化虚拟仪器系统模型。
在
这种模型中,分别包括了多个自动测试子系统与上层的数据管理与浏览子系统等,
软件结构范式已经不适用于函数化层次式系统范式,应该是基于分布式系统的客户
机-服务器(Client-Server)体系。
图2.9所示为扩展模型框图。
将其表示为公式形式,即为:
其中,SMi表示相应的虚拟仪器子系统,定义见标准模型[2.2]。
DS表示数据库服务
器,DCi表示为相应的数据操作客户机程序,包括上层数据管理程序、数据浏览程
序与数据查询程序等。
整个系统基于客户机/服务器模式,构成了企业内部局域网。
同时将测试与处理数据结果以主页方式发布,可以直接进入到Internet网中去。
这种扩展模型适用于网络化的、企业级的测试平台系统的设计与集成。
图2.9 虚拟仪器系统软件结构扩展模型框图
以上得出的三种虚拟仪器系统软件结构模型,是对基本范式的细化,也适用于不同
的设计人员。
对于一个仪器设计人员来说,仪器驱动程序与软面板的设计是其主要
工作,而对于一个系统集成人员来说,往往会选用一些性价比高的仪器模块,他们
关心的重点不一定是具体的仪器内部操作,而更注重如何通过系统软件元件接口,
进行方便、高效的系统集成,一个优秀的应用程序开发环境的选择以及丰富的编程
控件的获取,对于他们来说是更为直接的。
而对于组建网络化自动测试系统人员来
说,关心的重点是网络模型的选择与设计,数据的获取与传递,他们需要的是几乎
透明了的数据采集过程与结果,这就必须依赖于良好的软件接口技术。
本章提出三
种模型的目的,就是为了使各类设计人员都有据可依,各自的任务明确,工作重点
突出,为不同规模的虚拟仪器系统集成提供理论基础。
在以下的几章,是对系统中
所包含的元件的进一步细化,着重介绍了系统中各种元件的结构模型、设计方法与
接口技术,从而使整个虚拟仪器系统软件的设计与集成真正成为一个可操作过程。