IMPLEMENTATION OF THE

INSPECTION WORKSTATION CONTROLLER

NEW NIST PUBLICATION

October 18, 1988

July 13, 1988 By:

Stephen A* OselJa

joSpioRji rswxs®pi<i?-Hgsi»

f^yiOXOi iiliiili

Ixwo:

;<JOiyXO:

iiiliiliiiliii

IMPLEMENTATION OF THE INSPECTION WORKSTATION CONTROLLER

Stephen A. Osella

July 13, 1988

P «?are

? by United States Government employthp tt r the

heir official duties and is, therefore, a work oi U.S. Government and not subject to copyright.

ec^uiPment ' instruments, or materials are identified in this paper m order to adequately specify the experimental procedure. Such identification does not imply recommendation or endorsement by the National Bureau of Standard^

necessarily necessarily tKe^ “

equipment identified are^ the best available for the purpose.
'

.

.
TABLE OF CONTENTS

Page

I. INTRODUCTION 1

1. WHAT THIS DOCUMENT IS ABOUT 1

2 . AUDIENCE 1

3. OVERVIEW 1

II. HIGH LEVEL DESCRIPTION OF THE WORKSTATION CONTROLLER ... 3

1 . BRIEF DESCRIPTION 3

2. LOCATION IN THE WORKSTATION ARCHITECTURE...... 3

3. MAIN CONTROLLER FUNCTIONS 3

4. WORK ELEMENTS AND STATUSES 3

III. SPECIFIC WORKSTATION CONTROLLER DETAILS 5

1. WORKSTATION CONTROLLER FUNCTIONS 5

1.1. Cell Interface 5

1.2. Task Scheduling 5

1.3.. Eguipment Controller Interface . . . . * 5

2. WORKSTATION CONTROL STRATEGY 5

2.1. Task Decomposition Using Hierarchical Control .... 5

2.2. State Transition Using The UVA System Model 5

2.3. Data Driven Processes 5

IV. DATA STRUCTURES 7

1. AMRF DATA 7

1.1. Tray Definition 7

1.2. Tray Contents 7

1.3. Inspection Process Plan 7

2. INTERNAL DATA STRUCTURE 7

V. TASK DECOMPOSITION 9

1. WORKSTATION MANAGER (WSM) 9

2. PRODUCTION MANAGER ( PMGR) 11

3. QUEUE MANAGER (QMGR) 11

4. EQUIPMENT DISPATCHERS 12

i
VI. PROCEDURE MODULES 13

1 . wsclib 13

2. wsc_glob 13

3. cell_glob 13

4. disp_glob 13

5. net_trans 13

VII. INTERFACE TO EQUIPMENT 15

1. MODULES THAT INTERFACE TO EQUIPMENT 15

2. DETAILS OF THE CURRENT IMPLEMENTATION 15

3. CHANGES REQUIRED FOR CONTROLLER SUBSTITUTION 15

VIII. INITIALIZATION AND SHUT DOWN 17

1. START UP 17

2 . SHUT DOWN 17

IX. ERROR HANDLING 19

1. PROCESS PLAN PARSER ERROR 19

2. DATA SERVER ERROR 19

2.1. File Not Found 19

2.2. IMDAS Error . 19

3 . EQUIPMENT CONTROLLER ERROR. 19

X. USER INTERFACE . 21

1. EXTRA MODULES REQUIRED FOR TESTING 21

1.1. user_wsc 21

1.2. wsc irc 21

1.3. wsc_cmm 21

2. USER COMMANDS 21

3 . OPERATING OPTIONS 21

XI. FUTURE PLANS . 23

1. SOFTWARE DEVELOPMENT 2 3

1.1. Automatic Task Scheduling 23

1.2. Error Recovery 24
1.3. Multiple Work Orders Per Cell Command 24

1.4. Inspection Results Reported To AMRF Database 24

2. NEW HARDWARE 2 4

3. PROBLEM AREAS 2.5

APPENDICES

A. IWS DOCUMENTATION LIST 2 7

B. REFERENCES 2 9

C. GLOSSARY (and abbreviations) 31

D. LOCAL DATA FILES 33

READER COMMENT FORM 3 5

iii
IMPLEMENTATION OF THE INSPECTION WORKSTATION CONTROLLER

I. INTRODUCTION

1. WHAT THIS DOCUMENT IS ABOUT

This document describes the implementation specifics of the

Inspection Workstation Controller (WSC) program. This program

runs under the control of the ECS program that is described in the

document IMPLEMENTATION OF THE EXECUTION CONTROL SYSTEM OF THE

INSPECTION WORKSTATION . The controller program consists of state

machine modules that "customize" the controller for its particular

application — i.e. supervising the IWS

.

2 . AUDIENCE

Anyone who needs to understand the internals of the WSC software

should read this document. This includes anyone who will continue

the development of the WSC software or make modifications to it.

The document ARCHITECTURE AND PRINCIPLES OF THE INSPECTION

WORKSTATION describes the principles that the ecs and WSC programs

utilize. It is recommended that this document be read first.

3. OVERVIEW

Chapter II gives a top level description of the WSC. It specifies*

the location of the WSC in the IWS control hierarchy, and

describes the main functions the controller performs.

Chapter III discusses some of the principles used in the design of

the WSC.

Next, Chapter IV describes the main data structures, both global

to the AMRF as well as local to the IWS, that the controller

program uses. The specific task decomposition that the WSC

incorporates is explained next in Chapter V. Additionally,

procedure modules used by the main tasks discussed in Chapter V

are described in Chapter VI.

The actual interface to the equipment controllers that the WSC

supervises is specified in Chapter VII. Specific details used in

the start up and shut down procedures are described in Chapter

VIII. Errors that can occur during operation are listed and

explained in Chapter IX. Chapter X describes the user interface

to the WSC. Finally, Chapter XI discusses future development

plans for the WSC.

1
IWS WSC IMPLEMENTATION

The appendices include further information and implementation

details. Appendix A lists the entire IWS documentation set. In

Appendix B is the list of references. Appendix C contains a

glossary of terms used in this document. Appendix D specifies the

local data files used by the WSC.

Completing the document is a reader/comment form. You are

encouraged to write down your comments and mail the attached form

to the address specified.

2
IWS WSC IMPLEMENTATION

II. HIGH LEVEL DESCRIPTION OF THE WORKSTATION CONTROLLER

1. BRIEF DESCRIPTION

The Inspection Workstation Controller supervises the equipment

controllers of the Inspection Workstation. The controller uses a

data driven, hierarchical task decomposition control strategy and

incorporates the University of Virginia (UVA) model for system

initialization, restart, and shutdown [B.l].

2. LOCATION IN THE WORKSTATION ARCHITECTURE

As shown in Figure 1, the WSC is subordinate to the Cell

Controller and manages the operation of the Inspection Robot and

Coordinate Measuring Machine Controllers.

3. MAIN CONTROLLER FUNCTIONS

The overall function of the WSC is to interface with the Cell

controller, to schedule equipment tasks, and to regulate the

activity of the workstation equipment controllers.

4. WORK ELEMENTS AND STATUSES

The WSC receives commands from the Cell Controller. As stipulated

in the AMRF architecture and UVA system model specifications,

these commands are either transition or work order commands [B.2].

The WSC receives the standard transition commands and issues the

standard status responses. The work order commands supported by

the WSC are RECEIVE TRAY, INSPECT LOT, and SHIP TRAY.

3
IWS WSC IMPLEMENTATION

Figure 1: Logical Configuration of the

Inspection Workstation Controller

4
IWS WSC IMPLEMENTATION

III. SPECIFIC WORKSTATION CONTROLLER DETAILS

1. WORKSTATION CONTROLLER FUNCTIONS

1.1. Cell Controller Interface

The Cell to Inspection Workstation interface entails decoding

command data, parsing and managing commands, and reporting command

statuses. Interfacing with the Cell Controller is performed by

the Workstation Manager module of the Workstation Controller. The

implementation of the Workstation Manager is detailed in a

following section.

1.2. Task Scheduling

Task scheduling is a requisite responsibility for controllers

which use a hierarchical control strategy and are in charge of

managing a number of tasks which are dependent on shared

resources. The present Inspection Workstation configuration

consists of a Coordinate Measuring Machine used to measure the

dimensional tolerances of a part, a Surface Roughness Instrument

used to measure a part’s surface finish, and a robot used to

transfer parts from the tray to either of the measuring machines

or from one of the machines to the other. Task scheduling at the

IWS -involves coordinating the inspection processes of the CMM and

SRI with the transfer of parts- by the robot. Pertinent data is

retrieved from the AMRF database by the Production Manager module

and the Queue Manager module performs the required task

scheduling.

1.3. Equipment Controller Interface

The Workstation Controller interfaces with the equipment

controllers through individual equipment Dispatcher modules. The

implementation of the Dispatchers is detailed in a following

section.

2. WORKSTATION CONTROL STRATEGY

2.1. Task Decomposition Using Hierarchical Control

The WSC uses the hierarchical control strategy for task

decomposition [B.3]. The input task to the Inspection Workstation

Controller is a Cell Controller work order, such as INSPECT LOT,

and the output is a set of high level work elements to the

equipment controllers, such as INSPECT PART for the Coordinate

Measuring Machine Controller and TRANSFER for the Robot

Controller. These work elements constitute the process plan for

the inspection procedure. Consistent with the hierarchical

control philosophy, each level of the WSC hierarchy is in charge

5
IWS WSC IMPLEMENTATION

of decomposing the input command into a simpler form and when

appropriate, issuing new tasks to the lower levels of control.

Also, each module is subject to reporting the status of the input

command and supervising the operation of the next lower control

level [B. 4 ]

.

2.2. State Transition Using The UVA System Model

The UVA system model is used to specify the WSC state transition

processes. As defined in the UVA system model document, there are

three quiescent states and six non-quiescent states. The

quiescent states are COLD SHUTDOWN, WARM SHUTDOWN, and READY and,

the non-quiescent states are BUSY COLD STARTUP, BUSY WARM STARTUP,

BUSY COLD SHUTDOWN, RECONFIGURATION, BUSY CHANGE CONTROL MODE, and

BUSY CHANGE DATA MODE. At the moment only the quiescent and the

first three non-quiescent states have been implemented in the WSC.

The following states were added in the WSC to the basic UVA system

model explained above in order to account for a more varied

operation : BUSY INITIALIZE, SYNCHRONIZE WAIT, BUSY SYNCHRONIZE,

IDLE, and BUSY PROCESS. The first three states can be considered

to be sub-states of the BUSY COLD STARTUP state and the last two

to be sub-states of the READY state.

The WSC modules power up into the BUSY INITIALIZE state where

system initialization is performed. Subsequently, the SYNCHRONIZE

WAIT state is entered wherein a SYNCHRONIZE command is ' expected in

order to transit to the BUSY SYNCHRONIZE state. In the BUSY

SYNCHRONIZE, the WSC waits for a response of DONE from lower level

module before entering the WARM SHUTDOWN state.

READY is the state the WSC modules are in while expecting either

work orders or a WARM SHUTDOWN command. The BUSY PROCESS and IDLE

sub-states are used to distinguish between working and not working

on a work order in READY state. This differs from the BUSY WARM

SHUTDOWN processing of work orders where no sub-states are needed

since no new commands are accepted until warm shutdown is

completed.

2.3. Data Driven Processes

The control processes of the Inspection Workstation Controller are

data driven. Data driven process control implies that the while

the structure of the program is fixed, the output control commands

are dependent on the input data. In the WSC, there are three

variable data entities: the tray definition report, the tray

contents report, and the inspection process plan. The WSC uses

the tray contents report and the inspection process plan to

decompose the input work order command of INSPECT_LOT into the

scheduled set of equipment level work orders.

6
IWS WSC IMPLEMENTATION

IV. DATA STRUCTURES

1 . AMRF DATA

As stated above, the Workstation Controller uses three data

reports to prepare, schedule, and perform the inspection process.

The three reports are the Tray Definition, Tray Contents, and the

Process Plan reports. They are discussed in more detail later.

Data stored in the AMRF database is in a format which has been

specified in the Control-Database Interface document [B.5].

To access the data from the AMRF database, the WSC uses a Data

Server module which interacts with the Integrated Manufacturing

Data Administration System ( IMDAS ) [B.6]. The Data Server accepts

requests from the WSC, encodes them in the a form understood by

the IMDAS, monitors the status from the IMDAS, and then decodes

the responses back into a form understood by the WSC. Currently,

only the WSC makes use of the Data Server; however, this module

can be accessed by any of the Inspection Workstation Controllers.

1.1. Tray Definition

As specified by the Control-Database Interface document, the Tray

Definition report is used to create or obtain an attribute

description of a tray type. This report defines the tray sectors

and their position and size within the tray.

1.2. Tray Contents

The Tray Contents report is specifies the item serial number of

the part in each of the tray sectors defined in the Tray

Definition report and their position relative the sector origin.

1.3. Inspection Process Plan

The Inspection Process Plan report provides information about the

specific inspection steps with given precedence relations [B.7],

The inspection steps include instructions to the Coordinate

Measuring Machine to load data and to inspect a part, and to the

Inspection Robot to transfer parts, to load the Surface Roughness

Instrument data, and to inspect a part with the SRI.

2. INTERNAL DATA STRUCTURE

Using the three reports mentioned above, the WSC creates an

internal operation list data structure which maintains a view of

the Inspection Workstation processes. This data structure is

updated as the operation proceeds in order to preserve the IWS

world model.

7
IWS WSC IMPLEMENTATION

t

.

.

;•

'

'

8
IWS WSC IMPLEMENTATION

V. TASK DECOMPOSITION

1. WORKSTATION MANAGER (WSM)

The Workstation Manager module is the topmost layer of the WSC

hierarchy and serves as the communications administrator between

the Cell and the rest of the Inspection Workstation Controllers

(See Figure 2) . Its functions include receiving and managing cell

commands, reporting the IWS status back to the cell controller,

and monitoring the operation of the Production Manager Module.

The Inspection Workstation Controller utilizes the standard AMRF

command data communication protocol to interface with the Cell

Controller.

Upon receiving a cell command, the WSM first decodes it into the

local data structure. The WSM then looks at the input command and

depending on the current state, takes appropriate action if

possible. As specified in the AMRF architecture document, there

are two types of commands sent by the cell controller: transition

commands and work orders. Only one or the other is permitted per

cell command. Since the Workstation Manager filters the cell

commands, commands are strictly regulated between the lower levels

which greatly reduces the complexity of the control strategy.

A transition command causes the WSM to change to a non-quiescent

state pending a response frpm the lower level. However, if the

current state is READY and a WARM SHUTDOWN command is received,

then the WSM will transit to BUSY WARM SHUTDOWN state but will

continue to process all of the work orders in the queue before

issuing the WARM SHUTDOWN command to the lower level. The WSM

does not accept commands while in a non-quiescent state.

As specified in the UVA system model, the WSM only processes work

orders if it is in the READY state. Also, in the current

implementation only one work order is allowed per cell command.

The Inspection Workstation accepts three work orders: RECEIVE

TRAY, INSPECT LOT, and SHIP TRAY. In the current configuration of

only one tray table, both the RECEIVE TRAY and SHIP TRAY orders

are redundant since the information contained in them is

duplicated in the INSPECT LOT order.

The INSPECT LOT work order is a high level command directing the

WSC to inspect a tray of parts. The order includes data about the

tray type, the tray identification number, and the inspection

process plan name for the given tray of parts. Consequently, the

WSM issues an EXECUTE command to the Production Manager module

along with the above data as arguments. The WSM then changes

state from READY/IDLE to READY/BUSY PROCESS and stays in this

state until the Production Manager responds with a DONE status.

9
IWS WSC IMPLEMENTATION

From Cell Controller

Figure 2: Task Decomposition for the

Inspection Workstation Controller

10
IWS WSC IMPLEMENTATION

2. PRODUCTION MANAGER (PMGR)

The Production Manager’s primary responsibility is to coordinate

the inspection process. The PMGR receives from the Workstation

Manager module a command to EXECUTE along with the necessary tray

and part identification information. With this information, the

PMGR retrieves the tray definition, tray contents, and process

plan reports from the IMDAS and generates the overall equipment

task queue [B.8].

The task list is constructed by parsing the process plan report

which is developed offline using the interactive Computer Aided , Process Planning System of the AMRF . For the present workstation

organization of a Coordinate Measuring Machine ( CMM) and a Surface

Roughness Instrument (SRI) under the control of the Inspection

Workstation Robot, the task list contains commands to the CMM to

inspect a part, to the robot to transfer parts, and to the robot,

to inspect a part with the SRI. After the task list is made, the

PMGR issues an EXECUTE command to the next module and a pointer to

the overall workstation task list.

3. QUEUE MANAGER (QMGR)

The function of the Queue Manager is to set up and supervise the

operation of each of the equipment dispatcher modules. Upon

receiving the command to EXECUTE from the Production Manager, the

QMGR goes through the overall task list and generates the

individual equipment task lists while preserving the task order

and the starting precedence of the process plan. The QMGR then

sends an EXECUTE command and a pointer to the appropriate task

list to each of the dispatcher modules and awaits a response of

DONE which indicates the completion of all of the tasks in the

equipment task list.

An important job carried out by the QMGR is to detect equipment

deadlock. Deadlock is the condition where the start of a

machine's pending assignments are predicated on the completion of

another machine's task whose start is also blocked. The QMGR

receives three statuses from each of the equipment dispatchers:

DONE, WORKING, and BLOCKED. DONE indicates an idle state with no

pending tasks, WORKING signifies busy processing the task list,

and BLOCKED marks an idle state with an impeded pending task.

Deadlock occurs when all equipment dispatchers are reporting

BLOCKED. In the current implementation, this condition is

considered an error and deadlock resolution is not attempted.

11
IWS WSC IMPLEMENTATION

4. EQUIPMENT DISPATCHERS

There is one Dispatcher module for each equipment controller.

Each Dispatcher is responsible for deciding the next equipment

task in the list to be performed, sending back operation status to

the Queue Manager module, issuing commands to the equipment

controllers, and monitoring the status of the equipment

controllers

.

In a Dispatcher module, there are three sub-states of the READY

state: IDLE, BUSY PROCESS, and BLOCKED. The READY/IDLE state

indicates that the Dispatcher is ready to receive inspection

commands but has not yet received the EXECUTE order to begin

processing its specific equipment task list. After receiving the

EXECUTE command, the Dispatcher module reports back WORKING to the

Queue Manager module and then goes into the BUSY PROCESS substate.

In the BUSY PROCESS state, the Equipment Dispatcher module

attempts to complete its assigned tasks by going through its task

list trying to find an available task. A task is available if it

has not yet been processed and all of its preceding tasks have

been completed. If a task is free the Dispatcher issues the

command to the equipment controller and waits for it to respond

with a DONE status. After the Dispatcher receives a DONE status

from the equipment controller it again tries to find a new task to

work on.

On the other hand, if a task is not available, the Dispatcher

reports back to the Queue Manager a status of BLOCKED and enters a

BLOCKED state. In the BLOCKED state, the Dispatcher continually

checks its task list to see if a task has opened up. When that

task becomes available, the Dispatcher reports back WORKING to the

Queue Manager and returns to a BUSY PROCESS state.-

After the Dispatcher has completed all of the tasks in its

equipment task list, it reports back a DONE status to the Queue

Manager and enters the READY/IDLE state. In the IDLE state, the

Dispatcher waits for either another EXECUTE command or a WARM

SHUTDOWN command directing it to begin shut down procedures.

12
XWS WSC IMPLEMENTATION

VI. PROCEDURE MODULES

The modules in the task decomposition (state machine modules plus

the module machine) use procedures that are packaged into separate

modules. These modules are described in this section.

1. wsc_lib

This library module contains procedures from the Hewlett Packard

library that are not used by the other controllers.

2 . wsc_glob

This module includes data structures and procedures that are

specific to the Workstation Controller, and are referenced by

state machine modules as well as by procedure modules throughout

the Workstation Controller program.

3. cell_glob

This module contains data structures and procedures that are

specific to the Workstation Manager and the User Interface

modules

.

4 . disp_glob

This module contains data structures and procedures that are

specific to the Equipment Dispatcher modules.

5 . net_trans

In the Inspection Workstation, all inter-workstation controller

communication passes through the Workstation Controller. This

module is used to define and manage the pass through communication

mailboxes used by the workstation controllers.

13
IWS WSC IMPLEMENTATION
IWS WSC IMPLEMENTATION

VII. INTERFACE TO SUBORDINATE CONTROLLERS

1. MODULES THAT INTERFACE TO CONTROLLERS

With the current configuration there are two equipment dispatcher

modules: the Inspection Robot Controller Dispatcher (irc_disp)

and the Coordinate Measuring Machine Dispatcher (cmm_disp)

modules

.

2. DETAILS OF THE CURRENT IMPLEMENTATION

The details of the Dispatchers’ implementation was previously

discussed in the task decomposition section.

3. CHANGES REQUIRED FOR CONTROLLER SUBSTITUTION

The architecture of each of the equipment controllers is

essentially the same. Therefore, when a new piece of equipment,

along with its respective controller, is added to the workstation,

there are no modifications required in the Workstation controller

as long as the new equipment adopts the standard AMRF controller

architecture and communication protocol.

15
*

IWS WSC IMPLEMENTATION

.

.

.

’
IWS WSC IMPLEMENTATION

VIII. INITIALIZATION AND SHUT DOWN

According to the UVA system model, there are two start up states

and two shut down states. Refer to the IWS operation manual for

the exact start up and shut down procedures.

1. START UP

The two start up states are SYNCHRONIZE WAIT and WARM SHUTDOWN.

The start up transition goes from SYNCHRONIZE WAIT to WARM

SHUTDOWN after receiving a SYNCHRONIZE command, and from WARM

SHUTDOWN to READY state after receiving a WARM STARTUP command.

2 . SHUT DOWN

The two shut down states are WARM SHUTDOWN and COLD SHUTDOWN. The

shut down transition goes from a READY state to WARM SHUTDOWN

after receiving a WARM SHUTDOWN command, and from WARM SHUTDOWN to

COLD SHUTDOWN state after receiving a COLD SHUTDOWN command.

17
IWS WSC IMPLEMENTATION

.
IWS WSC IMPLEMENTATION

. IX. ERROR HANDLING

All error handling consists of error detection and then transition

to a COLD SHUTDOWN state. There is no way to recover from the

COLD SHUTDOWN state; therefore, all errors cause the system to

come to a halt.

1. PROCESS PLAN PARSER ERROR

The Production Manager module is in charge of retrieving the

Process Plan and assembling the operation task list. Process Plan

Parser error occurs when the Production Manager is reading the

report and the format of the Process Plan is incorrect. The

Process Plan is either retrieved from the IMDAS in remote data

mode or from a data file if in local data mode. This error will

not appear when working in local data mode.

2. DATA SERVER ERROR

The Data Server only detects errors and does not attempt to handle

the error. The error status is returned to the calling module for

error handling.

2.1. File Not Found

This error occurs if you are operating in local data mode and are

trying to access a data file and it does not exist. The Data

Server will signal an error.

2.2. IMDAS Error

This error occurs if you are operating in remote data mode and the

IMDAS responds with an error status.

3. EQUIPMENT CONTROLLER ERROR

This error occurs when one of the equipment controllers respond

with an error status.

19
IWS WSC IMPLEMENTATION

.

’

‘

.

' ‘

’
IWS WSC IMPLEMENTATION

X. USER INTERFACE

1. EXTRA MODULES REQUIRED FOR TESTING

1.1. user_wsc

This module is necessary when the Inspection Workstation is

operated in stand-alone mode. Using this module, the user can

issue commands to the Workstation Controller.

1.2. wsc_irc

This module is used to test the Workstation Controller without

requiring the Inspection Robot Controller to be connected.

1.3. wsc_cmm

This module is used to test the Workstation Controller without

requiring the Coordinate Measuring Machine Controller to be

connected.

2. USER COMMANDS

There are two types of commands that can be issued to the WSC:

transition commands and work order commands. The transition

commands used to start up the WSC are SYNCHRONIZE and WARM

STARTUP. The commands to' shut down the WSC are WARM SHUTDOWN and

COLD SHUTDOWN. There are three work orders that can be sent to

the WSC: RECEIVE TRAY, INSPECT LOT, and SHIP TRAY.

3. OPERATING OPTIONS

The user can set the WSC operating options as well as send

commands. There are various operating options that can be chosen

when running the WSC. These options are detailed in the

Operations Manual for the Inspection Workstation . The most

important options are indefinite operation of a work order and

enabling the Workstation Status display to monitor the Workstation

operation.

21
IWS WSC IMPLEMENTATION

*

.

.

.

'

22
IWS WSC IMPLEMENTATION

XI. FUTURE PLANS

1 . SOFTWARE DEVELOPMENT

1.1. Automatic Task Scheduling

An important requisite of the Hierarchical Control Strategy is

that each module must be able to make planning decisions

concerning the order in which to perform its tasks. At the

Inspection Workstation, scheduling is necessary at the Workstation

Controller level to organize the sequence of equipment inspection

work orders. As mentioned above, in the present implementation . the equipment level work orders are issued according to the preset

order defined when the process plan was developed offline.

One possible solution to the planning requirement is to imbed -an

Expert System within the control structure so that decisions can

be made dynamically and can be modified when more knowledge is

gained about the operation. With an Expert System to supervise

the task management, the operation task list, which is currently

assembled in the Production Manager, would contain only high level

directives such as INSPECT PART with arguments indicating the

location of inspection, the duration of the inspection, and the

name of the inspection plan to be used. The- logic of this is to

relieve the Cell Controller from having the need for knowledge of

how a Workstation performs its tasks which is sub-optimal for a

variety of reasons.

Therefore, in the new system, the scheduling would be a two step

process. The first step would be to break down each of the high

level directives into their logically connected components. For

example, the INSPECT PART (at CMM) order first requires a TRANSFER

command to the robot to get the part in question to the CMM, a

LOAD DATA command to the CMM to load the mandatory data, an

INSPECT PART command to perform the inspection on the part, and

finally, a TRANSFER command to return the part to wherever it

needs to go next.

To create this basic task list, the Expert System would make use

of knowledge about the current state of the Workstation

configuration, which would be represented as facts in its global

database, and decomposition rules, represented as production

rules, which would dictate how the process plan is to be

decomposed. Subsequently, the second step would fill in the

TRANSFER information, which is only known at run time, and would

make the decisions about which task is to be performed next.

23
IWS WSC IMPLEMENTATION

The Workstation Controller hierarchy will be modified to implement

the new scheduling system. It would still be necessary to have a

Cell interface module such as the Workstation Manager module of

the current implementation. The first task breakdown step would

be performed by the Task Manager module. This module would

retrieve the necessary data from the AMRF database, create the

logical operation task list, issue the command to EXECUTE to the

Dispatcher modules, and monitor the Dispatchers' operation.

The second step would be performed by the individual equipment

Dispatcher modules.

1.2. Error Recovery

Another critical use for an Expert System is error recovery.

Currently, the Inspection Workstation does not perform error

recovery when a fault is detected. An Expert System could be used

to diagnose the error and provide the means to recover from it. • Again, the Expert System would make use of the Workstation

configuration and the current state of the Workstation, and error

recovery rules which can be updated when more knowledge is gained.

1.3. Multiple Work Orders Per Cell Command

In the current implementation, only one work order is accepted per

cell command. In the future, the necessary cell command

processing will be managed by using. a data-driven rule-based

approach.

1.4. Inspection Results Reported To AMRF Database ( IMDAS

)

Currently, the only inspection decision is whether or not the part

met the specified tolerances. In the future it is intended that

the inspection data will be fed back into the AMRF database so

that it can be used by other workstations to increase

manufacturing efficiency and possibly for statistical control.

2. NEW HARDWARE

No new hardware is expected to be purchased in the near future for

the Workstation Controller.

24
IWS WSC IMPLEMENTATION

3. PROBLEM AREAS

Problems exist in the development of a Process Plan. Care must be

taken to prevent starting a task before a logical or physical

precedence is met. A logical precedence, for example, is that a

TRANSFER must be completed before an INSPECT PART can start. A

physical precedence for example is issuing a TRANSFER (from tray)

before that part is there to be transferred. If and when a new

Process Plan is created, it must be tested carefully before

automated operation is allowed.

25
IWS WSC IMPLEMENTATION

'

.

'

"
IWS WSC IMPLEMENTATION

APPENDICES

A. IWS DOCUMENTATION LIST

1. H. T. Moncarz, Architecture and Principles of the

Inspection Workstation . NBSIR 88-3802, June 8, 1988.

2. H. T. Moncarz, Implementation of the Execution Control

System of the Inspection Workstation . NBSIR 88-3787,

May 19, 1988.

3. H. T. Moncarz and T. H. Hopp, Implementation of the . CMM Controller , to be published as an NBSIR.

4. H. T. Moncarz and T. V. Vorburger, Implementation of

the SRI Controller . NBSIR 88-3794, March 21, 1988.

5. H. T. Moncarz and B. Borchardt, Implementation of the

Inspection Robot Controller , NBSIR 88-3772, April 21,

1988.

6. S. A. Osella, Implementation of the Inspection

Workstation Controller , NBSIR 88-3819, August, 1988.

7. J. Zimmerman, Inventory of Equipment in the Inspection

Workstation , NBSIR 88-3775, May 5, 1988.

8. H. T. Moncarz, S..A. Osella, B. Borchardt, and R.

Veale, Operations Manual for the Inspection

Workstation , NBSIR 88-3766, April 21, 1988.

9. J. Zimmerman, Recommended Technical Specifications for

Procurement of Commercially Available Systems for the

Inspection Workstation . NBSIR 88-3779, 1988.

27
IWS WSC IMPLEMENTATION

'

'

28
IWS WSC IMPLEMENTATION

B. REFERENCES

1. D. R. O'Halloran and P. F. Reynolds, Jr., "A Model for

AMRF Initialization, Restart, Reconfiguration, and

Shutdown", NBS/GCR 88/546, May 23, 1986.

2. C. R. McLean, Control Systems Command Feedback

Protocol Document , to be published as an NBSIR.

3. James S. Albus, Anthony J. Barbera, Roger N. Nagel,

"Theory and Practice of Hierarchical Control," 23rd

IEEE Computer Society International Conference,

September 1981.

4. T. H. Hopp and K. C. Lau, "A Hierarchical Model-Based

Control System for Inspection," Automated

Manufacturing , ASTM STP 862, L. B. Gardner, Ed.,

American Society for Testing and Materials,

Philadelphia, 1985, pp. 169-187.

5. Michelle Potts and Charles McLean, "Control-Database

Interface: Workstation Level Reports," AMRF Internal

Document, October 9, 1986.

6. C. Furlani, et al. Integrated Manufacturing Data

Administration System , to be published as an NBSIR.

7 . Peter F. Brown, and Charles McLean, "Interactive

Process Planning in the AMRF," Proceedings of Winter

1986 ASME Conference, Anaheim, California, 1986.

8. Don Libes and Edward Barkmeyer, "The integrated

manufacturing data administration system ( IMDAS ) — an

overview," International Journal of Computer

Integrated Manufacturing, Vol. 1, No. 1, pp. 44-49.

29
IWS WSC IMPLEMENTATION

'

'

• .

-

30
IWS WSC IMPLEMENTATION

C. GLOSSARY (and abbreviations)

ADI Abbreviation for the Automatic Dial Indicator,

automatic dial indicator

Instrument used to measure the distance that a spring

mounted stem is depressed.

CMM Abbreviation for the Coordinate Measuring Machine.

CMMC Abbreviation for the CMM Controller,

controller

Supervises the operation of a mechanism, another con--

troller, or both.

coordinate measuring machine

Machine used to measure the dimensions of a part.

ecs Abbreviation for the execution control system.

execution control system

Computer program that runs on each controller computer and

implements the AMRF design principles. This program loads

and executes those modules which determine which controller

is actually being run.

inspection workstation

AMRF workstation that inspects parts for dimensional

tolerance and surface finish.

IRC Abbreviation for the Inspection Robot Controller.

IWS Abbreviation for the Inspection Workstation.

logical architecture

Specifies the direction of commands and statuses between

controllers and between controllers and equipment.

physical architecture

Specifies the physical connections among the controllers

and equipment.

ready state

The state in which a controller is ready to accept work

order commands. This is the normal state of the controller

during its operation.

SRI Abbreviation for the Surface Roughness Instrument.

31
IWS WSC IMPLEMENTATION

state machine

Software control unit with outputs dependent on inputs to

it plus its internal state. This is the building block for

the IWS control software.

surface roughness instrument

Machine that measures the optical scattering off the

surface of a part that can be correlated with its surface

roughness

.

transition commands

Commands used to transfer the IWS to a new state (specified

by the UVA protocol)

.

UVA Protocol

Model, proposed by research group from the University of

Virginia and adopted by the AMRF, that specifies the start

up and shut down sequence for the AMRF as a whole as well

as every controller within the AMRF.

work element

The part of the work order command that specifies what main

controller function to perform.

work order commands

A command accepted by a controller when it is in ready

state, and used' to perform one of its main functions

(specified by the work element)

.

WSC Abbreviation for the Workstation Controller.

32
IWS WSC IMPLEMENTATION

D. LOCAL DATA FILES

The Workstation Controller adopts the same data report format used

by the AMRF Database reports. Therefore, refer to the ControlDatabase Interface document for the report format specification.

The following three sections describe the local report file name

convention used by the Workstation Controller.

4.1. Tray Definition

The Tray Contents reports are named by the number of sectors

contained in the tray type. For a four sector tray, which is what

the IWS receives, the Tray Definition report name is TRAY_DEF_4

.

4.2. Tray Contents

The Tray Contents reports are identified by the Tray Container

number given in the work order command issued by the Cell

Controller. For the three trays of parts, the Tray Contents

report file names are TRAY_510 for TRAY_510, TRAY_520 for

TRAY_52 0 , and TRAY_53 0 for TRAY_53 0.

4.3. Process Plan

The Inspection Process Plan reports are labelled by the Process

Plan name given in the work order command issued by the Cell • Controller. For the three trays of parts, the Process Plan report

file names are IWS_IWS_1 for TRAY_510, IWS_IWS_2 for TRAY_520, and

IWS IWS 3 for TRAY 530.

33
IWS WSC IMPLEMENTATION

II

34
READER COMMENT FORM

IMPLEMENTATION OF THE INSPECTION WORKSTATION CONTROLLER

This document is one in a series of publications which document

research done at the National Bureau of Standards' Automated

Manufacturing Research Facility from 1981 through March, 1987.

You may use this form to comment on the technical content or

organization of this document or to contribute suggested editorial

changes

.

Comments

If you wish a reply, give your name, company, and complete mailing

address:

What is your occupation?

NOTE: This form may not be used to order additional copies of

this document or other documents in the series. Copies of AMRF

documents are available from NTIS.

Please mail your comments to: AMRF Program Manager

National Bureau of Standards

Building 220, Room B-lll

Gaithersburg, MD 20899
'

.
NBS-H4A (REV. 2-8C) U.s. DEPT. OF COMM.

BIBLIOGRAPHIC DATA

1. PUBLICATION OR

REPORT NO.

2. Performing Organ. Report No. 3. Publication Date

SHEET (See instructions) NBSIR 88-3819 JULY 1988

4. TITLE AND SUBTITLE

"Implementation of the Inspection Workstation Controller"

5. AUTHOR(S)

Stephen A. Osella

6. PERFORMING ORGAN 1 ZATION (If joint or other than N BS, see in struct ion s) 7. Contract/Grant No.

NATIONAL BUREAU OF STANDARDS

U.S. DEPARTMENT OF COMMERCE 8. Type of Report & Period Covered

GAITHERSBURG, MD 20899

•

9. SPONSORING ORGANIZATION NAME AND COMPLETE ADDRESS (Street. City. State , ZIP

)

National Bureau of Standards

Gaithersburg, Maryland 20899

10.

SUPPLEMENTARY NOTES

Document describes a computer program; SF-185, FlPS Software Summary, is attached.

1

1.

A BST RAGT ! A 200 -word or less factual summary of most significant in formation . If document includes a significant

bibliography or literature survey, mention' if here)

This document describes the .implementation of the Inspection Workstation Controller

(WSC). The WSC is a program which is designed to supervise the equipment controllers

of the 'Inspection Workstation. The WSC uses 'a data driven, hierarchical task

decomposition control strategy and incorporates the University of Virginia model for

system initialization, restart, and shutdown. The WSC is comprised of a number of

Finite State Machine Modules each responsible for a particular aspect of the control

process

.

12.

KEY WORDS (Six to twelve entries; alphabet/ cal order; capitalize only proper names; and separate key words by semi colon s) AMRF ; IWS; Inspection Workstation; Hierarchical Control

13. AVAILABILITY 14. NO. OF

PRINTED PAGES

XXj Unl united

For Official Distribution. Do Not Release to NTIS 42

Order From Superintendent of Documents, U.S. Government Printing Office, Washington, D.C.

20402. 15. Price

XX Order From National Technical Information Service (NTIS), Springfield, VA. 22161 $11.95

LlSCOMM-DC 6043-P 80




.

..

.T

.

-

t.~ i

....