Comparing DCAF and CVT-based Application Architectures

[smithd]

Overview

Distributed control systems frequently need to aggregate data from multiple sources like TCP, local I/O, and industrial comms, perform operations on that aggregated data such as scaling, alarming, and control algorithms, and then route the result of that processing back out to the appropriate receiver. A sample application may have a component architecture like the following diagram.

Figure 1: Basic component architecture of a distributed control application

Previously published reference designs, based on the Current Value Table (CVT), including the Machine Control Architecture (MCRA), recommend an application architecture using asynchronous process loops, running in parallel. Communication of tags and simple data is these designs is handled using CVT tags.

Since the CVT is a global data exchange mechanism, it is simple to define separate processes which communicate with this global data source; this design quickly and easily solves the data aggregation problem. A simplified code example might look something like this:

Figure 2: Application code using parallel asynchronous processes

This approach is easy to learn and enables developers with basic proficiency in LabVIEW, to create applications with a modest amount of complexity quickly and successfully. However, this design does not address or resolve certain common issues facing developers of distributed control systems. These issues include:

• Robust error handling
• Deterministic execution
• System configuration management and parameterization

These concerns can be addressed with implementations such as custom file formats for configuration and a centralized messaging and error handling system to coordinate asynchronous process and consolidate error handling. The Asynchronous Message Communication (AMC) Library which includes the Queued Message Handler (QMH) template for developing individual processes, addresses some of the messaging and coordination issues. The Structured Error Handler (SEH) Library provides a basic architecture for handling and processing errors in an application.

The final design of an application using CVT and these other components can be a highly-coupled set of code that may be difficult to maintain and support. Advanced architecture skills and a proper design from the start of development of an application will allow this type of design to stay flexible and sclable while adding and modifying system features.

Without the proper design the code of such asn application might look something like this:

Although the end result can be a fully functional application, code created from this approach might still have some fundamental issues:

• Global data access in parallel processes will likely prevent deterministic execution of code
• Asynchronous access to global data can lead to race conditions
• Instantiating multiple copies of code can be difficult to manage, and can cause name collisions in the global data space
• A lack of a consolidated configuration mechanism makes errors more likely -- different APIs likely have their own implementation of tag based or file based configuration mechanisms, with little coherency between processes
• Lifetime and state management in the application is difficult, as there is no coherent shared state -- initialization and shutdown are component-specific, and safe states may not exist for a given module.

These challenges can be addressed using the Distributed Control and Automation Framework (DCAF) with its built-in Tag Bus Data data sharing mechanism. The fundamental purpose of the Tag Bus is the same as that of the CVT-based design -- the application needs to import data from a variety of sources and aggregate it in a single storage location for access by different code modules.

A locally scoped, dataflow-safe Tag Bus table can avoid the issues associated with global data access. By moving the execution of code modules from their own independently timed (asynchronous) loops into common execution and data engine, the framework can enforce consistent order of operations and eliminate the other issues mentioned above. The diagram below shows how a developer can use a locally-scoped Tag Bus to connect inputs and outputs with user processing.

Each code module used in the framework, which is analogous to one process in a CVT-based design, includes an input, processing, and output code block. These three main functions of each module are implemented in a class-based plugin API, that is defined as part of the overall framework. This allows the framework to excute these function for each module inline, or in a background process, and thereby maintain determinism of the overall application.

Using a common execution engine with plugin modules also provides an opportunity to create a unified configuration mechanism -- implemented using a configuration object for each plugin module, provided by the Configuration Editor Framework (CEF).

The execution engine is resposnible for the overall state logic as well as error reporting for all of the plugin modules. This main loop of the engine, provides an API which can be used to influence the state and access error reporting information. The end result is a development approach that provides standard schemes for error handling, state management, and system configuration while producing an application that can maintain determinism and which is free of race conditions.

Summary

Using the CVT-based architectures to develop a distributed control system, can allow you to quickly create basic applications and be up and running quickly. However, as you add features to these basic applications and move from development to deployment, you may encounter issues with configuration, coupling, determinism, and maintainability.

However, systems which need to be configured and replicated many times with slight variations, systems which need to be extremely robust and reliable, systems which need to be easy to maintain and reconfigure -- these types of systems stretch the boundaries of the CVT-based design. DCAF and the Tag Bus are intended to resolve these issues by enforcing a structure on the code across modules and processes. While this structure and framework has a learning curve, especially if you plan on creating your own custom plugin modules, the benefits often outweigh the costs for many application areas. If you are using the CVT to build applications, and are encountering some of the issues described above, we recommend learning more about DCAF and using it for your next project.