The RCS Software Library:

An Introduction

For a Romanian translation click here.


Introduction

The Real-Time Control Systems (RCS) Library is a software library that can be used to implement complex hierarchical and distributed control systems. It was developed by the Intelligent Systems Division of the National Institute of Standards and Technology.

Developing a complex real-time control system that can be composed of several subsystems distributed over multiple computers with (possibly) different operating systems is not trivial task. Challenging practical issues surround implementation of such a control system. The RCS Library was developed in order to facilitate the design and implementation of hierarchical and distributed real-time control systems for practical real-world problems. It has numerous features that make the job of the control system designer easier.
 

 With the use of the RCS Library it is very easy to develop and implement a controller that consists of interdependent computing nodes, is organized in a hierarchical structure, and is (possibly) distributed over different (and possibly incompatible) platforms (such as the one pictured below, that has three "levels" with the lowest level interfacing to various physically distinct portions of the plant, and with the lowest level interfaces implemented via different computers). With the help of the communication tools of the RCS Library, the computing nodes can still be connected to each other while running independently. They can share information even if they are operating on different hardware of software platforms.





The Reference Model Architecture

The control system construction methodology facilitated by the RCS Software Library is based on the Reference Model Architecture (RMA) for intelligent systems design developed by NIST. The RMA has a structure that organizes the different computing nodes, called modules or processes, in a control system in a hierarchical architecture (as shown in the figure above). The nodes in the upper levels of the hierarchy are supervisors of those in the lower levels. Therefore, they can send commands, or task requests, to the modules on a lower level of the hierarchy, and also read their status information.
 
 



The structure of RMA is regular and therefore easy to understand and implement. Every module, in the hierarchy of the RMA contains Sensory Processing (SP), World Modeling (WM), Value Judgment (VJ), and Behavior Generation (BG) processes, as well as a Knowledge Database (KD). See the above figure.
 

The SP Processes

The SP processes are responsible for getting information about the external (and internal) world in order to keep the "world model " (a representation of the world in which the control system is to act that is kept within the controller) more accurate and up to date. Moreover, they perform operations on the data that is gathered such as filtering, coordinate transformations, comparisons, integrating in time and/or space as well as interpreting it. Each SP process in each level uses the information from the lower levels for detection of objects or events of higher complexity.

The KD and the WM Processes

The World Model is an internal representation of the external (and internal) world. It is structured so that with each WM process there is a KD at each control node, or RCS module, of the hierarchy. The KD is a data store that contains both a prior information about the external and internal environment before any action begins, as well as information that is gathered as the system executes some actions.

The WM processes keep the KD current and consistent based on the information obtained from the SP processes. Moreover, they perform jobs such as simulation of possible actions and state prediction, and supply data to other processes.

The VJ Processes

The VJ processes compute the costs, risks, and benefits of plans and actions, the desirability, attractiveness and repulsiveness of objects as well as the uncertainty of the events detected. They can evaluate events as trivial or important, to indicate what to reward or punish, or what to treat as friend or enemy.

The BG Processes

The BG processes are the ones responsible of executing the tasks, job assignments.  Each RCS module, and therefore each BG process, can perform only a set of predefined tasks (determined by the RCS designer). Each BG process consists of Job Assignment (JA), Scheduler (SC), and Execution (EX) subprocesses.

The JA subprocesses decompose a given job, or task, into N distinct jobs to be performed by N distinct subsystems.
The SC subprocesses are associated with each subsystem and decompose a given job for this subsystem into a time sequence of sub-tasks to be performed.
The EX subprocesses are also associated with each subsystem and perform the tasks scheduled by the corresponding SC subprocess.

Every RCS system may have different organization and number of layers in its structure. The RCS system designer decides how to organize the layout of the controller hierarchy based on the system to be controlled. In other words, based on the physical layout of the subsystems, the physical and logical relation between the subsystems and the tasks that the subsystems can perform.
 

The Time and Space Resolution in RMA

The levels in the RMA control hierarchy are defined by decomposing the goals in time and space into levels of resolution. The resolution in time is implemented by loop bandwidth, sampling frequency, and state change intervals. The span in time is defined as the length of past traces and the length of the planning horizon. The resolution in space is implemented by resolution of world maps and grouping of elements in subsystems. The span in space is defined as the range of world maps and span of control. The sampling rate, the command update rate, the rate of task completion, and the rate of event occurrence increase in the lower levels and decrease in the higher levels of the RMA hierarchy. Similarly, the resolution in space increases at the lower levels and decreases at the higher levels of the RMA hierarchy. The amount of increase and decrease of the resolution in time and space in every level is determined by the particular application.


The RCS Methodology

The RCS methodology is a methodology that breaks down a complex problem into simpler, easy to understand, develop, implement, and maintain subproblems. Moreover, it supports the productivity and extensibility of the system.

A typical RCS design starts with a task decomposition analysis of the system. This involves identifying the tasks that each subsystem can perform and analyzing the task sequence scenarios that lead to the desired operation. During this stage the designer also defines the task knowledge and parameters, or basically the information to be stored in the world model and also to be shared between different modules. These include the goals and pre-conditions of the tasks.

The next step in a typical RCS design is to define the controller architecture. During this stage the designer considers the physical subsystems, including all the sensors and actuators, of the system as well as the logical relations between them. We start by assigning an RCS control module for each actuator and corresponding sensors in the lower level of the hierarchy and define the modules in the higher levels based on the subsystems and the information flow.

Having done the task decomposition analysis and completed the controller architecture, the designer breaks down each command, or task request, to a state table of rules. For each of these rules, the sensory conditions, operator requests, and system states are identified.

Having finished the RCS design the engineer faces the practical challenge of implementing the control algorithm. The RCS Library was developed to aid the designer at this stage of the complex control system implementation. Using the RCS Software Library one can overcome the practical challenges of implementing the control modules, the communication between them (which may involve communication over a network and between incompatible hardware and software), the operator interface, etc., very easily. Below we summarize some of the important features of the RCS Software Library.


Distinguishing Features of the RCS Software Library

The RCS Library does not specify implementation details. Therefore, it does not limit the implementation on particular hardware or software. It supports numerous platforms including Windows, Linux, SunOs, VxWorks, etc. See the The Table of Tested Platforms for the RCS Library for a complete list of tested platforms. This allows the RCS Library to be implemented for any application ranging from single-input-single-output (SISO) plants to intelligent autonomous control systems.

The Communication Management System (CMS) and Neutral Messaging Language (NML) are two powerful tools of the the RCS Library. They are used for communication between different processes, or modules, that may be running on different operating systems or platforms, connected over a bus or over a network. The RCS Library supports various different communication protocols including Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Remote Procedure Call (RPC). The communications in NML are message based and are done using shared memory buffers. The code development is uniform and does not depend on the particular operating system or platform. These tools allow different interdependent processes to be located anywhere and still be connected to each other. For more information on CMS and NML see The NML Programmer's Guide (C++ Version) or The NML Programmer's Guide (Java Version).

The generic RCS control node, NML_MODULE, that combines the NML communication tools with the RCS control routines. It operates on cyclic intervals and is designed so that easily it can handle the supervisor-subordinate structure of RMA. For each cycle time the module automatically checks for commands from its supervisor, reads the status of its subordinates, performs the algorithm for the current command, sends commands (if any) to its subordinates, and presents its status to the supervisor. For more information on the NML_MODULE see NML_MODULE.

The code development in RCS is uniform and system independent. Therefore, a code developed in one application can easily be ported and reused in another. Moreover, extending the system is easy and requires minimum code update. This saves the designer the problem of recoding if there is upgrade of the system or a change from one hardware (or software) to another.

The RCS Design Tool is a Java based graphical program that the designer can use to easily layout the modules of his or her controller structure and generate automatically all of the application independent code. This includes the code for the command and status messages to be passed between the modules, the code of the modules, the NML format and update functions, the NML servers as well as the scripts for compiling and running the application. The only coding part that is left are the data fields of the messages to be passed and the algorithms for the commands, since these may vary from application to application. For more information on the RCS Design Tool see RCS Design Tool Instructions.

The RCS Diagnostics Tool is another  Java based graphical program that an operator can use to connect to a running RCS application from a (possibly) remote host, view its status, and send appropriate commands to it. The operator can modify (or set) the fields of command messages before sending them, plot the fields of the status messages, view the current state of execution in the state table, etc. Scripts needed by the Diagnostics Tool can automatically be created by the Design Tool, therefore, using the Diagnostics Tool  does not result in any extra programming overhead. More detailed information on the RCS Diagnostics Tool is available on RCS Diagnostics Tool Instructions.

The RCS Library is free of charge. You can download it from the  Intelligent Systems Division's ftp site.


RCS has been implemented and tested on variety of applications including mining, manufacturing systems, autonomous undersea and land vehicles, space station telerobots, post office automation, etc. For more information on applications of the RCS Library see: RCS applications.

If you want to obtain more information on RCS see the web site Real-Time Control Systems (RCS) Library or consult the RCS handbook.

For a syllabus of a laboratory course on RCS see the web site RCS Laboratory Course.



If you have any questions, comments or suggestions related to the RCS Library, please send e-mail to Will Shackleford at shackle@nist.gov

To be automatically sent information on updates to the RCS library, please subscribe to the "nist_rcs" mailing list on http://www.onelist.com