Viewpoint News, November 2009

Development Tools

by James Campbell - jac@viewpointusa.com

We continue exploring the ‘7 Challenges for Highly Effective Test Engineers’ which are challenges that affect all test engineers developing new test systems or upgrading old ones.

Last month, I leapt into our first in-depth exploration of Product Complexity. This month’s Challenge covers Development Tools. Next month will be Engineering Proficiency.

Development tools add additional features every year. I’m not even talking about the changes driven by new hardware capabilities, such as multi-threading or FPGA. I’m speaking about the tools available to write an application.

There are several development platforms to choose. Some are based on language choice (e.g., LabVIEW versus .NET versus C++). Some are based on capability (Matlab has many numerical analysis tools that LabVIEW does not). Like most of you, I focus on LabVIEW development options, although Viewpoint also uses .NET for many important applications too. But even in this corner of the development option space, LabVIEW offers many tools that you probably either don’t use or don’t know about, so please read on.

It’s More than Writing Code

Over the past several years, LV has offered support for an increasing number of options for hardware targets. Each one of these targets offers slight flavors of the LV language.

As a simple example, the arithmetic operations on the PC platform natively use IEEE floating point math but on the FPGA they use integer math. And, RTFIFOs don’t even exist on non-realtime LV systems. Simply keeping abreast of the hardware target options is a challenge for development teams.

For example, at Viewpoint, additional effort is spent cross-training engineers to be proficient at LabVIEW RT as well as LV for Windows. It’s fairly obvious that our engineers using LVRT a lot are better at it than those that don’t use it very much.

But, besides keeping up with LV target nuances, the act of simply developing LV applications is more complex than ever.

The major force behind this growing complexity is the ability of LV programmers to push LV into bigger and more comprehensive applications. This push is succeeding because companies are more accepting of LV in these types of large and potentially critical applications.

I’d say that LV reached this level of complexity around 2006 or 2007, when LV 8.2 or 8.5 was released, respectively. Around this time, NI was releasing a stream of development tools to aid in these large applications. These tools are listed below, with version requirements as an indication of initial release date:

• LabVIEW VI Analyzer Toolkit (LV 8)
• LabVIEW Statechart Module (LV 8.6)
• LabVIEW Execution Trace Toolkit (Real-time LV7.1 & Desktop 8.6.1)
• LabVIEW Unit Test Framework Toolkit (LV 8.5)
• Source Code Control (Configuration Management)
• LabVIEW Deployment (App Builder and Real-time)
• NI Requirements Gateway

I did not include LV version numbers on the last few items because they’ve been around for a long time or don’t rely on LV. (Note that LV 8.0 was released in 2005, 8.2 in 2006, 8.5 in 2007, and 8.6 in 2008.)

The point I’m trying to make here is that large application development is not simply about LV anymore. Now, developers need to know about a variety of tools that simplify their development efforts but burden you with time spent on learning. Of course, not every tool is necessary for everyone, but even knowing their benefits can consume time. I’ll try to reduce that burden with the following quick explanations.

• LabVIEW VI Analyzer Toolkit: The thrust of this tool is to help developers assess and standardize code development by providing various numerical measures of VI code. By reacting to these measures and changing code and coding style, the VI performance can be improved and coding styles can be standardized. For example, the measure called ‘cyclomatic complexity’ is useful as a benchmark indicating the difficulty in developing a black box test for the VI.
• LabVIEW Statechart Module: This tool allows the overall application to be developed via state diagramming, by defining state actions and transitions.
• LabVIEW Execution Trace Toolkit: The usual debugging techniques can solve a lot of issues in your code. But, for really difficult issues, this tool allows you to watch every VI event in sequence during run time. In addition, it reports memory and reference leaks and thread usage. You can even use it to trace an EXE, if it has been built to include debug info.
• LabVIEW Unit Test Framework Toolkit: Best coding practices start with a methodology that includes testing. Ultimately, you create a suite of test VIs and this tool helps you manage and utilize that suite. With this tool, you can automate testing of your application, generate result reports, and check for coverage of your testing on your application VIs.
• Source Code Control: LV has supported SCC tools back to version 7 (or 6?). I think it’s fairly standard for people to use SCC on multi-developer projects, but even single developer projects should use SCC to reduce the risk of an unintended change in code or an inadvertent loss of files. The challenge with SCC is the introduction of new or updated tools and the need to learn them anew.
• LabVIEW Deployment: With the Project Window, you can configure deployments to various targets, such as Windows, real-time, and FPGA. Each one is fairly straightforward. But, it can be challenging to figure out what files are needed if you intend to deploy the same application to multiple systems.
• NI Requirements Gateway: Applications are being subject to more process and rigor. You must assure that the functionality of the delivered application satisfies all the required functionality. This tool assists with the tracking of all the requirements and which VIs or application features delivered on each requirement. In the FDA-regulated world, this tracking is called a traceability matrix.

Conclusion

Application development has been blessed and burdened with new capabilities in development environment and development tools. I listed several relevant tools offered by NI in the past few years. The equivalents of these development tools are already commonplace in the text-based development world, such as offered by Microsoft in the .NET development environment. And, I’m sure that NI will continue to improve their tools. The upside is better code and applications, but you’ll have to spend some time to learn.