Simplifying Real-Time Math Algorithm Development with NI LabVIEW

What is an embedded system? Although not a clearly defined term, an embedded system usually exhibits the following traits:

•Performs a dedicated function (as opposed to a desktop PC designed to perform many different functions)
•Incorporates different types of I/O (as opposed to a PC, which uses a keyboard and mouse for I/O in most cases)
•Features real-time restraints (to perform dedicated functions, its response to events must occur within defined times)

Whether an embedded system is a cell phone, a traffic light controller, or an industrial machine stamping out widgets, it generally meets these criteria. The brains of these systems – the embedded software running on the device – often require some kind of advanced mathematics to perform a signal processing or control function. In many cases, a domain expert in signal processing or control designs the math algorithms that define how the embedded system operates. The embedded software development process becomes complicated when you move these algorithms from the design environment on the desktop PC down into the embedded system processor so that it can process the I/O and meet the real-time requirements of the device or machine.

Algorithm engineering is an approach to design where the desktop algorithm design environment is seamlessly merged with the embedded engineering process through a single software language, which streamlines the process of design to implementation and potentially reduces the number of steps and people involved in the process. Real-time math is the mathematical input in this design process. It is the implementation of deterministic mathematical algorithms for deployment to embedded hardware.

Figure 1. Algorithm engineering requires several iterations between the design and prototype phases of development.

Traditional Approaches to Design

Traditional design approaches often require you to abandon not only the prototyping platform when you reach the final deployment phase but also your developed code, which results in additional time and cost in the development cycle. Developers have used low-level programming languages, such as ANSI C and C++, for years, and they share a somewhat common syntax familiar to programmers. However, the lack of “built-in” signal processing libraries that are portable from platform to platform, or hardware target to hardware target, requires these algorithms to either be integrated from a third party or developed from scratch, which is both error-prone and time-consuming. In addition, the underlying textual syntax of the language may not intuitively map well to the numeric algorithms being expressed. Consider the following example.

compared with:

[A,B,C,D] = cheby1(n,R,Wp,'ftype','s')

 

In contrast to low-level languages, generic math software packages, such as Scilab, The MathWorks Inc., MATLAB^® software, MapleSoft, and Mathematica, employ high-level abstract languages intended for mathematical exploration. However, deploying those algorithms can prove difficult because there is no direct translation from the implementation language to hardware. This translation is often a multistep process (see Figure 2) that involves not only the burden of intermediate languages and additional tools but also an additional process to verify that the translated code is equivalent to the initial implementation.

Figure 2. The process for deploying an .m file developed in a traditional mathematics tool to a multicore real-time hardware target can involve several complex steps.

Because these tools employ highly abstract languages, they lack some key characteristics necessary for hardware deployment. Consider .m file scripts used by MATLAB^®, Scilab, and others. The .m file language is loosely typed, meaning the data type of a variable can change at run time without explicit casting. While this can be valuable in a desktop environment where memory is abundant, dynamically changing a variable’s data type during an operation introduces jitter, which could violate the application’s timing constraints in a real-time scenario. The lack of explicit resource management functions and timing constructs further complicates the deployment of the .m file language to embedded hardware.

In addition to the cost of developing in a new environment, disjointed toolchains pose other challenges. Different or incompatible math libraries require integrating new libraries or developing algorithms from scratch, which can be time-consuming and error-prone.

MATLAB® is a registered trademark of The MathWorks, Inc.

LabVIEW: Real-Time Math Applied

The NI LabVIEW graphical development platform simplifies both the development and deployment of real-time math by offering the following:

• Multiple programming models
• Extensive built-in signal processing, analysis, and math libraries
• Simplified interactivity
• Tight hardware integration
• Inherent parallel programming for multicore and field-programmable gate array (FPGA) targets

Multiple Programming Models – While many LabVIEW developers predominantly use its graphical dataflow programming language, LabVIEW offers many other computational models such as configuration-based Express VIs, simulation loops, statecharts, ANSI C code integration, FPGA programming, and the MathScript Node for implementing your .m file scripts in LabVIEW applications. The benefit is flexibility. You can choose either one or multiple models of computation to best suit your application needs. A mathematical equation is best represented in a textual language, but configuring acquisition parameters for hardware is most easily done in a configuration window. Furthermore, these computational models give you the power to integrate your existing code, such as .m files, models, or HDL code, into the graphical development environment eliminating the need to redo work.

Figure 3. LabVIEW integrates multiple models of computation, or programming paradigms, into one platform to give you the flexibility to choose the best approach.

Built-In Signal Processing – With more than 1,000 functions for signal processing, analysis, and math, you have the flexibility to choose between several levels of abstraction for your algorithm. From low-level, point-by-point implementations of the fast Fourier transform (FFT) to high-level spectral analysis routines to industry-specific variations of the FFT for order analysis, LabVIEW provides the customizability that many applications require.

Simplified Interactivity – The LabVIEW GUI offers a level of interaction with algorithms that you can use to explore mathematical concepts by visualizing the effect that varying a certain parameter’s value introduces into your applications without the additional effort of rewriting code.

Figure 4. Use the LabVIEW GUI to easily interact with your algorithms.

Tight Hardware Integration – The integration of more than 7,000 drivers for rack-and-stack instrumentation to PC-based measurement hardware makes LabVIEW an industry standard for working with hardware. LabVIEW provides a seamless interface to take measurements from sensors across multiple form factors including USB, PCI Express, PXI, and Wi-Fi. You can also deploy LabVIEW applications to a range of targets, from low-profile embedded targets such as NI Single-Board RIO and ARM processors to high-performance real-time OSs with embedded FPGAs such as NI CompactRIO. This portability of hardware between desktop PCs and embedded targets can save time and money during the design phase when compared with hardware that has rigid and fixed I/O.

Multicore Programming – LabVIEW also simplifies the challenge of real-time math with its inherent multithreaded nature. Because of this, you can easily take advantage of hardware with multiple cores to maximize your performance. Traditionally, text-based programmers have been required to explicitly define threads in their applications using APIs such as OpenMP or POSIX.

Because text-based programming is inherently serial in nature, attempting to visualize parallelism in a multithreaded piece of code is difficult. On the other hand, consider Figure 5. Coders can easily visualize and program parallel applications by harnessing the graphical nature of LabVIEW. The software automatically generates threads for parallel sections of code, so engineers and scientists with little or no programming background can spend more time problem solving and less time worrying about the low-level implementation of their applications.

 
Figure 5.This shows a comparison of multithreading in LabVIEW and text-based languages.

By providing a single platform to design algorithms, test prototypes, and deploy hardware, LabVIEW gives you the ability to take math and analysis libraries all the way to embedded hardware.

Figure 6. LabVIEW bridges the gap between design and deployment by traditional tools.

Example Application

To explore how real-time math is applied, consider the development of a blood pressure monitoring system. Computerized biomedical devices serve as a good demonstration of products that rely on sophisticated algorithms to turn real-world signals into information that a user can understand.

Figure 7. Translating traditional implementations into a computerized form requires algorithm engineering and the ability to run code on a combination of desktop and embedded targets.

The majority of the data acquisition and conditioning is straightforward; however, the calculation of diastolic and systolic pressures is the brunt of the mathematical implementation. Because this code must eventually be deployed to an embedded target, you can use algorithm engineering to develop your calculation in an easily deployable manner. The many models of computation within LabVIEW give you the flexibility to choose your design approach. This example uses the .m file language through LabVIEW MathScript and implements the pressure calculation in a short script. Because you are working with LabVIEW, you can use a GUI to interact with your algorithm as you develop it, constantly iterating until your design is final.

Figure 8. You can use the GUI to control your algorithm parameters and instantly see how your adjustments affect your calculations.

Although this example demonstrates how to implement the algorithm using MathScript language via the LabVIEW 2009 MathScript RT Module, you can also implement the algorithm graphically. Figure 9 demonstrates equivalent implementations of the algorithm in MathScript and graphical LabVIEW. The input and output variables of the MathScript Node can interact with front panel controls and indicators, hardware I/O, graphical LabVIEW code, or any other computational result in your application.

Figure 9. LabVIEW provides multiple modules of computations for the implementation of your algorithms.

With the final algorithm validated, all that remains is deployment to an embedded platform. NI CompactRIO is the final platform for this example because of its embedded real-time OS, flexible I/O modules, and rugged characteristics. Traditionally, deploying a .m file to embedded hardware has required translating or reimplementing your code in C. However, the new LabVIEW MathScript RT Module provides the functionality to deploy custom .m files in LabVIEW to embedded hardware. With this new module, you can deploy your custom .m files to all NI real-time platforms as easily as if you were using a native LabVIEW VI. This example used the LabVIEW Project Explorer to configure the hardware and then deploy the application with a simple drag-and-drop operation.

Figure 10. Deploying your custom .m files to embedded hardware is as easy as a drag-and-drop operation with LabVIEW and the LabVIEW MathScript RT Module.

The LabVIEW MathScript RT Module enforces strict typing on the .m file language within the context of the LabVIEW graphical environment for efficient data type propagation throughout the underlying code. Doing so ensures that LabVIEW can efficiently compile the text-based MathScript code and optimizes the .m file language for real-time OSs.

Finding the Right Balance

Developing real-time math applications requires finding the right balance between the ease of implementing a mathematical algorithm and the ease of deploying that finished algorithm to deterministic, embedded systems. LabVIEW offers just the right balance by simplifying both sides of the equation. For more than 20 years, engineers and scientists have used LabVIEW to develop and test native math libraries because this graphical environment provides the flexibility to work within many levels of abstraction. Combined with the easy integration of hardware and simplified multicore programming, LabVIEW provides a simplified path for real-time math.

Explore LabVIEW 2009. 

Learn more about deploying text-based math to real-time hardware. 

Reader Comments | Submit a comment »