When and How to Use DCAF


The Distributed Control and Automation Framework (DCAF) is an application framework designed to help developers by simplifying and accelerating the development of reliable and robust embedded control and test applications in LabVIEW and LabVIEW Real-Time. To learn more about this approach and its benefits, visit Introduction to the Distributed Control and Automation Framework. The following article will describe when to use DCAF and explain common ways to use the framework.


When to Use DCAF

DCAF is a powerful tool that can be applied creatively to meet a variety of application requirements. However, like any other tool, the framework isn’t well suited for every job. The ideal application for DCAF is one that has an element of control, needs to be deployed in the field, and will be developed by someone with basic LabVIEW skills or greater. The ideal application also has a need for sending and receiving single point data across multiple devices, including NI controllers and third-party devices. Using DCAF for small proof-of-concept applications may be excessive, but DCAF is proven to save time and development efforts for applications that usually take on the order of months to complete.


Figure 1. DCAF Application Fit


DCAF has been successfully employed in multiple different industries such as Aerospace, Oil & Gas, Life Sciences, Automotive, and more. It is used in pure embedded control applications, such as a large-scale control system for operating an oil rig, as well as test applications that require some degree of control over the device-under-test, such as the testing of an entire airplane wing as it undergoes certain evaluations.


When to Not Use DCAF

DCAF is a tool for building embedded test and control applications with LabVIEW, but it’s not the right tool for every job. The framework is most useful for tasks that interact with single-point data needing updates at around 1 kHz or slower. As a general rule, it should not be used for application tasks that are heavy with waveform or message/event-based data.


DCAF is also not meant to replace other NI products that address specific application areas such as FlexLogger for configuration-based data logging applications, or VeriStand for model-based simulations.


Also, while the framework has the potential to make the development of an embedded test or control solution much easier, it still has a learning curve. This framework is not meant as a replacement for programming or for training. Contact an NI Partner to discuss the creation of turn-key solutions.


Using DCAF with Existing Modules

The easiest way to benefit from DCAF is as a data engine that utilizes existing modules. A collection of modules is provided with the DCAF installation and enable you to interface to local resources as well as I/O provided through common industrial communication protocols.

Existing I/O modules include:

  • RIO Scan Engine
  • Modbus
  • EthernetIP
  • Profibus
  • Profinet
  • J1939
  • DDS
  • OPC UA
  • FPGA

Existing data exchange modules include:

  • Current Value Table (CVT)
  • UI Reference Communication
  • TDMS Data Logger
  • UDP-based Engine-to-Engine Communication

See the complete list of available DCAF modules for more information.

After completing the installation process, these modules can be added to an application using the framework’s Standard Configuration Editor. The editor is available in the LabVIEW environment in Tools>>DCAF>>Launch Standard Configuration Editor...

Figure 2. Launch Standard Configuration Editor Menu

In the editor a developer configures each target of the application by adding them to the system. For each target, one or more engines can be added. Each engine controls the execution and timing of the modules within it. With the editor you configure the top level loop rate of each engine.

You then add all of the necessary modules to each engine and configure them. From here, added functionality is configured by routing and connecting data through channels and tags in the application. Each data item in a module is called a channel. Channels are mapped or connected to Tags which are the data items in each engine. For example, Scan Engine input channels can be easily routed with just a few clicks to an external Modbus master, written to a TDMS data file, and displayed on a simple user interface (UI); all without detailed knowledge of the framework.

Augmenting with Current Value Table (CVT) Module

In addition to acquiring and routing data, the framework also provides various methods for manipulating or processing acquired data. For a deployed application the most sustainable route is to develop project-specific logic within a framework module, but the Current Value Table (CVT) module can be used to export local engine data to a top level VI, debugging loop, or custom processing function. The CVT allows a user to connect data within the data engine to CVT tags that can be read or written to throughout an application. This is similar to a Scan Engine I/O variable, except the I/O connected to the CVT can come from any of the framework modules.

This approach removes the need to learn and implement the wide variety of I/O APIs in LabVIEW. A common data accessor like the CVT also allows users to easily change their data source or sinks to either a different set of hardware, or to a simulation, without having to rewrite any code. It’s much easier to reuse code with a common API like the CVT rather than with hardware-specific calls. As an extra benefit, the engine can still be used to automatically handle other tasks such as logging to data to disk.

While easy to use, the downside to using the CVT is that it bypasses some of the framework benefits. Global access to data reintroduces the possibility of race conditions. Global tags also make it difficult to support the creation of multiple instances of control logic, and limit the ability to reuse that logic across projects. It also introduces a cycle delay between data acquisition and data processing. To avoid these issues, the framework allows users to create control logic modules that run inline in the execution of the data engine. In addition, the API for engine data and the API for CVT data are closely related, making it simple in many cases to transition between the two implementations.

DCAF Static Channel Module

DCAF provides a Static Channel Module sample project that allows developers to create custom processing modules with a fixed number of inputs and outputs, and run the processing logic as a module within the framework.

Figure 3. DCAF Static Channel Module Template

This sample project provides a dialog which the developer uses to specify the names and data types of the module inputs and outputs. Once entered, the sample project will script out the majority of code necessary for the new module. In many simple cases a user can add their logic in a single VI, such as the one below.

The framework offers many extension points for customizing module behavior, but default implementations are automatically created by the project template script. The module can be customized for initialization or safe-state logic, adding new configuration parameters to the editor, or by adding a custom glyph for display in the editor’s tree control.

The main limitations of this simple solution for processing module development is that the quantity, name, and data type of all inputs and outputs must be static. Changes to inputs and outputs are facilitated by an easy-to-use script, but the final design must be decided at edit time instead of at run time.

The framework supports modules with dynamic run time channels, like a generic data logger whose inputs are configured in the editor. Their development is more complex, both due to requiring a greater understanding of the framework as well as the general challenges associated with developing dynamic code. Overall, the Static Channel Module sample project provides an easy way to create custom execution logic that benefits from the framework rules without a lot of complexity.

Other Ways to Use DCAF

There are many other ways to use and customize the framework, but they require more detailed knowledge of how the framework works. Some examples include:

  • Create an I/O or Data Service module that supports a variable number of channels (DCAF Dynamic Channel Module Template)
  • Customize the configuration editor for a specific project (Custom DCAF Configuration Editor Template)
  • Create a new execution engine with customized functionality for features such as error handling or module benchmarking
  • Create a processing module that supports its own model of computation. Existing examples include support for calling a shared library (DLL)

Check out the DCAF Developer's Guide for more information. 

An NI Partner is a business entity independent from NI and has no agency or joint-venture relationship and does not form part of any business associations with NI.