Open architecture controllers offer a multitude of benefits to users of machine tools, robots, and coordinate measuring machines, ultimately reducing the life-cycle costs of installing, operating, and maintaining manufacturing equipment. Aside from those benefits resulting from basing a controller on common operating systems and computing platforms, the main feature of an open architecture is the public availability of interfaces to controller functionality. These interfaces allow third parties who are not associated with the original equipment manufacturers to provide enhancements to the functionality of the machine. Efforts to standardize the interfaces to open architecture machine tool controllers are underway both in the United States. and abroad. In the United States, the Department of Energy and the National Institute of Standards and Technology have cooperatively undertaken this standards effort. One of the most important aspects of this program is the validation of interfaces on actual machinery in production applications. The goal of this validation process is to ensure that the interface specification is broad enough to encompass a significant portion of manufacturing applications, while still being practical to implement. This paper explores the problems resulting from defining interfaces to general controller functionality, when faced with the realities of validating the interfaces on controllers with specific operating systems, computing platforms, and control components.

KEYWORDS: open architecture controllers, motion control, standards

INTRODUCTION

In the early 1990s, the Manufacturing Engineering Laboratory of the National Institute of Standards and Technology (NIST) began the Enhanced Machine Controller (EMC) program to develop a modular definition of components for machine control [1]. The intent was to document the interfaces to these modules to the degree that would allow independent third parties to provide interoperable products. The development of this modular architecture grew out of NIST's experience developing controllers based on the Real-time Control System (RCS) architecture which has evolved within NIST over many years [2]. NIST and the Department of Energy national laboratories have combined their efforts in this area under the auspices of the Technologies Enabling Agile Manufacturing (TEAM) program, and are undertaking a formal review of the interface specification that has resulted from recent implementations of interface-based controllers [3]. This review also includes researchers from General Motors and the University of Michigan. A broader review is anticipated within the EMC Consortium, established by NIST in January 1996 to formalize a three-year review of controller implementations based on these interfaces.

The intent of the review process is to include validation tests of the interfaces to open architecture controllers in real-world applications. The review process will address the question, "Does the interface specification provide the necessary information required to support the features of open architecture controllers?" The question is somewhat ill-defined due to the lack of a precise definition of "open architecture." However, there are certain commonly-understood features that open architecture controllers are expected to have. Some of the most important features which drove the selection of the validation tests were:

• Interoperability: the ability of two or more components to exchange information and use the information that has been exchanged.

• Portability: the ease with which a module can be made to run in a controller based on another platform.

• Extensibility: the ability of users and third parties to incrementally add functionality to a module without replacing it completely.

INTERFACE DESCRIPTION

The development of the EMC architecture, shown in Figure 1, was the first step toward defining an interface specification. In this figure, boxes indicate the individual modules for which interfaces have been defined and validated. These include Task Sequencing, Trajectory Generation, Servo Control, and Discrete Input/Output. The Operator Interface, shown at the side, does not require any specific interfaces itself, but can be developed using only the interfaces provided by the other modules. Implementations of the operator interface need only avail themselves of messages to the controller and data provided by the controller: no additional interfaces are required to be defined in order to incorporate an operator interface into an EMC controller.

Figure 1. The EMC Architecture. Interfaces for Task Sequencing, Trajectory Generation, and Servo Control were targeted during the validation process.

Class definitions alone are not sufficient to describe the interfaces. The specification needed to include the expected behavior of the control modules in response to each control message, and their effect on the world model of each control module. This information is provided in manual-style pages accompanying the C++ class definitions, using Hypertext Markup Language (HTML) format.

Supplementing the message specification is a model of data transfer, the Neutral Manufacturing Language (NML) [4]. This model provides for "mailboxes" of data, with one or more readers and writers. Each module is modeled as a cyclic process, which reads its input command from its supervisor, reads the status of its subordinates (or sensors), and computes and sends outputs to its subordinates (or actuators).

The interface specification is divided into two parts: commands that each module will perform, and status that each module will maintain. Both commands and status are derived from the NML message base class, and require a unique identifier and zero or more data fields representing the parameters to the command or fields in the status. During the development of the specification, the intent was to analyze the general requirements of each module in terms of which commands it should be responsible for carrying out, and what world model status it should be responsible for maintaining. Ideally, the specification would be complete enough to never require modifications. In the case of the Servo Control module, a literature survey conducted over a period of years resulted in a cataloguing of 62 algorithms, and a generalization of an interface to this module that would support implementation of the servo control function with any of these algorithms. However, no matter how comprehensive such a survey, new algorithms will inevitably arise which require input data or provide output data that are not available in the interface. Because of this, extensions to the interfaces are anticipated. Indeed, the need for extensions was evidenced during several of the validation tests discussed in subsequent sections of this paper.

SUPPORT INFRASTRUCTURE

A central problem faced when developing the interfaces was eliminating suppositions for computing platforms, operating systems, and programming languages. Already one can see that the C++ form of the interfaces presumes a programming language. Vendors of modules (toward whom these interfaces are aimed) need to provide the command initiation functions and world model access functions for the platforms the vendors have selected. This does not prevent developers from using another language for the implementation (e.g., the graphical user interface was coded in Microsoft Visual Basic in this case), but it does require that the external interfaces be C++-linkable.

The picture is complicated when considering how one assembles a system with components that provide these interfaces. For example, as seen in Figure 1, the Trajectory Generator module supervises the Servo Control module, typically generating points in a world coordinate system and sending them to the Servo Control subordinate. However, the Trajectory Generator cannot, in general, call functions provided by the Servo Controller, since the Trajectory Generator may be running on a different computer than the Servo Controller.

This problem is one aspect of the more general configuration problem, which leads to the question, "What services can be expected in an open architecture controller that allow components to interoperate?" Aside from a vendor's need to access memory, disk files, timers, and other operating system resources, there is more required from the support infrastructure as the example above illustrates.

Because we needed to implement controllers for various machines to embark on the validation effort, we required some particular support infrastructure. We used the NIST RCS Library [4], which has been ported to a variety of computing platforms, and directly supports the RCS methodology for implementing real-time control systems by providing a uniform programming interface to communication, timing, shared memory, and mutual exclusion primitives. However, by selecting this library, we sidestepped an important problem: which support infrastructure should be presumed (and indeed accompany) the interface specification? Architectures exist which can serve the purpose, such as the Common Object Request Broker Architecture (CORBA) [5] from the Object Management Group, but requiring a particular infrastructure greatly constrains the potential spectrum of applications. Resolving this problem was outside the scope of this effort.

VALIDATION TESTS

The interface validation tests were conducted in testbeds at NIST in Gaithersburg, Maryland and at the General Motors Powertrain facility in Pontiac, Michigan. At NIST, the testbed consisted of a UNIX workstation simulation for initial development, and a two-computer controller for run-time tests on a desktop milling machine (minimill). The graphical user interface ran on Microsoft Windows on the first computer, and the real-time controller ran on a UNIX operating system on the second computer. Communication between the two took place via ethernet. In Pontiac, the testbed consisted of the same dual-computer controller as for the minimill, running a Kearney & Trecker 800 4-axis horizontal machining center. In this case, the two computers shared a split backplane, yet still were bridged via ethernet.

The use of multiple platforms for development was enabled by the RCS Library, which had already been ported to the platforms selected. The key to ensuring that the control code remained portable was to restrict all programming calls to the ANSI C++ language and the RCS Library. By doing this, porting the control code from one platform to another required only a recompile.

The exception to this was the graphics system, programmed explicitly for Microsoft Windows. Initially, we attempted to define a programmer's interface to the common functionality of windowing systems, implementing it for the Macintosh, Microsoft Windows, and X Windows. If programmers wrote only to this API, then porting the graphics code would only require a recompile. Despite its obvious benefits, this approach suffers from a significant drawback: programming support tools tailored to specific windowing systems accelerate development of these applications to the degree that coding by hand to a functional API takes far more time.

Three tests were selected that together exercised the specification's support for open features: the development of a graphical user interface; selection between two commercial motion control products; and the addition of probing capabilities.

Independent Graphic User Interface

Although a graphical user interface (GUI) is a necessary component of a machine tool controller, there were no specific command initiation functions or world model access functions defined for the GUI proper. The GUI execution followed a cycle in which operator input such as button presses or keyboard input were read, the NML messages for the appropriate control module were sent to the controller, and the world model status for all the modules in the controller was read and displayed. Because the NML classes for control messages and world model data had already been defined, there was no need to develop any additional NML classes for the GUI.

The GUI itself was written in Microsoft Visual BASIC, by programmers familiar with the language and with access to a version of the C++ header files for Microsoft Windows. After designing the GUI, programmers developed a working interface that linked to the RCS Libraries which provided transparent, cross-platform information sharing and worked on both the UNIX simulation, minimill controller, and K & T 800 controller interchangeably. Some results of this validation:

1. A version of the C++ header files needed to be provided for Microsoft Windows. This points out the inevitable choice of supported platforms control vendors must make. Had we not provided these for this platform, the developers of the GUI would have been forced to select another.

2. The interface to the controller included information such as filename parameters which presumed the existence of a filesystem shared between the controller and the GUI. This forces any implementation of a controller which supports these interfaces to provide a file system.

3. The need for an interface specification to the GUI did arise. In many cases, the controller needs to query the operator for information, or to prompt the operator to perform a manual task such as fixturing. As a result, we needed to augment the interface specification with a command to the operator interface to present instructions, and world model data containing the results of the manual operation.

4. The interface specification provides for status and error reporting in each module's world model. Unfortunately, the mechanism for reporting errors presumes the mailbox model of communication, which does not queue information. In the case of error reporting, a queued history is required. Because of this, an explicit queued model for error reporting was incorporated into the specification.

Motion System Interoperability

In order to test interoperability, we selected two commercial motion control boards which each aggregated servo control and trajectory planning functionality, and wrote interface functions which implemented the command initiation functions and world model status functions for each. Using these interface functions, the test consisted of running the controller with one motion control board, powering down, linking in the interface code for the second motion control board, and running the controller again.

This test brought to the fore one of the central issues in developing an architecture and its associated interface specification: once particular modules have been defined, what functionality should be assumed of them? Two approaches highlight the extreme viewpoints. The first takes the position that the definition should include all possible functionality, and that in virtually no case will a product support the entire functionality. This eliminates the need to extend the interface, but it raises the possibility that products will not interoperate if one assumes functionality of another that is not provided. The second supposes minimal functionality, assuming that all products will support it entirely. However, such a minimal interface specification would surely beg for extensions as more and more products incorporate technology not reflected in the minimal specification.

Because of the drawbacks in each approach, there is no clear answer to the question. In our case, we assumed that any particular scope of functionality would be too broad for some, and too narrow for others. Thus,we needed to determine mechanisms for both extending the interface and providing some configuration methodology that would codify the extent of functionality various products provided so that gaps would be obvious before integration began.

Our test highlighted a difference in the abilities of each product to plan smooth transitions between linear and circular-arc motion. We chose this specific instance as a chance to determine a configuration methodology that would list the suppositions on module behavior, and require that a conformance document be provided for each board that indicated conformance with each behavior. These files serve two purposes. First, they can be used to determine incompatibilities by the system designer before the arise in the field, and perhaps more importantly, they can be accessed at run time for diagnostics purposes.

When developing a general specification based on implementation experiences, there is a tendency for machine-specific and component-specific dependencies to be inadvertently incorporated. One example resulted from a peculiarity in the Kearney & Trecker 800 horizontal machining center which required that the single rotary axis be interfaced to different motion control hardware than the three Cartesian axes. Although there was no effect on the interface to the Trajectory Generation or Servo Control modules, the separation was evidenced in the implementations of the command initiation functions and world model access functions for each motion control board. Since these functions are akin to device drivers, one would expect that they would be provided by the vendors of the motion control products. However, this puts the burden on the vendor to customize their driver for each machine, which defeats the purpose of standard interfaces.

A solution is to make the separation in the Task Sequencer, whose logic already contains machine configuration information. In this case, motion control of the rotary axis is implemented with one component and motion control of the three Cartesian axes with a second, and this split is reflected not in the Trajectory Controller implementation but as two motion subordinates to the Task Sequencer.

Probing Extensions

Extensibility is perhaps the most difficult feature to achieve, primarily because of the impact it has throughout the controller. Adding capabilities to an open architecture controller will, in general, require extending the interface specification and extending each module to reflect the new ability of the controller. As a validation test for extensibility, touch-trigger probing and continuous analog probing were added to the existing EMC implementation.

Touch-trigger probing requires that the controller latch the axis positions in the servo controller in response to a trigger signal. The latched positions must then be saved, and the motion halted immediately. Continuous analog probing incorporates an analog probe into the latching, so that the trigger signal calls for simultaneous latching of the axis positions and the probe output. As with touch-trigger probing, data must be saved and motion halted.

The impact was broad. Although the interface specification already included the command initiation functions and world model access functions for touch-trigger probing, continuous analog probing was not anticipated by the developers of the interfaces and needed to be added to the trajectory planner and servo control modules. This addition merely allowed the probing to be specified. The existing interface functions to the motion control hardware needed to be modified so that the specified functionality could be accomplished. This did not require access to the source code of the existing implementation in this case, although in cases where the added functionality could interfere with resources used for existing functionality it would be necessary.

Within the Task Sequencer, two modifications were necessary. First, the part program interpreter required a language update that allowed probing to be specified. The language itself contained provisions for adding new statements, since this was anticipated. Had it not been extensible, the source code would be required. Using the same approach, the sequencer itself was augmented with logic to halt the trajectory controller when the trigger condition was observed.

It is highly desirable to avoid the disclosure of source code in an open controller because it is sensitive intellectual property. The approach often taken, as above, is to provide interface points throughout the controller, commonly called "hooks," to which extended functionality can be attached. The advantage is that source code need not be disclosed. The disadvantage is that if the designers of the original controller chose not to place hooks in a certain area, nothing can be done by third parties to get access to that area.

REFERENCES

1. Proctor, F. M., and Michaloski, J., "Enhanced Machine Controller Architecture Overview," NIST Internal Report 5331, December 1993.

2. Albus, J. S., "Outline for a Theory of Intelligence," IEEE Transactions on Systems, Man, and Cybernetics, Vol. 21, No. 3, May/June 1991.

3. Technologies Enabling Agile Manufacturing (TEAM) Application Programming Interfaces, Internet Location: http://isd.cme.nist.gov/info/team/

4. Shackleford, W., and Proctor, F. M., "The Real-time Control System Library," Internet Location: http://isd.cme.nist.gov/~shackle/rcslib/

5. Object Management Group, "What is CORBA?," Internet Location: http://ruby.omg.org/corba.htm

This publication was prepared by United States Government employees as part of their official duties and is, therefore, a work of the U.S. Government and not subject to copyright.