Top 5 Considerations When Choosing an Embedded OS for NI CompactRIO

Publish Date: Feb 24, 2014 | 1 Ratings | 1.00 out of 5 |  PDF

Overview

National Instruments offers a choice of embedded OSs to meet your application needs: NI LabVIEW Real-Time and Microsoft Windows Embedded Standard 7 (WES7). Each OS offers advantages for different tasks and operations. LabVIEW Real-Time offers determinism and reliability for mission-critical tasks and closed-loop control, while WES7 provides an extensive ecosystem of software and integrated user interface capability.

Many considerations go into determining the best OS for a particular application. This guide weighs the advantages and challenges associated with each option to help you make the best choice for your application.

Before evaluating your application needs in light of this guide, consider one key difference in the application development experience of LabVIEW Real-Time and WES7 that may be important in helping you decide what OS to use. LabVIEW Real-Time allows you to create your application using a remote development PC. Using this PC, you can create VIs, debug your application, and easily deploy it to your CompactRIO target. For WES7, you can choose to follow the same development pattern as LabVIEW Real-Time, or to install the LabVIEW Development System and the LabVIEW FPGA module directly on the CompactRIO target in order to create VIs, debug and deploy your application. Additionally, this development process requires you to compile your FPGA VI using a remote compile server, compile farm, or FPGA Cloud Compile Service.

Table of Contents

  1. 1. How Reliable Does My Application Need to Be?
  2. 2. How Will Users Interact With My System?
  3. 3. Do I Need to Host an OPC Server on My System?
  4. 4. Do I Need to Directly Connect to a Database From My System?
  5. 5. Does My Application Have Additional Needs Served by the LabVIEW for Windows Platform?
  6. Summary: Choosing the Right Embedded OS
  7. Next Steps

1. 1. How Reliable Does My Application Need to Be?

Figure 1. LabVIEW Real-Time and WES7 provide a higher degree of reliability when compared to general-purpose OSs.

Many embedded applications require a high degree of reliability. Determinism and extended system operation are both key metrics of reliability for embedded systems. Both LabVIEW Real-Time and WES7 can provide a higher degree of reliability when compared to general-purpose OSs such as Microsoft Windows 7 or Mac OSX. LabVIEW Real-Time provides the greatest level of application reliability through a high degree of determinism and excellent extended operation capabilities. WES7 does not provide determinism at all, but does have improved extended operation when compared to a general-purpose OS.

Determinism

The LabVIEW Real-Time OS is designed from the ground up to provide you with the highest degree of application reliability without implementing your system in hardware using the LabVIEW FPGA Module. One key metric of reliability is determinism: an OS’s ability to consistently perform a task in a known amount of time. The wider the variation of execution time, or jitter, between iterations of the same task or loop in LabVIEW, the lower the determinism. LabVIEW Real-Time has a very high degree of determinism, while WES7 has no determinism at all. This is a critical distinction for many applications.

LabVIEW Real-Time achieves determinism by giving you the ability to attain very precise timing control over your application tasks. Through the use of Timed Loops as well as prioritization of tasks, the OS can ensure that key application operations execute consistently and in a known amount of time. In terms of timing, WES7 operates in the same way as Windows 7, allowing any task to pre-empt execution of any other task, and preventing any measure of determinism at all.

Applications requiring consistent application execution time such as closed-loop proportional integral derivative (PID) control, or event response such as emergency stop operation should always use LabVIEW Real-Time. Deterministic communication protocols such as EtherCAT, often used for NI C Series expansion or motion control, also require LabVIEW Real-Time and cannot be used with WES7.

Extended Operation

Another key to reliability is ensuring that an application runs correctly for an extended period of time. Many embedded applications require continuous operation. Both LabVIEW Real-Time and WES7 have features and properties that make them a good choice for tasks requiring extended operation.

LabVIEW Real-Time OS components have been reduced to the minimum required to achieve determinism in a single application. Reducing system components and focusing on determinism reduces the probability of system failure due to crashes and other unforeseen problems. General-purpose OSs must attempt to provide resources and execution time to many different applications. Each additional application increases the opportunity and frequency of system failure.

LabVIEW Real-Time also has additional features, such as the Reliant file system and watchdog timers, that further ensure application reliability over an extended period of time. The Reliant file system by Datalight is designed for embedded systems that require high reliability. It provides immunity to file corruption resulting from system events such as unexpected power loss. Watchdog timers ensure that, in the event of an application failure, a system can be brought back to an operating state quickly and automatically.

WES7 augments the general-purpose OS properties of Windows 7 with a new feature called Enhanced Write Filter (EWF) to ensure a higher degree of reliability. EWF protects your files from corruption in an unexpected system event such as power loss by filtering file writes during operation to a RAM disk. Then, when the system is properly shut down, or when the user or application directs, the file writes stored in the RAM disk are committed to the physical disk. This allows you to choose when the system is vulnerable to file corruption and ensure that the operation is carried out only when it is safe to do so. If power is removed before file writes are committed to disk, the writes are lost, but critical application and system files are protected from corruption.

With EWF enabled, you can also use another feature in WES7 that allows you to hibernate your system once, and then resume from that hibernated system image many times. This feature is abbreviated as hibernate once/resume many or HORM. Using HORM, you can configure your system with your deployed application running exactly as you wish, hibernate the system, and then guarantee that for every subsequent power cycle. The system is brought to the exact same properly running state without any further interaction. This feature ensures that in the event of a failure, your system returns to a usable state in a minimal amount of time. Many embedded applications, such as information kiosks, can benefit from this functionality.

Back to Top

2. 2. How Will Users Interact With My System?

Most applications require some form of user interaction and interface visualization. Developing a human machine interface (HMI) is an important consideration when choosing an embedded OS.

As LabVIEW Real-Time has been specialized and reduced to ensure determinism and reliability, the functionality to display graphics has been removed from the OS. Therefore, to achieve a graphical HMI, a separate computer must be added to the system. This other computer could be a PC, laptop, or touch panel computer using the LabVIEW Touch Panel Module. Windows is used on this separate computer in conjunction with a LabVIEW for Windows application to facilitate the HMI tasks and interface with a LabVIEW Real-Time application through TCP, UDP, LabVIEW shared variable, or other method of communication.

You can also achieve an HMI for a LabVIEW Real-Time system through connection to a dedicated character display or other interface hardware via the serial port, or through the use of a thin Web-based client such as LabVIEW Web UI Builder for visualization.

WES7 does not require a separate computer to implement an HMI. You can use your WES7 LabVIEW application as your HMI, displaying its front panel to users through a connected VGA monitor and interacting with keyboards, mice, and touch screens via USB. This can reduce your overall system cost by replacing the separate windows computer for HMI tasks with a cheaper and easier to maintain VGA monitor.

Learn more about selecting the right visualization approach for your application.

Back to Top

3. 3. Do I Need to Host an OPC Server on My System?

OLE for process control (OPC) is a standard interface between numerous data sources such as programmable logic controllers (PLCs), remote terminal units (RTUs), and sensors. It gives these devices the ability to communicate with HMI/SCADA applications, application tools, and databases. National Instruments provides a number of ways to communicate using OPC. However, because OPC is fundamentally based on Windows technology, to host an OPC server on your embedded system, you must use WES7 as your OS.

Learn more about OPC.

NI OPC servers provide a general-purpose OPC server with multiple driver plug-ins to communicate with a multitude of serial and Ethernet-based industrial devices. Use this in conjunction with your LabVIEW client application to create a stand-alone OPC system capable of communicating with many different devices in WES7.

Besides OPC, WES7 works with a number of device and industry-specific communication protocols. National Instruments provides methods to communicate via Modbus, EPICS, as well as OPC through the LabVIEW Datalogging and Supervisory Control (DSC) Module. This module works with Windows-based OSs only.

LabVIEW Real-Time natively accepts Modbus and EPICS communication methods. OPC communication is based on Windows technology and therefore LabVIEW Real-Time systems cannot natively communicate via OPC. Instead, they must communicate with a separate Windows-based computer via TCP, UDP, or LabVIEW shared variables and use this computer to translate their communication into OPC. This can easily be achieved using LabVIEW DSC and LabVIEW shared variables hosted on the Windows-based computer.

Learn how to connect LabVIEW with third-party hardware using OPC.

Back to Top

4. 4. Do I Need to Directly Connect to a Database From My System?

WES7 supports data logging to a database via the LabVIEW DSC Module. Database logging with LabVIEW DSC was specifically designed for easy configuration and operation. It can easily connect and log directly to many common relational databases such as Oracle, mySQL, and Microsoft SQL. LabVIEW DSC also includes its own integrated database, Citadel, optimized for efficient long-term logging.

WES7 also works with the LabVIEW Database Connectivity Toolkit, which allows more customized creation, querying, and retrieval of data from any provider that adheres to the Microsoft AciveX Data Object (ADO), OPC database connectivity (ODBC), or object linking and embedding database (OLE DB) standard. Similar to LabVIEW DSC, the Database Connectivity Toolkit supports communication to common databases such as Oracle and Microsoft SQL.

Like OPC, many common database communication methods are based on Windows technologies such as ActiveX. Because of this, the LabVIEW Database Connectivity Toolkit does not work in LabVIEW Real-Time applications.

Learn more about data-logging options with LabVIEW DSC.

Database connectivity is still possible using LabVIEW Real-Time, but an intermediate Windows host computer must be used; similar to the method employed to achieve OPC communication, as well as HMI capabilities from LabVIEW Real-Time. Standard communication methods such as TCP, UDP, and LabVIEW shared variables are used to communicate with this separate Windows host computer.

Learn more about communicating with relational databases in LabVIEW Real-Time.

Back to Top

5. 5. Does My Application Have Additional Needs Served by the LabVIEW for Windows Platform?

LabVIEW for Windows is supported by an extensive array of add-on toolkits, modules, and libraries not available in LabVIEW Real-Time. Through the use of LabVIEW Application Builder for deployment, the full LabVIEW for Windows platform is supported on WES7.

If your application requires Windows-only LabVIEW modules, such as LabVIEW DSC, or Windows-only toolkits, such as the Report Generation and Data Finder Toolkit, you should consider using WES7 as your embedded OS.

There is also an array of DLLs, .NET assemblies, and ActiveX controls that can extend the functionality of your application and reduce your development time when using the LabVIEW for Windows platform.

Many modules and toolkits within the LabVIEW platform work with Windows and LabVIEW Real-Time such as the LabVIEW Control Design and Simulation Module and Internet Connectivity Toolkit. So it is important to examine your needs and check to ensure that LabVIEW Real-Time works with all of the modules, toolkits, and related software you intend to use.

Learn more about add-on software for LabVIEW.

Back to Top

6. Summary: Choosing the Right Embedded OS

When considering the choice between LabVIEW Real-Time and WES7 for your embedded application, consider your application needs first. If determinism and continuous operation are critical for system success, choose LabVIEW Real-Time.

However, if your critical needs include an integrated HMI and access to the ecosystem of software provided to you by Windows and the LabVIEW for Windows platform, choose WES7.

Back to Top

7. Next Steps

Learn more about the RIO platform

Learn more about LabVIEW Real-Time

Learn more about Microsoft Windows Embedded Standard 7

Shop for a Multicore CompactRIO

Configure a complete CompactRIO system

Back to Top

Bookmark & Share


Ratings

Rate this document

Answered Your Question?
Yes No

Submit