Browse Prior Art Database

Object-Oriented Design for Real-Time Manufacturing Control and Analysis

IP.com Disclosure Number: IPCOM000111583D
Original Publication Date: 1994-Mar-01
Included in the Prior Art Database: 2005-Mar-26
Document File: 2 page(s) / 112K

Publishing Venue

IBM

Related People

Mackie, DB: AUTHOR

Abstract

An object-oriented program design is disclosed that facilitates real-time manufacturing data collection and analysis, particularly process control and interlock. A repository exists of individual unit objects, each of which has a link to generic product design objects within a second repository; each of the latter has a set of customizable material and process objects. In this way data collected at the individual unit level can be immediately analysed against generic product design specifications.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 50% of the total text.

Object-Oriented Design for Real-Time Manufacturing Control and Analysis

      An object-oriented program design is disclosed that facilitates
real-time manufacturing data collection and analysis, particularly
process control and interlock.  A repository exists of individual
unit objects, each of which has a link to generic product design
objects within a second repository; each of the latter has a set of
customizable material and process objects.  In this way data
collected at the individual unit level can be immediately analysed
against generic product design specifications.

      An object is an encapsulation of a data structure with
functions that act upon the structure.  The program design uses two
main repositories of objects.  The first repository contains objects
that each model a single uniquely identifiable manufactured unit; for
example if a plant manufactures widgets, each of these represents a
single widget.  The second repository contains objects that model a
single uniquely-identifiable manufactured product design; for example
each of these represents a single brand or style of widget, such as
one object for vanilla widgets, one for micro widgets, or one for the
widget Mark II  model.  Each unit object (in the first repository)
has a pointer to a product object (in the second repository).

      Each unit on the manufacturing line will proceed through a
series of steps contributing to its manufacture; at each step data is
produced (such as the number of components placed in which location,
or the performance of a given component in a  test).  The program
defines event objects to model collectable data, and step objects for
each of the steps producing data.

      There are different kinds of events; namely, the program has a
hierarchy of subclasses defined to model collectable data.  That is
to say, all events are defined to have an occurrence date and time,
and a responsible employee.  At the next level of the hierarchy,
subclasses add features and function to the model, so that, for
example, unit events have a unique unit identifier as well as a
unique identifier for the step being performed for the event.  In
this way, the program can collect any kind of data by using existing
subclass definitions or by adding new definitions within the event
hierarchy.  Each unit object maintains a list of the event objects
that have happened to the unit.  Events contain the functions for
placing them selves appropriately in the database, so the data
collection system  has  the simple paradigm of data collection
stations creating event objects and telling the objects to send
themselves to the database.

      Steps are defined to contain the data and function required to
control process interlock.  They model all the steps that may occur
in the lifetime of a unit, and allow design constraints to be placed
on the occurrence of steps to units.  For example, a unit may proceed
to one step only if it has p...