WO2003017111A1 - Executif de communication modulaire extensible a file d'attente de messages active et pre-validation intelligente des messages - Google Patents

Executif de communication modulaire extensible a file d'attente de messages active et pre-validation intelligente des messages Download PDF

Info

Publication number
WO2003017111A1
WO2003017111A1 PCT/US2002/023247 US0223247W WO03017111A1 WO 2003017111 A1 WO2003017111 A1 WO 2003017111A1 US 0223247 W US0223247 W US 0223247W WO 03017111 A1 WO03017111 A1 WO 03017111A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
component
buffer
electronic device
delegator
Prior art date
Application number
PCT/US2002/023247
Other languages
English (en)
Inventor
James T. Kent
David A. Toot
Original Assignee
Cognis Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US10/188,853 external-priority patent/US20030135547A1/en
Application filed by Cognis Corporation filed Critical Cognis Corporation
Publication of WO2003017111A1 publication Critical patent/WO2003017111A1/fr

Links

Classifications

    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01N—INVESTIGATING OR ANALYSING MATERIALS BY DETERMINING THEIR CHEMICAL OR PHYSICAL PROPERTIES
    • G01N35/00—Automatic analysis not limited to methods or materials provided for in any single one of groups G01N1/00 - G01N33/00; Handling materials therefor
    • G01N35/00584—Control arrangements for automatic analysers
    • G01N35/00722—Communications; Identification
    • G01N35/00871—Communications between instruments or with remote terminals
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01N—INVESTIGATING OR ANALYSING MATERIALS BY DETERMINING THEIR CHEMICAL OR PHYSICAL PROPERTIES
    • G01N21/00—Investigating or analysing materials by the use of optical means, i.e. using sub-millimetre waves, infrared, visible or ultraviolet light
    • G01N21/17—Systems in which incident light is modified in accordance with the properties of the material investigated
    • G01N21/25—Colour; Spectral properties, i.e. comparison of effect of material on the light at two or more different wavelengths or wavelength bands
    • G01N21/27—Colour; Spectral properties, i.e. comparison of effect of material on the light at two or more different wavelengths or wavelength bands using photo-electric detection ; circuits for computing concentration
    • G01N21/274—Calibration, base line adjustment, drift correction
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01N—INVESTIGATING OR ANALYSING MATERIALS BY DETERMINING THEIR CHEMICAL OR PHYSICAL PROPERTIES
    • G01N35/00—Automatic analysis not limited to methods or materials provided for in any single one of groups G01N1/00 - G01N33/00; Handling materials therefor
    • G01N35/00584—Control arrangements for automatic analysers
    • G01N35/00722—Communications; Identification
    • G01N35/00871—Communications between instruments or with remote terminals
    • G01N2035/00881—Communications between instruments or with remote terminals network configurations
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01N—INVESTIGATING OR ANALYSING MATERIALS BY DETERMINING THEIR CHEMICAL OR PHYSICAL PROPERTIES
    • G01N21/00—Investigating or analysing materials by the use of optical means, i.e. using sub-millimetre waves, infrared, visible or ultraviolet light
    • G01N21/17—Systems in which incident light is modified in accordance with the properties of the material investigated
    • G01N21/25—Colour; Spectral properties, i.e. comparison of effect of material on the light at two or more different wavelengths or wavelength bands
    • G01N21/31—Investigating relative effect of material at wavelengths characteristic of specific elements or molecules, e.g. atomic absorption spectrometry
    • G01N21/35—Investigating relative effect of material at wavelengths characteristic of specific elements or molecules, e.g. atomic absorption spectrometry using infrared light
    • G01N21/359—Investigating relative effect of material at wavelengths characteristic of specific elements or molecules, e.g. atomic absorption spectrometry using infrared light using near infrared light
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01N—INVESTIGATING OR ANALYSING MATERIALS BY DETERMINING THEIR CHEMICAL OR PHYSICAL PROPERTIES
    • G01N2201/00—Features of devices classified in G01N21/00
    • G01N2201/12—Circuits of general importance; Signal processing
    • G01N2201/127—Calibration; base line adjustment; drift compensation
    • G01N2201/12746—Calibration values determination
    • G01N2201/12753—Calibration values determination and storage
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01N—INVESTIGATING OR ANALYSING MATERIALS BY DETERMINING THEIR CHEMICAL OR PHYSICAL PROPERTIES
    • G01N2201/00—Features of devices classified in G01N21/00
    • G01N2201/12—Circuits of general importance; Signal processing
    • G01N2201/127—Calibration; base line adjustment; drift compensation
    • G01N2201/12792—Compensating own radiation in apparatus
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01N—INVESTIGATING OR ANALYSING MATERIALS BY DETERMINING THEIR CHEMICAL OR PHYSICAL PROPERTIES
    • G01N35/00—Automatic analysis not limited to methods or materials provided for in any single one of groups G01N1/00 - G01N33/00; Handling materials therefor
    • G01N35/00584—Control arrangements for automatic analysers
    • G01N35/00594—Quality control, including calibration or testing of components of the analyser
    • G01N35/00712—Automatic status testing, e.g. at start-up or periodic

Definitions

  • the present invention relates to managing communications between sending and receiving electronic devices, and in particular, to message-based communications for interfacing independent electronic devices.
  • Data communication is an important aspect of any data processing system.
  • integrated circuit chips such as microprocessors
  • microprocessors require communication with external devices, e.g., to receive input from a user or display input from a user, as well as to store or retrieve from a memory or storage device.
  • Computers and other electronic devices also have a need to communicate with other such devices, e.g., to distribute processing tasks among multiple devices or to exchange information managed by one device with another device that needs to utilize the information.
  • control devices such as machines, valves, actuators, etc. are typically managed by a controller, which receives feedback from one or more sensing devices that monitor the progress of a manufacturing operation.
  • control devices such as control valves that add ingredients to a chemical formulation or that transfer ingredients or finished products to and from storage tanks, environmental controls that control reaction temperatures, ambient pressures, and the like, etc.
  • sensing devices such as temperature gauges, pressure gauges, conductivity sensors, etc.
  • Some manufacturing control systems are highly centralized, whereby sensing devices gather data and forward the data to a central controller that processes the data and controls one or more control devices accordingly.
  • a more decentralized approach is often superior in many situations, particularly where sensing and control devices may be physically dispersed over a wide geographical area.
  • controllers are interfaced together, with individual controllers utilized to interface with selected subsets of sensing and/or control devices in the system.
  • communications between controllers, sensing devices and control devices are typically more sophisticated than centralized systems that utilize central controllers and relatively "dumb" sensing and/or control devices.
  • message-based communications are often used in decentralized systems, whereby information units known as messages are passed between devices using a particular format that is understood by both the sending and receiving devices.
  • Messages are often processed as "events" that are capable of being responded to by a receiving device with a similar type of message. Messages may also be ordered to ensure timely delivery and eliminate race conditions that could compromise data integrity or result in incorrect control settings.
  • Another aspect of a decentralized system is the ability to incorporate a wide variety of devices into a single system, often using devices that are manufactured by different entities and that may not be specifically adapted to work with other types of devices also used in the system. In many instances, such devices are specifically configured to communicate information according to a particular communications protocol, which may include a specific message format, and even a particular type of electrical connector and/or wiring. Should different devices within a particular system not subscribe to the same communications protocol, often custom hardware and/or software is required to appropriately interface the devices.
  • one type of manufacturing control system utilizes a central database that receives input data from one or more sensing devices and stores the states of the input data in the database.
  • IR infrared
  • NIR NIR spectroscopy
  • Spectroscopy has been used in laboratory environments to perform quantitative analysis of chemical compositions. Spectroscopy provides the advantage that material samples can be analyzed relatively quickly and often without any preparation of the samples or any time-consuming wet chemistry. Many IR and NIR spectrum analyzers are principally designed to be used in laboratory environments, and traditionally, these types of laboratory instruments have not been particularly well-suited for use in manufacturing control systems.
  • IR and NIR spectrum analyzers also have other potential uses that would benefit from enhanced communication abilities.
  • a spectrum analyzer typically must incorporate some form of analysis engine to process the spectral information generated by an NIR or IR sensor.
  • a spectrum analyzer utilizes chemometrics or other multivariate regression methods to derive quantitative information about a particular sample from the sensor data. It has been found that a large number of outside factors, including various measurement conditions such as environmental parameters, instrument parameters and analysis techniques, as well as various sample conditions based upon the properties of the composition when the sensor data is obtained, can affect quantitative analysis results. For this reason, analysis is often a complex mathematical process requiring a relatively high performance computing system to process sensor data in a reliable and efficient manner.
  • message buffers or "queues" are often used to temporarily store messages as they are being processed.
  • Messages received by a device are typically enqueued on a message queue, and a computer program periodically polls the queue for new messages. Whenever a new message is detected, the computer program processes the message as appropriate.
  • Messages are typically ordered for first-in-first-out processing, and in some instances prioritization rules may be applied to handle messages with differing degrees of urgency.
  • Queues are often associated with queuing "strategies," which essentially define how and by what means messages are received, stored, processed and ultimately responded to. These queuing strategies may ultimately affect response speed, processing speed, and other determining performance factors in both sending and receiving devices. As a result, when different devices are integrated into a message- based system, the queuing strategy used to interface those devices often must be specifically tailored to adequately handle the performance requirements of such devices. Where different devices have widely divergent performance characteristics, integration of the devices through a common queuing strategy can be difficult.
  • manymessage-based systems inherently support various forms of "business rules" that define the accepted format of messages, as well as what messages and message types are appropriate for a particular system.
  • business rules are implemented by whatever computer program handles a received message, e.g., by performing error checking and the like while handling the message.
  • the business rules are often highly application-specific.
  • the business rules are often applied only after a message is enqueued on a queue, so that unacceptable messages will still typically be placed on a queue before any problems are detected. Therefore, given the possible variations in different message-based communications systems, queuing strategies and business rules often must be specifically developed and implemented within individual devices in a particular system, often using custom hardware and/or software. As a result, integrating multiple disparate devices together into a system may not be possible in some instances, or in the least, may require substantial customization, leading to increased cost and reduced performance.
  • a modular architecture is used to facilitate message-based communications in such a manner that queuing strategies, business rules and the like may be accommodated within a message-based environment in a reliable and efficient manner.
  • application- specific software components can be assembled together to readily adapt a generic message-based system for use in a specific application.
  • intelligent pre- validation of messages may be implemented in such a modular architecture to permit a business rule-independent messaging infrastructure to be readily adapted to support specific business rule requirements for a particular application.
  • an active message queue architecture is utilized within a modular environment to facilitate the processing of messages sent by a sending electronic device to a receiving electronic device.
  • the architecture includes a message buffer that is configured to receive messages, with each message associated with a message type among a plurality of message types.
  • a plurality of software-based processor components are utilized to perform tasks associated with messages received by the message buffer, and at least one processor component is configured to initiate an action on a receiving electronic device.
  • a plurality of software-based controller components are also utilized, with each associated with a message type among the plurality of message types, and each configured to handle a message associated with such associated message type by dynamically instantiating at least a subset of the plurality of processor components.
  • the architecture also utilizes at least one delegator component that is associated with at least one message type among the plurality of message types and is configured to monitor the message buffer for messages associated with such associated message type.
  • the delegator component dynamically executes a controller component associated with an associated message type in response to detecting an addition of a message associated with such associated message type to the message buffer.
  • a message buffer is integrated with a buffer services component and a plurality of message validation components, where each message validation component is associated with at least one of a message type and a receiving electronic device, with each message validation component configured to validate a message sent to the message buffer by a sending electronic device prior to addition of the message to the message buffer, and with each message validation component further configured to return a result that indicates whether the message should be accepted by the message buffer.
  • the buffer services component processes a first message sent to the message buffer by invoking a message validation component associated with the first message and selectively adding the first message to the message buffer based upon the result returned by the invoked message validation component.
  • FIGURE 1 is a block diagram of a communication system incorporating a communication executive consistent with the invention.
  • FIGURE 2 is a block diagram of an exemplary hardware environment for the communication executive of Fig. 1.
  • FIGURE 3 is a layer diagram of the principal software components in the communication executive of Fig. 1.
  • FIGURE 4 is a flowchart illustrating the program flow of a message received routine executed by the COM service of the communication executive of Fig. 1.
  • FIGURE 5 is a flowchart illustrating the program flow of a routine executed by a delegator component in the communication executive of Fig. 1.
  • FIGURE 6 is a flowchart illustrating the program flow of a routine executed by a controller component in the communication executive of Fig. 1.
  • FIGURE 7 is a flowchart illustrating the program flow of a routine executed by a processor component in the communication executive of Fig. 1.
  • FIGURE 8 is a sequence diagram illustrating various possible execution sequences of processor components in the communication executive of Fig. 1.
  • FIGURE 9 is a flowchart illustrating the program flow of a routine executed by a message validation component in the communication executive of Fig. 1.
  • FIGURE 10 is an object diagram illustrating the principal data structures utilized in connection with managing communications with the communication executive of Fig. 1.
  • FIGURE 11 is a block diagram of one exemplary application of the communication executive of Fig. 1, for use in interfacing remote sensors with a central processor.
  • FIGURE 12 is a block diagram of another exemplary application of the communication executive of Fig. 1, for use in a manufacturing control system.
  • FIGURE 13 is a block diagram of another exemplary application of the communication executive of Fig. 1, for use in an inventory management system.
  • the hereinafter-described embodiments of the invention utilize a unique communication executive to provide a flexible, extensible and modular message- based interface between electronic devices, often in a manner that permits independent and disparate electronic devices, which may not have been specifically designed to communicate with one another, to communicate in a near real-time manner.
  • the modular and extensible architecture of the interface further often permits substantial code reuse to be employed when an interface is being adapted for use in a particular environment, thus reducing development time and increasing interface reliability.
  • Fig. 1 illustrates an exemplary communication system 10 incorporating a communication executive 12 consistent with the invention.
  • the communication executive 12 is utilized to interface sending electronic devices with receiving electronic devices via a message-based protocol.
  • a sending electronic device in this context may refer to any electronic device capable of sending or otherwise outputting information, while a receiving electronic device may refer to any electronic device capable of receiving or otherwise inputting information.
  • an electronic device may operate both as a sending electronic device and a receiving electronic device, and further, that a communication executive may be implemented within the same physical hardware as either or both of a sending and receiving electronic device (i.e., a communication executive may be used to manage commumcations within a single electronic device, and even within a single integrated circuit within an electronic device).
  • a communication executive consistent with the invention which is illustrated in Fig. 1, is that of interfacing various data processing devices 14 (e.g., data collection devices, data display devices, data recording devices, controller devices, etc.) with various data resources 16 (e.g., databases, data analysis tools, etc.).
  • data processing devices 14 e.g., data collection devices, data display devices, data recording devices, controller devices, etc.
  • data resources 16 e.g., databases, data analysis tools, etc.
  • devices 14 and resources 16 it should be appreciated that any device or resource may function from time to time as a sending electronic device, a receiving electronic device, or both.
  • Communication executive 12 is typically interfaced with devices 14 and resources 16 via one or more network interconnections 18, each of which may represent practically any type of networked interconnection, including but not limited to local-area, wide-area, wireless, public networks (e.g., the Internet), and combinations thereof, as well as point-to-point serial or parallel interconnects, buses, infra-chip interconnects, and embedded interconnects.
  • network interconnections 18 each of which may represent practically any type of networked interconnection, including but not limited to local-area, wide-area, wireless, public networks (e.g., the Internet), and combinations thereof, as well as point-to-point serial or parallel interconnects, buses, infra-chip interconnects, and embedded interconnects.
  • network interconnections 18 may represent practically any type of networked interconnection, including but not limited to local-area, wide-area, wireless, public networks (e.g., the Internet), and combinations thereof, as well as point-to-point serial or parallel interconnects, buses, infr
  • Communication executive 12 is typically implemented in software that resides and executes upon a computer or other data processing system. As shown in Fig. 2, for example, communication executive 12 may reside on a computer 20, specifically within a memory 22 thereof, and be executed by one or more processors 24 interfaced with memory 22.
  • Processor 24 may represent one or more central processing units (e.g., microprocessors), and memory 22 may represent the random access memory (RAM) devices comprising the main storage of computer 20, as well as any supplemental levels of memory, e.g., cache memories, non- volatile or backup memories (e.g., programmable or flash memories), read-only memories, etc.
  • RAM random access memory
  • memory 22 may be considered to include memory storage physically located elsewhere in the computer 20, e.g., any cache memory in any processor 24, as well as any storage capacity used as a virtual memory, e.g., as stored on a mass storage device or on another c ⁇ mputeTcoupled to computer " 20 ⁇ via a network.
  • Computer 20 also typically receives a number of inputs and outputs for communicating information externally.
  • computer 20 may include a user interface 26, including various user input devices (e.g., a keyboard, a mouse, a trackball, a joystick, a touchpad, and or a microphone, among others) as well as various display devices (e.g., a CRT monitor, an LCD display panel, and/or a speaker, among others).
  • user interface 26 may alternatively be implemented on a terminal or workstation interfaced with the computer, as is well known in the art.
  • computer 20 also typically includes one or more mass storage devices 28, e.g., a floppy or other removable disk drive, a hard disk drive, a direct access storage device (DASD), an optical drive (e.g., a CD drive, a DND drive, etc.), and/or a tape drive, among others.
  • mass storage devices 28 e.g., a floppy or other removable disk drive, a hard disk drive, a direct access storage device (DASD), an optical drive (e.g., a CD drive, a DND drive, etc.), and/or a tape drive, among others.
  • computer 20 may include an interface 30 with one or more ports to permit the communication of information between the sending and receiving devices coupled thereto, wherein each interface is dependent upon the particular network interconnection to which the computer is coupled to a particular sending or receiving device.
  • computer 20 typically includes suitable analog and or digital interfaces between processor 24 and each of components 22, 26, 28 and 30 as is well known in the art.
  • Computer 20 generally operates under the control of an operating system (not shown separately), and executes or otherwise relies upon various computer software applications, components, programs, objects, modules, data structures, etc. (e.g., communication executive 12, among others). Moreover, various applications, components, programs, objects, modules, etc. may also execute on one or more processors in another computer in communication with computer 20, e.g., in a distributed or client-server computing environment, whereby the processing required to implement the functions of a computer program may be allocated to multiple computers.
  • an operating system not shown separately
  • various applications, components, programs, objects, modules, data structures, etc. e.g., communication executive 12, among others.
  • various applications, components, programs, objects, modules, etc. may also execute on one or more processors in another computer in communication with computer 20, e.g., in a distributed or client-server computing environment, whereby the processing required to implement the functions of a computer program may be allocated to multiple computers.
  • routines executed to implement the embodiments of the invention whether implemented as part of an operating system or a specific application, component, program, object, module or sequence of instructions will be re f err ed tomereimas ⁇ "computer programs", or simply “programs”: " The computer programs typically comprise one or more instructions that are resident at various times in various memory and storage devices in a computer, and that, when read and executed by one or more processors in a computer, cause that computer to perform the steps necessary to execute steps or elements embodying the various aspects of the invention.
  • signal bearing media include but are not limited to recordable type media such as volatile and non- volatile memory devices, floppy and other removable disks, hard disk drives, magnetic tape, optical disks (e.g., CD- ROM's, DND's, etc.), among others, and transmission type media such as digital and analog communication links.
  • communication executive 12 of Figs. 1-2 is that of interfacing various electronic devices coupled over a communication network such as the Internet, a Local- Area Network, a Wide- Area Network, and combinations thereof, using a conventional network-based protocol such as TCP/IP. It is this specific implementation that will be focused upon hereinafter, it being understood that the presentri ⁇ vention is not limited solely for use in such an implementation.
  • Fig. 3 illustrates the principal software components in communication executive 12.
  • Several layers of software are defined at 40-54, and are used to provide a flexible, extensible and modular communications service for linking electronic devices to one another in a structured manner.
  • External device layer 40 represents the source and destination devices that utilize the communication executive. It will be appreciated that each external device will typically include its own queuing strategy and may require various business rules to control the messages sent by or received by such devices.
  • Network services layer 42 represents the network protocol services required to interface the communication executive with the particular type of networks over which the external devices are accessible.
  • COM service layer 44 which represents a buffer services component, provides an external interface to a message repository or database, and in the illustrated embodiment, is implemented as a Visual Basic COM object that acts as the liaison between the message repository and any system that wishes to enter tasks into or retrieve information from the repository.
  • the COM service layer is called by the network services layer 42, or other non-network based systems directly, e.g., via DCOM calls, in a manner well known in the art.
  • the network and COM service layers 42, 44 may require customization for use in different environments.
  • the network services may require differing functionality.
  • the network services may function as a listening device, capable of receiving TCP/IP packets and forwarding packets in a predetermined format to the communication executive as required.
  • the COM service into the message repository may vary in other applications.
  • the COM service is instantiated whenever data is received, and the COM service is configured to dynamically generate requests from received data. Given the variable types of devices that may be coupled to a communication executive, however, the COM service will differ for various applications.
  • MN components 46 may also be provided in communication executive 12. Each MN component performs pre-validation of received messages for particular types of messages and/or for messages directed toward particular receivers.
  • the MN components typically implement desired business rules, and are used to validate a message using artificial intelligent techniques before the message is added to a message repository. In this manner high-level message processing may occur prior to the message being accepted onto a message repository. In other embodiments, however, MN components may not be used.
  • the MN components are layered on top of a message repository, also referred to herein as a cube 48, which represents the database or buffer within which messages are stored.
  • message repository 48 When coupled with one or more delegators 50, message repository 48 forms an active queue that actively manages messages placed on the buffer by the COM service.
  • Each delegator 50 functions as a monitor task that actively monitors for messages of a particular type.
  • a delegator in response to detecting a new message for which it is responsible, dynamically spawns (or otherwise executes) one or more controller components 52 to handle such messages.
  • controller components 52 to handle such messages.
  • a delegator will call a controller for each message type for which the delegator is responsible.
  • each delegator is implemented as a Visual Basic program such as an ActiveX executable, although other software implementations may be used in the alternative.
  • each controller component 52 is dynamically instantiated or spawned by a delegator to handle a particular message type.
  • controller components may remain resident at all times, and as a result, may be executed by a delegator on an as-needed basis. Instantiation or spawning in addition to execution is therefore optional in some embodiments.
  • each controller represents a logical layer split into two physical layers.
  • a controller is capable of handling complex chain processing, with a CBO layer implemented as a Visual Basic program, e.g., an
  • the SBO layer may be implemented as a Visual Basic program such as a COM+ ActiveX DLL that calls one or more processor components 54 dedicated to handling a specific message type to process the relevant messages in the message repository.
  • a delegator maybe allowed to process requests of different types without having to wait for any of the requests to complete.
  • other software implementations may be used for a controller consistent with the invention.
  • Each processor component 54 is implemented in the illustrated embodiment as a Visual Basic COM object that contains the business logic for a particular system using the communication executive as its queuing engine.
  • the processor components are typically resident outside of the communication executive, and are used to interact directly with destination devices to actually process messages in the manner appropriate for a particular device.
  • the processor components read messages from the message repository and interface with a destination device either directly or by adding new out-bound messages to the message repository via the CBO layer of the associated controller.
  • a processor component can perform any number of tasks associated with a message, including in many instances initiating some action on a destination device.
  • Fig. 3 also illustrates an optional system analyzer 56, which may represent one or more self-diagnosis routines that constantly monitor the health of the communication executive. Typically, when an analyzer detects a problem, an entry may be logged in, and depending upon the severity of the error, a message may be sent to an administrator. In this regard, the system analyzer functions in a similar manner to other network monitoring products.
  • a device wishing to send a message via the communication executive to another device in the system will initiate a function call to the COM service associated with that device, which, if the message is acceptable, will place the message on the message repository. Then, a delegator associated with the particular type of message will dynamically spawn one or more controllers to handle the message. The appropriate controller will in turn call one or more processor components to actively handle the task. The result of handling a message may also incorporate sending a response message or initiating another message for another device coupled within the system. The details of this overall program flow are illustrated in greater detail in Figs. 4-9 below.
  • Fig. 4 illustrates a message received routine 60, executed for example by COM service 44 whenever a message needs to be placed on the message repository.
  • Routine 60 begins in block 62 by determining whether a message validation component needs to be called for the message.
  • a message validation component typically message validation components, if used, are associated with particular message types, and are used to pre-validate a message before the message is placed on the message repository, or cube. Therefore, if such a component exists for the particular message type with which the message is associated, block 62 passes control to block 64 to call the appropriate message validation component.
  • the message validation component typically has the ability to either accept, reject or modify an incoming message.
  • block 62 passes control directly to block 68 to enqueue the message onto the cube.
  • an active monitoring process associated with the repository is utilized to automatically handle the message by dynamically instantiating one or more controller components associated with the message type for that message.
  • a delegator component may be implemented as a Visual Basic ActiveX executable program, among other implementations.
  • a delegator will first connect to the message repository and create a list of available delegator components, as shown in block 72. Once the initial connections have been established, the delegator is ready to receive events, and to monitor for new messages placed on the cube.
  • the delegator waits on a wait block 74, for various types of events that may be directed to the delegator.
  • the delegator also periodically monitors the cube for the receipt of a new message.
  • events may be handled in a different thread from message monitoring.
  • block 74 also monitors for the placement of a new message on the cube.
  • block 82 is called to determine whether the delegator is currently enabled. If not, the message is ignored, and control returns to block 74. If the delegator is enabled, however, block 82 passes control to block 84 to retrieve the message data from the cube. Block 86 then determines whether any other delegator is currently handling the message, e.g., by determining whether a flag or indicator set in the message record indicates that the message is associated with another delegator. If so, no further processing by the delegator occurs, and control returns to block 74.
  • block 90 determines what controller is required for processing the message, typically based upon the type of message as found in the message record, as well as a known mapping between controllers and messages defined within the system.
  • Block 92 then dynamically instantiates, or spawns, such controller, which also incorporates execution of the spawned controller. Control then returns to block 74 to process other events and messages.
  • a delegator component may show an administrator the number of times a delegator has searched the cube for messages, and the number of times the delegator has completed the search.
  • a cycle time representing the period during which the delegator periodically checks the cube, may also be configurable and displayed to a user.
  • Status information may also be displayed illustrating whether the delegator is currently enabled or disabled, as well as indicating when messages are received and when controllers are spawned in response to reception of such messages.
  • a status window displayed to an administrator may also include various user interface controls such as START and STOP buttons that selectively enable or disable the delegator, as well as an END button that shuts down the delegator in the manner described above.
  • Fig. 6 next illustrates a controller routine 100 executed by a controller component consistent with the invention.
  • the controller component is typically divided into two physical layers, a CBO controller layer and an SBO controller layer, with the CBO controller layer configured as a single-use (class parameter) ActiveX executable, and the SBO controller layer being implemented as a COM+ ActiveX DLL Visual Basic program.
  • the CBO controller layer includes a hidden form with a timer control that is initially inactive when instantiated by a delegator component.
  • a method e.g., a start controller method, may be exposed by the controller, and include a controller ID parameter, delegator ID parameter, a delegator pointer and error information.
  • the method when called by a delegator, stores the parameters in private variables, loads the hidden form, and enables the time control on the form. Then, the method ends and returns control to the calling delegator, which frees the delegator to process messages of a different system ID/message type, while the controller proceeds with processing of messages.
  • the timer control may be set to fire some delay after being enabled, e.g., one second. Once the time control fires, an instance of an SBO controller is created and messages are processed as described below. Once the process messages method has completed, a DONE method exposed by the delegator may be called to return error and status information to the delegator.
  • a controller routine 100 generally begins in block 102 by connecting to the message repository and obtaining a list of messages that need to be processed.
  • block 104 obtains a list of processors that are to be launched, including the desired order.
  • Block 106 then initiates a FOR loop to process each of the processors necessary to be launched. For each such processor, control passes to block 108 to determine whether the processors needs a transaction.
  • processors may be grouped into transactions, with transactional groups defined within the message repository. Processors may be defined within the same transactional group based upon processing order and whether or not each processor is batch or single record. By being placed in a transactional group, multiple processors can apply multiple changes to a database or multiple databases and have the changes committed or rolled back as a group.
  • block 108 simply passes control to block 110 to launch the appropriate processor, e.g., by instantiating the processor or making a function call to the processor as appropriate. Control then passes to block 112 to determine whether the last processor has been reached, whereby control returns to block 106 to process additional processors as appropriate.
  • block 108 passes control to block 114 to determine whether the message is part of a previous transaction. If not, control passes to block 116 to begin the transaction, and then to block 118 to launch the appropriate processor. Otherwise, if the message is part of a previous transaction, block 114 passes control directly to block 118. Once the appropriate processor has been launched, control passes to block 120 to determine whether the next processor is part of the same transaction. If not, control passes to block 122 to commit the transaction. Regardless of whether the next processor is part of the same transaction, control then passes to block 112 to determine whether the last processor has been launched. If not, control returns to block 106. Otherwise, control passes to block 124 to commit any open transactions, and then to block 126 to update the statistics associated with the message. Upon completion of block 126, routine 100 is complete.
  • the determination of what processors are to be launched for a particular type of message is made by accessing a database such as the message repository, within which such information is stored.
  • the settings may include information as to which processors to call and in what order, as well as whether each of these processor is a batch or single record processor.
  • the information is stored in connection with data records that map specific processors to specific controllers, e.g,. in the tblControllerProcessors table 196 discussed below in connection with Fig. 10.
  • each processor has one method, e.g., an execute method, that is called by a controller to invoke the functionality in the processor.
  • the execute method may include a record ID field, as well as option delegator ID, system ID, message type, text data, binary data, error code data, etc., with the record ID used to identify the function call as either a single record call, where the ID of the particular message record is passed, or a batch-type call, where a unique token, e.g., "-1" is used in the record ID field.
  • the error information and text and binary data may be provided to allow a controller to pass data from a previously-called processor to a next processor.
  • an execute method may be configured to return a status to the controller, indicating whether the execution was successful.
  • the error information may be processed by the controller as appropriate, i.e., by rolling back the transaction, aborting processing of the message, and/or updating the message status. It may also be desirable to keep track in the controller of the time it takes to process a message, and use this information to store statistical information regarding the operation of the controller. The time to process may also be utilized to trigger a watchdog timer should a processor not process a message in an appropriate period of time.
  • Fig. 7 illustrates a processor routine 130 executed by generic processor component consistent with the invention.
  • routine 130 represents the execute method exposed by the respective processor.
  • block 132 is called to read the message record for the relevant data, and then to block 134 to perform processing on the message as required.
  • Block 136 determines whether the processor is being executed in batch mode (i.e., where a batch mode is indicated in the method call), and if so, control passes to block 138 to determine whether the last message has been processed.
  • a unique token is applied in the function call that indicates to the processor component that all messages of a particular message type should be processed.
  • block 132 when in batch mode, initially reads the first message matching the particular message type handled by the associated controller.
  • block 136 passes control to block 140 to return appropriate success or failure information to the calling controller, as well as provide state information (if applicable) to the controller. Also, as shown in block 138, if the last message in a batch mode has been processed, block 138 passes control to block 140. Once block 140 is complete, routine 130 terminates.
  • a processor may be configured to send a message to its associated external device to perform tasks on that device, and in a format that is understood by the device. Moreover, a processor may respond to a particular message by returning status information or requested information, e.g., by modifying the message record as appropriate. A processor may also be configured to generate new messages, e.g., response messages, which are placed on the message repository and processed in a like manner. Other functions, e.g., updating the database, sending an email, posting data to a web page, interfacing with another system, or practically any other function capable of being performed by a computer, may also be performed by a processor consistent with the invention.
  • Fig. 8 illustrates an exemplary controller 150 and various function calls to a number of processors 152 in response to the reception of a particular type of message.
  • processors A, B and C a controller may be capable of spawning multiple processors that execute concurrently in different threads.
  • controller 150 may also spawn processors sequentially within the same thread.
  • processors E and F not only can a controller spawn a processor, but one processor may spawn one or more additional processors that are executed in the same or different threads, and which may execute sequentially or concurrently in those different threads.
  • the modular architecture by the herein-described communication executive provides substantial flexibility and maximizes the ability to reuse code from generic or pre-existing environments.
  • Fig. 9 next illustrates an exemplary message validation component routine 160 executed by a message validation component consistent with the invention.
  • a message validation component may be dynamically instantiated in response to reception of a message of a particular type and/or destined for a particular receiving device, and preferably before the message is placed on the message repository.
  • the purpose of a message validation component is to perform high-level message validation prior to placement of the message on the repository, so as to minimize the amount of custom high-level processing that must occur via the controllers and processors, and thus limit the degree of customization required in such components.
  • Routine 160 begins in block 162 by reading the message data passed from the COM service.
  • Block 164 analyzes the message data according to business rules that are encoded into the validation component.
  • the message validation component operates generally as a plug-in associated with a message type and/or a particular message receiver, and is configured to analyze, validate, modify or perform whatever tasks are necessary to properly format the message for processing by the communication executive.
  • a message validation component has the capability of accepting a message, modifying a message, or rejecting a message and returning any errors to the calling service.
  • An advantage of message validation is the ability to provide real-time validation of messages so a requester does not need to check back to see if the message was accepted or rejected.
  • Data analysis in block 164 generates a result that indicates whether the message should be accepted, rejected or accepted with changes. As shown in block 166, if the message is to be rejected, control passes to block 168 to return "FALSE" to the COM service, indicating that the message has been rejected. Routine 160 is then complete.
  • message validation can be performed with minimal customization required to the overall communication executive.
  • This modular and extensible approach therefore facilitates incorporating business rules into a communication system with minimal customization.
  • Fig. 10 generally illustrates one exemplary implementation of the data structures maintained within a message repository 180 consistent with the invention. Messages are maintained in message record table 182. Binary and text data are respectively associated with a particular message using the tables shown at 184 and
  • Message records are also associated with particular "systems" via a tableT88lhat ⁇ mamfam ⁇ s ⁇ tfre ⁇ alM ⁇ are stored in a controller table 190 with a mapping record 192 linking a controller to a delegator defined in a delegator record 194.
  • each controller is linked to processors via a table 196, with processors defined by processor records in table 198.
  • Statistical data is maintained in a statistics table 200, with error data maintained in an error table 202, linked to binary and text data in tables 204 and 206.
  • Table 182 is the main queue (the Cube) for all tasks:
  • Table 194 contains all the Delegators and their settings:
  • Table 190 contains all the Controllers and their settings:
  • Table 198 contains all the Processors and their settings:
  • Table 192 links a Delegator with its Controllers:
  • Table 196 links a Controller with its Processor:
  • Table 202 is updated with any errors that occur during the processing of a message:
  • Table 188 includes the valid System ID's and message types:
  • Table 200 includes statistical data:
  • Table 218 includes all long text data for a message:
  • Table 188 includes all binary data for a message:
  • Table 206 includes all long text for an error record:
  • Table 204 includes all binary data for an error record:
  • system ID refers to the type of communication system utilized in the communication executive. As will be appreciated by one of ordinary skill in the art having the benefit of the instant disclosure, multiple systems may be interfaced through the same communication executive. In situations where only a single system is being interfaced in the manner described herein, the system ID-related fields may be omitted from the various tables.
  • message types defined for a particular system will vary from system to system. Message types may be distinguished based upon the type of receiving device, the type of sending device, the type of resource being utilized, the type of transaction (e.g., based upon logical distinctions between activities performed with the system), etc.
  • Message types may be distinguished based upon the type of receiving device, the type of sending device, the type of resource being utilized, the type of transaction (e.g., based upon logical distinctions between activities performed with the system), etc.
  • message repository stored procedures that may be utilized in connection with the above-described data structures are listed below. Such methods are made available by the message repository. In addition, it may be desirable to permit processor components to invoke these methods if data is required from a message, or if data needs to be written to a message.
  • sp_SendMessage Writes a record from the Cube.
  • sp_RemoveMessage Deletes a record from the Cube.
  • sp_PurgeAU Purges all records from the Cube with a given "to name" and message type.
  • sp_UpdateStatus Updates the status of a record to a supplied value.
  • sp_InsertError Inserts an error into the Error Log.
  • sp_AddStatistics Adds a new statistics record to the tblStatistics table.
  • sp_AutoAddStatistics Adds new statistical record for each calendar day. May be executed through a job that runs once every day at 12:00 a.m.
  • sp_U ⁇ dateStatistics Updates statistics from the tblStatistics table.
  • spJUpdateMsgDelegatorlD Updates the Delegator ID field in a Cube record with the ID of the Delegator that is processing the message.
  • sp_UpdateDelegatorStatus Updates the status of a Delegator. Read to determine if a Delegator is free to look for messages in the Cube.
  • sp_Remove01dStatistics Removes statistics from the tblStatistics table that are older than 30 days. This procedure may be scheduled to run automatically each day.
  • spJUpdate Delegator Status Updates the OkToRun field for the Delegator.
  • the COM services may expose the following methods to calling systems to execute.
  • the COM service object may be stateless —that is, all data needed for a method to function may be passed in as parameters, and all variable within the object may be declared as local variables:
  • ReadAUMessages (ToID, MsgType, OUT_Error_Code, OUT_Error_Description, OUT Messages) Returns an XML Stream of Record ID's that are currently in the Cube that match the ToID and MsgType parameters. Returns TRUE if successful or FALSE if unsuccessful. If the method returns FALSE, the Error_Code and Error_Description contain the error code and error message that occurred.
  • the Messages parameter may be an XML stream with the following layout: ⁇ Messages>
  • This XML stream can then be parsed and the ReadMsgData method can be called to obtain individual record information from the Cube.
  • SendMsg (FromID, ToID, MsgType, Priority, OUT_MsgID, OUT_Error_Code, - OUT Error Description, OptionaTMiscl, Optional Misc2, Optional Misc3, Optional Misc4, Optional MiscS, Optional TextDataln, Optional BinaryDataln)
  • the Send method may automatically call the Execute method for the MV component associated with this SystemID and MessageType (if one exists). If the method returns TRUE, then the MsglD will contain the ID of the message from the Cube that can be used in conjunction with the Delete, CheckStatus, and ReadMsgData methods. Regarding the Send method, regardless of whether or not the Delegator for that system has been disabled or closed, the COM Service will still typically enter records into the Cube.
  • the Delete method Removes a message from the Cube based on the RecordlD. Returns TRUE if successful or FALSE if unsuccessful. If the Delete method was unsuccessful, the Error_Code and Error_Description parameters may contain the actual error code and error message that occurred.
  • the Error_Code and Error_Description parameters may contain the actual error code and error message that occurred.
  • ReadMsgData (MsgID, OUT_FromID, OUT_ToID, OUT_MsgType, OUT_Priority, OUTJdiscl, OUT_Misc2, OUT_Misc3, OUTJ4isc4, OUT_Misc5, OUT_TextDataIn, OUTJBinaryDataln, OUT_DelegatorID, OUT_Error_Code, O UT_Error_Description)
  • the Error_Code parameter may contain the error code and the Error_Description parameter may contain the error message.
  • the OkToRun value will be returned in the OUT_DelegatorStatus field. This value may be a Boolean value.
  • OUT_Error_Code and OUT_Error_Description may contain the error number and error description if any error occurs.
  • GenerateErrorRecord (FromID, ToID, MsgType, Priority, MsgID, MsgError_Code, MsgError_Description, ErrorDate, Processor, DelegatorlD, OUT_Error_Code, OUT_Error_Description, Optional Miscl, Optional Misc2, Optional Misc3, Optional Misc4, Optional Misc5, Optional TextDataln, Optional BinaryDataln)
  • the XML may have the following format: ⁇ Processors>
  • the XML may have the following format:
  • ControllerOrder> ⁇ /ControllerOrder> ⁇ /Controllers>
  • the XML may have the following format :
  • GetDelegator Information (DelegatorlD, OUT_DelegatorDescription, OUTjCycleTime, OUT_DelegatorStatus, OUT_Error_Code, O UT_Error_Description)
  • UpdateDelegatorStatus (DelegatorlD, NewStatus, OUT_Error_Code, O UT_Error_Description)
  • UpdateMsgDelegatorStatus (MsgID, DelegatorlD, OUT Error Code, O UT_Error_Description)
  • UpdateMsgStatus (MsgID, NewStatus, OUT_Error_Code, O UT_Error_Description)
  • ProcessedOK may be a Boolean value.
  • the above-described communication executive has a wide variety of uses in various applications, particularly where it is desirable to interconnect electronic devices having different queuing strategies and/or business rules.
  • FIG. 11 illustrates a remote sensing environment 220 that utilizes a central processor 221 including a communication executive 222 that interfaces a plurality of remote sensing stations, or sensors, 224 with a data repository 225 and analysis engine 226. Additional details regarding such a system are described, for example, in the aforementioned related U.S. Provisional Application No. 60/307,348, which is incorporated by reference herein.
  • centralized analysis functionality may be used to permit, for example, independent entities to contract for analysis services to be provided by the central processor, needing only access to an NTR sensor and appropriate networking capabilities.
  • the relatively complex processing required to perform quantitative analysis can be maintained in a central location, thus reducing the complexity and cost of the remote stations.
  • any required customization of remote stations can be minimized.
  • centralized analysis allows for greater control over the models used in the analysis, as well as facilitates updates or improvements to the models since they are typically not distributed to the remote stations.
  • Each remote sensor 224 may include, for example one or more near infrared (NIR) instruments 228 interfaced with a client-side computer, or user interface, 230, e.g., a laptop or other single-user computer.
  • NTR near infrared
  • the NTR instruments 228 are utilized to generate spectral data for a material for the purpose of performing quantitative and/or identification analysis on materials or compositions located at remote locations.
  • the spectral data generated by the remote sensors is then transmitted either in raw or pre-processed form to a central processor including an analysis engine that analyzes the spectral data using chemometrics or other multivariate methods to determine the quantitative properties of a particular material or composition.
  • the analysis engine may also return the processed results to the remote station from which the data was generated.
  • Each remote sensor may utilize, for example, a Matrix-F NTR instrument available from Bruker Optics Inc.
  • a laptop or other web-enabled computer may then be used to provide user input and display capability for communicating with a central web server.
  • a client computer may not be required, e.g., if the instrument itself incorporates suitable networking and display capabilities.
  • Other NIR instruments or sensing systems may be used in the alternative as well.
  • the spectral data (as well as other measurement data such as input data received from an operator) and the processed measurement results may be transmitted via HTML-compatible forms processed by a web server 234, which is interposed between the sensors and the communication executive 222.
  • the web server may incorporate practically any conventional web server technology, e.g., Active Server Page (ASP) services.
  • ASP Active Server Page
  • Analysis engine 226 includes an analysis controller 240 coupled to a model engine 242, which relies on stored models 244 in data repository 225 to apply chemometric analysis to spectral data generated by the remote sensors.
  • An analysis database 246 is also provided in data repository 225 to store the spectral data and processed results. Databases 244 and 246 may be integrated into the same database management system, or may be maintained in separate such systems.
  • Communication executive 222 includes a cube 250 that is accessed via a COM Service 252 instantiation responsive to requests received by web server 234.
  • a delegator 254 operates on messages received by cube 250, resulting in the dynamic instantiation of a controller 256 responsive to an appropriate message.
  • Controller 256 has access to one or more processors 258 functioning as request handlers for the central processor. Each processor 258 is coupled to receive and transmit data from and to analysis database 246, as well as to forward requests in an appropriate format to analysis controller 240.
  • the herein-described system of Fig. 11 provides the capability for near real-time processing and scalability to permit a large number of remote sensors to access centralized models for the purpose of processing spectral data and returning measurement results to the remote sensors. As a result, the local processing required at each remote sensor can be minimized.
  • the communication executive must be capable of handling a large number of requests at a time.
  • the herein-described communication executive provides first-in-first-out queuing, as well as automated message detection to enable near real-time processing.
  • the pipeline-processing framework facilitates extension of the message processing functionality of the communication executive due to the relative ease in which additional components can be added to the process.
  • support for the use of message validation components facilitates pre-processing of all incoming requests from remote sensors.
  • an operator at a remote sensor performs NIR spectroscopy on the material to generate measurement data, e.g., spectral data.
  • An application running on the associated computer for the NTR instrument then transmits the measurement data over the Internet to web server 234. Some preprocessing of the measurement data may also be performed prior to transmission to web server 234.
  • the web server In response to the receipt of a request from a remote sensor, the web server instantiates a COM Service component 252, and invokes a send message function to push the measurement data into the message repository (cube). The COM Service then waits for the status of the message to change. The web server also writes the measurement data to the analysis database at the same time as adding the message to the cube.
  • the delegator associated with that message detects a new message and instantiates an appropriate controller component.
  • the controller component subsequently launches one or more processor components as defined in the configuration tables for the cube.
  • the processor components then read the measurement data from the cube, and forward the data to the analysis engine (and optionally, the analysis database as well) to perform chemometric analysis of the data.
  • the request made by the processor is typically in a format that is native to the analysis engine.
  • the analysis engine performs the desired analysis of the measurement data, and stores the results in analysis database 246.
  • the request in the cube is updated to a "complete" status by the processor, and the web server reads the information from the analysis database based upon a detected "complete” status in the cube. The web server then returns an HTML-compatible web page to the operator, presenting the requested results.
  • System 270 is an example of a manufacturing control system in which a communication executive 272 is utilized to interface a manufacturing automation system 274 (incorporating control devices and/or sensor devices), as well as additional sensors such as an NIR sensor 276, with a manufacturing database 290.
  • the manufacturing automation system 274 may incorporate a manufacturing process automation system such as the DeltaV automation system available from Fisher-Rosemount.
  • Communication executive 272 includes a message repository or cube 276 accessed by one or more instantiations of COM Service 278.
  • a delegator 280 and controller 282 are also shown.
  • a plurality of processors 284, 286 and 288 are illustrated for performing different tasks in response to messages placed on the cube.
  • a manufacturing database 290 is coupled to the processors, as well as to a task assembler 292 and at line processor 294.
  • An analysis controller e.g., as described above in connection with Fig. 11, may also interface with processor 284 for the purpose of interacting with NIR sensor 276, which provides additional feedback for a manufacturing process.
  • the system of Fig. 12 operates as a task-based control system, where tasks are performed in response to an indication that a new task is required by either the task assembler 292 or at line processor 294.
  • Communication with the communication executive is established through the appropriate COM Service 278, which writes a request to the cube 276 as appropriate.
  • the respective task assembler or at line processor then monitors the progress of the message through the COM Service.
  • the delegator that is responsible for that type of message reads the new message from the cube, and instantiates a controller responsible for handling such messages.
  • the controller then updates the status of the message to "in process," and based upon the settings in the database, calls one or more processors 284, 286 and 288 to handle the message as appropriated, passing data as needed.
  • processors 284 and 288 have the ability to communicate with manufacturing database 290 to retrieve appropriate information, as well as write the results to the database.
  • processor 288 may log events to the manufacturing database through its operation as an event log controller.
  • processor 284 may perform the function of an analysis request handler for interfacing with analysis controller 296.
  • Processor 286 may function as a spreadsheet handler, e.g., to perform complex calculations.
  • System 300 is an example of an inventory management system in which a communication executive 302 is utilized to interface one or more inventory measurement sensors 304 with an inventory database 306.
  • Each sensor 304 may be implemented using any device capable of detecting a particular type of inventory (e.g., a fluid level, a particulate level, etc.), coupled with functionality for transmitting the sensed data for collection by the inventory management system.
  • sensors 304 may be grouped as illustrated at 308 into a tier of measurement devices located at supplier sites.
  • Other sensors 304 may be coupled to a data consolidator 310 using third party technology.
  • data generated by the sensors 304 is output over a communications network such as the Internet 312 to an Internet webserver 314, e.g., providing ASP pages suitable for receiving the data in an appropriate format.
  • sensors 304 and/or consolidator 310 may be configured to generate XML data streams, and to post such XML-formatted data to an ASP page resident on the web server.
  • Consolidator 310 may be capable of pooling the data from multiple sensors 304 into a consolidated XML document.
  • some or all of the sensors 304 maybe coupled to ebserver 314 via other communication networks.
  • ebserver 314 may be utilized, whereby webserver 314 may not be utilized.
  • Communication executive 302 includes one or more instantiations of COM Service 320 that submit messages to a message repository or cube 322.
  • a delegator 324 and controller 326 are also shown.
  • one or more processors 328 are dynamically instantiated to perform actions in connection with inventory database 306 in response to messages placed on the cube.
  • the system of Fig. 13 collects inventory data from sensors 304 and forwards the data to database 306.
  • processor 328 or alternatively, other program code, may be configured to track current inventories and, as necessary, notify purchasing personnel and/or automatically order or schedule the delivery of additional inventory.
  • feedback information may be provided to the various sites served by sensors 304.

Landscapes

  • Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Chemical & Material Sciences (AREA)
  • Analytical Chemistry (AREA)
  • Biochemistry (AREA)
  • General Health & Medical Sciences (AREA)
  • General Physics & Mathematics (AREA)
  • Immunology (AREA)
  • Pathology (AREA)
  • Engineering & Computer Science (AREA)
  • Mathematical Physics (AREA)
  • Theoretical Computer Science (AREA)
  • Spectroscopy & Molecular Physics (AREA)
  • Computer And Data Communications (AREA)

Abstract

La présente invention concerne un appareil, un progiciel et un procédé permettant d'incorporer un exécutif de communication modulaire extensible (12) pour intégrer l'utilisation un ou plusieurs dispositifs électroniques (14) entre eux en réduisant les charges indirectes liées à personnalisation. Si on utilise une architecture modulaire, c'est pour favoriser les communications à base de messages de façon que les stratégies de mise en file d'attente, les règles de gestion et analogue trouvent leur place de façon fiable et rentable dans un environnement de communications à base de messages. Grâce à cette architecture modulaire, il est possible de réunie des composants de logiciel spécifiques d'application de façon à adapter rapidement un système à base de messages génériques prévu pour une application spécifique. En outre, la pré-validation intelligente des messages peut être mise en oeuvre dans une telle architecture modulaire de façon à permettre d'adapter rapidement une infrastructure de messagerie indépendante des règles de gestion pour qu'elle soit compatible avec des exigences spécifiques que pose une application particulière en matière de règles de gestion.
PCT/US2002/023247 2001-07-23 2002-07-18 Executif de communication modulaire extensible a file d'attente de messages active et pre-validation intelligente des messages WO2003017111A1 (fr)

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US30734701P 2001-07-23 2001-07-23
US30734801P 2001-07-23 2001-07-23
US60/307,347 2001-07-23
US60/307,348 2001-07-23
US10/188,853 US20030135547A1 (en) 2001-07-23 2002-07-05 Extensible modular communication executive with active message queue and intelligent message pre-validation
US10/188,972 2002-07-05
US10/188,972 US7194369B2 (en) 2001-07-23 2002-07-05 On-site analysis system with central processor and method of analyzing
US10/188,853 2002-07-05

Publications (1)

Publication Number Publication Date
WO2003017111A1 true WO2003017111A1 (fr) 2003-02-27

Family

ID=27497775

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2002/023247 WO2003017111A1 (fr) 2001-07-23 2002-07-18 Executif de communication modulaire extensible a file d'attente de messages active et pre-validation intelligente des messages

Country Status (2)

Country Link
TW (1) TW576986B (fr)
WO (1) WO2003017111A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5183829B1 (ja) * 2012-02-24 2013-04-17 三菱電機株式会社 通信装置及び通信方法及びプログラム

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4888726A (en) * 1987-04-22 1989-12-19 Allen-Bradley Company. Inc. Distributed processing in a cluster of industrial controls linked by a communications network
US5485579A (en) * 1989-09-08 1996-01-16 Auspex Systems, Inc. Multiple facility operating system architecture
US5729544A (en) * 1994-05-09 1998-03-17 Motorola, Inc. Method for transmitting data packets based on message type

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4888726A (en) * 1987-04-22 1989-12-19 Allen-Bradley Company. Inc. Distributed processing in a cluster of industrial controls linked by a communications network
US5485579A (en) * 1989-09-08 1996-01-16 Auspex Systems, Inc. Multiple facility operating system architecture
US5729544A (en) * 1994-05-09 1998-03-17 Motorola, Inc. Method for transmitting data packets based on message type

Also Published As

Publication number Publication date
TW576986B (en) 2004-02-21

Similar Documents

Publication Publication Date Title
US20030135547A1 (en) Extensible modular communication executive with active message queue and intelligent message pre-validation
US10054935B2 (en) Apparatus and method for web-based tool management
WO2019195121A1 (fr) Système de gestion de travailleur numérique
US7242991B2 (en) Workflow control configurator for use with process, factory-floor, environmental, computer aided manufacturing-based or other control system
US7290030B2 (en) Internet object based interface for industrial controller
US7082604B2 (en) Method and apparatus for breaking down computing tasks across a network of heterogeneous computer for parallel execution by utilizing autonomous mobile agents
US8028049B1 (en) Apparatus and method for web-based tool management
US7987254B2 (en) Automation network, remote access server for an automation network and a method for transmitting operating data between an automation system and a remote computer
US20040254945A1 (en) Business process management for a message-based exchange infrastructure
US20040042471A1 (en) System and method for open control and monitoring of biological instruments
JP2003506773A (ja) 自動化検査室用ソフトウエアアーキテクチャ
US7478128B2 (en) Notification management for monitoring system
US6240331B1 (en) Integrated management of semiconductor process data
US20090157864A1 (en) Grid computing control method for testing application program capacity of server and service method thereof
CN109425749A (zh) 用于操作实验室系统的方法
EP1247296A2 (fr) Procede et appareil destines a communiquer des images, des donnees et d'autres informations dans un identificateur d'origine de defaut
US7242995B1 (en) E-manufacturing in semiconductor and microelectronics processes
CN109246219A (zh) 一种IoT数据采集系统的工作方法及系统
WO2007064127A1 (fr) Systeme de calcul distribue pour tester la capacite de programme d'application d'un serveur
WO2003017111A1 (fr) Executif de communication modulaire extensible a file d'attente de messages active et pre-validation intelligente des messages
JP3710534B2 (ja) 工程制御方法
US20040255057A1 (en) Method and apparatus for providing help information in multiple formats
Michaloski et al. Quantifying the performance of MT-Connect in a distributed manufacturing environment
US7299158B2 (en) Process control data collection
Hung et al. Development of an automatic virtual metrology framework for TFT-LCD industry

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG UZ VN YU ZA ZM ZW

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BY BZ CA CH CN CO CR CU CZ DE DM DZ EC EE ES FI GB GD GE GH HR HU ID IL IN IS JP KE KG KP KR LC LK LR LS LT LU LV MA MD MG MN MW MX MZ NO NZ OM PH PL PT RU SD SE SG SI SK SL TJ TM TN TR TZ UA UG UZ VN YU ZA ZM

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ UG ZM ZW AM AZ BY KG KZ RU TJ TM AT BE BG CH CY CZ DK EE ES FI FR GB GR IE IT LU MC PT SE SK TR BF BJ CF CG CI GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP