1. How Reliable Does My Application Need to Be?
Figure 1. RTOSes 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. A Real-Time OS (RTOS) and WES7 can both provide a higher degree of reliability when compared to general-purpose OSs such as Microsoft Windows 7 or Mac OSX. An RTOS 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.
RTOSes are 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. Both VxWorks and NI Linux Real-Time have a very high degree of determinism, while WES7 has no determinism at all. This is a critical distinction for many applications.
VxWorks and NI Linux Real-Time achieve 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 an RTOS. 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.
Another key to reliability is ensuring that an application runs correctly for an extended period of time. Many embedded applications require continuous operation. VxWorks, NI Linux Real-Time, and WES7 all have features and properties that make them a good choice for tasks requiring extended operation.
RTOS 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.
VxWorks utilizes the Reliant file system, by Datalight, designed for embedded systems that require high reliability. It provides immunity to file corruption resulting from system events such as unexpected power loss, ensuring application reliability over an extended period of time.
NI Linux Real-Time and VxWorks can also implement watchdog timers, ensuring 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.
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.
Many RTOSes have been specialized and reduced to ensure determinism and reliability, the functionality to display graphics is often removed from the OS. Therefore, to achieve a graphical HMI, a separate computer must be added to all VxWorks and some NI Linux Real-Time systems. 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.
The new NI Linux Real-Time based-Performance CompactRIO Controllers offer display support for local HMIs. 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.
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 Classic OPC and OPC Unified Architecture (UA), the new communication technology standard. Classic OPC is fundamentally based on Windows technology, so to host an OPC server on your embedded system, you must use WES7 as your OS. OPC UA can deploy on a variety of embedded systems regardless of whether the system is a general purpose operating system, such as Windows, or a deterministic real-time operating system.
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. For NI real-time hardware targets, the LabVIEW Real-Time Module enables the OPC UA communication feature set. These capabilities allow both Windows and real-time based LabVIEW applications to communicate through the OPC UA networks to OPC UA-enabled PLCs, data logging historians, and SCADA systems.
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.
Database connectivity is still possible using LabVIEW Real-Time. Standard communication methods such as TCP, UDP, and LabVIEW shared variables can be used to communicate with a separate Windows host computer or server that hosts the database. On NI Linux Real-Time targets you can host a database on the controller, such as PostgreSQL, running alongside your LabVIEW application.
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. NI Linux Real-Time targets can run Shared Object (.so) libraries.
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.
6. Summary: Choosing the Right Embedded OS
When considering the choice between WES7 and an RTOS for your embedded application, consider your application needs first. If determinism and continuous operation are critical for system success, choose VxWorks or NI Linux Real-Time.
However, if your critical needs include access to the ecosystem of software provided to you by Windows and the LabVIEW for Windows platform, choose WES7.
7. Next Steps
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. Permission to use and/or modify the penguin image is granted by Larry Ewing and The GIMP.