Application frameworks aid complex control system programming

Control system software is getting more complex. Controllers have faster CPUs and are increasingly networked, creating a whole new level of system complexity. To create software for these complex, distributed systems, software developers are starting to use application frameworks, which are domain-specific software architectures.

By Brett Murphy, VP, Real-Time Innovations February 1, 2001

Control system software is getting more complex. Controllers have faster CPUs and are increasingly networked, creating a whole new level of system complexity. To create software for these complex, distributed systems, software developers are starting to use application frameworks, which are domain-specific software architectures. Frameworks include design templates, tools, and ready-to-use components that require less set up.

Several commercial frameworks target particular application domains. For instance, frameworks for telecommunications switches, Java-based graphical user interfaces, distributed e-commerce (JavaBeans), expert systems, and others are available.

In high-level work cell architecture, subsystems are represented by
components interconnected with programming interfaces. Implementation
of the robot component includes both state machine logic and data flow
programming constructs.

Simplify with subsystems

In control systems, event and continuous processing are tightly integrated. An application framework requires two different programming constructs: cyclical-data processing (such as feedback control loops) and event-driven logic (such as error handling and start-up sequences). The framework must make it simple to efficiently program, design, and integrate these constructs.

To manage complexity of large control systems, its software system must easily break down into recognizable subsystems. The framework must encourage a hierarchical, object-oriented design with well-defined interfaces. For instance, first-tier objects can be controllers and devices. After that, complex devices can subdivide into subsystem objects, continuing the process, until it makes sense to define the functionality of each object. Over time, as the team develops standardized interfaces between objects, they can be reused.

For example, the diagram (below, left) outlines a simplified robotic work-cell controller. With an application framework, the system can be divided into subsystem objects that include robot, vision system, graphical interface, and the cell controller. These subsystems can use a network to synchronize activities and pass data.

Defining objects, behavior

Drilling down into the robot, high-level state machine control logic and cyclical data processing objects are defined. Further down in the object hierarchy are defined the implementation of event and continuous functionality of the robot controller.

This example was developed with an application framework called ControlShell from Real-Time Innovations (Sunnyvale, Calif.). ControlShell combines graphical programming diagrams for both cyclic processing and event-driven behavior.

Cyclic blocks in the diagram can be implemented as sub-diagrams, C++ object-oriented code, or even dynamic systems in Simulink from MathWorks (Natick, Mass.). Event-driven behavior is implemented in UML (universal modeling language)-style statechart diagrams.

Both types of diagrams are integrated into objects called Composite Object Groups (COGs), which provide intuitive building blocks for more complex systems. All the objects can be stored as components in a repository for future reuse.

By breaking complex systems into reusable subsystems, object-oriented application frameworks reduce system complexity. They also focus on constructs that fit the domain and let engineers think intuitively; provide structure that speed designs and coordinate teams; and enable reuse that produces more-reliable code in less time.

For more information, visit www.rti.com or www.controleng.com/freeinfo .

Author Information
Brett Murphy, vp, Real-Time Innovations; e-mail comments to gmintchell@cahners.com