labview csv文件处理_LabVIEW之父：如何提高抽象层级改进软件效率

EEWORLD

电子资讯 犀利解读 

技术干货 每日更新

 

日前，在NIWEEK 2018上，NI共同创始人、Fellow、有着LabVIEW之父称号的Jeff Kodosky做了主题演讲，他畅谈了未来LabVIEW的软件架构。

未来，LabVIEW将可通过更高级的抽象，实现在一个程序框架中对上位机和FPGA同时编程，双方的数据交互在统一平台下执行，而不像过去通过队列形式实现。这会给编程带来更大的便利性，尤其是面对复杂系统，采用更高级的编程语言可加速用户的开发周期。

“就好像开车一样，如果你需要加速，采用自动变速箱直接踩油门的方式比手动换挡便捷很多，这就是通过提高抽象级别让软件变得更加简单高效。”Jeff说道。

NI共同创始人、Fellow、LabVIEW之父Jeff Kodosky

以下是其演讲内容

LabVIEW设计初衷只是为科学家和工程师可以快速完成他们的测试测量系统，而无需专门的程序员团队。

正如说过的，像电子表格程序可帮助金融分析师编程一样，我们给工程师和科学家开发一套属于他们自己的加速编程工具。

目前来看，LabVIEW已经成功地完成了这一任务。

通过LabVIEW，数以万计的工程师、科学家、测试人员甚至医学研究员等各行业专家成功完成了他们的自动测试系统。LabVIEW加速了研究开发，减少了测试时间和成本，同时就减少了产品开发周期。

LabVIEW在持续改进和创新上有着悠久历史，每个版本既保持向后兼容性，同时也在不断引入新功能。

LabVIEW最显着的进展是引入对实时系统和FPGA支持。用户无需成为VHDL专家，便可通过构建在FPGA上运行的图形化程序来满足性能要求。今天，随着系统的复杂性不断增加，需要更多的并行处理，更多的物理I/O，更紧密的时序和同步以及更多的分布式组件。

    LabVIEW演进历史

所以，我们将如何继续应对未来的复杂性呢？

一种方法是建立良好的策略和流程，保持测试套件和文档的全流程管理。现有的软件工程方式已成功构建了大型测试系统。

另外软件架构同样可以通过组织和限制设计遵循帮助认证过的Patterns，例如，LabVIEW中的Project templates和Actor Framework就是这种方法。

当然，工具和开发环境的改进也有帮助。例如，通过LabVIEW NXG与DAQmx驱动程序和DAQ硬件的集成更加紧密，使交互式探索和自动化测量变得更加容易。

此外，专用工具可以通过减少定制开发的需求来处理整体流程的复杂性。像TestStand这样的专用工具可以处理应用程序的标准部分，而只开发您需要的自定义测试步骤。

    通过NI提供的专用工具，加速软件开发和实施周期

第二种方法则是提高我们用于设计系统的抽象级别。对于目前复杂的系统，我们可以利用人工智能等方式提高抽象级别，可以减少人为的复杂性。想象一下你的车，如果您想要加速，使用自动变速箱等更高级别的抽象比标准变速箱更简单，因为标准变速箱还需要额外的手脚配合进行离合换挡。

两年前，我们在LabVIEW中引入了Channel Wire，提高了通信并行处理设计的抽象级别。相比低级语言设计起来更容易，更明显也更易于理解。实际上还有更多的工作可以进一步提高LabVIEW的抽象级别。

    采用Channel Wire，上位机与FPGA之间的通信只需要简单的连线即可实现

从历史上看，我们的开发理念都是首先着眼于使难题成为可能，然后再让它们变得更容易。

NI已经创建了跨越处理器和FPGA的测量应用程序，现在是时候考虑提高抽象级别以增加便捷性了。

假设我们可以在LabVIEW中将FPGA表示为一个盒子。内部的图表代表部署到FPGA中，外部的图表表示在处理器上运行。它们之间的通道表示通信路径，编译器使用底层的FIFO和DMA资源来实现连接。

Target软件体系结构对于简化cRIO应用和FlexRIO点对点通信应用程序，甚至对于分布式应用程序来说显示出巨大的前景。

这是我们为提高抽象级别而进行的一个例子，如果我们能够真正实现它，它将成为最先进的技术进步。

如图所示，未来可在一个软件系统开发框架内，实现上位机与FPGA的共同开发

让我来尝试描述我们一项正在进行的研究工作，它可以通过更加模糊且更高级的处理方式加速我们的设计流程。以一个麦克风测量系统来举例。

最开始，我们勾勒出设计理念，包括展示要测试的麦克风，提供激励信号的扬声器，驱动扬声器的波形发生器，测量响应信号的数字化仪器以及设置增益与频率。

这种草图经常需要改进，例如，当我们为了获得更高的精准性，需要测量激励信号。

如果我们可以在LabVIEW中放置一个抽象设计节点并编辑它的图标来表示麦克风，用另一个图标来表示扬声器，为声波添加一些剪贴画，我们可以快速生成一个草图。

作为项目的一部分，它需要一些文档，但同样提高系统层级的话，我们就可以把它当做实施整个系统的启动点。

如果我们可以注释导线以显示激励信号，作为连续步进频率波形，并且对采集输出进行注释以显示要分析的波形流，这将使抽象算法更为清晰。

我们还可以显示将采集到的信号流分成时间间隔信息。

我们可以标记这个抽象级别，并通过将生成节点扩展为波形计算和波形输出来继续改进设计。

并将采集节点扩展为模拟输入，将节点分割成块。

现在我们意识到，只有当我们有相同的时间参考时，这才会起作用，因此我们引入了一个开始时间，于是开始生成和采集同步。

在这一点上，我们发现我们忽略了一个重要问题。由于声传播，来自麦克风的信号将比刺激信号显着延迟。于是我们决定通过在波形的开始处生成一个特殊的脉冲并使用它来同步采集的信号来解决这个问题。

当我们语义缩放到更高级别的抽象添加测试项时，我们看到一条线，显示共同开始时间。

我们认为它足够重要，可以在此级别展示，因此我们可以实现这一目标。然后，我们添加连接以传递同步脉冲，并设置为在波形开始处显示。这时又会看到需要实施的新连接。

我们继续完善波形输出节点，并展示如何将同步脉冲发送到采集点上。

接下来可以改进该节点以显示同步脉冲被重新采样并用于匹配采集的信号的同步。我们继续以这种方式工作，一直到一个工作应用程序完成，不断进行缩放，在一个层面上编辑并在其他层面上进行配合修正，以符合一致性。

最终只通过一个开发软件，便可实现测试系统的搭建

这种丰富的设计环境将使用户能够创建易于理解和维护的系统。

在多个抽象层次上工作是解决复杂性的最有效方法，它可以逐步公开和抽象语义细节，以便您可以更好地设计测量系统，并根据需求不断演变。

正如Alan Kay所说，“预测未来的最好方法就是创造未来。”

我们构建的环境变得越来越复杂，这需要更复杂的测试和测量系统与之匹配。需要更复杂的工具来减少人为造成的复杂性并可提供更高级的抽象层设计。通过我们对产品的不断改进，将进一步实现这一愿景。

我们希望提供不断创新的工具，构建未来所需的系统，NI的愿景一直都是如此。

附：英文演讲原版

The original goal for LabVIEW was to make it easier for scientists and engineers to automate their test and measurement systems without requiring a team of programmers— similar to the way spreadsheet programs helped financial analysts.

LabVIEW successfully accomplished that goal.  

There have been countless examples where domain experts: engineers, scientists, test technicians, and even medical researchers, have successfully automated their measurement systems.  

They have sped up their research and discovery, reduced test times and costs, and reduced time to market for new products.

LabVIEW has a long history of continuous improvement and innovation.  Each version introduced new capabilities while preserving backward compatibility.  

Among the most notable advances was the introduction of real-time and FPGA support.  Without having to be a VHDL expert, a LabVIEW user can address higher performance requirements by building diagrams that run on an FPGA.

The complexity of systems being built today continues to increase.  There is need for more parallelism, more physical I/O, tighter timing and synchronization, and more distributed components.

So, how can we deal with this complexity?

One way is to institute good policies and processes, and maintain thorough test suites and documentation.  

Large test systems are successfully being built today using these software engineering practices.

Frameworks can help too, by organizing and constraining designs to follow approved patterns.  Project templates and the Actor Framework in LabVIEW are examples of this approach.

Improvements in tools and development environments help also.  

For instance, LabVIEW NXG has a much tighter integration with the DAQmx driver and DAQ hardware, making it much easier to explore interactively and then automate your measurements.

Specialized tools can deal with complexity by reducing the need for custom development.  

A purpose-built tool like TestStand can handle the standard parts of your application while you develop only the custom test steps you need.

Another powerful way to deal with complexity is to raise the level of abstraction we use for designing systems.  

There is inherent complexity in the system being built, as well as artificial complexity of the tools being used.  

Raising the level of abstraction reduces artificial complexity. 

Think about driving your car.  If you want to accelerate and merge into highway traffic, using the higher level abstraction of an automatic transmission is simpler than a standard transmission, where you need an extra arm and leg for the gear shift and clutch.

Two years ago, we introduced the Channel wire in LabVIEW, raising the level of abstraction for designing communicating parallel processes.  

It is easier, more visible, and more understandable than using lower level language elements.

There is more that can be done to further raise the level of abstraction in LabVIEW.

Historically, we have focused first on making difficult things possible, and then later making them easier.  

We made it possible to create measurement applications that span across processors and FPGAs.  

Now it’s time to raise the level of abstraction and make it easier.

Suppose we could represent the FPGA as a box in LabVIEW.  The diagram inside gets deployed to the FPGA and the diagram on the outside runs on the processor.  

A Channel between them represents the communication path, and the compiler uses the underlying FIFO and DMA resources to implement the connection.

The Target structure shows great promise for simplifying cRIO applications, and FlexRIO peer-to-peer communication applications, and even for networked distributed applications.  

It is one example of the research we are doing to raise the level of abstraction, and it will be a major advance in the state of the art, if we can actually make it work. 

Let me describe another, more ambitious, and fuzzier, research effort underway, and illustrate with a short storyboard.

Imagine we want to build a measurement system to test microphones.  

We go to the whiteboard and sketch our design idea, showing a microphone to test, a speaker to provide a stimulus signal, a waveform generator to drive the speaker, a digitizer to measure the response signal, and some computation which produces a graph of the gain versus frequency.

This high level sketch often gets lost, but even if it’s preserved, it almost never gets updated, when, for instance, we decide to measure the stimulus signal too, for better accuracy.

If we could drop an abstract design node in LabVIEW and edit its icon to represent a microphone, and another to represent a speaker, add some clip art for the sound waves, we could quickly build up a sketch similar to the whiteboard version.  

Preserving this as part of the project would at least provide some useful documentation, but it could also be a launching point for implementing the whole system.

If we could annotate the wire to show the stimulus signal is a continuous stepped-frequency waveform, and annotate the acquisition output to show a stream of waveform chunks to analyze, that would make the abstraction clearer.  

We could also show the time interval information that’s needed to split the acquired signal into chunks.

We can mark this abstraction level and continue to refine the design by expanding the generate node into waveform calculation and waveform output.  

And expanding the acquisition node into analog inputs feeding nodes that split the data into chunks.  

Now we realize that this will work only if we have the same time reference so we introduce a start time which synchronizes the start of generation and acquisition. 

At this point we discover that we’ve overlooked an important issue.  

The signal from the microphone is going to be significantly delayed compared to the stimulus signal because of the acoustic propagation.  

We decide to fix that by generating a special pulse at the beginning of the waveform and using it to align the acquired signals.

When we semantically zoom back out to a higher level abstraction to add this, we see a dimmed connection showing the common start time we added.  

We deem it important enough to show at this level so we enable it.  Then we add the connection to pass the pulse for aligning and show how it appears at the start of the waveform.

Zooming back down, we see the new connection that needs to be implemented.

We continue to refine the waveform output node and show how the sync pulse is sent it to the acquisition node.  

And we refine that node to show the sync pulse being resampled and used to match the acquired signals and align them.

We continue in this manner all the way to a working application, semantically zooming up and down as desired, editing at one level and having those edits reflected at other levels to maintain consistency.

Such a rich design environment, as envisioned here, would enable users to create systems that are much easier to understand and maintain over time.  

Working at multiple levels of abstraction is a powerful way to tame complexity.  It enables the progressive disclosure and abstraction of semantic detail, so you can better design your measurement system, and confidently evolve it as requirements change.

Our built environment is getting more complex, requiring more complex test and measurement systems.  

These in turn require more sophisticated tools that reduce artificial complexity and support higher levels of abstraction.  

As we further develop this vision, we continue to deliver advances in current products.  

By empowering you with innovative tools to build the systems you need, we know the future is in good hands.