We are deep in the middle of planning for 2010 right now. One of the areas we want to continue to invest in (or perhaps raise our investment) is around user groups. Working with user groups can be a tricky topic for us – the best groups are those run completely by customers, and they tend to be the ones who don’t want a lot of interference from NI trying to “sell” them on products. On the flip side, we are often asked for new technical content that can be used for user group presentations. 

Feel free to comment on this topic – I’ll create a poll to make it easier to respond:

Physical User Groups
If you are looking for more information on user groups. you can learn about physical user group meetings in your area at http://www.ni.com/usergroups

Virtual User Groups
We have a new capability on our Web site for creating virtual user groups. Most of these are organized around specific topics like “Building Large Apps with LabVIEW” or “RF Testing” and so on. You can see a list of these at http://decibel.ni.com/content/groups

Feel free to comment with any specific ideas for future user group meeting topics you would like to see…

The other day I ran into LabVIEW developer Phil Joffrain, one of my friends from my R&D days, and asked him to share some of his tips for serious LabVIEW development – we settled on three “random tips about under-utilitized development features” as the approach. Phil is a hardcore computer science major who has been working at NI for 7 years. He has worked on our LabVIEW SignalExpress project, which is a unique combination of a LabVIEW-built application running within a C/C++ application framework – so Phil is constantly switching contexts in terms of programming language – he is an expert programmer using LabVIEW for professional development.

Here are three tips for hardcore users – this may be something new for you to consider, or it may be old news.

1. Type Defs:

Large application constantly need to pass around bundles of information. Bundles of information obviously come in different types, but more importantly, the type of information can sometimes change either midway through development, or from release to release. An easy way to bundle information in LabVIEW is to use a Cluster. Clusters, for example, which contain a fixed number of items could in the future need to contain more or less items. But when a cluster being used by a large number of subVIs needs to update, it’s simply not feasible to open each and every subVI to update the cluster being passed in by hand (or by writing a tool to do it). Instead, turning that cluster into a Type-Def solves this problem since changes made to a type-def update all consumers automatically. It’s also important to note that there are 2 types of type-defs in LabVIEW: regular type-defs, and strict type-defs. The difference (as the name implies) is in the level is strictness and the frequency by which the type-def will update when changes are made to it. Strict type-defs contain the most information about its contents and force updates most frequently. Now type-defs are not simply a good idea for large clusters of data, they are also very useful for single item types. Imagine for example, an internal API where a set of subVIs take in a control reference. If this is a strict reference (meaning that extra information about that control is associated with that reference), making a change to the original control will change the strict reference type and break that input to all our subVIs. Having a strict type-def which simply contains that strict control reference means that only one place needs to be updated, to automatically propagate that change. When a number of subVIs take in the same type of input or produce the same type of output is when using type-defs makes sense.

2. User-Defined Events for the Event Structure

Most large applications have to process requests or provide the application with actions to perform. The LabVIEW event structure is an ideal tool to do this. The common use case for the event structure is often associated with processing control value changes on a User Interface, but this is only scratching the surface of the event structure’s usefulness. First of all, what makes the event structure such a useful tool, is that it doesn’t poll the UI for changes, nor does it steal the CPU waiting for things to happen. When no timeout is set on the event structure, it is happy to wait and wake up only when needed (unlike old-style state machines that comprise of a while loop and case structure). But the main feature of the event structure that is often overlooked is User-Defined events. A developer can create custom events that can be received by the event structure. This allows the developer to create a messaging system to process requests and define actions to be performed. The powerful thing about User-Defined events is that a developer gets to dictate what information gets sent to that event via the event’s internal terminals. A very simple example of this is: you can create an event called “save”, which has a path attribute. When the event gets called, the path attribute can be accessed using that events terminals, and the application can save its state at the path given. It is the caller of the event who would have gotten to specify what path to provide. Old and alternative ways of doing this was to use a LabVIEW Queue, who’s elements would either be a cluster of the data you wanted to pass around, or a variant so that anything could be passed. Both of these techniques have issues. One places a burden on the type of data that can be passed in the cluster, the other places the burden on the receiver of the data to extract it from the variant. The event structure removes both of these burdens by allowing each event type to have different data passed to them, and by giving direct access to that data within the event case via the internal terminals.

3. LabVIEW Classes

A relatively new feature to LabVIEW which is becoming mainstream very quickly is LabVIEW Classes. The fear with using a new feature is often the potential instability and performance hit, but a lot of time and effort has recently be put into LabVIEW Classes to make them more stable, faster and quickly becoming a mature feature of LabVIEW. The benefits of using LabVIEW Classes are the same as using any object-orientated programming approach to a large application; scalability and modularized components are among the top reasons. A lot of large applications today need an easy way to “plug in” new features, or new tools. When these new features or tools share common information and common abilities with the existing ones, having a base class with that information and ability that a new feature or tool can inherit from simplifies code greatly. A new plug-in no longer needs to start from scratch nor start by copying over half the code, it simply “plugs in”. Adding the extra functionality to that new feature or tool’s class is all that is left. In addition, new information and abilities added to the base class are automatically also available to the classes that inherit from it.

In a recent post on sumerlin.com, the author bemoaned the fact that the software industry has made great strides in programmer productivity with new visual tools (like LabVIEW), but has done so at the expense of visibility into the size of the code. His blog harkens back to the exact day that his guys re-wrote more than 30,000 lines of FORTRAN and Assembly code for simulating satellite communications in LabVIEW in just a few days. This event was what pushed the author into the ranks of management because “at his age” he could no longer keep up with the latest productivity tools in the new “visual” programming world. (He actually never mentions LabVIEW, but instead he refers to GOOP - the graphical object oriented programming tools from Endevo/Flander)

First, let me say that our goal has never been to push people out of programming. In fact, through efforts like our partnerships with Lego Mindstorms and FIRST Robotics, we are working hard to bring more kids into programming. But that’s not the point…

The issue is that the programming industry, particularly in mission-critical application areas, has spent years building tools, tactics, and programmers’ intuition around traditional code complexity metrics like single lines of code (SLOC). Although we can find lots of examples where graphical programming is more advantageous than text-based code (see multicore), we can’t ignore all of the history and infrastructure built up over the years around text-based languages. Users need some methodology for measuring the complexity or size of their projects – for estimating project timelines/cost, for comparing programmer productivity, or for planning maintenance. 

We’ve built a lot of tools and integration over the past 5 years to address some of these traditional software engineering challenges with LabVIEW. More specifically, LabVIEW has tools built into the Professional Development System for measuring the complexity of your code, as well as some tests you can run with VI Analyzer for measuring cyclomatic complexity of code. This is just another one of the efforts we’ve made to map LabVIEW to the traditional programming process for large applications. 

My question to any of you LabVIEW users out there – are you using these complexity metric tools? Or better yet, were you aware of them? Let me know.

Following up on my earlier “LabVIEW on TV” post, I wanted to share with you a grass roots effort from a group of our AEs here in Austin who refer to themselves as Waterloo Labs. Our AE department is full of recently graduated engineers and computer scientists from some of the top schools around the country. Once they get more acquainted with our products and technology, they tend to find very creative ways to experiment with it. These guys are taking it one step further. They are combining our cool technology with their interest in movie making and multimedia, and creating their own web-based version of a MythBusters-like show called Waterloo Labs. I urge you to check it out – it’s pretty cool, in a geeky sort of way.

We spend a lot of our time in Marketing trying to figure out ways to penetrate the hardcore programmers of test and embedded systems out there with our graphical programming story. We are constantly looking for ways to make more credible arguments with benchmarks, case studies, and code examples to convince experienced programmers that LabVIEW is a valid alternative.

A different approach is to go after the next generation and get kids excited about our technology before they ever get “stained” with the traditional approach. We experiment with a lot of ideas to try to get kids interested in technology in general, and LabVIEW more specifically. Also, because our tools are so widely used, we have to learn how to market through the channels that are emerging – YouTube, Twitter, Facebook, etc. We do a lot of experiementing to see how we can get people interested in our tools beyond the traditional marketing approaches. These Waterloo Labs guys are driving right down the middle of all of this – and its all driven from their own interest and passion in the technology and the media. Their latest video has more than 200,000 views.

It’s interesting to talk to the crustiest, most entrenched, hardcore programmers who are so set in their ways that they swear they could never switch to LabVIEW even if they wanted. These sames guys are the ones who light up when you tell them that their kids can program robots with LabVIEW. Perhaps more cool videos like Waterloo Labs is what we need to be doing.

A little side note about NIWeek…

The last night of NIWeek, after the annual Wednesday night NIWeek party, I was reminded of the real reason you should consider coming to NIWeek next year. We stumbled into a bar on 6th street sat and watched an amazing blues guitar virtuoso jam out for about 3 hours of some of the most ear-splitting, face-burning, mind-blowing guitar pyrotechnics I’ve ever seen to a “crowd” of about 9 people for no cover charge. There is something really cool (and tragic) about seeing a talent that good in a place that small. It was awesome. 

So talk about all of the great networking and coding techniques you can pick up here when you are convincing your boss to come next year, but keep artists like Eric Tessmer  in mind. (and don’t forget a really good alarm clock – those Thursday morning keynotes are great)

• We have got to change our values in most of the western world with respect to how we view science and engineering versus other professions. Dean Kamen of DEKA Research and inventor of the Segway, among many other things, described this crisis most eloquently and I won’t try to reproduce all of it here. He did made one comparison that I found particularly instructive, though: he described countries and cultures as going through development much like individuals. They start life taking risks and learning quickly and over time become more risk-averse and conservative. In this sense, it is not a coincidence that the US was the great innovator in the world at the beginning of last century; we didn’t have smarter people, we were just willing to take more risks. Now, that risk taking has moved to other regions. He did mention that perhaps the set of crisis that currently face us will push us to reevaluate what is ultimately important in our culture and give us a renewed sense of purpose.
• We announced our co-development project with Tektronix on a high bandwidth PXI digitizer. This project is unique in that it leaverages the strengths of both companies to bring a unique product to the market that neither of us could have done alone. This got me thinking a lot more about the idea o Cooperative Innovation. In fact, I’m currently writing a column for Electronic Design on this subject. Look for it in the next couple of months.
• My kids loved the expo. As engineers, we all need to do a better job engaging our children and children in general on what we do. We often mistakenly think that our work is over their heads or will be boring to them. Instead, creating new things is fascinating to children and we need to encourage this. Of course, the fact that we had a “Robot Petting Zoo” didn’t hurt, either.
• Most of our community has dated impression of what NI does. So many of our key customers, after attending their first NI Week, say ” I now have a completely different impression of NI”. While it remains difficult to explain exactly what it is we do, as a marketer, this lays down a challenge to do a better job presenting our company’s vision to the world.

OK, that’s all I’ve digested for now. Time to get to work on NI Week 2010.

NIWeek 2009 is in the books, and NI as a whole is recovering from our annual NIWeek hangover. A few thoughts looking back at the week:

1. Attendance was stellar – we actually saw a slight increase in attendance over 2008 numbers. For those of you who were able to join, a big “thank you” for investing your time and energy by coming to the conference. We recognize that any kind of expense is going to be looked at very closely in these tough times.

2. Graphical System Design as a concept seemed to get its legs at this NIWeek. The notion of using LabVIEW beyond its test and measurement roots as a system design platform was evident throughout the conference. The tremendous activity around robotics was the strongest testament to this. Not just the technologies and success stories, but the people who showed up who are involved in this area was impressive – Dean Kamen, Ellen Purdy, Dr. Dave Barrett… (more on that in a separate blog entry – it’s justified).

3. The future of LabVIEW is bright – for the first time in awhile, we shared some of the new technologies that we are developing in LabVIEW and there was genuine interest and excitement from the users. In particular, we are doing some things to address some core issues with the product and language in the short term (next year or two), as well as starting to reveal some of our 3 to 5 year plans that will have an even greater impact. It’s always exciting to see the amazing solutions from our users each year at NIWeek. It’s even better to see the smiles and fist-pumps from users when you let them know where we are going to confirm we are working on the right things. (I’ll have to figure out how I can post on some of this stuff for those of you who were not able to make it to NIWeek).

4. The Austin Convention Center re-affirmed its position as the coldest building in North America. I think the HVAC system there alone could cure our global warming problem.

… more thoughts to come…. Anyone who was there, feel free to tack on with your own comments.

I had so many people ask me the same question, that I went ahead and created a new post to answer:

When you create a snippet, we indicate that fact two ways:

• the image is surrounded by a dashed line
• the snippet glyph is appended to the top of the image

See below for an example. Feel free to drag this into a blank LabVIEW 2009 VI to try it out. Or you can see more here.

NIWeek 2009 – Getting back to the (deeply technical) basics. 

That was one of our goals for NIWeek this year. In the past several years, we really pushed the envelope into application areas with the Summits – mini-conferences within NIWeek – on topics like RF, Sound and Vibration, Vision, Robotics, etc. These have been great at attracting experts from these areas and having more topical discussions about trends and techniques. However, we still believe that NIWeek at its core is about LabVIEW and what you can do with it. This year, we made a concerted effort to “go deep” and deliver very technical presentations at the conference. Two areas where we got a lot of great attendance and feedback were on the LabVIEW Scripting session and the LabVIEW for large applications. 

The scripting session had over 180 people in attendance. Scripting refers to the set of APIs you can use to edit or generate VIs – use LabVIEW to create macros if you will. You can learn more about it at our LabVIEW APIs community group. We also highlighted some pretty cool uses of scripting in a video we showed during Jeff K’s keynote. Check it out:

The LabVIEW for Large Apps sessions was standing room only as well. It covered all the tools and techniques for using LabVIEW in a large, team-based environment for large projects, including topics like:

• Configuration Management (Source Code Control, Diff, Merge, etc)
• Requirements Management
• Testing and Debugging (Unit testing, dynamic and static code analysis, etc)
• Documentation and validation

Yes, we have tools for all of these. Check it out at at www.ni.com/largeapps

The next version of LabVIEW will be coming to a presentation near you very soon. I thought I would share the back story about one of the new features that you will see called the VI Snippet. 

First, the problem statement. For many years, we’ve been working on better ways to empower users to share their code with other users – through better Web features on ni.com and better ways of packaging and distributing your VIs. The popularity of the platform, and the expertise of our user base, can be measured in some ways by the number of VIs available on the Web – it’s a kind of currency for LabVIEW. 

We have a few challenges in enabling users to share code:

1. LabVIEW is graphical, so you really need to see the block diagram to understand what techniques you want to learn more about
2. Seeing the diagram ins’t enough – it needs to be easy to get the VI from a Web site into your LV environment so you can experiment with the code. One advantage text-based languages has is you can simply cut and paste text from any document into your environment to transfer it. LabVIEW code needs to move that easily. 

With these seemingly insurmountable hurdles in the way, enter the Hogg – that would be Simon Hogg, one of our talented young LabVIEW product managers. Simon had some ideas on how we can create a better experience for users to share code, but rather than try to convince R&D to build something, he went off and built it prototyped it himself (the beauty of LabVIEW for fast prototyping). The idea is simple, but when implemented comes across as magical. In LabVIEW 2009, you create a special screen shot of your VI – called a VI Snippet – which embeds the actual binary information of the VI into the image. You can then post that image anywhere on a Web page and other users simply drag the image onto a blank block diagram in LabVIEW and voilá! – the actual LabVIEW code is there, ready to explore, edit, or run. Check out the video below to see it in action:

Once Simon created his prototype, it was quickly dubbed internally as “the Hogg Feature” or “the Hogg” for short. We’ve even taken it to its verb form – similar to “googling” or “xeroxing” something, when you distribute a VI Snippet, you are “hogging it.” 

Naturally, there was the small step of actually designing, implementing, and testing the feature in R&D to make it work in the product for real – but having a working prototype was a great influencer. If one of our product managers can prototype the feature, then certainly our R&D guys can develop it. 

So I wanted to share this story to show that even the best-laid plans at NI to smoothly manage the feature set of upcoming LabVIEW versions can be disrupted here when someone combines initiative with the power of LabVIEW programming to make something happen (and because the Hogg is a cool feature). I look forward to “hogging” some VIs posted by the c0mmunity of LabVIEW users in the near future.

I’ve been busily updating our LabVIEW roadmaps for NIWeek next week and once again I am faced with the challenge of creating a presentation that is relevant to a crowd of LabVIEW users – we are doing so many things with LabVIEW, that is more difficult than you think. So as I am preparing for next week, I thought I would hit the user base to see what you guys want to know. 

My goals for a roadmap presentation are:

1. Show your loyal users that you are hearing them and understand their concerns, and share our plans to address these concerns

2. Explain our higher-level strategy and investment directions (for example, if you aren’t considering the benefits of using LV FPGA with our RIO architecture, you need to)

3. Recap where we are today – most users can’t keep up with everything we are doing

4. Speak to the skeptics in the room with an honest assessment of key issues that have and share plans to address those issues (to push them to reconsider)

5. Capture reactions to our plans, questions, and open issues from the customers at hand.

Maybe I am missing something. Respond with any other general topics that you would like to see in a LabVIEW roadmap discussion, or send in specific questions or comments so I can comment and/or include them in my presentation.

I found the article particularly inersting as it articulates some common challenges I’ve been seeing in semiconductor characterization that I believe PXI and LabVIEW are very well-suited to solve. We are, in fact, seeing a major uptick in the use of these platforms in applications such as these. Another technolgy that I believe will be important in these applications is the user-programmable FPGA. I discussed this trend in a previous post on Protocol Aware ATE.

1) A large number of LXI instruments already had Ethernet connectivity and then added LXI compliance;

2) Many LXI instruments also have other buses that can be used to connect them to a PC, such as GPIB and USB; and

3) Not all standalong instruments are connected to a PC at all.

Not that these issues are a problem for users - it makes sense to have standards around implementation of Ethernet instruments and it makes sense to give users a choice of connectivity options. The only problem is that these numbers are positioned this way to influence public opinion; in this case, to imply that the use of LXI is greater then it actually is. I don’t blame the LXI group for trying, but I do commend Martin Rowe for questioning the report.

Expansion of Wireless and Protocol-Aware Test
In addition to emerging technological advances, software-defined instrumentation has proved ideal for rapid-growth areas such as wireless and protocol-aware test. For example, consumer electronics devices including cell phones and automotive in-dash entertainment systems often integrate multiple communication protocols and standards such as GSM, GPS, and WLAN. Test engineers using traditional instruments rely on vendors to develop dedicated, stand-alone instruments to test each standard. With software-defined instruments, engineers and researchers can test multiple standards using common modular hardware components and implement emerging and custom wireless protocols and algorithms in their test systems regardless of the maturity of a new wireless standard.

For example, Dr. Umberto Spagnolini at the Polytechnic Institute of Milan is using LabVIEW to prototype algorithms for emerging standards such as WiMAX. Researchers such as Dr. Spagnolini can directly control system parameters, including channel coding, power, and modulation scheme, while adding fading and multipath interference to determine system immunity as a prototype of emerging WiMAX algorithms.

In the semiconductor industry, the demand for increasingly functionality and integration continues unabated. As a result, semiconductor companies are heavily investing in complex systems on a chip (SoCs) and systems in a package (SiPs) technologies. It is often difficult to fully verify these devices using traditional ATE, which has led to an increased demand for so-called protocol aware test or the ability to test devices by emulating the real-world signals connected to them.

These increasing requirements for semiconductor test and the need to reduce total test costs have led industry organizations such as the Semiconductor Test Consortium (STC) and the newly founded Collaborative Alliance for Semiconductor Test (CAST) to investigate standards around open test architectures that support the integration of modular, software-defined instrumentation such as PXI into traditional semiconductor ATE. By using software-defined, FPGA-based instrumentation in these semiconductor test systems, engineers can achieve real-time responses with the standard pin electronics found in traditional ATE, lowering the total cost of test through better use-case coverage and improving the user’s ability to debug failures.

Trend#2: Increased Adoption of Parallel Processing Technologies

Multicore technology has become a standard feature in automated test systems and a necessity for today’s electronic devices that are processing unprecedented amounts of data. Software-defined instrumentation takes advantage of the latest multicore processors and high-speed bus technologies to generate, capture, analyze and process the gigabytes of data required to properly design and test electronic devices. Multicore architectures can present a challenge when used with traditional text-based programming environments that are not inherently parallel and require low-level programming techniques. However, test engineers quickly can realize the benefits of multicore technology through inherently higher level programming environments such as LabVIEW, which automatically distributes multithreaded applications across multiple computing cores for maximum performance and throughput.

Many test engineers I talk to are already experiencing the challenge of programming multicore in that, for the first time, they are not seeing an increase in test system performance when updating the PC in the system. In fact, due to the potentially slower clock rates of many multicore processors, their systems may actually run slower!

On the other hand, Alejandro Torres, senior manufacturing test engineer at Sanmina-SCI, provided an example of the potential business benefits attained by using programming tools tuned for multicore technology when he stated, “By leveraging the multicore technology in LabVIEW and the latest NI multicore PXI embedded controller, we were able to increase our test throughput by one additional workday per week. Best of all, we achieved this throughput increase by simply upgrading from a previous-generation PXI single-core embedded controller to the latest NI PXI multicore embedded controller with only minimal changes to our code.”

Another area of growth for software-defined instrumentation is the increase in system-level design tools for FPGAs. Many modular instruments now come equipped with FPGAs, including several released in the past year that offer the high-performance Xilinx Virtex-5 FPGA. These FPGA-based instruments provide test engineers with the ability to implement more complex digital signal processing at faster rates than ever before. Because software programs such as LabVIEW give test engineers the ability to program FPGAs without requiring knowledge of VHDL, the performance benefits of FPGAs are no longer limited to a subset of hardware engineers with extensive knowledge in digital design.

Next week, I’ll post on the third trend, the Expansion of Wireless and Protocol-Aware Test.

These demands have led to three major trends that I believe will significantly influence the Test and Measurement industry over the next year. Instead of blogging them all here today, I will share one per entry over the next few weeks.

Trend#1: Growth of Software-Defined Instrumentation

The adoption of software-defined instrumentation is the most significant trend in test and measurement for 2009. Software-defined instruments, also known as virtual instruments, consist of modular hardware and user-defined software that give engineers the ability to combine standard and user-defined measurements with custom data processing using common hardware components. This flexibility has become critical as electronic devices such as next-generation navigation systems and smart phones integrate diverse capabilities and rapidly adopt new communication standards. Using software-defined instruments, engineers rapidly can reconfigure their test equipment by modifying software algorithms to meet changing test requirements.

In addition, engineers are using software-defined instrumentation to achieve new levels of measurement performance and lower test costs by applying the latest technological advancements such as multicore processors and field-programmable gate arrays (FPGAs) in their test systems to meet the demands of new application areas such as wireless and protocol-aware test.

Because of the flexibility and cost-effectiveness of this approach, thousands of companies are adopting software-defined instrumentation and industry standards that build on this approach continue to grow, even in the difficult world economy. For example, according to the PXI Systems Alliance, more than 100,000 PXI systems will be deployed by the end of 2009, and the number of deployed PXI systems is expected to double in the next decade.

Jessy Cavazos, test and measurement industry manager at Frost & Sullivan, recently confirmed that PXI is influencing this trend when she stated, “The open, modular architecture of software-defined instruments such as those in PXI have proven beneficial to a wide range of industries, and, as a result, PXI revenue in measurement and automation is expected to grow at 17.6 percent CAGR through 2014. The performance delivered by the PXI platform has successfully addressed areas such as RF applications in radar testing, mobile phone testing and other wireless applications that were previously impossible to address with other instrumentation.”

Next week, I’ll post on the second trend, the increased adotoption of parallel technologies.

Testing more with less means that you may have to reevaluate your approach to test, and indeed, it is in disruptive conditions such as we now face that new ideas are the most prone to take hold. I believe that modular, software defined test systems provide the greatest opportunity for testing more with less – regardless of the dimension where optimization is needed. For example, optimizing the test speed of a production system is often the best path to decreasing test costs. For other applications, reconfiguring a single tester to test multiple devices yields the best results. And in very complex testers, the capital cost may the focus for cost reduction. For each of these situations, and in many others, the software-defined approach has proven time and time again to deliver dramatic improvements.

Let me share a few examples. In a production system, time is, quite literally, money. If you can reduce test time by ½, then you may be able to put half the number of testers at the end of a line. Wireless devices, in particular, are often expensive and time consuming to test. Many cellular phones are still tested with a inefficient method called “call-processing”. In this approach, a device called a “one-box tester” is used to actually simulate a phone call to the device under test. Bringing a phone up into a call is slow and is unnecessary to test if the device is correctly assembled. This would be like testing a television by watching a movie on it, instead of simply sending it a test pattern and verifying the result. More and more cellular handset manufacturers are moving to a software-defined test system that instead tests the physical layer signal of the device and uses signal processing in software to perform the necessary tests to verify each type of wireless standard. This technique is often 2-5 times faster than call-processing, which results in huge savings for the manufacturer.

Another example of achieving cost savings with a modular, software-defined approach is to use the flexibility of software to reconfigure a system to test many different types of devices. Another challenge in wireless test is that many devices have multiple wireless standards. My beloved iPhone, for example, now has 5 radios! Often, these different standards have required different instruments with their own vendor-defined measurement routines. A software-defined system can be reconfigured to test each standard with the same hardware. And when standards inevitably change and evolve, a software-defined system is in a much better position to be able to react to these changes.

A final example is in semiconductor ATE. Many semiconductor devices are tested on so-called “Big iron” testers. These testers have the sophisticated digital infrastructure and pin-electronics to test high performance semiconductors such as processors and SOCs. For simpler devices with low target prices, such as a MEMs sensor or an RFID, however, these testers may be overkill. Because they have the infrastructure to support high performance, it is difficult to scale them to these simpler requirements. A modular, open system such as PXI, though, has a very low entry cost and can be configured with only the minimum required capability, which results in lower capital expenditure.

So, in these turbulent economic times, it will be up to test engineers to innovate using the latest technology to meet the challenges of testing more with less. And those companies and individuals that do this the best will be able to come out of this difficult time stronger than before and ready to take advantage of new opportunities as conditions improve.