System, method and article of manufacture for building an enterprise-wide data model

Abstract

A system software solution for controlling an enterprise having one or more components for controlling one or more aspects of an industrial environment. The software includes one or more components for controlling one or more aspects of an industrial environment with code that creates a database of components from existing schematics and timing diagrams. Each of the components have control, diagnostic and resource information pertaining to enterprise resources utilized in the industrial environment. The system also generates code that controls resources comprising cognitive and timing information that synchronizes events throughout the enterprise. The database of components including code that updates the database to reflect changes in the enterprise that manages the design, simulation, implementation and maintenance of a manufacturing enterprise utilizing the database of components. The enterprise control system integrates existing data models into control resources and stores the updated control resources in the database and creates visualizations including schematics, timing diagrams and sequencing charts.

Claims

What is claimed is:

1. A method for controlling an enterprise with one or more components, including a computer for controlling one or more aspects of an enterprise, comprising the steps of:

(a) creating a database of components, each of the components containing control, diagnostic and resource information pertaining to enterprise resources in the enterprise utilizing existing product, process and machine models of the enterprise to populate the database;

(b) generating code for control resources from causal, sequence and timing information to synchronize events throughout the enterprise;

(c) updating the database of components to reflect changes in the enterprise;

(d) generating visualizations of the enterprise utilizing the control resources and a display to reflect changes in the enterprise; and

(e) controlling the enterprise utilizing the database of components and the visualizations.

2. A method as recited in claim 1, including a database component that defines hydraulic information for the enterprise.

3. A method as recited in claim 1, including a database component that integrates existing data models into the control resources.

4. A method as recited in claim 1, including a database component that defines diagnostic information for the enterprise.

5. A method as recited in claim 1, including a database component that defines user interface information for the enterprise.

6. A method as recited in claim 1, including a database component that defines safety information for the enterprise.

7. A method as recited in claim 1, including a database component that defines control information for the enterprise.

8. A system for controlling an enterprise, including a computer with one or more components for controlling one or more aspects of an industrial environment, comprising:

(a) a database of components, each of the components containing control, diagnostic and resource information pertaining to enterprise resources in the enterprise utilizing existing product, process and machine models of the enterprise to populate the database;

(b) a code generator that generates control resources from causal, sequence and timing information to synchronize events throughout the enterprise;

(c) the database comprising update code that updates the database of components to reflect changes in the enterprise;

(d) first enterprise system control code that generates visualizations of the enterprise utilizing the control resources and a display to reflect changes in the enterprise; and

(e) second enterprise system control code that controls the enterprise utilizing the database of components and the visualizations.

9. A system as recited in claim 8, including a database component that defines hydraulic information for the enterprise.

10. A system as recited in claim 8, including a database component that integrates existing data models into the control resources.

11. A system as recited in claim 8, including a database component that defines diagnostic information for the enterprise.

12. A system as recited in claim 8, including a database component that defines user interface information for the enterprise.

13. A system as recited in claim 8, including a database component that defines safety information for the enterprise.

14. A system as recited in claim 8, including a database component that defines control information for the enterprise.

15. A computer program embodied on a computer-readable medium for controlling an enterprise, comprising:

(a) a database code segment containing control, diagnostic and resource information pertaining to enterprise resources in the enterprise utilizing existing product, process and machine models of the enterprise to populate the database;

(b) a code generator code segment that generates control resources from causal, sequence and timing information to synchronize events throughout the enterprise;

(c) the database code segment including update code that updates the database of components to reflect changes in the enterprise;

(d) a first enterprise control code segment that generates visualizations of the enterprise utilizing the control resources and a display to reflect changes in the enterprise; and

(e) a second enterprise control code segment that controls the enterprise utilizing the database of components and the visualizations.

16. The computer program embodied on a computer-readable medium as recited in claim 15, including a database component that defines hydraulic information for the enterprise.

17. A computer program as recited in claim 15, including a database component that integrates existing data models into the control resources.

18. A computer program as recited in claim 15, including a database component that defines diagnostic information for the enterprise.

19. A computer program as recited in claim 15, including a database component that defines user interface information for the enterprise.

20. A computer program as recited in claim 15, including a database component that defines safety information for the enterprise.

Description

COPYRIGHT NOTIFICATION

Portions of this patent application contain materials that are subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document, or the patent disclosure, as it appears in the Patent and Trademark Office.

FIELD OF THE INVENTION

This invention generally relates to improvements in computer systems, and more particularly, to system software for managing the design, simulation, implementation and maintenance of a manufacturing enterprise.

BACKGROUND OF THE INVENTION

This invention relates to electronic programmable controllers for operating industrial equipment and visualizing the industrial environment being controlled. Electronic programmable controllers utilize a programming language to develop control programs to control industrial equipment.

Programmable controllers are well-known systems for operating industrial equipment, such as assembly lines and machine tools, in accordance with a stored program. In these controllers, a stored program is executed to examine the condition of specific sensing devices on the controlled equipment, and to energize or de-energize selected operating devices on that equipment contingent upon the status of one or more of the examined sensing devices. The program not only manipulates single-bit input and output data representing the state of the sensing and operating devices, but also performs arithmetic operations, timing and counting functions, and more complex processing operations.

One industry that extensively uses programmable controllers is the automotive industry. In the automotive industry, various automotive parts are conveyed along machine lines consisting of many consecutive workstations. Most workstations include at least one tool that performs some function to alter the characteristics of workpieces as they are delivered to the station. For example, an unfinished cast engine block that requires a plurality of holes, bores, and threads, as well as other metal-removing procedures, may be provided at the beginning of a machine line that produces finished engine blocks. The machine line may consist of any number of different stations, each station performing a different procedure on the unfinished block. An indexer in the form of a transfer bar can be arranged to move each block from one station to the next following a completed process. Typically, at each station the block would be clamped prior to any metal-removing operation.

In this type of system, a programmable controller would receive inputs from all of the various tools at all of the workstations and would provide activating output signals to synchronize machine operation. During metal-removing periods with the transfer bar out of the way, all of the tools would perform their functions. In between metal-removing periods during transfer periods, the tools would be parked, the clamps unclamped, and the transfer bar would advance workpieces from one station to the next.

Industrial controllers are frequently programmed in Ladder Logic (LL) where instructions are represented graphically by "contacts" and "coils" of virtual relays connected and arranged in ladder-like rungs across power rails. LL, with its input contacts and output coils, reflects the emphasis in industrial control on the processing of large amounts of input and output data.

LL also reflects the fact that most industrial control is "real time"; that is, an ideal industrial controller behaves as if it were actually composed of multiple relays connected in parallel rungs to provide outputs in essentially instantaneous response to changing inputs. Present industrial controllers do not, in fact, employ separate parallel relay-like structures, but instead simulate the parallel operation of the relays by means of a conventional Harvard or Von Neumann-type computer processor which executes instructions one at a time, sequentially. The practical appearance of parallel operation is obtained by employing extremely fast processors in the execution of the sequential control program.

As each rung is executed, inputs represented by the contacts are read from memory (as obtained from inputs from the controlled process or the previous evaluation of coils of other rungs). These inputs are evaluated according to the logic reflected in the connection of the contacts into one or more branches within the rungs. Contacts in series across a rung represent boolean AND logic whereas contacts in different branches and thus in parallel across the rung represent boolean OR logic.

Typically a single output coil at the end of each rung is set or reset. Based on the evaluation of that rung, this setting or resetting is reflected in the writing to memory of a bit (which ultimately becomes an output to the industrial process or to another LL rung).

Once a given rung is evaluated the next rung is evaluated and so forth. In the simplest form of LL programming there are no jumps, i.e. all rungs are evaluated in a cycle or "scan" through the rungs. This is in contrast to conventional computer programming where branch and jump instructions cause later instructions or groups of instructions to be skipped, depending on the outcome of a test associated with those branch or jump instructions.

While LL is well suited for controlling industrial processes like those in the automotive industry, LL programming is not an intuitive process and, therefore, requires highly skilled programmers. Where hundreds of machine tool movements must be precisely synchronized to provide a machining process, programming in LL is extremely time-consuming. The time and relative skill associated with LL programming together account for an appreciable percentage of overall costs associated with a control system. In addition, the final step in LL programming is typically a lengthy debugging and reworking step that further adds to overall system costs.

One way to streamline any type of programming is to provide predefined language modules, expressed in a language such as LL, which can be used repetitively each time a specific function is required. Because of the similar types of tools and movements associated with different machine-line stations, industrial control would appear to be an ideal industry for such language modules.

The predefined logic module approach works quite well for certain applications, like small parts-material handling or simple machining. The reason for this is that the LL required for these applications tends to be very simple. In small parts material handling applications the I/O count is low and the interfaces between modules are minimal. In fact, the mechanisms are often independent units, decoupled from neighboring mechanisms by part buffers such that no signals are required to be exchanged between modules. These "loosely coupled" systems lend themselves to "cut and paste" programming solutions.

But the predefined, fixed logic module approach does not work well for other applications, for example metal-removing applications. There are two main reasons for this. First, there can be considerable variation in how components, such as sensors and actuators, combine to produce even simple mechanisms. Second, processes like metal removing normally requires tightly controlled interaction between many individual mechanisms. Exchanging signals called interlocks, between the control logic modules of the individual mechanism controls the interaction. The application of specific interlocks depends on knowledge of the process and the overall control strategy, information not generally needed, or knowable, when the control logic for each mechanism is defined.

For example, a drill is a typical metal-removing tool used in the automotive industry. In this example an ideal drill is mounted on a carriage that rides along a rail between two separate limiting positions on a linear axis, an advanced position and a returned position. Two limit switches, referred to herein as returned and advanced LSs, are positioned below the carriage and, when tripped, signal that the drill is in the returned and advanced positions, respectively. Two separate dogs (i.e. trigger extensions), an advanced dog and a returned dog, extend downwardly from the bottom of the carriage to trip the LSs when the advanced and returned positions are reached, respectively. In the ideal case, both LSs may be assumed to be wired in the same "normally opened" manner, so that electrically speaking they are open when released and closed when triggered. In this ideal case, where the physical characteristics of the switches are limited, a single LL logic rung can determine when the drill is in the returned position and another rung can determine when the drill is in the advanced position.

Unfortunately, in reality, there are electrically two types of LSs, one LS type being wired normally opened and the other type wired normally closed. Furthermore, any LS can be mechanically installed in a tripped-when-activated configuration, or a released-when-activated configuration. All combinations of these types are used for various types of applications. Thus, application requirements may demand control logic capable of handling any configuration of LS types.

Simple mathematics demonstrates that with two different electrical types of LSs and two mechanical configurations, there are sixteen possible configurations of a two-position linear slide. Consider the language modules required to implement position logic for all these configurations. To accommodate all sixteen-switch configurations, there could be sixteen different language modules, each containing fixed LL logic, and each named for the case it could handle. In this case, there would be duplicate logic under different names. Alternatively, four unique language modules could be provided, but then the user would have difficulty identifying which of the sixteen physical configurations that the four modules could handle.

Clearly, even for a simple drill mounted on a two position linear slide, application variables make it difficult to provide a workable library of fixed language modules. Adding more switches to the linear slide only increases, to an unmanageable level, the number of language modules required in the library.

Moreover, the contents of a complete language module for a drill must also consider other variables. These variables include, for example, the number and type of actuators required; the type of spindle, if any; whether or not a bushing plate is required; what type of conveyor is used; whether or not the drill will include an operator panel to enable local control. If an operator panel is included, what type of controls (i.e. buttons, switches and indicator lights) are required, just to name a few. Each tool variable increases the required number of unique LL modules by more than a factor of two, which makes it difficult at best to provide an LL library module for each possible drill configuration.

Taking into account the large number of different yet possible machine-line tools, each tool having its own set of variables, the task of providing an all-encompassing library of fixed language modules becomes impractical. Even if such a library could be fashioned, the task of choosing the correct module to control a given tool would probably be more difficult than programming the required LL logic from scratch.

For these reasons, although attempts have been made at providing comprehensive libraries of fixed language modules, none has proven particularly successful and much LL programming is done from scratch.

Manufacturing customers have long desired an integrated environment for generating an initial design schematic specifying a functional description of a manufacturing environment without the need for specifying product and manufacturing details. The system is provided with a designer studio that utilizes a common database of pre-architected modules to integrate a total system solution for the enterprise. The pieces of this system include design, simulation, implementation and maintenance information for both product and manufacturing.

SUMMARY OF THE INVENTION

The foregoing problems are overcome in an illustrative embodiment of the invention in which a system for designing, simulating, implementing and maintaining an enterprise solution for an enterprise is disclosed. The system includes software that controls an enterprise. The software includes one or more components for controlling one or more aspects of an industrial environment with code that creates a database of components, each of the components containing control, diagnostic and resource information pertaining to enterprise resources utilized in the industrial environment. The software system also generates code that controls resources comprising cognitive and timing information that synchronizes events throughout the enterprise. The database of components includes code that updates the database to reflect changes in the enterprise that manage the design, simulation, implementation and maintenance of a manufacturing enterprise utilizing the database of components.

The system software defines and illustrates the electrical, pneumatic, hydraulic, logic, diagnostics, external behavior, controlled resources and safety elements of an enterprise control system. The elements of the control system are encapsulated in objects of an object-oriented framework within a control assembly. The control assembly is the fundamental building block for providing object-oriented control of the enterprise. A control assembly component is a deployable control subsystem that provides an interface using a common object model that is configurable. The enterprise control system also sequences the behavior of the enterprise utilizing information from a control sequence chart, the control assembly information and a timing diagram to effectuate control of the enterprise.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and further advantages of the invention may be better understood by referring to the following description in conjunction with the accompanying drawings, in which:

FIG. 1A is a block schematic diagram of a computer system for example, a personal computer system in accordance with a preferred embodiment;

FIG. 1B provides a display of ladder logic in accordance with a preferred embodiment;

FIG. 2 illustrates an enterprise control system in accordance with a preferred embodiment;

FIG. 3 illustrates a control assembly display from an enterprise control database in accordance with a preferred embodiment;

FIG. 4 is a block diagram depicting the logical flow of the enterprise control system in accordance with a preferred embodiment;

FIG. 5a is a block diagram schematic representing a system including a diagnostic engine for diagnosing the behavior of a machine controlled by a discrete event control system in accordance with a preferred embodiment of the present invention;

FIG. 5b is a flow chart representing exemplary steps for defining, updating and selecting the optimum diagnostic rules for the system of FIG. 5a while the diagnostic engine is in the learning mode;

FIG. 5c is a flow chart representing exemplary steps for identifying a malfunction in the behavior of the machine and updating the timing statistics associated with the diagnostic rules while the diagnostic engine of FIG. 5a is in the diagnostic mode;

FIG. 6 illustrates the user display for opening a project in accordance with a preferred embodiment;

FIG. 7 is a Designer Studio window in accordance with a preferred embodiment;

FIG. 8 is a Designer Studio display with control assemblies completed in accordance with a preferred embodiment;

FIG. 9 is a control assembly wizard in accordance with a preferred embodiment;

FIG. 10 is a control assembly wizard name operation in accordance with a preferred embodiment;

FIG. 11 is a control assembly wizard to select control resources in accordance with a preferred embodiment;

FIG. 12 is a control assembly wizard to label components associated with the control assembly in accordance with a preferred embodiment;

FIG. 13 is a control assembly wizard summary in accordance with a preferred embodiment;

FIG. 14 is a Designer Studio display of a new control assembly integration in accordance with a preferred embodiment; and

FIG. 15 is a schematic of a pneumatic system of a control environment in accordance with a preferred embodiment;

FIG. 16 illustrates the hierarchical relationship between a machine and an indexer in accordance with a preferred embodiment;

FIG. 17 illustrates a template in accordance with a preferred embodiment;

FIG. 18 illustrates a machine tree in accordance with a preferred embodiment;

FIG. 19 illustrates a master control panel in accordance with a preferred embodiment;

FIG. 20 illustrates the symbolic expression language in accordance with a preferred embodiment;

FIG. 21 illustrates an exemplary rung in accordance with a preferred embodiment;

FIG. 22 illustrates a required full set of conditions in accordance with a preferred embodiment;

FIGS. 23-35 illustrate an exemplary set of templates in accordance with a preferred embodiment;

FIG. 36 is a flow chart of the process by which the user creates the control diagram in accordance with a preferred embodiment;

FIGS. 37-43, represent all of the templates required to completely specify an axis in accordance with a preferred embodiment;

FIG. 44 illustrates a control panel editor in accordance with a preferred embodiment;

FIGS. 45 & 46 illustrate bar chart images in accordance with a preferred embodiment;

FIG. 47 is a contingency screen in accordance with a preferred embodiment;

FIG. 48 is a flowchart detailing the logic associated with compilation in accordance with a preferred embodiment;

FIGS. 49A and 49B are ladder logic displays in accordance with a preferred embodiment;

FIG. 50 illustrates an attributes table in accordance with a preferred embodiment;

FIG. 51 is a ladder logic display in accordance with a preferred embodiment;

FIG. 52 is a flowchart of observed functional processing in accordance with a preferred embodiment;

FIG. 53 is a flowchart of bucket processing in accordance with a preferred embodiment;

FIG. 54 is a splash screen in accordance with a preferred embodiment;

FIG. 55 is the initial display for the Designer Studio in accordance with a preferred embodiment;

FIG. 56 illustrates a menu that is utilized to open a project in accordance with a preferred embodiment;

FIG. 57 illustrates a display menu that is utilized to select an existing project to load in accordance with a preferred embodiment;

FIG. 58 illustrates an Open Project dialog in accordance with a preferred embodiment;

FIG. 59 ilustrates a menu display for facilitating an "Add Control Assembly" dialog 5900 in accordance with a preferred embodiment;

FIG. 60 illustrates the first menu in an "Add Control Assembly" dialog in accordance with a preferred embodiment;

FIGS. 61 to 67 illustrate a user experience with a wizard in accordance with a preferred embodiment; and

FIG. 68 illustrates the processing that occurs when a user presses the finish button in accordance with a preferred embodiment;

FIG. 69 illustrates the selection processing associated with a particular control assembly in accordance with a preferred embodiment;

FIG. 70 illustrates the processing of a control assembly in accordance with a preferred embodiment;

FIGS. 71 to 79 provide additional displays in accordance with a preferred embodiment; and

FIG. 80 is a block diagram of a control assembly in accordance with a preferred embodiment.

DETAILED DESCRIPTION

A preferred embodiment of a system in accordance with the present invention is preferably practiced in the context of a personal computer such as an IBM, Apple Macintosh or UNIX based computer. A representative hardware environment is depicted in FIG. 1A, which illustrates a typical hardware configuration of a workstation in accordance with a preferred embodiment having a central processing unit 10, such as a microprocessor, and a number of other units interconnected via a system bus 12. The workstation shown in FIG. 1A includes a Random Access Memory (RAM) 14, Read Only Memory (ROM) 16, an I/O adapter 18 for connecting peripheral devices such as disk storage units 20 to the bus 12, a user interface adapter 22 for connecting a keyboard 24, a mouse 26, a speaker 28, a microphone 32, and/or other user interface devices such as a touch screen (not shown) to the bus 12, communication adapter 34 for connecting the workstation to a communication network (e.g., a data processing network) and a display adapter 36 for connecting the bus 12 to a display device 38. The workstation typically has resident thereon an operating system such as the Microsoft Win/95 NT Operating System (OS) or UNIX OS. Those skilled in the art will appreciate that the present invention may also be implemented on platforms and operating systems other than those mentioned.

A preferred embodiment is written using JAVA, C, and the C++ language and utilizes object oriented programming methodology. Object oriented programming (OOP) has become increasingly used to develop complex applications. As OOP moves toward the mainstream of software design and development, various software solutions will need to be adapted to make use of the benefits of OOP. A need exists for these principles of OOP to be applied to a messaging interface of an electronic messaging system such that a set of OOP classes and objects for the messaging interface can be provided.

OOP is a process of developing computer software using objects, including the steps of analyzing the problem, designing the system, and constructing the program. An object is a software package that contains both data and a collection of related structures and procedures. Since it contains both data and a collection of structures and procedures, it can be visualized as a self-sufficient component that does not require other additional structures, procedures or data to perform its specific task. OOP, therefore, views a computer program as a collection of largely autonomous components, called objects, each of which is responsible for a specific task. This concept of packaging data, structures, and procedures together in one component or module is called encapsulation.

In general, OOP components are reusable software modules that present an interface that conforms to an object model and which are accessed at run-time through a component integration architecture. A component integration architecture is a set of architecture mechanisms which allow software modules in different process spaces to utilize each others capabilities or functions. This is generally done by assuming a common component object model on which to build the architecture.

It is worthwhile to differentiate between an object and a class of objects at this point. An object is a single instance of the class of objects, which is often just called a class. A class of objects can be viewed as a blueprint, from which many objects can be formed.

OOP allows the programmer to create an object that is a part of another object. For example, the object representing a piston engine is said to have a composition-relationship with the object representing a piston. In reality, a piston engine comprises a piston, valves and many other components; the fact that a piston is an element of a piston engine can be logically and semantically represented in OOP by two objects.

OOP also allows creation of an object that "depends from" another object. If there are two objects, one representing a piston engine and the other representing a piston engine wherein the piston is made of ceramic, then the relationship between the two objects is not that of composition. A ceramic piston engine does not make up a piston engine. Rather it is merely one kind of piston engine that has one more limitation than the piston engine; its piston is made of ceramic. In this case, the object representing the ceramic piston engine is called a derived object, and it inherits all of the aspects of the object representing the piston engine and adds further limitation or detail to it. The object representing the ceramic piston engine "depends from" the object representing the piston engine. The relationship between these objects is called inheritance.

When the object or class representing the ceramic piston engine inherits all of the aspects of the objects representing the piston engine, it inherits the thermal characteristics of a standard piston defined in the piston engine class. However, the ceramic piston engine object overrides these ceramic specific thermal characteristics, which are typically different from those associated with a metal piston. It skips over the original and uses new functions related to ceramic pistons. Different kinds of piston engines will have different characteristics, but may have the same underlying functions associated with it (e.g., how many pistons in the engine, ignition sequences, lubrication, etc.). To access each of these functions in any piston engine object, a programmer would call the same functions with the same names, but each type of piston engine may have different/overriding implementations of functions behind the same name. This ability to hide different implementations of a function behind the same name is called polymorphism and it greatly simplifies communication among objects.

With the concepts of composition-relationship, encapsulation, inheritance and polymorphism, an object can represent just about anything in the real world. In fact, our logical perception of the reality is the only limit on determining the kinds of things that can become objects in object-oriented software. Some typical categories are as follows:

Objects can represent physical objects, such as automobiles in a traffic-flow simulation, electrical components in a circuit-design program, countries in an economics model, or aircraft in an air-traffic-control system.

Objects can represent elements of the computer-user environment such as windows, menus or graphics objects.

An object can represent an inventory, such as a personnel file or a table of the latitudes and longitudes of cities.

An object can represent user-defined data types such as time, angles, and complex numbers, or points on the plane.

With this enormous capability of an object to represent just about any logically separable matters, OOP allows the software developer to design and implement a computer program that is a model of some aspects of reality, whether that reality is a physical entity, a process, a system, or a composition of matter. Since the object can represent anything, the software developer can create an object which can be used as a component in a larger software project in the future.

If 90% of a new OOP software program consists of proven, existing components made from preexisting reusable objects, then only the remaining 10% of the new software project has to be written and tested from scratch. Since 90% already came from an inventory of extensively tested reusable objects, the potential domain from which an error could originate is 10% of the program. As a result, OOP enables software developers to build objects out of other, previously built, objects.

This process closely resembles complex machinery being built out of assemblies and sub-assemblies. OOP technology, therefore, makes software engineering more like hardware engineering in that software is built from existing components, which are available to the developer as objects. All this adds up to an improved quality of the software as well as an increased speed of its development.

Programming languages are beginning to fully support the OOP principles, such as encapsulation, inheritance, polymorphism, and composition-relationship. With the advent of the C++ language, many commercial software developers have embraced OOP. C++ is an OOP language that offers a fast, machine-executable code. Furthermore, C++ is suitable for both commercial-application and systems-programming projects. For now, C++ appears to be the most popular choice among many OOP programmers, but there is a host of other OOP languages, such as Smalltalk, common lisp object system (CLOS), and Eiffel. Additionally, OOP capabilities are being added to more traditional popular computer programming languages such as Pascal.

The benefits of object classes can be summarized, as follows:

Objects and their corresponding classes break down complex programming problems into many smaller, simpler problems.

Encapsulation enforces data abstraction through the organization of data into small, independent objects that can communicate with each other. Encapsulation protects the data in an object from accidental damage, but allows other objects to interact with that data by calling the object's member functions and structures.

Subclassing and inheritance make it possible to extend and modify objects through deriving new kinds of objects from the standard classes available in the system. Thus, new capabilities are created without having to start from scratch.

Polymorphism and multiple inheritance make it possible for different programmers to mix and match characteristics of many different classes and create specialized objects that can still work with related objects in predictable ways.

Class hierarchies and containment hierarchies provide a flexible mechanism for modeling real-world objects and the relationships among them.

Libraries of reusable classes are useful in many situations, but they also have some limitations. For example:

Complexity. In a complex system, the class hierarchies for related classes can become extremely confusing, with many dozens or even hundreds of classes.

Flow of control. A program written with the aid of class libraries is still responsible for the flow of control (i.e., it must control the interactions among all the objects created from a particular library). The programmer has to decide which functions to call at what times for which kinds of objects.

Duplication of effort. Although class libraries allow programmers to use and reuse many small pieces of code, each programmer puts those pieces together in a different way. Two different programmers can use the same set of class libraries to write two programs that do exactly the same thing but whose internal structure (i.e., design) may be quite different, depending on hundreds of small decisions each programmer makes along the way. Inevitably, similar pieces of code end up doing similar things in slightly different ways and do not work as well together as they should.

Class libraries are very flexible. As programs grow more complex, more programmers are forced to reinvent basic solutions to basic problems over and over again. A relatively new extension of the class library concept is to have a framework of class libraries. This framework is more complex and consists of significant collections of collaborating classes that capture both the small scale patterns and major mechanisms that implement the common requirements and design in a specific application domain. They were first developed to free application programmers from the chores involved in displaying menus, windows, dialog boxes, and other standard user interface elements for personal computers.

Frameworks also represent a change in the way programmers think about the interaction between the code they write and code written by others. In the early days of procedural programming, the programmer called libraries provided by the operating system to perform certain tasks, but basically the program executed down the page from start to finish, and the programmer was solely responsible for the flow of control. This was appropriate for printing out paychecks, calculating a mathematical table, or solving other problems with a program that executed in just one way.

The development of graphical user interfaces began to turn this procedural programming arrangement inside out. These interfaces allow the user, rather than program logic, to drive the program and decide when certain actions should be performed. Today, most personal computer software accomplishes this by means of an event loop that monitors the mouse, keyboard, and other sources of external events and calls the appropriate parts of the programmer's code according to actions that the user performs. The programmer no longer determines the order in which events occur. Instead, a program is divided into separate pieces that are called at unpredictable times and in an unpredictable order. By relinquishing control in this way to users, the developer creates a program that is much easier to use. Nevertheless, individual pieces of the program written by the developer still call libraries provided by the operating system to accomplish certain tasks, and the programmer must still determine the flow of control within each piece after it's called by the event loop. Application code still "sits on top of" the system.

Even event loop programs require programmers to write a lot of code that should not need to be written separately for every application. The concept of an application framework carries the event loop concept further. Instead of dealing with all the nuts and bolts of constructing basic menus, windows, and dialog boxes and then making these things all work together, programmers using application frameworks start with working application code and basic user interface elements in place. Subsequently, they build from there by replacing some of the generic capabilities of the framework with the specific capabilities of the intended application.

Application frameworks reduce the total amount of code that a programmer has to write from scratch. However, because the framework is really a generic application that displays windows, supports copy and paste, and so on, the programmer can also relinquish control to a greater degree than event loop programs permit. The framework code takes care of almost all event handling and flow of control. The programmer's code is called only when the framework needs it (e.g., to create or manipulate a proprietary data structure).

A programmer writing a framework program not only relinquishes control to the user (as is also true for event loop programs), but also relinquishes the detailed flow of control within the program to the framework. This approach allows the creation of more complex systems that work together in interesting ways, as opposed to isolated programs, having custom code, being created over and over again for similar problems.

Thus, as is explained above, a framework basically is a collection of cooperating classes that make up a reusable design solution for a given problem domain. It typically includes objects that provide default behavior (e.g., for menus and windows). Programmers use it by inheriting some of that default behavior and overriding other behavior so that the framework calls application code at the appropriate times. There are three main differences between frameworks and class libraries:

Behavior versus protocol. Class libraries are essentially collections of behaviors that you can call when you want those individual behaviors in your program. A framework on the other hand, provides not only behavior but also the protocol or set of rules that govern the ways in which behaviors can be combined, including rules for what a programmer is supposed to provide versus what the framework provides.

Call versus override. With a class library, the class member is used to instantiate objects and call their member functions. It is possible to instantiate and call objects in the same way with a framework (i.e., to treat the framework as a class library), but to take full advantage of a framework's reusable design, a programmer typically writes code that overrides and is called by the framework. The framework manages the flow of control among its objects. Writing a program involves dividing responsibilities among the various pieces of software that are called by the framework rather than specifying how the different pieces should work together.

Implementation versus design. With class libraries, programmers reuse only implementations, whereas with frameworks, they reuse design. A framework embodies the way a family of related programs or pieces of software work. It represents a generic design solution that can be adapted to a variety of specific problems in a given domain. For example, a single framework can embody the way a user interface works, even though two different user interfaces created with the same framework might solve quite different interface problems.

Thus, through the development of frameworks for solutions to various problems and programming tasks, significant reductions in the design and development effort for software can be achieved. HyperText Markup Language (HTML) is utilized to implement documents on the Internet together with a general-purpose secure communication protocol for a transport medium between the client and the merchant. HTML is a simple data format used to create HyperText documents that are portable from one platform to another. HTML documents are Standard Generalized Markup Language (SGML) documents with generic semantics that are appropriate for representing information from a wide range of domains. HTML has been in use by the World-Wide Web global information initiative since 1990. HTML is an application of ISO Standard 8879:1986 Information Processing Text and Office Systems; SGML.

To date, Web development tools have been limited in their ability to create dynamic Web applications which span from client to server and interoperate with existing computing resources. Until recently, HTML has been the dominant technology used in development of Web-based solutions. However, HTML has proven to be inadequate in the following areas:

Poor performance;

Restricted user interface capabilities;

Can only produce static Web pages;

Lack of interoperability with existing applications and data; and

Inability to scale.

Sun Microsystem's Java language solves many of the client-side problems by:

Improving performance on the client side;

Enabling the creation of dynamic, real-time Web applications; and

Providing the ability to create a wide variety of user interface components.

With Java, developers can create robust User Interface (UI) components. Custom "widgets" (e.g. real-time stock tickers, animated icons, etc.) can be created, and client-side performance is improved. Unlike HTML, Java supports the notion of client-side validation, offloading appropriate processing onto the client for improved performance. Dynamic, real-time Web pages can be created. Using the above-mentioned custom UI components, dynamic Web pages can also be created.

Sun's Java language has emerged as an industry-recognized language for "programming the Internet." Sun defines Java as: "a simple, object-oriented, distributed, interpreted, robust, secure, architecture-neutral, portable, high-performance, multithreaded, dynamic, buzzword-compliant, general-purpose programming language. Java supports programming for the Internet in the form of platform-independent Java applets." Java applets are small, specialized applications that comply with Sun's Java Application Programming Interface (API) allowing developers to add "interactive content" to Web documents (e.g. simple animations, page adornments, basic games, etc.). Applets execute within a Java-compatible browser (e.g. Netscape Navigator) by copying code from the server to client. From a language standpoint, Java's core feature set is based on C++. Sun's Java literature states that Java is basically "C++, with extensions from Objective C for more dynamic method resolution."

Another technology that provides similar function to JAVA is provided by Microsoft and ActiveX Technologies, to give developers and Web designers wherewithal to build dynamic content for the Internet and personal computers. ActiveX includes tools for developing animation, 3-D virtual reality, video and other multimedia content. The tools use Internet standards, work on multiple platforms, and are being supported by over 100 companies. The group's building blocks are called ActiveX Controls, small, fast components that enable developers to embed parts of software in HyperText markup language (HTML) pages. ActiveX Controls work with a variety of programming languages including Microsoft Visual C++, Borland Delphi, Microsoft Visual Basic programming system and J++. ActiveX Technologies also includes ActiveX Server Framework, allowing developers to create server applications. One of ordinary skill in the art will readily recognize that ActiveX could be substituted for JAVA without undue experimentation to practice the invention.

A ladder logic editor in accordance with a preferred embodiment allows a user to program and display a PLC's ladder program as illustrated in FIG. 1B. The program utilized is the RSLogix program manufactured and sold by the assignee of the subject patent. The programming tool provides a graphical user interface to facilitate rapid prototype and production of programs for execution in a PLC. Information is organized in rungs of sequential instructions organized in the shape of a ladder (ladder logic). The tool allows an operator to determine if a particular hardware entity is in a particular state and thereby allows the operator to exercise complete control over the environment. The RSLogix program tool supports traditional ladder logic and nontraditional control languages such as C, C++ and Java. It takes advantage of a current and future pool of developing control programmers and supports a large base of legacy applications. The emphasis of this tool is to improve a programmer's productivity in entering control code.

Although tools for programming a particular PLC to perform a particular task utilizing ladder logic exist, an integrated solution for designing, simulating, implementing and maintaining both product and manufacturing information across an enterprise has not existed until now. An enterprise wide solution is important to achieve important customer goals such as reducing commissioning time by allowing validation of the design before investing significant resources in implementing a design that may not address customer requirements. A preferred embodiment also provides consistent information across the enterprise without requiring redundant information. A single database is employed to capture and maintain design, simulation, implementation and maintenance information concerning the enterprise wide solution. The single database also facilitates consistent design and implementation details since changes in the product and process are stored as changes to the control are effected.

Another customer goal is to reduce downtime. This goal is addressed in accordance with a preferred embodiment by the architecture of the system. In accordance with a preferred embodiment, each component is designed with data and logic associated with various pieces of information that are critical to the operation of the component and the system. One set of information that is designed into each component is the logic and data for diagnosing problems with the component. Thus as models of the enterprise are built utilizing these components, the diagnostic system is automatically constructed based on carefully thought-out information for each of the components. Thus, as a sensor level measuring proper performance levels falls below an approved threshold, information about the particular component and the level is available with non-ambiguous data that can be communicated back to the operator to solve the problem.

Today, major manufacturers are digitally integrating their design, simulation, implementation and maintenance manually and also integrating their processes and the processes of their suppliers. They are being driven to a solution in accordance with a preferred embodiment because design and manufacturing processes of major manufacturers are complex and the scale of their operations is enormous. Complex, large scale integration requires that all design, simulation, implementation and maintenance information must be accessible digitally across an enterprise in a common format. Each enterprise design domain (e.g., part, machine, control, and diagnostic) must be modeled in a computer representation containing syntax (format of the domain representation) and semantics (meaning of the domain representation). Finally, an integrated data model in accordance with a preferred embodiment must be adhered to by the entire enterprise to establish mappings between the domains and their respective representations. The resultant solution eliminates the barriers that traditionally exist between the design and manufacturing domains.

FIG. 2 illustrates an enterprise solution in accordance with a preferred embodiment. In today's environment a body engineer designs a door assembly based on experience of parts, structural knowledge and welding information. This information is given to a machine or tool engineer to design a .sub.-- detailed process and tools for manufacturing the door based on other experience and existing manufacturing information. Then, the control engineer must design the sensor/actuator relationships to implement the manufacture of the door in an automated environment based on experience. Timing diagrams, causal relationships, a Human Machine Interface (HMI), input/output tables, safety and diagnostic information must be integrated into the design after the fact and control logic must be generated to execute on the PLCs to implement the manufacturing processes. Then the control environment including clamps, hydraulics, electrical, robots and transport systems must be integrated with the PLC to begin testing the feasibility of the architecture. Resultant changes and additional diagnostic information are cycled through as time marches on. Finally, the process engineer translates management numbers for finished goods into a high-level process of actions and resources based on acquired experience and provides raw materials and goals to drive the manufacturing process. Currently, without the subject invention, this process can literally take years.

Enterprise wide controls in accordance with a preferred embodiment are necessary to organize and manage the increasing amount of information necessary to facilitate effective control of machines, processes and products. Management of this information includes validation statistics for the manufacturing enterprise, diagnostics and an organizational structure that avoids redundancies to avoid storage and execution inefficiencies. Feedback of control information into the design system is also critical to maintain a current view of the enterprise at all times and to synchronize information so that all engineers are literally singing out of the same hymnal.

Enterprise wide controls construct a control system within an integrated, enterprise-wide model that reuses control assemblies from existing subscription libraries and linkages between products, processes, machine and control models. Controls, diagnostics and HMI code from the control system model database is systematic with full coverage diagnostics from the start of the process to completion. The code is always consistent with product, process, machine and control models. The enterprise wide control system generates code that is utilized to animate simulation and subsequent production displays with a graphical depiction at various levels of hierarchical detail of the enterprise. An operator can zoom in to observe particular areas based on information from the enterprise to control large parts of the enterprise from a central control station.

An Enterprise Control Database (ECDB) acts as a single repository of enterprise information containing instantaneous access to engineering bill-of-material (EBOM) data for parts and assembly of parts as well as maintaining manufacturing bill-of-material (MBOM) which tracks the finished goods inventory as it is built. Factory service records are also captured and stored in the database as they occur. Control assemblies and control components are also stored in the ECDB. Diagnostic assemblies and diagnostic components are also stored with the control system configuration (processor, racks, networks and wiring diagrams).

A control component in accordance with a preferred embodiment is a machine part that either accepts inputs from the control system and/or generates outputs to the control system. A control assembly (descriptive class) is a configuration of control components and the defined set of states the control component can attain. The control assembly generates additional machine resource requirements and requests to the mechanical design system. A schematic of each control assembly is stored in the ECDB.

A control assembly is also responsible for performing one or more actions defined as a discrete action class. For example, a class action may be an input signal that requests an action in an external word, or an input signal that confirms completion of a particular task. A class action in accordance with a preferred embodiment can appear as a bar on a barchart. A class input, often referred to by old-time control engineers as a digital input or DI could be an input signal indicative of a state in the enterprise.

For example, when a heater reaches a threshold temperature, the process can proceed. Other examples include emergency stop, part present or a mode switch. Typically, class inputs are utilized as safeties, interlocks, cycle enablers or diagnostic inputs. A class output, digital output (DO) is an output signal to the enterprise to signal information. For example, turning on a cycle complete light. These entities readily lend themselves to implementation in an object-oriented abstraction as realizable classes for use in instantiating object instances of the classes. Examples of realizable classes in accordance with a preferred embodiment include PartPresent, ControlRobot, DumpSet, PinSet and SafeBulkHeadClampSet.

FIG. 3 illustrates a database entry for a safe-bulkheadclamp in accordance with a preferred embodiment. Each of the control valves, cylinders and other clamp information is stored in a single record completely defining the clamp and its characteristics to enable it to open and close on a target assembly effectively and safely. In addition, the database keeps track of how many catalog entries have incorporated this physical component into their design.

A diagnostic component in accordance with a preferred embodiment is an electrical, mechanical or pneumatic component that has no direct connection to the control system and is architected into the component for diagnostic purposes.

A diagnostic assembly (descriptive class) is a configuration of control components and diagnostic component in which the configuration is determined by the causal relationships that are useful for diagnostic purposes. Additional machine resource requirements may be required to generate requests to the mechanical design system.

FIG. 4 is a block diagram of the enterprise system in accordance with a preferred embodiment. A CATIA design station 400 utilizes a CNEXT interface to transmit design information, activities (process steps) and resources (a description of the tooling machine) to the Enterprise Database (ECDB) 410. The design information is a picture, for example a door welding station, with robot welders, clamps, a PLC and a transport mechanism. The ECDB receives information from the CATIA CNEXT interface defining activities and resources that will be necessary to build the station.

The ECDB integrates information from the CATIA CAD package 400, Designer Studio 430, code generation 440, final code 470 and the causal model subsystem 450. The activities and information that come from the CATIA interface 400 are created by a mechanical tool designer and they omit key information that comes from the control designer.

The Designer Studio 430 completes the activity and resource information in the ECDB 410 utilizing a graphical user interface that is C++ based Java code. The key organizing concept throughout an enterprise system in accordance with a preferred embodiment is CONTROL ASSEMBLY. Control assembly refers to utilizing a component based software assembly just as hardware designers utilize chip assemblies in hardware design and manufacture. A template type building block architecture is enabled for designing and managing enterprises. Software and hardware components are cataloged in the ECDB 410 for maximal reuse of the components. The ECDB 410 is a relational database implemented in a Microsoft Access product in accordance with a preferred embodiment. One of ordinary skill in the art will readily comprehend that other databases (relational or network) could readily be substituted without undue experimentation.

Once the database is populated, then information from the database is utilized to construct a code generation data structure 440 in a tree format as described later in detail. The database is also utilized to create the causal model 450. The causal model 450 is utilized to enable system diagnostics. The causal model is a LISP knowledge base.

The causal model 450 and the code generation data structure 440 is utilized as input for the PanelView Editor to automatically generate the operator's interfacce. Old code modified to work with new interface. The PanelView Editor also generates control code in the form of ladder logic. The causal model 450 generates diagnostic ladder logic that is mixed with the control code from the code generation 440 to create the final code 470 for controlling and monitoring the enterprise. The ladder logic is downloaded to the PLC 472 for controlling the enterprise.

The relay ladder logic code for control and diagnostics are merged by multiplexor code. The PanelView Editor generates code that enables the user interface to display graphical depictions of what is happening in the process and also to display diagnostic output.

The EDCB is also used by the RSWire schematic processor 480 to create schematic depictions of the sensor environment and transmit the schematic results back to the CNEXT system in CATIA where the tool design was also performed. This architecture, in accordance with a preferred embodiment, facilitates the location of changes in the processing efficiently which streamlines location of modification locations in the stations and control logic downstream.

The output from the ECDB is also provided to a schematic detailing package (RSWire) which enables a control engineer to decide where each of the clamps on a welding machine should be and locates valves, pneumatic piping etc. on the schematic detailing. A control engineer can place the cylinders and the schematic is generated from this information for wiring, piping and/or HVAC layout. Components are predesigned that enable design of an enterprise wide control system in accordance with a preferred embodiment of the invention. Control assemblies are merely objects encapuslating data and functions for performing standard control functions. Another set of macros are architected in accordance with a preferred embodiment for wiring diagrams that are componentized.

What we do for simulation is to load the PLC code into a PLC simulator SOFTLOGIX 5 (A/B product). This is utilized to drive a CAD simulator. The PLC Simulator & CAD Simulator utilize information from the CATIA database and the ECDB in accordance with a preferred embodiment. Then, when the code has been debugged, it is downloaded to the PLC 472 for production testing and ultimately running the enterprise.

The final schematics generated by the schematic tool 480 are ultimately sent back to CATIA 400 utilizing the standard CNEXT interface. This feedback mechanism is necessary to synchronize the CATIA database with the ECDB 410. This feedback mechanism also facilitates the addition of geometry to the original CAD drawings.

The database design of the ECDB includes tables that map activities into information appearing in the tables that is imported from the existing CATIA drawings. The resource import table is called Structural Components. It is implemented in accordance with a preferred embodiment in an ACCESS database with a record of the following structure:

    ______________________________________
    U:.backslash.ANEC.about.1.backslash.VCM.backslash.IAM98VCM980330a.mdb
    Monday, March 30, 1998
    Table: StructuralComponents
    Properties
    Date Created: 3/6/98 11:18:49 AM Def. Updatable:  True
    Last Updated:    3/30/98 2:14:37 PM
    OrderByOn:
             True
    RecordCount:
              56
    Columns
    Name Type                 Size
    StructuralComponentID Number (Long)
                              4
    AllowZeroLength:   False
    Attributes:        Fixed Size, Auto-Increment
    Collating Order:   General
    ColumnHidden:      False
    ColumnOrder:       Default
    ColumnWidth:       Default
    Ordinal Position:  1
    Required:          False
    Source Field:      StructuralComponentID
    Source Table:      StructuralComponents
    ExtID Text                255
    AllowZeroLength: False
    Attributes:      Variable Length
    Collating Order: General
    ColumnHidden:    False
    ColumnOrder:     Default
    ColumnWidth:     8268
    Description:     unique id for this spatial
                                 component
    DisplayControl:  Text Box
    Ordinal Position:
                     2
    Required:        False
    Source Field:    ExtID
    Source Table:    StructuralComponents
    Label Text                50
    AllowZeroLength: False
    Attributes:      Variable Length
    Collating Order: General
    ColumnHidden:    False
    ColumnOrder:     Default
    ColumnWidth:     1620
    Description:     label to show on graphic
                                 renditions of this
                                 component
    DisplayControl:  Text Box
    Ordinal Position:
                     3
    Required:        False
    Source Field:    Label
    Source Table:    StructuralComponents
    Class Text                50
    AllowZeroLength: False
    Attributes:      Variable Length
    Collating Order: General
    ColumnHidden:    False
    ColumnOrder:     Default
    ColumnWidth:     1545
    Description:     class of spatial components
                                 to which this instance
                                 belongs - detemines what
                                 types of control components
                                 can be in this spatial
                                 component
    DisplayControl:   Text Box
    Ordinal Position:
                     4
    Required:        False
    Source Field:    Class
    Source Table:    StructuralComponents
    WorkCellID Number (Long)  4
    AllowZeroLength: False
    Attributes:      Fixed Size
    Bound Column:    1
    Caption:         WorkCell
    Collating Order: General
    Column Count:    1
    Column Heads:    False
    Column Widths:   1440
    ColumnHidden:    False
    ColumnOrder:     Default
    ColumnWidth:     1140
    Decimal Places:  Auto
    Default Value:   0
    Description:     workcell that this component
                                 is part of - either this field
                                 or the next one is mandatory
    DisplayControl:  Combo Box
    Limit To List:   False
    List Rows:       8
    List Width:      1440twip
    Ordinal Position:
                     5
    Required:        False
    Row Source Type: Table/Query
    Row Source:      SELECT DISTINCTROW
    [WorkCell].[WorkCellID] FROM [WorkCell];
    Source Field:    WorkCellID
    Source Table:    StructuralComponents
    PartOf Text               255
    AllowZeroLength: False
    Attributes:      Variable Length
    Collating Order: General
    ColumnHidden:    False
    ColumnOrder:     Default
    ColumnWidth:     5985
    Description:     other spatial component that
                                 this component is part of - if
                                 this field is 0, it is a top
                                 level component
    DisplayControl:  Text Box
    Ordinal Position:
                     6
    Required:        True
    Source Field:    PartOf
    Source Table:    StructuralComponents
    Comment Memo              --
    AllowZeroLength: False
    Attributes:      Variable Length
    Collating Order: General
    ColumnHidden:    False
    ColumnOrder:     Default
    ColumnWidth:     Default
    Ordinal Position:
                     7
    Required:        False
    Source Field:    Comment
    Source Table:    StructuralComponents
    Relationships
    Reference26
    StructuralComponentsControlAssemblyInstance
    StructuralComponentID StructuralComponentID
    Attributes:      Not Enforced
    Attributes:      One-To-Many
    Reference 27
    StructuralComponents PCCInstanceElements
    StructuralComponentID StructuralComponentsID
    Attributes:      Not Enforced
    Attributes:      One-To-Many
    Table Indexes
    Name                 Number of Fields
    PrimaryKey           1
    Clustered:       False
    Distinct Count:  56
    Foreign:         False
    Ignore Nulls:    False
    Name:            PrimaryKey
    Primary:         True
    Required:        True
    Unique:          True
    Fields:          StructuralComponentID,
                            Ascending
    SpaceComponentID          1
    Clustered:       False
    Distinct Count:  56
    Foreign:         False
    Ignore Nulls:    False
    Name:            SpaceComponentID
    Primary:         False
    Required:        False
    Unique:          False
    Fields:          ExtID, Ascending
    StructuralComponentsID    1
    Clustered:       False
    Distinct Count:  56
    Foreign:         False
    Ignore Nulls:    False
    Name:            StructuralComponentsID
    Primary:         False
    Required:        False
    Unique:          False
    Fields:          StructuralComponentID,
                            Ascending
    WorkCellID                1
    Clustered:       False
    Distinct Count:  1
    Foreign          False
    Ignore Nulls:    False
    Name:            WorkCellID
    Primary:         False
    Required:        False
    Unique:          False
    Fields:          WorkCellID, Ascending
    User Permissions
    ACR
    admin
    ALA
    ALA2
    BJB
    CPI
    Group Permissions
    Admins
    Guests
    LETTERS
    MODIFY
    READ ONLY
    REPAIR
    Users
    Items that utilize the control assembly catalog have the
    following structure:
    Table: ControlAssemblyCatalog
    Properties
    Date Created: 10/22/97 1:25:38 PM Def. Updatable:
    True
    Description:
              CUnit stands for "control unit"
    Last Updated:
                   3/30/98 1:45:32 PM
              These are the generic types of assemblies that
              are relevant for control. The description only
              specifies how to interact with assembly from a
              control standpoint; it doesn't say how the
              instance will be used.
    OrderByOn:
              False    RecordCount:
    Columns
    Name Type                 Size
    ControlAssemblyCatalogID Number (Long)
                               4
    AllowZeroLength: False
    Attributes:      Fixed Size, Auto-Increment
    Collating Order: General
    ColumnHidden:    False
    ColumnOrder:     Default
    ColumnWidth:     1092
    Description:     unique identifier for the
                                 component structure
    Ordinal Position:
                     1
    Required:        False
    Source Field:    ControlAssemblyCatalogID
    Source Table:    ControlAssemblyCatalog
    Label Text                25
    AllowZeroLength: False
    Attributes       Variable Length
    Collating Order: General
    ColumnHidden:    False
    ColumnOrder:     Default
    ColumnWidth:     Default
    Description:     human readeable name for
                                 the component structure
    DisplayControl:  Text Box
    Ordinal Position:
                     2
    Required:        False
    Source Field:    Label
    Source Table:    ControlAssemblyCatalog



    DecompositionType Text    50
    AllowZeroLength: False
    Attributes:      Variable Length
    Bound Column:    1
    Collating Order: General
    Column Count:    1
    Column Heads:    False
    Column Widths:   1440
    ColumnHidden:    False
    ColumnOrder:     Default
    ColumnWidth:     1944
    Description:     whether this assembly can be
                                 broken down into discrete
                                 components or whether it is
                                 a single object like a robot
                                 or a PanelView.
    DisplayControl:  Combo Box
    Limit To List:   False
    List Rows:       8
    List Width:      1440twip
    Ordinal Position:
                     3
    Required:        False
    Row Source Type: Value List
    Row Source:
    "Virtual";"Physical";"Programmable"
    Source Field:    DecompositionType
    Source Table:    ControlAssemblyCatalog
    TemplateType Text         50
    AllowZeroLength: False
    Attributes:      Variable Length
    Collating Order: General
    ColumnHidden:    False
    ColumnOrder:     Default
    ColumnWidth:     1890
    Description:     Polaris template type to use
                                 with this element
    DisplayControl:  Text Box
    Ordinal Position:
                     4
    Required:        False
    Source Field:    TemplateType
    Source Table:    ControlAssemblyCatalog
    Comment Memo              --
    AllowZeroLength: True
    Attributes:      Variable Length
    Collating Order: General
    ColumnHidden:    False
    ColumnOrder:     Default
    ColumnWidth:     6012
    Description:     a brief comment on the use
                                 of the control assembly - should
                                 fit into 2 or 3 lines
    Ordinal Position:
                     5
    Required:        False
    Source Field:    Comment
    Source Table:    ControlAssemblyCatalog
    Explanation Memo:         --
    AllowZeroLength: False
    Attributes:      Variable Length
    Collating Order: General
    ColumnHidden:    False
    ColumnOrder:     Default
    ColumnWidth:     Default
    Description:     a longer comment about
                                 properties of the assembly
    Ordinal Position:
                     6
    Required:        False
    Source Field:    Explanation
    Source Table:    ControlAssemblyCatalog
    Relationships
    Reference1
    ControlAssemblyCatalog
                       DCCElements
    ControlAssemblyCatalogID
    ControlAssemblyCatalogID
    Attributes:      Not Enforced
    Attributes:      One-To-Many
    Reference11
    ControlAssemblyCatalog
                       DCCActions
    ControlAssemblyCatalogID
    ControlAssemblyCatalogID
    Attributes:      Not Enforced
    Attributes:      One-To-Many
    Reference2
    ControlAssemblyCatalog
                       DCCElements
    ControlAssemblyCatalogID
    ControlAssemblyCatalogID
    Attributes:      Not Enforced
    Attributes:      One-To-Many
    Reference6
    ControlAssemblyCatalogControlAssemblyInstances
    ControlAssemblyCatalogID
    ControlAssemblyCatalogID
    Attributes:      Not Enforced
    Attributes:      One-To-Many
    Table Indexes
    Name                 Number of Fields
    PrimaryKey           1
    Clustered:       False
    Distinct Count:  19
    Foreign:         False
    Ignore Nulls:    False
    Name:            PrimaryKey
    Primary:         True
    Required:        True
    Unique:          True
    Fields:          ControlAssemblyCatalogID,
                            Ascending
    User Permissions
    ACR
    admin
    ALA
    ALA2
    BJB
    CPI
    Group Permissions
    Admins
    Guests
    LETTERS
    MODIFY
    READ ONLY
    REPAIR
    Users
    ______________________________________