NIDays 2006 媒体见面会朱君女士演讲内容
 |
|
LabVIEW也可以“从娃娃抓起” |
概述(LabVIEW 8.20)
今年是LabVIEW图形化软件平台正式推出20周年，为了庆祝和纪念这一具有历史意义的里程碑，NI将最新发布的LabVIEW 20周年纪念版命名为8.20版本。
经历20年的发展，LabVIEW从当年虽然功能有限但已体现出未来巨大发展潜力的1.0版本，发展到今天工程师和科学家们用来进行高效设计、构建和发布的8.20版本，LabVIEW已经成为测试测量和控制行业的标准软件平台。
也就在过去20年间，微处理器性能、存储容量和磁盘容量这些指标提高了约10000倍。虚拟仪器技术与这些日新月异的商业技术一直保持着同步的发展，同时NI正在一步步实践着对于“虚拟仪器技术”的远景目标。展望未来，借助主流商业技术的进步，NI策略性地将我们的目标更新为“图形化系统设计（Graphical System Design）”的概念——即通过在同一个LabVIEW软件平台上集成从设计、原型到测试的全过程，进一步全面提高整个工程流程的效率。
LabVIEW 的诞生（计算机和GPIB仪器）
1983年的时候，NI生产GPIB接口设备，用于仪器和计算机之间连接，彼时公司已小有规模，运营良好。当我们解决了仪器连接方面的问题之后，就决定着手攻克测试测量中更深层的难关，也就是测量软件的开发。
我们目睹了基于计算机的电子制表软件为金融领域带来的巨大便利，受此启发我们也希望能为本行业发明一种同样高效的工具，应用于工程师和科学家们所进行的测试测量系统的自动化项目。
当时最常用的编程语言是BASIC，但是很显然工程师们需要一种更高级、更强大的编程语言，不过对此我们当时并没有一个具体明确的概念。
1984年当苹果公司推出了Macintosh 计算机之后，情况出现了重要的转机。我们看到了这台小机器上的图形化特性后，就知道“图形化”就是我们今后要走的道路。因为相对于输入一串串的命令行进行操作，人们使用鼠标和图形化界面时所发挥的创造力和高效率是前所未有的。
图形化前面板是人与测量程序交互的最佳途径。前面板与实际仪器的面板十分相似，实际上，这些程序就是虚拟仪器。
理论上这是一个很好的概念，但当我们去实际操作的时候，这个概念却带来了意想不到的难题。在这个最初的构想下，使用交互式面板作为用户界面来写测量程序，居然要比用传统的BASIC还要困难得多。所以，我们决定深入研究能否发明一种创新的方式来通过Macintosh的图形化界面来建立一个更简单易用的具有交互面板的程序。
我们研究了相当数量的图解技术，但每次都还是回归到数据流结构，因为这是最常用、也是最有效的方式。一旦我们能找出如何将结构化编程的概念与数据流相结合，一切问题就将迎刃而解。
虚拟仪器技术由结构化的数据流框图和交互式面板组成。将图标与面板相结合的方式使虚拟仪器在其他程序框图中也能被调用。这样，我们就能按照各种不同的需求灵活地构建复杂的多层次系统。最后，我们必须要做的就是建立一个软件环境，能使科学家和工程师们可以简单快速地构建起虚拟仪器程序。
LabVIEW 版本1
我们与一群年轻的毕业生一起选择了一处远离公司的办公室研究这个项目，以便不被烦心的日常工作打扰。
我们设立了一个远大的目标，心怀着改变世界的使命感。我们面对许多开发上的挑战，有时我们甚至怀疑能否开发出LabVIEW，如果可以做到的话，我们又是否能让人们愿意购买和使用。我们努力激励自己，设定了许多高难度的目标，现在回顾那一段历程，发现我们当时所完成的大大超出了原先的预期——那确实是一段令人激动的日子。
1985年6月我们开始写程序代码，到10月完成了原型。1986年4月我们正式宣布了LabVIEW的诞生，同时NI的名字首次出现在杂志的封面上。不过我们低估了后期调试所需耗费的大量时间，因此直到1986年10月LabVIEW 1.0才正式发货。
LabVIEW 版本2
在LabVIEW发布之后，我们并不确定会发生什么，但事实上，之后发生的情况颇为出乎意料。
我们的目标市场（纯粹的仪器控制领域）并不看重LabVIEW的出现，他们仍满足于继续在PC机上使用BASIC语言来控制一组台式仪器。显然，他们对基于Macintosh的编程不感兴趣。然而，我们发现购买和使用LabVIEW的用户来自于更广泛的各个行业，其应用范围涵盖测试测量、监控、建模到仿真等。他们受到LabVIEW图形化概念的启发，很快地开始尝试各种创新的理念和具有挑战性的应用项目。
我们当时的心情是既欣喜又担忧，因为LabVIEW 1 是一个解释型系统，其运行效果与BASIC相似，但许多新兴应用却需要更高性能来实现高效的结果。因此，在完成了NI当时最大的开发项目后，我们立即投入了新的大项目---LabVIEW 2.0的开发。
为了达到更高的性能，我们必须要发明一种用于LabVIEW 结构化数据流语言的编译器。这个巨大的难题花了我们很长的时间才得以解决。在此期间，新推出的计算机开始采用彩色屏幕，包括更大的内存和更多的插入式卡槽数，基于这些技术的发展，我们推出了一系列多功能的模拟/数字插入式板卡，快速打入了数据采集市场。
因此，当我们在继续开发编译器的过程中，我们意识到还需对编辑器、图形显示以及LabVIEW 的其他细节进行重大改进。直到我们最后几乎完全重写了全部代码之后，版本2才初具规模。在版本1推出之后，我们花了3年多时间，于1990年1月正式发布LabVIEW 2.0版本。
回顾这些，我们感到十分庆幸的是，我们最初定的目标市场仅限于仪器控制领域，但实际情况是当时的这个市场并不看重LabVIEW，反而没有让我们陷入在一个单一的领域，而且通过与更多领域工程师和科学家的接触、交流，让我们发现这个工具可以比预想的具有更强大的功能和更广泛的应用。
LabVIEW的持续创新（时间线）
到了1992年，PC已能处理16位Windows 系统上的32位应用程序，在此基础上，我们推出了一个用于Sun和PC的版本。此时，LabVIEW已经发展成为一个成熟的应用程序，自推出以来的6年间得到了用户的积极反馈，因此PC版本很快得到广泛应用。
每次LabVIEW 主要升级版本的发布都包含许多新特性，但一直以来其核心却始终未曾改变。这一点有力地证明了LabVIEW 核心理念的稳定和强大。
LabVIEW的普及和成功带动了NI不断推出新的产品线，如数据采集（DAQ）、PXI和模块化仪器等。NI公司成功的关键一点就是在于将软件和硬件高度集成为一个统一的开发平台。
LabVIEW 5的时候就为多处理器设备提供了预先设置的多线程支持功能。用户不必为了利用多处理器技术而担心线程的问题、或改变他们正在进行的工作。 LabVIEW这种结构化的数据流语言本质上具有并行的特性，因此客户的程序框图能自动地在多处理器上更快地运行。
LabVIEW的首个实时（RT）版本于1999年诞生，可运行于实时操作系统上，并且能使循环确定地运行。虽然当时的LabVIEW RT是一个年轻的、具有很大发展潜力的产品，不过这个创新的理念已经可以帮助我们进入控制设计和仿真市场。
LabVIEW 7 引入了波形数据类型，以及一些交互性更强的、基于配置的函数，使应用开发更加简便。此外，它还实现了对PDA的支持，并提供了状态图设计的向导功能。
从技术层面来看，该版本最具有创新的特性在于LabVIEW可应用于FPGA。自发明LabVIEW以来，我们就有一个梦想，去实现“编译直接下载到目标硬件”，但在当时我们并不清楚如何将其变为现实。
当FPGA出现时，我们开始进行尝试，并最终解决了如何使用LabVIEW程序框图表达电路结构的问题。在1997年我们展示了初步原型，但其后又花了6年多的时间才发布了第一个版本的LabVIEW FPGA。
LabVIEW FPGA的问世让不具备VHDL编程经验的人也同样可以进行硬件设计，而且LabVIEW本质上的数据流并行性非常符合FPGA并行电路特性，在此基础上可以达到很好的空间利用和时间性能。当然，我们还需对电路生成做更多的优化工作。
现在，LabVIEW FPGA 不但能为用户带来许多价值，而且也是我们发展“图形化系统设计”远景目标的基础所在，同时也为我们提供了一个极好的内部使用的研究平台，在研发硬件产品时可以对定时器和基本I/O进行更多的研究。
LabVIEW 8为分布在不同计算目标上的各种应用程序的开发和发布提供了许多支持。
LabVIEW 20周年纪念版——LabVIEW 8.20第一次发布了仿真框图和MathScript节点这两大功能，大大提升了其在设计市场的地位。这一版本也是第一次推出简体中文版，为中国工程师和科学家们简化了学习和操作的复杂度，更好地受益于这个高效的编程平台。
孩子们的LabVIEW （LEGO MINDSTORMS NXT）
一个特别的LabVIEW版本已经成功地应用于第二代LEGO MINDSTORMS嵌入式计算机上，让孩子们能够对MINDSTORMS NXT进行编程，并自己动手制作机器人。这个项目真是既有趣又让人振奋。看到刚上学的孩子们完成各类机器人，并能用程序控制它们的时候，我们感到自己的工作得到了最好的回报。我们从中学到的最有用的一点就是如何使我们的软件更简单易用。
发展趋势（多核处理器）
多核处理器时代的到来使得摩尔定律可以继续生效，解决了困扰处理器发展的一些常规难题，如功耗上的考虑和尺寸的限制等。
对于传统基于文本的顺序编程，如果不花费大量的工作量对代码进行重写，就不能充分利用多核处理器的性能。
不同于文本编程，LabVIEW自版本5开始，用户就无须对代码做任何改变，就能支持均衡的多处理器。得益于LabVIEW内置的并行性，所以用户不用担心复杂的线程问题——程序框图会在多核处理器下自动地加快运行速度。
LabVIEW用户能够马上从多核设备中受益。同时NI也在努力创建更多的方式得以在多核处理器上获取更高的灵活性和性能，并进一步简化并行程序的构架。
持续发展趋势（编辑方式的提升）
图形Diff在LabVIEW 5中就已经实现，但为了团队合作开发环境的需要，我们还需要完成合并求补运算。
使用LabVIEW，分布式应用的构建会比以往更容易，但在我看来，复杂性依然很高。因此我们在LabVIEW 8中引入了项目（Project）窗口来帮助管理多目标的分布式应用，而现在我们正致力于研发一个伴随窗口（companion window），它可以显示项目的图解视图，包括描述项目组件之间的逻辑和物理连接。我认为这样会使分布式应用的显示、开发和发布——包括动态无线网络，更轻松方便。
持续发展趋势（定时）
对定时和触发的表述仍是我们的一个主要研究重点。即使我们已经在定时循环和序列等新的结构上取得了很大进步，但我们要做的还有很多。
在我们在关注定时的时候，我们到底看重的是什么？如果我们通过使用LabVIEW FPGA，消除Von Neumann计算机的资源竞争冒险，我相信我们唯一关心的定时是I/O定时，因为只有I/O具有对外部世界的可见效果。所以I/O定时是我们唯一要表述的定时，而其他的都留给编译器去安排。
通过LabVIEW FPGA平台，我们可以肯定我们所创造的定时表述方式能以足够的精确度来指定FPGA上的精密同步。
我们在LabVIEW中试验性地采用了一种新的连线，它可用于表述两个不同时域之间的定时连接和异步通信通道，增强了LabVIEW的图形化，尤其在描述多目标的分布式应用的时候。我认为这一连线是代表系统设计的必要组件，但我还不确定它是否足够表达所有在系统框图中需要表示的内容。
持续发展趋势（计算模型）
除了核心的结构化数据流语言，LabVIEW也支持其他计算模型，如状态图、仿真图、文本数学表达式和交互式配置的高级节点。所有这些计算模型都能映射成基本的LabVIEW结构，这不仅保证了集成的完整，也意味着这些计算模型能在所有支持LabVIEW的目标平台上运行。
拓展这些计算模型，开发其他可能的模型是我们正在进行的工作。比如，可以把LEGO MINDSTORMS NXT看作简化的机器人计算模型。这是否意味着我们可以在特定应用领域使用其他简化的模型呢？或许我们也可以公布技术标准，鼓励第三方共同构建模型。
持续发展趋势（研究）
除了许多我们正在进行的开发项目外，我们也致力于一系列的研究项目，尽管它们可能无法得出结果。在此，我介绍其中一个称之为“自动程序框图验证”的研究。
我们设想最终能将正确性证明（correctness proof）加入到虚拟仪器程序框图源代码之中。用户可以通过名为定理模块的图形结构用正确性断言（correctness assertion）来评注他的程序框图，就像普通的程序框图一样，定理模块使用同样的程序框图元素来表达定理。
用LabVIEW编译程序框图时，特定的插件把定理模块断言解析成逻辑形式的中间层，通过归纳试探法（induction heuristics），插件程序能将对象级（object-level）程序框图和元层（meta-level）断言译为符合一阶数学逻辑的归纳证明法则(proof obligation)。然后证明法则被传递到一个试图得到证明的高级定理证明器。
如果得到证明，则验证了程序框图与它的特殊定理相吻合。如果不能得到证明，则用户能得到关于定理中所缺少信息的提示或是程序框图中哪里出错的提示。用户能够在自己的设计中纠正错误，修改正确性断言，并引导定理证明器试图找到证明。
通常，为了将待验证的问题分为多个可管理的步骤，也可能通过多个定理模块来分别表述相应的辅助定理（lemma）。用户能选择将未经证明的定理模块编译为运行检测点(run-time check)，运行检测点能够记录错误或者中断执行。
现在，我们与德州大学Austin分校的联合小组共同开发这个项目，正处在初级阶段。在过去，我们实验的只是一些很简单的例子和看来可行的方法。我们只是在初步探索的阶段，因此可能需要很长时间这个项目的成果才会开始在LabVIEW中出现。
结尾（应用）
将交互式前面板用户界面和图形化的结构数据流程序框图创造性地结合起来，灵活、强大的LabVIEW软件平台已经成为包括数据采集、控制、系统设计等各类应用的必备工具。各领域的科学家和工程师都能受益于LabVIEW的高效、强大和开放。
NI致力于不断提高图形化编程的技术发展水平，同时也一以贯之地保持LabVIEW从诞生以来延续至今的基本理念上的核心完整性和价值。
文章出处：NI
