The development of automated control systems is difficult, expensive and demanding. The reason is that control systems are fundamentally very complex. The more the capabilities of control systems are increased, the more complex they become.

This increase in complexity is also accompanied by increased cost and risk of failure, rendering the entire system inflexible and potentially inoperable.

RCS Enterprise Control addresses these issues with a total systems design approach that is modular, scalable, reliable, and understandable. RCS Enterprise Control (RCS-EC) is meant for building complex real-time control systems.

The RCS-EC implements an architecture for the design, implementation, maintenance, operation and diagnostics of complex, real-time control systems. This architecture supports the incremental evolution from the operation of many activities under manual control, to a partially automated system coordinated with manual operations, to a fully autonomous system. In addition, the subsystem can be designed so that it can be readily integrated with other components of the system, as they are designed and built.

Use of the RCS-EC design approach results in a total system design that is also the representation of the software architecture of the system. Each of the specified control modules becomes a software program unit whose function is to perform the partial decomposition of the task within well-controlled limits of responsibility.

The RCS-EC Environment

To provide for extensibility and maintainability, RCS-EC is built around the concept of a unit building block - the control module. These control modules are connected to other control modules, not by the tightly coupled interaction of subroutine calls, but through well-defined data interfaces. The functionality of this control structure encompasses many aspects of information processing including communications, task knowledge, task decomposition, world model data, sensory-interactive control and multi-level operator interfaces.

Each control module is a software component that can run independently or as part of a hierarchical system.

A hierarchical task decomposition, rather than functional, is used to group and coordinate the various control activities at different levels. This builds a layered tree of responsibility for the activities to be controlled, and implicitly identifies places of coordination and points of authority in the decision making process. This type of architecture results in a structure that identifies points where new activities can be added and minimizes the changes that a new activity causes to the other parts of the system.

A very important element in the design of this architecture is consideration of human limitations in the management of complex information. To deal with this issue, strong emphasis has been placed on generic processing structures. That is, the operation of the control modules is the same, so that they become replicas of one processing format.

The RCS-EC architecture has evolved to become a viable system for generic real-time control. The real-time aspect of control is based on the concept of producing a response to changes in input data soon enough for that response to be effective. If a control cycle (in which the input data are sampled and the output response generated) is repeated at a sufficiently fast rate, the system will provide continuous control in real-time. The RCS methodology creates a system where the processing is broken into components small enough to execute within one control cycle. In this way, sampled data are examined in a structured, deterministic manner to see if any changes in processing are required in each control cycle.

The control modules function is to perform a partial task decomposition of an input command into a set of simpler output commands. This decomposition is a function of the status from the module(s) below, the present state of the world model database and the feedback from sensory processing.

Each module:

Generates output commands to subordinate level(s) and actuators

Reports status to the supervisory level (the level above),

Processes sensor inputs, operator request, and program request

Updates relevant world model data.

The control module's framework is identical in all modules. Processing within the control module is partitioned into three categories: preprocessing, decision processing and post processing.

Preprocessing routines transform commands, sensory data and status feedback into a form that will be convenient for the logic processing routines. It essentially extracts a high level symbolic representation of the input state defined by the data in the input buffers. This symbolic data is then tested in the state tables.

Logic processing is executed in the form of state tables that represent in each line the total description of an anticipated input condition (the high level symbolic data extracted by preprocessing) and the corresponding response activities. This partitions a task, represented in a rule-like format, into small decision tables according to their applicability to a particular command at that layer. This representation allows programmers to "zoom-in" on a complex problem defining the individual states and concentrate on how to deal with each one separately.

Post-processing routines transform the results from the output procedures called by the state table mechanism into a form convenient for the next module to use, and maintain such internal variables as counters.

Each control module carries out only its limited responsibility by transforming its input data into the appropriate output data set. The integration of the system occurs through a communication mechanism that moves these interface data sets between modules through a shared memory structure. This causes the system to never appear more complex than a single control module's computation. It greatly facilitates multiple processor implementation, since control modules represent clearly separated units that can be mapped onto one or many computers.

Control Module Responsibilities

Provide decision processing and status updates on task commands

Process real-time sensor information

Receive and respond to operator requests

Receive and respond to program requests

Evaluate state table rules relevant to the current task

Issue task commands to subordinate control modules

Process real-time actuator commands to the Virtual I/O system

Publish relevant world model information to all levels of the hierarchy Top

Design Methodology - 6 steps

Step 1

Scenarios of the desired tasks are analyzed to identify the task knowledge. This knowledge is represented in the form of a hierarchical task decomposition where a high level command is decomposed into lower level subcommands. At the next layer down, each of these subcommands is further decomposed into yet simpler subcommands. This process is repeated, generating successively simpler and simpler component sub-tasks until the bottom output of actuator drive signals is reached.

Hierarchical task decomposition tree

Step 2

This task decomposition hierarchy is mapped onto an organizational framework of control modules that are to perform this task decomposition. Figure 2 shows the correlation of the task decomposition to layers of control modules and pictorially represents typical ranges of activities controlled at each level. The control module is the generic building block of the methodology. It performs a similar role to an individual within a chain of command. It carries out a partial task decomposition of its command into simpler commands to issue to a subordinate level and coordinates the activities of the levels immediately subordinate to it.

Tasks mapped to control module framework

Step 3

Having defined each level's limited area of responsibility in carrying out the task, we can now determine what sensory data) might be appropriate for each level. That is, what does each level need to know about the outside real-world in order to make its next decision on what to do to carry out its command.

Sensor data mapped to control modules

Step 4

The next step is to decide what internal and world model data each control level based on that module must keep's limited, defined responsibility in carrying out the task. World model data is written by one module, but potentially read by many other modules. World model data provides additional information about the "world" that the system is controlling.

World model data

Step 5

The operator interactions with the system are determined next. These include what data can be accessed (present sample inventory and location, present state of robotic operations in task, position of robot, etc.), and what system capabilities can be controlled (position of robot, gripper, storage rack, operations of bar-code reader and balance.) Having defined these interactions, the next step is to determine where they interface into the system. Which control module has the responsibility to react to particular operator inputs or provide status.

Operator requests processed by control modules

Step 6

Each command at each control level is defined within the system as a separate state table of task knowledge rules. For each of these tables, the status sensory conditions, operator requests, and states are identified. These define the various input conditions (in the context of that particular command) that will trigger each output action subcommand.

Commands are processed with state tables

Thus from this design activity, the base line controller is defined in terms of both its organizational structure and in which modules certain types of sensory processing, decision support and actuator control should occur.

Top