|
LabView follows a data flow-based model for running virtual instruments. A block diagram node executes when all its inputs are available. When a node completes execution, it supplies data to its output terminals and passes the output data to the next node in the path. For example, consider this PID loop implemented in LabView. In this case, the block diagram executes from left to right, not because the objects are placed in that order, but because the PID function cannot execute until its inputs have passed on information about a setpoint, gains, and the process variable. In general, nodes execute only when data are available at all their input terminals. They supply data to their output terminals only when they finish execution. Since its invention 20 years ago, LabView has expanded to run on various platforms such as the CompactRIO system shown here. |
|
Designers typically prototype embedded designs on COTS (commercial off-the-shelf) hardware which may include FPGA logic. Flow-based programming tools such as LabView permit development of algorithms on a COTS platform which can then easily port to a custom embedded system for actual deployment, if needed. |
Mike Trimborn
National Instruments Corp.
Austin, Tex.
Edited by Leland Teschler
A Venture Development Corp. survey last year found that nearly 48% of the total production cost of embedded systems comes from software development. That’s one reason graphical system design is attracting interest. It is a way of boosting the productivity of both professional programmers and of people who devise the algorithms that software implements. Graphical-system design uses graphical-programming languages, such as National Instruments LabView and commercial off-the-shelf (COTS) hardware, to address these productivity issues. Tools such as LabView also address vertical design areas that include the design of motion control systems, digital filters, communication systems, and more. Programs that implement graphical-system design are embodiments of what is called graphical-data-flow programming. It is useful to review the underlying concepts behind graphical- data flow to better understand how programs such as LabView can simplify design tasks. Interestingly, graphical-data flow only recently has started to come into wider use in combination with graphical-design aids. For many years, LabView was perhaps the most visible example of graphical-data flow applied towardthe design of engineered systems, many used for testing. This year marks the 20th anniversary of LabView, and only now, combined with graphical aids, is it finding mainstream use elsewhere. Microsoft, for example, says it will use graphical-data-flow techniques in its Robotics Studio programming Suite scheduled for release later this year. This suite of programs, among other things, will let students work with Lego Mindstorm robotic components. And LabView has been applied in Mindstorm educational settingsfor several years.
The key point about data-flow programming is that it defines applications as networks of “blackbox” processes. These processes exchange data across predefined connections. Graphical-data flow gives the user access to these black-box processes only through their connections. Also, blackbox processes can be viewed as reusable components that don’t know the name of other black boxes with which they communicate. Users can reconnect different black boxes endlessly to form different applications without having to change any of the blackboxes internally.
Data-flow programming gets its name from the fact that application developers need only work with flows of data through these connections rather than having to define a sequence of commands as with conventional sequentialprocedure code. The fact that data-flow programming defines applications in terms of modular black-box processes makes it work well with multiprocessor computers, and also as modern embedded software.
WORKING WITH BLACK BOXES
In IT lingo, the streams of data passing between black boxes are called information packets and the connections through which they pass are bounded buffer connections. Each process identifies its related connections by port names, rather than directly. A connection engine or scheduler routine relates port names to the real network and drives the individual processes. Moreover, the list of connections that define an application is defined separately from the internal logic of the processes. So it is appropriate to view applications as a system of data streams being transformed by processes, rather than as one step after another taking place until all the data is processed. In a graphical-data-flow application, numerous processes proceed concurrently, and it is the bounded buffers that ensure work can proceed in parallel this way using finite resources. However, people who develop applications in a data-flow system quickly forget about such mechanisms and just think in terms ofconnections among processes.
The classic example is the spreadsheet where users specify a cell formula which can depend on other cells. When any of those cells update, the first cell’s value automatically recalculates. One change can initiate a lengthy chain of changes when one cell depends on another cell which in turn depends on yet another, and so forth. But data flow is not just for recalculating numeric values as inspreadsheets. It can be used to re-draw a picture as directed by mouse movements. Thus a graphical- data-flow application becomes essentially a list of connections, which can be generated by a graphical tool. LabView follows such a model for running virtual instruments (VIs). A block diagram node executes when all its inputs are available. When a node completes execution, it supplies data to its output terminals and passes the output data to the next node in thepath.
In particular, this approach can change the way developers look at engineering applications. An example of designing digital filters shows how. In this case, a domain expert can interactively design a high-level description of filter parameters as for a low-pass filter response, and automatically convert the description to a fixedpoint version using LabView. Once converted to fixed point, the tool can run simulations to compare fixed and floating-point implementations.
The filter designer can iterate on the design until they are satisfied with the simulation results. At this point they might turn the code over to an engineer who specializes in designing code for embedded applications, and who would actually devise a form of it for implementation.
Conversely, coders who need to tweak the algorithm can make the needed changes and regenerate updated LabView or C code. The fact that both domain experts and computer engineers can use one platform and the same tools makes the development process more efficient. A graphical approach implemented today also provides a consistent interface for I/O components. I/O nodes serve as simple interfaces to basic components for analog and digital I/O.
Additionally, these I/O nodes give developers access to specific device drivers for reading and writing to peripherals such as serial or Ethernet interfaces. Graphical paradigms also give engineers the ability to write C code within the graphical context as a means of tweaking the performance of critical software routines. The proper execution of the graphically developed application, plus any tweaking done in other languages, is ensured by porting the graphical paradigm to a third-party C cross compiler. The compiler will link, compile, and download the code to the processor that will actually run the application.
DEALING WITH COMPLEXITY
Graphical-development systems help domain experts prototype and deploy algorithms. In recent years they have also reduced the degree of knowledge developers need to have about the physical makeup of the computer systems running the algorithm. Platforms such as LabView abstract many complexities involved with real-time and FPGA development Developers need only learn one language to implement all the programmable components of their system, which can include real-time processors and FPGAs. To illustrate, consider an automotive engineer developing an electronic-control unit (ECU) for an automobile. An ECU, of course, handles everything from timing the ignition coils to turning on the headlights. The graphical-system design approach is flexible enough to let the engineer integrate into the system additional design tools or existing IP from athird party.
One company using the Lab-View approach for ECU development is Drivven, which specializes in ECU research. Drivven creates a wide range of custom devices and IP for implementing ECUs and for connecting them to the outside world. Drivven uses the NI CompactRIO embedded system to prototype many of its designs and even created custom CompactRIO modules. (See MACHINE DESIGN, 9/16/04, pg. 33.) CompactRIO is a COTS platform that includes a real-time x86 processor, an FPGA, and modular industrial I/O.
Drivven’s custom modules connect directly to cam and crank sensors, ignition coils, and spark plugs. Additionally, Drivven developed a library of IP for FPGAs to customize and tweak the sensor interfaces. Bringing its IP into LabView let Drivven engineers use a simple block representation for processes that are inherentlycomplicated.
Drivven implemented a fully functional ECU simulator for the Yamaha R6 on the CompactRIO in about three man months, including development time for custom CompactRIO modules. Engineers developing the ECU can use direct calls within the graphical environment to implement the control code on a realtime processor. With prototyping complete, engineers can use graphical-system design platforms to deploy their code to a final, custom device. LabView can target code to any 32-bit processor. Using the same platform to target custom devices provides a much easier and efficient transition from prototype to deployment.
MAKE CONTACT
National instruments, ni.com