Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1998-12-23
2002-05-28
Amsbury, Wayne (Department: 2771)
Data processing: database and file management or data structures
Database design
Data structure types
Reexamination Certificate
active
06397225
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates generally to automation control systems, and, more particularly, to a messaging system having a protocol independent message format.
2. Description of the Related Art
Many manufacturing facilities have installed automated systems for controlling the manufacture of products. These control systems typically include a network of computers, or other processing devices, that connect various components of the system (e.g., processing equipment, records control equipment, product flow equipment, etc.). Usually the control system is implemented using software written for computers implementing UNIX or Microsoft Windows® NT that communicate over a Transmission Control Protocol/Internet Protocol (TCP/IP) network.
The control system software allows various components on the system to interact in accordance with the system protocol. An exemplary messaging product for providing such an exchange is the ISIS system offered by Stratus Computer, Inc. Generally, the ISIS system provides a message bus for use in information exchange. One or more pieces of equipment may be coupled to the message bus. An equipment interface (i.e., a computer executing interface software) communicates with the message bus and generates ISIS compatible messages for transmission to other devices. Available messaging systems, such as the ISIS system, sometimes use non-preemptive, ping-based communication protocols. If the message bus checks the availability of a piece of equipment (i.e., pings the equipment), and the equipment interface fails to respond, the device is disconnected from the message bus. A disconnection problem is also encountered by other programs, such as 16-bit Windows® programs handling context switches and user input.
Typically, one or more servers are coupled to the message bus for storing and retrieving information, such as tracking information, manufacturing information, and the like. The servers are coupled to relational databases for storing and retrieving the data. Relational database transactions are inherently atomic, in that they cannot be broken down into smaller transactions for completion. In some cases, a database transaction may take a long time to complete due to the size of the database being accessed. During this access time, the message bus may ping the device database application, which cannot respond due to the pending transaction. In such a case, the application may be disconnected from the bus and thus be unavailable for future access.
One technique for addressing the latency problem involves using a front end application on the server to receive a message, decode the message (i.e., also known as parsing the message), and enqueue the message. A database interface portion of the server software retrieves messages from the queue and executes the instructions therein as resources are available. The front end application maintains communication with the message bus, so the server is not disconnected while retrieving the data. This technique has several limitations.
Typically, accesses to the server include database column name information. The front end application parses the message to extract the command and column name information to verify that the command is acceptable to the database interface (e.g., proper format, necessary fields are present, etc.). Both the front end application and the database interface must know the structure of the database to properly address the instruction. Changes in the database structure require reprogramming of both the front end application and the database interface.
Another limitation lies in the fact that programming names used to reference variables often do not mirror the column names of the database. For example, programming names often include mixed-case characters and/or special characters (e.g., wafer_Id). Typically database column names referenced by the database are not case sensitive and cannot include some special characters. Also, the results are returned from the database in lower case (e.g., waferid). To address this problem, the front end application and the database interface must be hard coded to translate the program names to column names for accessing the database (e.g., wafer_Id=waferid), and must also translate the column names provided in the results of the database transaction back into program names that can be transferred back to the requesting device (e.g., waferid=wafer_Id).
Using the two process architecture described above (i.e., front end application and database interface) to address the latency problem creates a code maintenance problem. Both the front end application and the database interface must be reprogrammed in response to changes in the database structure or column names (e.g., addition of a new column to the database). If other devices on the message bus access the database, they must also be recoded in response to database changes. The code is not portable, in that unique code must be created for each type of equipment being serviced. For example, if a different device is added to the network a custom front end application specific to the new device must be created.
The present invention is directed to overcoming, or at least reducing the effects of, one or more of the problems set forth above.
SUMMARY OF THE INVENTION
One aspect of the present invention is seen in a messaging system including a message bus and a first processing device. The message bus is adapted to transmit a first message. The first message includes a second message, and the second message includes at least a first command. The first processing device is coupled to the message bus. The first processing device includes a message interface adapted to receive the first message and extract the second message independent of the first command. An input queue is adapted to store the second message. A message interpreter is adapted to retrieve the second message from the message queue and decode the second message to identify the first command.
Another aspect of the present invention is seen in a method for communicating messages the method includes transmitting a first message over a message bus. The first message includes a second message, and the second message includes at least a first command. The first message is received and the second message is extracted independent of the first command. The second message is stored in an input queue. The second message is retrieved from the message queue. The second message is decoded to identify the first command.
REFERENCES:
patent: 4945471 (1990-07-01), Neches
patent: 4949239 (1990-08-01), Gillett et al.
patent: 5583487 (1996-12-01), Ackerman et al.
patent: 5761083 (1998-06-01), Brown, Jr. et al.
patent: 5987633 (1999-11-01), Newman et al.
patent: 6064816 (2000-05-01), Parthasarathy et al.
patent: 6073174 (2000-06-01), Montgomerie et al.
patent: 6167406 (2000-12-01), Hoskins et al.
patent: 6182252 (2001-01-01), Wong et al.
patent: 6192282 (2001-02-01), Smith et al.
patent: 6198480 (2001-03-01), Cotugno et al.
Brown Russell C.
Likes Donald C.
Advanced Micro Devices , Inc.
Amsbury Wayne
Williams Morgan & Amerson P.C.
LandOfFree
Messaging system with protocol independent message format does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Messaging system with protocol independent message format, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Messaging system with protocol independent message format will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2845876