Choosing a Software Architecture for Programming NI Linux Real-Time Systems

Publish Date: Mar 16, 2015 | 3 Ratings | 5.00 out of 5 | Print | Submit your review


The first step in designing your NI Linux Real-Time system is to choose an application software architecture. This is the top-level program that will communicate to I/O, run analysis and make critical decisions based on inputs and outputs. There are multiple software design patterns, and deciding between them requires an understanding of what makes an NI Linux Real-Time system “real-time.”

Table of Contents

  1. Real-Time Operating Systems
  2. Software Design Patterns
  3. Next Steps

In embedded system design, a real-time OS (RTOS) has to respond to externally generated input stimuli within a finite and specified period.[1] In other words, the system must respond to inputs deterministically. Most practical applications that fit this definition fall into three categories: event response, closed-loop control, and embedded monitoring. To find out if an RTOS is right for your application, read Do I Need a Real-Time System?

Figure 1. Examples of real-time applications include event response in airbag systems, control within unmanned aircraft, and long-term structural monitoring.


1. Real-Time Operating Systems

Continue reading this section to learn more about how real-time operating systems enable specialized applications to execute within their design constraints.

As an RTOS, NI Linux Real-Time uses a real-time scheduler to execute event response, closed-loop control, and embedded monitoring applications within their time constraints. The following section gives a high-level overview of real-time concepts; for an in-depth explanation of this information, read What is a Real-Time Operating System?

NI Linux Real-Time employs a strict priority system to allow for multithreading while maintaining determinism. The priority system is much more rigidly enforced in real-time than in a general-purpose OS, which favors a round-robin system in which each thread is guaranteed a certain amount of processor time. On an RTOS, you can specify in software which thread has the highest priority and know with certainty that its execution will always preempt other threads.

It follows that enforcing determinism has implications on how you structure your code. All deterministic operations must be kept within a distinct task, which is given top priority. Typically, there is only one deterministic task per real-time application, although multiprocessor architectures provide the option for parallel time-critical execution. Lower priority, nondeterministic operations (such as network communication) are contained within one or more separate task, which execute after the time-critical task has released resources.

There are many other factors to consider when developing a real-time system, but one of the most important is managing shared resources used by your application. A shared resource is any object that only one thread can access at a time – examples include certain data structures, I/O ports, drivers, or the memory manager. Failing to manage shared resources effectively can lead to a situation called “priority inversion,” where a time-critical task must wait on a lower-priority task to release a shared resource. NI Linux Real-Time uses a mechanism called “priority inheritance” to resolve priority inversions, but it is no replacement for established best practices such as real-time FIFOs, re-entrancy, and the pre-allocation of large memory blocks.

With these concepts in mind, it is clear that developing real-time software requires an added level of consideration over general-purpose programming. Therefore, it is important to choose the right software architecture that will fit your project goals and complement your programming experience.


Back to Top

2. Software Design Patterns

With NI Linux Real-Time, it is possible to target NI hardware using the LabVIEW Real-Time Module, C/C++, or a combination of both.


Figure 2. Choose the LabVIEW Real-Time Module, C/C++, or a combination of the two for targeting NI Linux Real-Time systems.


Design Patterns 1 & 2: LabVIEW RIO Architecture

The LabVIEW reconfigurable I/O (RIO) architecture combines LabVIEW system design software with reconfigurable off-the-shelf hardware. This architecture is based on four components: a processor, a reconfigurable FPGA, measurement I/O hardware, and LabVIEW. Using an integrated hardware and software platform built on the LabVIEW RIO architecture, you can simplify system development across a variety of industries and applications.


Figure 3. Use the LabVIEW Real-Time and LabVIEW FPGA modules to target the real-time processor, FPGA, and I/O in the LabVIEW RIO architecture.


The LabVIEW Real-Time Module includes a full suite of compiler, linker, and debugging tools with hundreds of math, control, and signal processing algorithms that run deterministically in NI Linux Real-Time.

FPGA chip adoption across all industries to augment processor-based systems is driven by the fact that FPGAs combine the best parts of custom designed ASICs and processor-based systems. With the LabVIEW FPGA module, engineers can leverage this technology in their designs without learning hardware description languages like VHDL.  Start learning more about the LabVIEW FPGA Module.

In choosing the LabVIEW RIO Architecture for your application software architecture, you have access to the following features out of the box:

  • A full integrated development environment (IDE) with built-in, automatic cross compilers for all NI real-time hardware
  • Integration of C/C++ shared libraries and applications
  • Enhanced debugger with the Real-Time Trace Viewer
  • Real-time FIFOs for deterministic inter-process communication
  • Timed Loops for setting timing constraints, specifying priorities, and dividing tasks between execution cores.
  • Watchdog functions for automatic recovery and maximum uptime.
  • Built-in analysis and control IP for your FPGA designs.
  • One-step deployment to NI hardware.

The LabVIEW RIO architecture provides all the tools to develop and debug sophisticated embedded systems in less time and with fewer resources; see examples here. To learn how to use LabVIEW to program your NI Linux Real-Time system, please see Using LabVIEW for NI Linux Real-Time System Design.


Design Pattern 3: Real-Time C/C++ Development With LabVIEW FPGA

You can also develop, debug, and deploy applications to the open embedded processor written entirely in C or C++ using Eclipse or any other IDE while gaining the benefits of LabVIEW for programming the FPGA.

As stated above, FPGAs combine the best parts of custom designed ASICs and processor-based systems in applications that span all industries. With the LabVIEW FPGA Module, you can use this technology in your designs without learning hardware description languages like VHDL. Learn more about LabVIEW FPGA.

The FPGA Interface C API provides a communication layer between the FPGA and real-time application for I/O control and data streaming. This offers an interface for accessing FPGA controls, indicators, DMA FIFOs, interrupts, and arrays.

To learn how to use C/C++ to program your NI Linux Real-Time system, see Building C/C++ Applications for NI Linux Real-Time.


Back to Top

3. Next Steps

Using LabVIEW for NI Linux Real-Time System Design

Building C/C++ Applications for NI Linux Real-Time


[1] Oshana, Robert and Mark Kraeling. Software Engineering for Embedded Systems: Methods, Practical Techniques, and Applications. Waltham: Newnes, 2013. Print.

The registered trademark Linux® is used pursuant to a sublicense from LMI, the exclusive licensee of Linus Torvalds, owner of the mark on a worldwide basis.

Back to Top

Bookmark & Share


Rate this document

Answered Your Question?
Yes No