Todd Dobberstein
NATIONAL INSTRUMENTS CORP.
AUSTIN, TEX.

Edited by Leland Teschler

Once upon a time, there was a company that was developing a relatively high-volume device that used a CompactRIO as its embedded computer platform. There was motor control involved, and the prototype built around the CompactRIO worked great. The prototype was done in record time and more than proved the concept. The company figured they were good to go to the next step.

That’s when they realized they had a dilemma: Go with the CompactRIO in the production version of the product, or build custom hardware to get the cost down. The latter approach would bring them back to square one. All the Lab- View code they’d originally written for the prototype would end up in the ash can. Ditto for the testing code. All in all, it would be an effective way of adding about nine months to the development cycle.

We can learn from the travails of this company about what can go wrong with an embedded computing project in the absence of advanced planning. Use of a commercial off-the-shelf (COTS) platform like the CompactRIO is often a good idea. COTS is frequently the way to go when getting an idea or concept to a functioning prototype quickly. But engineers make a strategic mistake if they have a mindset that the real work starts once the prototype is a success.

Of course, it is a natural idea to think about custom hardware as a way to drive down costs of a product destined for high-volume deployment. But this process adds time and makes the deployment process more complex. As the engineers in our example found out, it can often mean throwing out numerous person-hours of code work and starting over.

Fortunately, the COTS-or-custom decision today isn’t black or white. There are various COTS platforms available. They span a gamut ranging from systems that are nearly complete and self-contained, to modular equipment that is the next best thing to a custom design. Still, there are caveats that will help avoid a lot of wheel spinning regardless of the path taken. One should be clear about the trade-offs of COTS hardware platforms: You’ll pay more for the hardware but you can expect to reach the market much more quickly. In addition, COTS systems are scalable. They can be a convenient means of addressing the inevitable feature-creep that takes place after the first prototype.

There are three basic deployment technologies to consider when it comes to COTS: unpackaged embedded systems, packaged embedded systems, and industrial PCs. Unpackaged embedded systems are available in several form factors (Mini-ITX, PC/104, and so on). These often take the form of circuit boards and racks. Unpackaged embedded systems tend to be the most economical COTS in terms of hardware cost. These systems also host a variety of processor architectures and are characterized by a small operating system and I/O support that is basic.

Here’s the rub: The softwaredevelopment tools for such systems are almost never integrated. It’s not uncommon to use a processor board from one supplier and I/O from several others. The I/O drivers, of course, must either be written or integrated into the system so they work reliably. Guess who gets stuck with that task. And these systems typically require you to verify regulatory certifications such as EMI and CE compliance on your own. So get ready to book some time in an RF anechoic chamber somewhere.

Another factor to be aware of concerns the field-programmable gate arrays (FPGAs) now commonly used in embedded computing systems. Different FPGAs tend to use their own flavor of a hardware- description language (HDL). If you have never programmed in the language your FPGA uses, there is a learning curve to climb.

On the other hand, a packaged embedded system tends to be more self-contained. That means you can buy the thing more or less complete in its own housing. Besides featuring the same components as unpackaged embedded systems, packaged embedded systems deliver specifications for shock, vibration, operating temperature, and environmental certifications.

Obviously, these systems will generally be more expensive than a few boards plugged in a rack. But they often come with integrated software-development tools and a more-extensive set of integrated I/O options. Examples are Advantech’s Adam PC-based controller and the National Instruments CompactRIO embedded system.

Industrial PCs are a step up the chain from packaged systems. PC technology is readily available, and it’s easy to find programmers. Moreover, industrial PCs offer the most comprehensive options for development tools and I/O capabilities. They provide many of the same specification and certification advantages as other packaged embedde d systems. But these capabilities come at a cost. As you might expect, these systems are significantly more expensive than the other two options.

FPGA At the center
FPGAs deserve special consideration because they are at the heart of so many computing platforms. You can find FPGAs in COTS hardware products that include unpackaged embedded systems, packaged embedded systems and PCI FPGA boards for industrial PCs. FPGAs are an interesting middle ground between custom application-specific IC (ASIC) design and offthe- shelf technology. They are a means of defining specialized circuitry but are reconfigurable so they avoid the high fabrication cost that hampers ASIC and custom development. Thus an FPGA at the core of an embedded system helps create a high-performance and scalable system.

FPGAs typically off-load processing and critical control tasks from the embedded-system processor. This is partly out of convenience but mostly out of necessity. A processor-only approach just doesn’t work anymore with the increasing use of sophisticated algorithms and the trend toward more-complicated systems. Processors are still a main component and are ideal for networking, floating- point processing, and handling peripherals (displays, USB and serial devices, keyboards, and so on). But more and more, FPGAs are the preferred way to add processing power to an embedded system.

FPGAs typically handle such tasks as signal processing, control algorithms, and digital communication. The industry is even using FPGAs as processors. For example, there are several so-called soft-core processors built on FPGAs that emulate multicore processors. And there is a variety of FPGA IP available for signal processing, control, communication, image processing, and more. This eliminates the need to reinvent the wheel for widely used tasks.

Nevertheless, FPGA architectures are not all created the same. In a COTS platform, the location of the FPGA within the system can make a big difference in performance. Obviously, the FPGA should connect directly to the processor if it is to off-load processing tasks. So a high-speed data bus or data path between the processor and FPGA will facilitate off-loading. This data path is often a bus but could also be a serial interconnect: PCI, PCI Express, USB 2.0, Serial ATA, IEEE 1394, and so on.

When such systems are built around a data bus, bus latency is a factor to be aware of. This is a gauge of whether there will be delays associated with FPGA/processor interactions. It is hard to give general numbers for latency figure of merit. Designers must evaluate each situation in context.

I/O location is important as well. There are advantages to having the I/O for control and acquisition connected directly to the FPGA rather than through a bus. FPGAs are parallel devices so they can control several I/O devices on a fine-grain level of timing. And of course, there is no bus latency or overhead in a direct connection between an FPGA and I/O.

An example of a COTS that has an FPGA at its center is the National Instruments CompactRIO packaged embedded system. It uses a Xilnix FPGA and a Freescale PowerPC microprocessor with the VxWorks real-time operating system. The PowerPC connects to the FPGA via an internal PCI bus. In addition, the FPGA ties directly to connectors for various analog and digital I/O modules. These typically go to such I/O as sensors, actuators, communication buses, or to custom-designed I/O.

A word about software development: Traditionally, FPGAs are programmed with low-level hardware description languages such as Verilog or VHDL. To actually use these tools, you need a good amount of experience in hardware design. Fortunately, there are alternatives for firms lacking that experience in-house. An example is National Instruments LabView FPGA programming software. Users program FPGAs sitting in their target systems with intuitive, easy-to-use graphical function blocks. There are also programming tools from companies that convert C code to VHDL.

Early Deployment Planning
The point of early planning is to make the hardware and software of the prototype system match, or come close to matching, that of the deployment system. The more the planning, the less the likelihood of rework later on.

Although it may sound obvious, the COTS vendor you choose for the prototype should have deployment hardware that performs well enough with a cost that is acceptable for the application needs. What you are looking for here is a standard hardware architecture shared among different deployment components. Of course you want to use the software designed for your prototype in the deployed system. This is generally the whole reason for staying with COTS hardware for deployment rather than building something custom; or at any rate, it should be the reason. Software reuse not only avoids wheel reinvention. It also maintains a consistent code base throughout prototyping and deployment that allows more time for code testing. Reliability goes up, testing and development time go down.

One example of a COTS deployment path is the various hardware platforms that all share a common reconfigurable I/O (RIO) architecture. This National Instruments architecture combines a real-time processor, an FPGA, and a wide variety of I/O that includes analog, digital, motion, and communication. The National Instruments RIO deployment curve includes industrial PCs such as PXI and other commercial industrial PCs and packaged embedded systems like the CompactRIO embedded system. It goes without saying that the LabView code developed on one of these platforms runs on the others.

Finally, use of COTS hardware for deployment also creates a more maintainable machine. It’s the COTS vendor, not you, that must worry about components going end-of-life. Ditto for rebuilding hardware when the need for a redesign comes around.

Make Contact
CompactRIO page, www.ni.com/compactrio/
National Instruments Corp. FPGA page, www.ni.com/fpga/
Video of Sanarus Medical Inc.’s Jeff Stevens describing Visica 2 at NIWeek, tinyurl.com/223urn