In a distributed, object-oriented, hierarchical shop control system, there are many ways of organizing the interactions between supervisory controllers and subordinate controllers. Depending on what model of job control is used, objects will be allocated differently among the levels of control, and the interactions between controllers will vary considerably. This paper describes five models of job control that are equally functional, but use different paradigms for managing jobs. Although each is attempting to serve the same purpose in the same context, the five ways of viewing the system lead to distinct implementations that cannot interoperate. This demonstrates the importance of specifying the control model when designing an object-oriented manufacturing system.

Some years ago, object-oriented programming languages were introduced to improve the maintainability and reusability of software systems. The object-oriented approach permits developers to map real-world entities, such as machine controllers, to programming language constructs called classes that encapsulate the attributes and behaviors needed to model the real-world entity. Usage of object-oriented techniques is motivated by the belief that they result in software that is more understandable as well as more maintainable and reusable.

Object-oriented programming languages are complemented by an object-oriented mechanism for communication between programs, where the programs run independently and may run on different physical computer systems. The "owner" program for a given object creates the object and uses the program memory resources to store the state (data) of the object. When a program invokes an operation on an object that it owns (a "local" object), it is just like a function call; but when a program invokes an operation on an object that is owned by a different program (a "remote" object), the request and its response must be transmitted over the network. Distributed object architectures, such as the Common Object Request Broker Architecture (CORBA) (OMG, 1997), provide this network service so that invoking operations on remote objects is no harder for the programmer than invoking operations on local objects. This capability leads to the construction of "distributed object systems" in which the conceptual design of a distributed system is mapped onto a distributed object implementation. Because of their maintainability, performance, and standardization, distributed object architectures are being examined by some manufacturers as a possible replacement for aging and/or inadequate message bus architectures.

Object orientation is not, however, without its problems. A good mapping between real-world entities and implementation classes only happens as the result of good design decisions. If the design embodies confused thinking, then the resulting implementation will suffer, and may not work out at all. A consistent way of viewing a system is called an "object model." There may be several equally good object models for a particular system, but a consistent design requires that exactly one object model be chosen. Sometimes it is not until implementation is underway, and unexpected incompatibilities between components begin to crop up, that it is found that the system design does not consistently adhere to one object model.

This paper describes five different object models for hierarchical job control in manufacturing. In hierarchical job control, planning and dispatching responsibility is distributed between supervisory entities and subordinate entities. A job supervisor dispatches low-level jobs to any number of subordinates to accomplish its high-level goals. This permits localization of planning and replanning activities and easier coordination of the manufacturing activities of interrelated equipment.

Hierarchical job control is a good candidate for distributed object technology because it is decentralized and uses multiple semi-autonomous entities. By presenting five object models for hierarchical job control, we hope to facilitate the design process for distributed object systems in the manufacturing domain, and help designers to avoid dangerous ambiguities in their specifications.

For the National Advanced Manufacturing Testbed (NAMT) Framework project (Bloom and Christopher, 1996), a prototype, distributed manufacturing system was developed at the National Institute of Standards and Technology. It serves as a testbed and trial implementation for emerging specifications such as SEMATECH's CIM Framework (CIMF) (Eng et al., 1996).

In the testbed system, one of the important areas for protocol testing is the management of Jobs (or Tasks) on the factory floor. Following the apparent intent of the CIMF and several other specifications now being developed for "Manufacturing Execution Systems," the overall model used for the management of Jobs is a hierarchical one. There are two components involved in the communications about a given Job: a "supervisor," such as a shop dispatcher, and a "subordinate," such as a workcell controller.

During the initial analysis in which the Framework team attempted to understand the component interactions of version 1.3 of the CIMF, three possible models of job control – three different but equally valid scenarios for component interaction – came to be identified. Two more models were identified later after our assumptions were analyzed in more detail.

Each model admits to several possible implementation structures (variants), because functions can be assigned to different classes of objects (where classes of objects are internal software structures) within the same control entity to accomplish the same effect. For this discussion, an entity is one of the components that communicate with each other in a distributed manufacturing system. A single entity may implement multiple classes of objects, but ultimately those objects will all share the same process space on the same machine. Therefore, at a certain level, it does not matter which specific object handles any given operation, since they are all different faces of the same entity. Depending on whether the goal is maximal similarity to a specification, adherence to some particular methodology, or ease of implementation, the allocation of operations to specific objects will be made in different ways. That which distinguishes one model of job control from another is the allocation of objects to different entities, not the allocation of operations to different objects within an entity.

While the issue of variant interpretations of object-oriented control specifications is a narrow and seldom visited topic, literature dealing with the application of object-oriented techniques to manufacturing systems in general is abundant.

Mize et al. (1992) make the case for object-oriented modeling of manufacturing systems and express the benefits of making the validation, revision, and reuse of models an integral part of the process of building manufacturing systems. They draw a useful distinction between physical objects that represent real-world entities, information objects that are just containers for data, and control/decision objects like the Controller objects that we introduce below.

Chen and Lu (1997) advocate a design methodology that includes an Informational Model, a Functional Model, and a Dynamical Model. The Dynamical Model, for which they use Petri-nets, helps to clarify intended behaviors that are not necessarily obvious from the object model and/or specification that is eventually produced.

Lenart and Nof (1997) provide a detailed case study of migrating a sheet metal manufacturer to an object-oriented system using parallel objects. In an earlier paper, Nof (1994) surveys five different object-oriented case studies that employed a variety of tools and techniques. Similarly, Smith and Joshi (1992) provide an example of applying object orientation and other techniques to optimize the development of FMS control software, with special attention to code reuse.

The reader is encouraged to explore the above referenced papers to obtain additional background, introductory material, and references to more related work.

The following subsections present five generic models of job control. Each one is illustrated with an example showing two levels of control, implemented using two generic classes, Controller and Job. The models have been rendered as sequence diagrams in the Unified Modeling Language (Rational, 1997).

In the sequence diagrams, different fonts have been used to distinguish descriptive messages, which merely change the value of an information field to describe the current state of something, from prescriptive messages, which are commands telling a subordinate entity to make something happen. Prescriptive messages are typeset in bold while descriptive messages are in a normal font. This convention is useful for clarifying the intent of operations when it is not obvious from their names. For example, an operation named "makeStopping" might be either prescriptive (stop the machine!) or descriptive (update the record to show that the machine is stopping now).

Some of the models have variants which we have identified as the "job-centric" and "controller-centric" variants. The difference between these variants is whether job-related operations are encapsulated with the Jobs or are instead placed on the Controllers. This may affect whether a particular Job object is an information object that simply contains data about the specific job or a control object that encapsulates control functions for the specific job as well. As was mentioned in the Introduction, the ramifications of this particular decision are not serious, so for the purposes of this discussion we do not consider these variants to be different models.

A brief comparison of the five models is shown in Table 1. They are distinguished by the entity that "hosts" or "owns" the job. This "ownership" means that, in an implementation, the Job object will exist in the entity's work space and may be tightly integrated with its control system. The ownership of a job therefore has a deciding role in how it is feasible to distribute control logic among objects in the system.

The SUB model corresponds to a way of thinking in which a job is "owned" by the subordinate. The subordinate entity provides one Controller object and a Job object to represent each task; the supervisor provides only a Controller object to the subordinate. Task-related feedback to the supervisor must either be sent directly to the Controller object or communicated through an out-of-band mechanism, such as "events."

Figures 1 and 2 illustrate the job-centric and controller-centric variants of this model (SUBj and SUBc) for a normal job dispatch scenario. In SUBj, job-specific control logic is encapsulated in the Job; in SUBc, all of the control logic is lumped into the Subordinate, and the Job is only an information object.

The following explains the steps of the normal job dispatch in greater detail.

• Supervisor invokes a createJob operation on the subordinate Controller, which returns a Job object owned by the subordinate.
• Supervisor supplies values for the attributes of the Job object to describe the task that must be done.
• Supervisor instructs the subordinate to start the job. Implementation variants:

• SUBj: Operation on the Job, Job::start(void).
• SUBc: Operation on the subordinate Controller, Controller::startJob(Job).

• Subordinate begins the task.
• When the task is completed:

• SUBj: Supervisor finds out by polling the status of the job, Job::getStatus(void).
• SUBc: Subordinate invokes an "inform" Operation on the supervisory Controller, Controller::informJobCompleted(jobName), or uses an out-of-band mechanism, such as "events." Only the job name is meaningful to the supervisor, since the job itself is owned by the subordinate.

If the supervisor needed to abort the task, or to perform some other supervisory intervention (pause/resume, stop, hold, etc.), it would do so in a way similar to the way it started the job:

• To abort the job:

• SUBj: Operation on the Job, Job::abort(void), or
• SUBc: Operation on the subordinate Controller, Controller::abortJob(Job).

While it is possible to mix aspects of SUBj and SUBc in various ways by moving individual operations between the Job and the subordinate Controller, or by switching between polling, inform messages, and events to supply feedback to the supervisor, the mixed variants sacrifice consistency of design without producing any benefits in return. We will therefore simplify this discussion by sticking with two canonical variants that exemplify two major views of the role of the Job.

The choice between using commands of the form Job::abort(void) or Controller::abortJob(Job) corresponds to two different approaches to objectifying the job control domain. If one recognizes jobs as tangible objects having state, behavior, and identity (Booch, 1991), then pausing, stopping, and aborting are all behaviors of jobs, and they belong as operations on the Job objects. On the other hand, one could argue that jobs are not tangible objects, but are merely processes performed by the controllers. In that case, the pausing, stopping, and aborting of jobs are all behaviors of the Controller object, and the Jobs themselves, if they exist at all, are only records for job-related data.

The SUBj variant does not require the supervisor to expose any object services to the subordinate. SUBj thus offers the potential for the supervisor to be a "pure client" – an entity that exposes no services – and the subordinate to be a "pure server" – an entity that does not use the services of any other. This makes SUBj the easiest to implement using CORBA, where "impure" servers may require additional programming overhead to obtain all necessary object references and to prevent deadlock situations. SUBj is also the closest thing to an open-loop control system in which the subordinate provides no feedback at all. However, SUBj requires more communication between the Subordinate object and the Job object than does SUBc, so there is no clear winner for simplicity of implementation.

Of the three feedback mechanisms suggested (polling, inform messages, or events), only the polling mechanism shown in SUBj is really consistent with object-oriented design, in that an operation dealing with the status of the Job is an operation on the Job object. But the polling mechanism thus represented is very inefficient for real-time control activities. The "inform" mechanism, using the Job name, is a kind of faux object-oriented mechanism that is adequate to the need and maintains at least the client/server relationship. But the "notification" mechanism poses a real threat to object-oriented design. The mechanism itself is simply an open-ended messaging scheme that maintains neither the object-oriented association of the operation with the Job object nor the client/server relationship. It is a general-purpose communication service that is "object-oriented" only to the extent that the supervisor internally renders the arrival of the event into one of the other two forms.

The SUP model corresponds to a way of thinking in which a job is "owned" by the supervisor and is "assigned" to the subordinate to work on. The supervisory entity provides one Controller object and a Job object to represent each subordinate task; the subordinate provides only a Controller object. Task-related feedback to the supervisor may be communicated through the Job object that was assigned to the subordinate.

Like SUB, SUP also has job-centric and controller-centric variants (SUPj and SUPc). SUPj is shown in Fig. 3. The only difference in SUPc would be that feedback would be provided by an inform message to the supervisor or an event instead of by a setStatus operation on the job.

The advantage of the SUP model is that it exposes the Job object in the supervisor, giving the subordinate a truly object-oriented means of reporting status changes and providing other feedback information to the supervisor. Because these operations can directly trigger some action in the supervisor, this model effectively addresses the need for real-time interactions. However, the full benefit of the object-oriented approach is not realized in the SUPc variant since job-related operations are not directed to the jobs themselves.

Both SUP variants require the supervisor and subordinate to act as both client and server; the simplifications that are possible with SUBj are not possible with SUP.

The DUP model corresponds to a way of thinking in which a job is not "owned" by either the supervisor or the subordinate, but rather is a joint concept of which each has a somewhat independent view. Each entity has a Job object that represents its view of the task, and each identifies its Job object to the other. (This is closer to the internal models of the two entities, since the supervisor's Job object is related to other tasks and concerns in the supervisor's scope of work, while the subordinate's Job object is related to the details of its execution within the subordinate's scope of work.) The entities communicate with each other and "maintain synchronization" of the two Job objects primarily by invoking operations on each other's Job object. As with previous models, there is a job-centric variant (see Fig. 4) and a controller-centric variant; however, because the JobAtSub is created using the JobForSub, the start job command can only go to the subordinate controller. Subsequent job-related commands and feedback can be shifted between the jobs and the controllers to create the variants.

The advantage of the DUP model is that each entity exposes its view of the job and each entity has access to operations on the other entity's Job. These can be used for retrieving information as well as sending commands or notifications. With the exception of the start job command, operations on Jobs can be used consistently with no need for job control operations on the Controller or out-of-band feedback mechanisms. And because each can invoke the other, real-time interaction requirements can be met. The disadvantage is the complexity of having two different representations of the job and of keeping them consistent with one another.

Apart from object-oriented purism, there is a further advantage to the DUP model over the SUP model when one expands the view to include external monitoring of shop-floor activity. With the SUP model, the external monitor client can only obtain the supervisor's view of what is happening to the Job; it cannot obtain first-hand Job information from the subordinate that is actually carrying out the job. With the DUP model, the external monitor can obtain both, but most importantly, it can obtain the subordinate's view.

The DUP model is thus the synthesis of the best features of both the SUP model and the SUB model: convenient object-oriented real-time interaction coupled with external visibility of the subordinate's Job. Unfortunately, it is also the most complicated in terms of interface and programming requirements.

From the controller-centric variants of previous models, where the Job objects are relatively passive, it is but a small step to the database hosted job model (DB), where a passive Job object is divorced from both controllers and is instead owned by a third entity. The perspective of the DB model is that the job is really not inherent in either the supervisor or the subordinate but is a collective abstraction, represented by an information object.

In the DB model (see Fig. 5), the supervisor and the subordinate each provide only a Controller object, and the "database server" maintains a Job object for each job anywhere in the system. This model has many of the advantages of the DUP model with somewhat less complexity and slightly higher overhead. In addition, it separates the issue of who "owns" the Job objects from how the interaction is specified, which increases modifiability. However, the opportunity to encapsulate traditional control logic in the Job object or tightly integrate it with a controller is lost.

Note how the "get status" message is not considered prescriptive as it was in Fig. 1. This reflects the fact that there is no opportunity in this case to check the actual status of the physical machines in real time when the request arrives. While a subordinate hosted job can insure that the status that it returns is consistent with reality, a database hosted job can only return the contents of its status field, which may have pending uncommitted updates from the subordinate.

The DB model supports a data-driven approach that can be consistently applied throughout the system, where all state information is kept in a single database and all decisions are made based on the contents of that database. That approach makes it easier to keep a history and to implement persistence for important information. Taking this view further, the integrity constraints and triggers provided by modern "active" databases could be put to good use insuring that the supervisor's and the subordinate's views of the job are consistent, deriving the states of higher-level jobs from the states of their constituent tasks, and automatically notifying the controllers of important changes. At some point, however, as more and more triggers are added, the database-owned jobs would become non-traditional control objects. This would shift significant control functionality away from the systems that were designed to make such decisions and wreck the hierarchical control architecture, potentially creating a monolithic controller for the entire shop. It would become a centralized control architecture instead of a hierarchical one (Duffie et al., 1988).

While it enhances modifiability, the separation of the Job object from the controllers creates a potential pitfall: it may be unclear to the programmer of an entity whether that entity is expected to provide the services pertaining to a particular Job object. This means that the client behavior of entities must be defined as well as their server behavior. But the most serious disadvantage is a practical one: with the database owning all of the jobs, the database becomes an additional single point of failure for the entire factory.

The mobile job model (MOB) represents a novel approach in which ownership of the job is transferred from supervisor to subordinate and back again, and the job object actually moves from entity to entity. In MOB (see Fig. 6), there is no issue of maintaining consistency between multiple views of the job. All of the state information and much of the control logic is encapsulated in the mobile Job object, and a controller that is not currently holding the job does not worry about it until it is sent back.

Obviously, there is reason for concern that the Job object is now a particularly nasty single point of failure. For example, if the Job is lost in transit between one controller and another, not only is the job lost, but it is possible that the loss may even go undetected. On the other hand, assuming that this problem is overcome by some technical means, MOB offers a degree of encapsulation for job-related operations and data that is unmatched by any of the other models. In MOB, it is not necessary to separate the supervisor's job view from the subordinate's job view when writing the control code. Instead, the viewpoint of the control code is that of the job itself, seamlessly following the thread of control from supervisor to subordinate and back again. The encapsulation is so complete that the controllers in the hierarchical framework could themselves be highly generic, mere vehicles for the specialized control logic in a very heterogeneous collection of jobs.

The technology to support this mode of programming in the CORBA environment (BEA Systems, Inc. et al., 1998) should be commercially available soon, and experiments in applying the MOB model may yield interesting results on the model's practical value, be it positive or negative.

The relative costs and benefits of the five models are summarized in Table 2. SUB and SUP, by assigning ownership of the job to one entity or the other, make some operations easier and other operations more difficult or less elegant. DUP makes all operations elegant at the cost of greater complexity and redundancy, which may lead to two inconsistent representations of the same job. DB solves this problem by creating a canonical record of the job state, but it makes it more difficult to encapsulate control logic in the Job objects. (It also creates some question about whether the "canonical" job state matches the "actual" job state at the machine level at any given time.) Finally, MOB allows creative approaches to the system design at the cost of higher complexity and fragility.

Assuming that each model is correctly and consistently adhered to by an implementation, the visible differences are fairly minor. The important point is that an ambiguous specification can easily result in an inconsistent implementation that does not work at all. An examination of the models and of our own experiences suggests the following recommendations for avoiding ambiguity.

1. Provide sequence diagrams that show how objects are meant to interact in normal scenarios.
2. Specify the intended host of created objects using placement, a "new" message, or another convention as appropriate.
3. Where possible, explicitly designate objects as physical objects, information objects, or control/decision objects.
4. Specify whether operations such as "set status" are intended to be descriptive or prescriptive. That is, does this merely change the value of an information field in a job record to reflect what I believe the current status to be, or does it equate to a command to a subordinate entity to "make it so?"
5. Check whether the specification admits more than one of the five control models that we have identified.

Five different but equally functional models of job control have been presented. Although each is attempting to serve the same purpose in the same context, the five ways of viewing the system lead to distinct implementations that cannot interoperate. It is not possible to use a supervisor from one model with a subordinate from another; they would have conflicting assumptions about the ownership and usage of job objects.

Given these incompatibilities caused by nothing more than differing models of job control, it is essential that any standard or specification within the job control arena be clear and unambiguous in its description of its job control model to avoid potential interoperability failures. Definitions of controller objects, job objects, and the related interfaces are necessary, but in the absence of a control model they are not sufficient to guarantee interoperability.

Heterarchical systems (Duffie et al., 1988, Duffie and Piper 1986) can also suffer from the kinds of potential ambiguities and alternate models that we have found in the hierarchical case. If entities in such a system are represented by software "agents," then an object model naturally emerges with various agent classes. However, specifying the control model may not be straightforward. These models may be even more prone to ambiguity than hierarchical ones since the role of each entity in the overall control scheme is less restricted. It would be easy, for example, to create deadlocks or repeated time-out conditions if it is not clear which of two entities is supposed to be waiting on the other.

Even though the number of entities in our models is small, we still have not exhausted all possible models of job control. As new paradigms like mobile objects emerge, new ways of performing old tasks become apparent, and specifications that once were unambiguous can become subject to new interpretations.

The authors thank all of the reviewers, within and without NIST, whose comments have improved this paper.

Bloom, H. M. and Christopher, N., 1996, "A framework for distributed and virtual discrete part manufacturing," in Proceedings of the CALS EXPO '96, Long Beach, CA.

Booch, G., 1991, Object-Oriented Design with Applications, Benjamin/Cummings, p. 77.

Chen, K. Y. and Lu, S. S., 1997, "A Petri-net and entity-relationship diagram based object-oriented design method for manufacturing systems control," International Journal of Computer Integrated Manufacturing, Vol. 10, pp. 17-28.

Duffie, N. A., Chitturi, R., and Mou, J. I., 1988, "Fault-tolerant Heterarchical Control of Heterogeneous Manufacturing System Entities," Journal of Manufacturing Systems, Vol. 7, pp. 315-327.

Duffie, N. A. and Piper, R. S., 1986, "Nonhierarchical Control of Manufacturing Systems," Journal of Manufacturing Systems, Vol. 5, pp. 137-139.

Eng, L., Freed, K., Hollister, J., Jobe, C., McGuire, P., Moser, A., Parikh, V., Pratt, M., Waskiewicz, F., and Yeager, F., 1996, Computer Integrated Manufacturing (CIM) Application Framework Specification 1.3, SEMATECH, 2706 Montopolis Drive, Austin, TX 78741 U.S.A.

Lenart, G. M. and Nof, S. Y., 1997, "Object-oriented design of information integration in sheet metal manufacturing," International Journal of Computer Integrated Manufacturing, Vol. 10, pp. 29-50.

Mize, J. H., Bhuskute, H. C., Pratt, D. B., and Kamath, M., 1992, "Modeling of integrated manufacturing systems using an object-oriented approach," IIE Transactions, Vol. 24, pp. 14-26.

Nof, S. Y., 1994, "Critiquing the potential of object orientation in manufacturing," International Journal of Computer Integrated Manufacturing, Vol. 7, pp. 3-16.

Smith, J. S. and Joshi, S. B., 1992, "Reusable software concepts applied to the development of FMS control software," International Journal of Computer Integrated Manufacturing, Vol. 5, pp. 182-196.

Table 1: Five models of job control

Model ID	Description	Feasible control distribution
SUB	Subordinate hosted job	Job may encapsulate subordinate job control
SUP	Supervisor hosted job	Job may encapsulate supervisor job control
DUP	Duplicated job	Separate subclasses may encapsulate respective control
DB	Database hosted job	Job is primarily an information object
MOB	Mobile job	Job may encapsulate multi-level control

Table 2: Costs and benefits

Model ID	Costs	Benefits
SUB	No object reference for supervisor's view	Easy CORBA implementation
SUP	No object reference for subordinate's view	Easy feedback to supervisor
DUP	Redundancy, complexity	Full objectification of both job views
DB	Messy to encapsulate control logic in job	Canonical job view
MOB	Complexity, fragility	Admits non-traditional design

Figure 1: Subordinate hosted job model, job-centric variant (SUBj)

Figure 2: Subordinate hosted job model, controller-centric variant (SUBc)

Figure 3: Supervisor hosted job model, job-centric variant (SUPj)

Figure 4: Duplicated job model, job-centric variant (DUPj)

Figure 5: Database hosted job model (DB)

Figure 6: Mobile job model (MOB)