US20060064503A1 - Data routing systems and methods - Google Patents

Abstract

A data routing system for collecting data from at least one data origin and distributing data to at least one data destination. The data routing system comprises a data input module and a data output module. The data input module operatively connected to the at least one data origin. The data input module is configured to collect data from the at least one data origin. The data output module operatively connected to the data input module and to the at least one data destination. The data collection component is configured to distribute the data collected by the data input module to the at least one data destination.

Description

RELATED APPLICATIONS
• This application claims priority of U.S. Provisional Patent Application Ser. No. 60/506,104, filed Sep. 25, 2003, the contents of which are incorporated herein by reference.
FIELD OF INVENTION
• The present invention relates to computer systems for collecting data from one or more disparate data sources and distributing the collected data to one or more disparate data destinations.
BACKGROUND OF INVENTION
• The present invention is used in the context of collecting and distributing data. The present application uses the term “routing” to refer to the process of both collecting data from data origins and distributing data to data destinations. The terms “data” and “data items” are used herein to refer to numeric, binary, or string data generated in an analog or digital format. Data is typically generated by machines, devices, or the like forming part of a larger working environment. The term “machine” as used herein refers to a physical asset used to perform a predetermined task. The term “device” is typically applied to a machine with a relatively small footprint.
• The data origin or origins thus may be formed by any machine or device (mobile or not) that stores data and which is either directly controlled by humans through a user interface or automatically controlled via a computer based system. However, the present invention is of particular significance in the context of a working environment defined by a motion control system, and that application of the present invention will be described in detail below. The present invention may have broader application to other working environments, however, and the scope of the present invention should be determined by the claims appended hereto and not the following detailed description.
• A motion control system typically comprises a plurality of motion control machines or devices each programmed to perform an individual task. The motion control system is configured to coordinate the individual tasks so that the motion control system itself performs a combined task.
• Each motion control machine or device comprises a controller that generates and/or stores data indicative of the state of the machine or device at a particular point in time. Typically, some or all of this data changes because the state of the machine changes as the machine performs its individual task.
• The data generated and/or stored by the motion control machines and/or devices of a motion control system can be used to optimize the performance of one or more of the individual machines as well as the entire motion control system. The data destinations where the data is sent can thus take any one or more of a number of forms, including a database system, a plant floor process management system, software used to optimize overall production flow, other software systems, and/or another data routing system as described herein.
• The collection and distribution of the data associated with individual motion control machines is, however, complicated by several factors. The sheer volume of data can overwhelm the ability of the data destination to store and/or process the data collected. In addition, the data origins and data destination may employ different, unique, or proprietary hardware and software systems that utilize different data acquisition commands, data formats, and data transmission protocols.
• The need thus exists for data routing systems and methods that simplify the collection of data from diverse data origins and the subsequent distribution of data to diverse data destinations.
SUMMARY OF INVENTION
• The present invention may be embodied as a data routing system or method for collecting data from at least one data origin and distributing data to at least one data destination. The data routing system comprises a data input module and a data output module. The data input module operatively connected to the at least one data origin. The data input module is configured to collect data from the at least one data origin. The data output module operatively connected to the data input module and to the at least one data destination. The data collection component is configured to distribute the data collected by the data input module to the at least one data destination.
DETAILED DESCRIPTION OF THE DRAWINGS
• FIG. 1 is a somewhat schematic block diagram of a data routing system of a first embodiment of the present invention;
• FIG. 2 is a somewhat schematic block diagram of a data routing system of a second embodiment of the present invention, where the data routing system has been optimized for use with a motion control system;
• FIGS. 3-8 are scenario maps depicting the interaction of one or more components of the data routing system ofFIG. 2 in different operational scenarios;
• FIGS. 9-19 are examples of user interface configurations that may be used by the example data routing system ofFIG. 2;
• FIGS. 20 and 21 are highly schematic block diagrams depicting alternate relationships of data inputs, data outputs, and decision logic that may be used by the example data routing systems ofFIGS. 1 and 2.
DETAILED DESCRIPTION OF THE INVENTION
• Referring initially toFIG. 1 of the drawing, depicted therein is adata routing system20 constructed in accordance with, and embodying, the principles of the present invention. Thedata routing system20 is used to route data or data items collected fromdata origins22 to one ormore data destinations24.
• As described above, the terms “data” and “data items” will be used herein to refer to numeric, binary, or string data values collected in an analog or digital format from adata origin22. Examples of data types that represent data or data items as defined herein include ADDRESS, ARRAY, BIT, BYTE, WORD, DWORD, LONG, REAL, DOUBLE, FLOAT, BINARY BLOB, STRUCTURE, STRING, and ASCII STRING.
• Thedata origins22 are machines, devices, or the like forming part of a larger working environment. The working environment is not a part of the present invention and thus will not be described herein beyond what is necessary for a complete understanding of the invention. The terms “machine” as used herein refers to a physical asset used to perform a predetermined task. The term “device” is typically applied to a machine with a relatively small footprint.
• Examples of machines as defined herein include a CNC mill used to shape metal, a pick-n-place machine used to position parts on a circuit board, a robotic machine used to perform surgery, a medical data input device (i.e. blood glucose meter, asthma meter, etc), a gaming device, a robotic toy, an animatronics figure, a robotic machine used to deliver goods to a warehouse or to people, an automobile, a truck or farm vehicle, a boat or ship, an airplane, a jet, a helicopter, a spacecraft, and/or a hardware or software-based control system within a personal computer or even just a personal computer or hand-held computer itself. The data origin or origins thus may be formed by any machine or device (mobile or not) that stores data and which is either directly controlled by humans through a user interface or automatically controlled via a computer based system.
• As shown inFIG. 1, the data collected by thedata routing system20 is delivered to one ormore data destinations24. Thedata destinations24 can take on many forms and serve many functions, but a primary function of thedata destinations24 is to use the data collected from the machines in the working environment to optimize operation of the individual machines and the overall working environment.
• The exampledata routing system20 is a software system that comprises a datainput module group30, an optional datacache module group32, and a dataoutput module group34. The term “module” as used herein refers to a binary block of computer logic that contains functions, objects, components, ActiveX components, .NET source, HTML, XML and/or other computer code that can be executed in real-time or in script form. Several examples of a module include an executable EXE, a dynamic link library DLL, an OLE component or set of components housed within a DLL or EXE, an ActiveX Control, an HTML or XML based Control, a VB script source file, a Java Serverlet, Java Control, Java Object, NET Package, etc.
• The datainput module group30, datacache module group32, and dataoutput module group34 typically run on a processor forming part of a computer system, but may be configured to operate across several discrete processors forming part of one or more computer systems.
• Thedata routing system20 operates basically as follows. The datainput module group30 communicates with one ormore data origins22 to obtain data indicative of a state or condition of the machine or device forming each of thedata origins22. If used, the datacache module group32 temporarily or persistently stores the data collected by the datainput module group30. The dataoutput module group34 determines the conditions under which data collected by the datainput module group30 stored in the datacache module group32 is sent to one or more of thedata destinations24. The dataoutput module group34 optionally also determines the format in which data is sent to thedata destination24 and/or the method of transporting the data to thedata destination24.
• The example datainput module group30 comprises adata collection component40 and one or moredata source components42. The term “component” as used herein refers to a logical organization of computer commands designed to perform an operation or set of operations. Examples of components include OLE components, ActiveX controls, HTML or XML based controls, HTML or XML based objects, .NET objects, C++ objects, C function set, Visual Basic objects, and the like. A component may operate on a single processor or may be distributed across a plurality of processors.
• Thedata collection component40 associates all of the data collected with thedata origins22 from which the data was collected. Thedata collection component40 may be connected directly to one or more of thedata origins22 or may be connected to one or more of thedata origins22 through thedata source components42 as shown. If thedata collection component40 is connected directly to adata origin22, thedata collection component40 and thedata origin22 must be pre-configured to work with each other, and thedata collection component40 is considered data origin independent, whereas thedata source component42 is considered data origin dependent. However, if thedata collection component40 communicates directly with adata origin22, it then becomes data origin dependent.
• Preferably, however, one or moredata source components42 are provided to allow thedata collection component40 to operate in a data origin independent manner. In this case, the exampledata source components42 are each associated with one or more of thedata origins22. Thedata source components42 collect data from aparticular data origin22 or class ofdata origins22 and pass this data to thedata collection component40 in a predetermined format. Thedata source components42 may run entirely on the same processor or processors as thedata routing system20, entirely on a processor or processors associated with thedata origin22, or on processors associated with both thedata routing system20 and thedata origin22. Although optional, the use of thedata source components42 is preferred to isolate thedata collection component40 from the operational details of each of thedata origins22.
• The datainput module group30 may collect data from thedata origins22 by one or more of a number of methods. For example, thedata source components42 and/ordata collection component40 may read register values on the machine or device, read shared memory provided by the machine or device, send commands to the machine or device for which a data response is given containing the data requested, read variables provided by the machine or device, read and write to variables in a sequence necessary to produce data values, query data using a proprietary or standard data protocol, call a function provided by the machine or device, build and send a command based on a protocol used to communicate with the machine or device for which a data response is provided by the machine or device from which the data is extracted, and/or the like.
• The optional datacache module group32 comprises adata store component50 and at least onedata cache52. Thedata collection component40 passes data to thedata store component50; thedata store component50 stores this data in one or more of thedata caches52. Thedata caches52 may be temporary or volatile memory devices such as RAM or may be permanent or persistent memory such as a hard drive or database system. Thedata store component50 further retrieves data from theappropriate data cache52 as necessary. If thedata cache module32 is not used, data collected by thedata collection component40 is passed directly to the dataoutput module group34 in real time.
• Thedata output module34 comprises a data output component60. As mentioned, the data output component60 may receive data directly from thedata collection component40. However, if thedata cache module32 is used, the data output component60 may direct thedata store component50 to read data stored in one or more of thedata caches52 and transfer the stored data to the data output component60.
• The dataoutput module group34 further comprises one or moredata transport components62. Each of thedata transport components62 defines or is associated with a method or system of transporting data from the data output component60 to one or more of thedata destinations24. The data output component60 selects an appropriate one of thedata transport components62 for each data element based on thedata destination24 to which the data element is to be sent.
• Optionally, the dataoutput module group34 further comprises adata formatter component64. Thedata formatter component64 contains logic, templates, or the like for arranging data elements in a format appropriate for one or more of thedata destinations24. Thedata formatter component64 allows thedata destinations24 to be implemented in a machine or device independent manner by obviating the need for thedata destinations24 to process data elements in the format generated by thedata origins22.
• The dataoutput module group34 further optionally comprises aninference engine component66. If used, theinference engine component66 helps the data output component60 to determine the data destination ordestinations24 where each data element is set. Theinference engine component66 may further assist the data output component60 to make the determination of which data is to be output (if any) and/or whichdata transport component62 to use and/or whether thedata formatter component64 is to be used.
• Thedata routing system20 of the present invention thus collects data from one ormore data origins22 and routes this data to one ormore data destinations24. The use of thedata routing system20 allows the data destination ordestinations24 to operate independent of the implementation details of the data origin ororigins22. In addition, thedata routing system20 can be configured to be independent of the data destination through the use of thedata transport components62, anddata formatter components64.
• Turning now toFIGS. 2-21 of the drawing, depicted therein is a data routing system120 of the present invention. The example data routing system120 operates in the same basic manner as thedata routing system20 described above but is optimized to operate in a working environment defined by a motion control system.
• FIG. 2 illustrates that the data routing system120 is a collection of modules or components used to collect machine data from thedata origins122 and then send some or all of the data collected to thedata destinations124. Thedata destinations124 may be either a local data destination (for later replication to a remote data destination) or a remote site (either a remote data routing system or third party data destination).
• Theexample motion system122 as defined in U.S. Pat. No. 5,691,897, but other motion systems may be used instead or in addition. As will be described in further detail below, themotion system122 defines or is associated with one or more application programming interfaces. Themotion system122 is not per se part of the present invention and will not be described herein beyond what is necessary for a complete understanding of the present invention.
• Thedata destinations124 may use the data delivered by thedata routing system20 for a variety of purposes. A primary function of thedata destinations124 is to optimize and/or monitor the operation of the machines and/or devices forming the motion control system that themotion services122 or other software used by thedata sources142 communicate with. Thedata destinations124 can thus take any one or more of a number of forms, including a database system, a plant floor process management system, software used to optimize overall production flow, or other software systems, and/or another data routing system as described herein.
• The example data routing system120 is connected to thedata destination124 through anetwork126. Thenetwork126 is a combination of hardware and software architectures that forms a link between two or more computer systems. Examples of network architectures include a packet based network, a streaming based network, broadcast based network, or peer-to-peer based network. Examples of networks that may be used as thenetwork126 include a TCP/IP network, the Internet, an Intranet, a wireless network using WiFi, a wireless network using radio waves and/or other light based signals, and the like.
• The software components making up the example data routing system120 may be organized into three module groups: a data input.module group130, a datacache module group132, and a dataoutput module group134. The datainput module group130, datacache module group132, and dataoutput module group134 typically run on a processor forming part of a computer system, but may be configured to operate across several discrete processors forming part of one or more computer systems connected by a computer network.
• The datainput module group130 comprises adata collection component140 and a plurality ofdata source components142aand142b. The datacache module group132 comprises adata store component150 and one or more data cache components152. The dataoutput module group134 comprises adata output component160, one or more data transport components162, adata formatter component164, and aninference engine component166.
• Thedata collection component140 is responsible for collecting data from the machine asset and routing all data collected to the datacache module group132. Thedata collection component140 is responsible for managing one or moredata source components142 for which data is collected and route the data collected to the datacache module group132.
• Thedata source components142aand142bcommunicate with themotion system122. Each data source communicates with the motion system using whatever means are available including to the use of application programming interfaces (API)170a,170b, and170cassociated with themotion system122, using (API) provided by a motion system vendor, or using network or other communication protocols. The exampledata source component142ais configured to receive data from the API's170aand170b, while the exampledata source component142bis configured to receive data from theAPI170c.
• The exampledata collection component40 manages one or moredata source components142 and is responsible for routing the data collected to thedata store component150 of thedata cache module132. Optionally, eachdata collection component140 may communicate directly to themotion system122 without the need for an intermediarydata source component142. However, the use of thedata source component142 allows for code reuse as thedata collection component140 may then implement all common functionality, thus making eachdata source component142 extremely thin and easy to build and maintain. In addition, the use of eachdata source components142 allows thedata collection component150 itself to be independent of each data origin with which eachdata source component142 communicates to collect data.
• Eachdata source component142 is responsible for mapping the data collected from the data source (i.e. XMC API, XMC CNC API, OPC Server, or proprietary data source) into the format expected by thedata collection component140 and ultimately thedata store component150. The main goal of thedata source components142 is to provide a consistent interface to thedata origin122, thereby freeing the client from the details of thedata origin122 and allowing all data sourcecomponents142 to act and operate in the same manner from the perspective of thedata collection component140.
• The datacache module group132 caches the data received so that it may later be analyzed or otherwise processed. In particular, thedata store component150 manages one or more data caches152 and is responsible for storing all data received and giving access to all data stored. Optionally, eachdata store component150 could cache all data received directly without the need for an intermediary data cache152. However, the use of the data cache or caches152 allows for code reuse and also allows thedata store component150 to remain independent of any caching technologies used by each data cache component152. Thedata store component150 may then implement all common functionality, thus making eachdata cache module132 also extremely thin and easy to build and maintain.
• The terms “primary data cache” and “secondary data cache” may be used to refer to one or more of the data caches152 depending upon whether certain features of thedata cache module132 are implemented and/or used as will be discussed in detail below. The suffix “a” is used inFIG. 2B to designate a primary data cache, and the suffix “b” is used to designate a secondary data cache.
• Each data cache152 stores data in adata target172 such as a database on a hard drive, RAM memory, or another persistent or volatile storage medium. The main purpose of the data caches152 is to provide a consistent interface to the data storage medium used so that the caches152 appear to be the same to the user, thus freeing the client of any details handling various caching mechanisms.
• The dataoutput module group134 is responsible for sending the data collected by the datainput module group30 and/or stored by the datacache module group32 to thedata destination122. Thedata output component160 manages the other components forming thedata output module34, namely, the data transport components162, thedata formatter component164, and theinference engine component166.
• More specifically, thedata output component160 is responsible for sending data to one ormore data destinations124. As generally described above, the data destination may be an enterprise data management system, an artificial intelligence system, a plant floor process management system, software used to optimize overall production flow, another data routing system such as thesystems20 and120 described herein, and/or other software systems used to optimize and/or monitor how the overall factory operates based on how each machine making up the factory runs.
• Theinference engine component166 is responsible for mapping the data elements received from the datainput module group130 or datacache module group132 through thedata output component160 to thedata destinations124 to which the data elements are to be sent. The data transport component162 defines which data elements are to be sent to whichdata destination124. When performing this mapping, theinference engine component166 also optionally provides a set of rules and/or other criteria that are used to determine whether or not each output defined by the data transport component162 should ‘fire’. For example, theinference engine component166 may use one or more of the following logic systems: artificial intelligence systems, fuzzy logic algorithms, neural network pattern matching, genetic algorithms, expert system logic, and/or other computer based decision-making and/or pattern matching based systems, to determine when a given set of one or more data elements should be sent out. In the simplest case, an identity transform may be used which causes all data inputs received to be sent out as matching data outputs.
• Thedata formatter component164 is used to format all or portions of the data set to be transported to thedata destinations124. For example thedata formatter component164 may be used to format data output by theinference engine component166 into a certain XML schema or other proprietary data format.
• The data transport component162 is responsible for sending the data to theultimate data destination124, including an enterprise database, an enterprise software system, or even another data routing system such as the data routing system120.
• Referring still toFIG. 2, also depicted therein is adata manager180 that allows the user to manage operation of the data routing system120. Thedata manager180 controls access to property pages exposed or generated by user-interface components associated with thecomponents140,150,160,162,164, and166. Property pages may also be exposed or generated by user interface components associated with thecomponents142 and152. In particular, the example data routing system120 comprises datacollector property pages182, datastore property pages184, dataoutput property pages190, datatransport property pages192, data formatterproperty pages194, and inference engine property pages196. As will be described in further detail below, theproperty pages182,184,190,192,194, and196 allow the user to initialize, configure, and control thecomponents140,150,160,162,164, and166, respectively.
• In the following discussion and in the drawings, theproperty pages182,184,190,192,194, and196 also refer to the user-interface components associated with these property pages. The property pages182,184,190,192,194, and196 and other interface elements are separated from thecomponents140,150,160,162,164, and166 in the system120 to optimize the overall system flexibility and facilitate evolution toward new and future user interface technologies such as HTML based web user interface, SOAP/XML based interfaces, Microsoft .NET based interfaces, etc. Optionally, however, thecomponents140,150,160,162,164, and166 could directly expose property pages and other user-interface elements.
• Referring now toFIGS. 3-8, the interactions of the components and property pages forming the datainput module group130, datacache module group132, and dataoutput module group134 will now be described in further detail in the various scenarios required to implement the functions of the example data routing system120.
• Before using the data routing system120, the system must first be initialized. During initialization, all components are started and configured with their initial settings. Initializing the system involves configuring the data routing system120 so that it knows what data to collect, where to collect it from, how to process the data collected and where to send the processed data. Once initialized, the system is ready to begin collecting, storing and processing machine and/or device data.
• The initialization process includes to levels. First, the overall data routing system120 must be configured by connecting one or moredata collection components140 data and one or moredata output components160 to thedata store component150. Once connected, the components making up each of thedata input module130,data output module134, anddata cache module132 groups must next be configured.
• The process of initializing the data routing system120 will now be described with reference toFIG. 3 Initially, thedata manager180 is run to configure the overall system120.
• Thedata manager180 of the data routing system120 next uses the datastore property pages184 paired with thedata store component150. The datastore property pages184 query thedata store component150 for all entries in the dataoutput module group134 category (or optionally queries for each entry directly using the OLE Component Categories) and displays each entry visually in theproperty page184.
• Next, after the user selects which data output module orsystems134 to activate, the list of activedata output components160 associated with the selected data output module orsystems134 is sent back to thedata store component150 so that it may use the active components. Thedata store component150 could optionally query a separate ‘configuration’ component used to select the activedata output modules134 to use later when processing data to be output. Additionally, the activation of eachactive component160 may optionally be activated programmatically instead of by the user.
• During its initialization, thedata store component150 creates an instance of each activateddata output component160 so that thedata store component150 can send data update events to each upon receiving new cache data.
• Similar to the configuration of the dataoutput module group134, the datastore property pages184 query the datainput module group130 for a list of supporteddata collection components140. Optionally, thedata store component150 may query thedata collection components140 of the datainput module group130 and display each thesedata collection components140 visually so that the user can activate allcomponents140 that are appropriate for collecting data.
• Once selected visually by the user, the active list of one or moredata collection components140 is sent to thedata store component150. Optionally, thedata store component150 could query a separate ‘configuration’ component used to select the activedata output modules134 to use later when processing data to be output. Additionally, the activation of each component may optionally be activated programmatically instead of by the user.
• During initialization, thedata store component150 creates an instance of each activedata collection component140.
• Once the main componentsdata store component150,data collection component140, anddata output component160 of thedata output module134 are configured, the user (or configuration program) must configure the components used by each of thesystems140,150, and160. The main configuration task for thedata collection component140 is that of selecting the data source components142 (and the data items supplied by each) from which data is to be collected. The process of configuring the components used by thesystems140,150, and160 will now be described with reference toFIG. 4.
• The following steps take place when configuring thedata collection component140 and related components.
• First, thedata manager180 is used to configure thedata collection component140.
• Second, the datacollector property pages182 are used to configure thedata collection component140. Optionally, all configuration may be done programmatically by another software module.
• Each of the datacollector property pages182 queries the Data Source OLE Category of components to see what data sourcecomponents142 are available. Optionally, thedata collection component140 may be queried for the list of all data sourcecomponents142 available.
• A visual list of available data sourcecomponents142 is next constructed, thus allowing the user to select which data source component orcomponents142 to use when collecting data. Optionally, thedata collection component140 could directly talk to thedata source components142; however such direct communication would reduce code reuse as thedata collection component140 allows eachdata source component142 to be very thin, making thesecomponents142 easy to build and maintain.
• Finally, after the user selects thedata source components142 to use, a list of active data sourcecomponents142 is passed to thedata collection component140, which then creates an instance of each selected component.
• Optionally, eachdata source component142 may use an associated property page (not shown) that allows the user to visually (or software to programmatically) configure and select the data inputs from which data is to be collected by eachdata source component142. Eachdata collector component140 may also define a set of data inputs that the user may configure and select; however this it not optimal as thedata source components142 allow eachdata collector component140 to remain independent of how each data origin actually works; i.e. the data items they provide and how the data for each data item is actually collected.
• Referring now toFIG. 5, the following steps take place when configuring the datacache module group132, which includes thedata store component150 thereof. Configuring thedata store component150 requires the selecting of the data cache152 to use. When caching data there are three main methods that may be employed: (1) cache all data to memory only; (2) cache all data to a persistent storage such as a database, or (3) a mixture where data is initially cached to memory and then ‘rolled-over’ into the persistent store at certain intervals or after a specified amount of data has been collected. All three models are utilized by the datacache module group132 of the data routing system120, where only one method is necessary to build a picture of the overall state of the data origin at a given moment in time.
• In a first step shown inFIG. 5, thedata manager180 of the data routing system120 is used to configure thedata store component150 and associated components using the embedded datastore property page184. As described above, thedata store component150 can be configured to implement all user aspects that it needed to edit and otherwise allow the user interact with the data and configuration managed by the component. However, separating the user interface from the component in a parallel component has several advantages that allow for easily adopting future user-interface based technologies such as HTML, Windows .NET, and thin client. For these reasons the user interface has optionally been separated from the main logic making up thedata store component150. As generally described above, this same design organization is used throughout the entire system120 by all components having an associated property page.
• The datastore property page184 component queries thedata store component150 for the list of data cache components152 that are available and displays the list visually. The list of available components152 may optionally be provided programmatically by a separate component used for configuration. As an additional option, the datastore property page184 may directly query the Cache Category of components in the OLE Component Category.
• From the datastore property page184, the user visually selects the specific data cache components152 to use and the specific caching strategy to employ (single caching or roll-over where data from one cache is rolled over to another cache based on certain criteria such as an interval of time, or a data cache data threshold being met). The selected data cache components152 and strategy selected by the user are transferred to thedata store component150 which then stores the settings.
• Eachdata output component160 and associated components act as a data output ‘pipeline’ where data follows a set of steps that determines what data will be output, what format that data will be output in, and where the data will be sent. Referring now toFIG. 6 of the drawing, depicted therein are the steps that take place when configuring thedata output component160 and its related components.
• First, thedata manager180 is used to configure the various aspects of thedata output component160 and its associated components.
• When configuring thedata output component160, the dataoutput property page190 parallel component acquires the list ofinference engine components166,data formatter components164, and data transport components162 that are available. Once the list of data transport, data formatter, andinference engine components162,164, and166 is acquired, a visual display of the list is created on the dataoutput property page190 so that the user can select one or more of thecomponents162,164, and166 from the list as appropriate for their application.
• To obtain this list of components, the dataoutput property page190 may either query thedata output component160 or directly query the OLE Category for each of the data transport component162,data formatter component164, andinference engine component166. If thedata output component160 is queried for the list of available components in each category, thedata output component160 in turn may then internally query a pre-configured list or the OLE components falling into each respective OLE Category for the data transport component162,data formatter component164, andinference engine component166.
• After the user selects one or more data transport components162, one or more data formattercomponents164, and one or moreinference engine components166, the list of components to activate is sent to thedata output component160, which stores the component information as its active components and then creates an instance of each component.
• Next, each data transport component162 is queried for its list of supported outputs. The list of supported data outputs is then passed to the inference engine component orcomponents166 selected.
• Next, thedata output component160 queries thedata store component150 for its list of supported data items, usually stored in the data cache components152 and previously selected when configuring thedata collection component140. The list of supported input data items is then passed to the inference engine component orcomponents166 selected.
• When the inference engine component orcomponents166 have both the inputs and outputs available, the user may optionally configure rules or other criteria used to determine when each output is ‘fired’ based on the input data received. As examples, one or more of a set of Fuzzy Logic rules, a previously trained Neural Network pattern, a Genetic Algorithm fitness, Expert System logic, or other custom logic may be used to determine when certain outputs are sent through the data output pipeline to the data destination.
• In addition, the data formatter component orcomponents164 may also be configured to output data in data formats supported by eachdata destination124. For example, adata formatter component164 may be used to output data items received in a certain proprietary schema. However, thedata formatter component164 would need to be configured so that it would know how to match the data items received to the proprietary schema. This step in the configuration process would allow the user, or another software program, to make this configuration.
• And finally, the data transport component or components162 would need to be configured so that they could properly send data received to the end data targets that it supported. For example, a data transport component162 configured to use TCP/IP may need to have target TCP/IP addresses configured or TCP/IP ports configured telling thecomponent42 where to send the data.
• Once initialized, the data routing system120 is ready to start collecting data and storing all data collected as previously configured.FIGS. 7A and 7B depict the interactions that take place when collecting data.
• First eachdata source component142 either polls for data or receives previously configured events from its data origination. For example, when using themotion system124 or an OPC server as the data origin, events may be received telling thedata source component142 that new data is available.
• Upon receiving a data update event, thedata source component142 fires an event to its respective parentdata collection component140.
• Upon receiving its event, thedata collection component140 then fires an event to thedata store component150.
• Upon receiving each data update event, thedata store component150 uses the active caching component or components152 to store the data. Optionally, thedata cache module132 may employ a roll-over strategy in which data received is passed to one or moredata cache modules132 after a certain criteria is met such as in interval of time passing or a data caching threshold being met.
• After caching the data, thedata store component150 fires a data update event to any data output component orcomponents160 connected to thedata store system132.
• Upon receiving the data update event, thedata output component160 may optionally query thedata store component150 for more data if needed to gain a full description of the current state of the machines forming themotion system122.
• All data input information is then passed to theinference engine component166 for processing. Upon receiving the data, theinference engine component166 runs its preconfigured rule set against the data set received and produces the output (if any) that is eligible to be sent to thedata destinations124. If theinference engine component166 employs a dynamic model of the data, its internal model may alter itself based on the input data received. For example, aninference engine component166 that uses a neural network may ‘learn’ from the data by changing the neural network's weights based on the data input values received.
• If data is eligible to be output, and adata formafter component164 is used, the output data received from theinference engine component166 is then sent to thedata formatter component164. Upon receiving the data, thedata formatter component164 transforms the data received into the supported output data format and passes the new output data back to thedata output component160.
• The formatted data is then passed to the data transport component or components162 to be transported or sent to thedata destinations124. If adata formatter component164 is not used, the raw data format output from theinference engine component166 is used and passed directly to any active data transport component162. Upon receiving the output data, the active data transport component or components162 send the data to theirrespective data destinations124. For example, a TCP/IP transport would packetize the data into TCP/IP packets and send the data stream to a preconfigured TCP/IP address/port. Alternatively, a wireless transport may broadcast the data out on a pre-configured frequency.
• Referring now toFIG. 8 of the drawing, depicted therein is a relationship among the interface windows and dialogs that form the property pages used to configure the example data routing system120. Thedata manager180 presents to the user a main window220 (FIG. 9) that is used to access thedata property pages182,184,190,192,194, and196 used to configure all settings of thedata collection component140,data store component150, anddata output component160 forming up the system120.
• The examplemain window220 presented by thedata manager180 to configure each of themain components140,150, and160 is shown inFIG. 9. In particular, themain page220 of thedata manager180 acts as a control panel that allows the user to configure and monitor how data flows from eachdata source122 to theeventual data destination124.
• Each of the user interface elements of themain page220 on thedata manager180 will now be described with reference toFIG. 7.
• A “Configure”button222 allows the user to configure the overall system120 by building up the overall data transfer pipeline. This option is only available when running the application as an Administrator on the system.
• A “Start”button224 starts monitoring thedata source components142 and feeds the data received through thesystem220.
• A “Stop”button226 stops monitoring thedata source components142 and shuts down the entire monitoring process.
• A “Monitoring”icon230 visually displays whether or not monitoring is currently enabled.
• A “Close”button232 closes the monitoring application window but does not close the application. Since the application runs as a system tray application, you must exit the application by right clicking on the system tray icon.
• A “Status”window234 visually shows the overall configuration and status of the system including all nodes making up thedata input module130,data store system132, anddata output module134.
• The following sections describe how to build and configure the overall system120 using examples of thevarious property pages182,184,190,192,194, and196.
• Referring initially toFIG. 10, depicted therein is aconfiguration dialog window240 that is associated with thedata manager180. The configuration dialog window allows a user to build the overall data routing system120. The user interface elements making up theconfiguration dialog window240 are as follows.
• An “Add Data Collector . . . ”button24 displays a dialog containing a list of alldata collection components140 available to the system. Once selected, the selecteddata collection components140 are added to the system120. Thedata collection components140 are connected to thedata store component150 so that data events are sent to thedata store component150 each time data items are received by each of thedata collection components140 from their respective various data sourcecomponents142.
• An “Add Data Output . . . ”button244 displays a dialog containing a list of alldata output modules134 available to the system. Once selected, thedata output modules134 are added to the system. Eachdata output module134 manages a data pipeline that may involve inference rules or other decision-making technology that tell when to fire each data output.
• A “Delete”button246 removes a module from the list of components making up the overall data routing system120.
• A “Load” button250 loads the components of a previously saved data routing system120 from a persistent storage medium such as a file or database.
• A “Save”button252 saves the current data routing system120 to a persistent storage medium such as a file or database.
• A “Close”button254 closes the configuration dialog.
• A “Node”control260 contains the current modules making up the data routing system120, includingdata collection components140,data store components150, anddata output components160.
• An “About” property page262 displays information about the currently selected module in the node list.
• A “Settings”property page264 displays a property page corresponding to the currently selected node in the node list. The property page allows the user to configure the settings specific to the node selected.
• Examples of interface elements that may be used to implement theproperty pages182,184,190,192,194, and196, as well as other related property pages, will now be described with reference toFIGS. 11-18. The “Delete”, “Load”, “Save”, and “Close” interface elements depicted inFIGS. 11-18 apply to the “Node” Control on the left part of each figure (not shown) and will not be described in detail below.
• An example of the datacollector property page182 is depicted inFIG. 11 of the drawing. The datacollector property page182 allows a user to configure the components, such as thedata collection components140 and/ordata source components142, of the datainput module group130.
• A “Data Sources” list box270 contains a list of all data sourcecomponents142 available to the system. The list of available data sourcecomponents142 is acquired by either directly enumerating the Data Source OLE Category of components or by querying thedata collection component140 for all data sourcecomponents142 that it ‘knows’ about.
• A “Select”button272 adds the currently selected item in the list ofdata source components142 to the currently selecteddata output module134 in the main node list.
• A “Target Scan Rate”edit field274 allows the user to input a global scan rate that applies to all data sourcecomponents142 that may be controlled using a global scan rate.
• A datasource property page280 is depicted inFIG. 12. The data sourceproperty page280 allows the user to select the data items made available by eachdata source component142. The selected data items are then fed into thedata store component150 and eventually on into the selectedinference engine component166. The following user-interface elements make up the data sourceproperty page280.
• A “Data Items” list box282 contains a list of all data items made available by eachdata source component142. The user must enable the data items that they want to monitor in their system. The list of available data items is acquired by browsing a particulardata source component142.
• A “Scan Rate”edit box284 allows the user to enter the scan rate to use for this specific data source (which may be different from the global scan rate). If no scan rate is entered, the default global scan rate is used when appropriate.
• A datastore property page290 depicted inFIG. 13 is used to configure thedata store component150 by selecting and configuring the data cache or caches152 used and the specific caching strategies for each. The following user-interface elements make up the datastore property page290.
• A “Data Caches” list box292 contains a list of all data caches152 available to the system120. The list of available data caches152 may be acquired either by directly enumerating the data cache OLE Category of components or by querying thedata store component150 for a list of active data caches152.
• A “Select” button294 adds the currently selected item in the “Data Caches”list box290 to the currently selecteddata store component150 in the master node list.
• Referring now toFIG. 14, depicted therein is a datacache property page320 that allows the user to configure the specific caching strategy to be used by each data cache152. The following user interface elements make up the datacache property page320.
• An “Enable data roll-over” check-box322 allows the user to enable/disable data roll-over. When enabled, data placed in a particular data cache152 can roll-over into another, or secondary, data cache152 upon meeting certain criteria specified by other of the user-interface elements forming the datacache property page320.
• An “After reaching cache data threshold of”radio button224, if selected, determines that roll-over occurs when a certain number of bytes are cached in the primary data cache, assuming that data cache roll-over is also enabled bycheck box322. A caching threshold data field324aallows the user to specify the data cache threshold. After reaching the roll-over threshold level, all data currently in theprimary data cache152ais copied to thesecondary data cache152b.
• An “After time interval of”radio button326, when selected determines that roll-over occurs at specifically set time intervals, again assuming that data cache roll-over is enabled bycheck box322. A time interval data field326aallows the user to specify the duration of the time interval. Upon the expiration of each time interval all data in theprimary data cache152ais automatically copied over to thesecondary data cache152band then removed from theprimary cache152a.
• A “Roll-over to” list-box328 contains a list of data caches that can be used assecondary caches152b. Theprimary cache152arolls data over to thesecondary cache152bselected by pressing a “Select” button328a.
• Referring now toFIG. 15, the dataoutput property page190 is depicted therein in further detail. The dataoutput property page190 is used to configure thedata output module134 by selecting the data transport components162,data formatter component164, andinference engine component166 that are to make up the data output pipeline. The following user-interface elements make up the dataoutput property page190.
• An “Interface Engines” list-box330 contains a list of all inference engine component orcomponents166 that are available to the system120. A first “Select”button330a allows one or more of theinference engine components166 to be selected. As generally described above, eachinference engine component166 is responsible for mapping input values to output values and determining when each data element should actually be sent to thedata destination124.
• A “Data Formatters” list-box332 contains a list of all data formattercomponents164 that are available to the system120. A second “Select”button 332a allows one or more of the data formattercomponents164 to be selected. Eachdata formatter component164 is responsible for transforming data input into another data format that is output as output data.
• A “Data Transports” list-box334 contains a list of all data transport components162 that are available to the system120. A third “Select” button 334a allows one or more of the data transport components162 to be selected. Each data transport component162 is responsible for sending the data received to theultimate data destination124, such as an enterprise database, analysis system, another data routing system, or the like.
• The inferenceengine property page196 will now be described in further detail with reference toFIG. 16. The inferenceengine property page196 is used to configure the settings defining how theinference engine component166 actually works. Theinference engine component166 maps inputs received to expected outputs defined by the data transport component162. When mapping inputs to outputs, theinference engine component166 optionally uses decision logic to determine whether or not each output should fire (i.e. be sent on to one or more data transport component162) based on the inputs received. The user interface elements making up the inferenceengine property page196 are as follows.
• An “Input Data Items” list-box340 contains a list of all data inputs received from thedata input module130 via thedata store component150. An “Output Data Items” list-box342 contains a list of all data outputs received from thedata output module134 via the data transport component162. A “Rule Map” list-box344 contains a list of rules that define how to map the received data inputs to the outputs.
• In this sampleinference engine component166, the user drags items from the Input DataItems list box340 into the inputs making up the rule-map as listed in the RuleMap list box344. The rule-map associated with each of the items in the Input DataItems list box344 defines when to fire output to each defined output.
• An example dataformatter property page194 is depicted inFIG. 17. The data formatterproperty page194 allows the user to configure how the final data output is actually formatted. For example, theexample property page194 depicted inFIG. 17 illustrate how to map data outputs into an XML schema. The following user interface elements make up the data formatterproperty page194.
• An “XML Schema Map”350 control contains an editable XML Schema that allows a user to drag an output data item into different portions of the schema essentially ‘linking’ the data item to that portion of the XML schema. When linked, the final XML data file is built by using the XML schema and then placing data from each output data item into the slots where they are linked into the XML schema.
• An “Output Data Items List” list-box352 contains a list of all data outputs available as defined by thedata output module134 via the data transport component or components162.
• Depicted inFIG. 18 is an example of a datatransport property page192. The datatransport property page192 allows the user to configure the specific settings of each data transport component162 used to communicate with the data destination ordestinations124. Theexample property page192 depicted inFIG. 18 is an example property page for a data transport component162 that communicates across a TCP/IP based (wire-based or wireless) network. The data transport property page employs the following user interface elements.
• A “Target TCP/IP Address”360 edit field allows the user to enter the target TCP/IP address of the machine or machines forming destinations where data is to be sent.
• A “Target TCP/IP Port”edit field362 allows the user to specify a set of one or more TCP/IP ports to use on the target TCP/IP address.
• A “Use UDB Broadcasting”radio button364 directs the transport to broadcast the output data using the UDP broadcasting protocol and ignore the target TCP/IP address as data will be sent to all machines formingdata destinations124 on thenetwork126.
• A “Use Peer-to-Peer Messaging”radio button366 directs the transport to use a peer-to-peer messaging protocol such as the one used with Windows Instant Messenger, where data is sent immediately to the target machine forming thedata destination124 and may optionally be displayed in an Instant Messenger viewing application such as Windows Messenger.
• A “Use Data Streaming”radio button368 directs the transport to use a data streaming technology where the data outputs are streamed to the target(s) in a manner similar to that of a streaming music or video source. Optionally, the data outputs may also be interleaved into an existing music, video, or other data streaming data source.
• A “Use Virtual Private Networking Tunneling”radio button370 directs the transport to use a tunneling technology, where the data packets making up the output data are embedded within another packet type, optionally encrypted and secured, and then sent to the target over another protocol such as HTTP, or in this case the PPTP or L2TP protocol. SOAP or XML messaging is another manner of tunneling where the data is placed within a SOAP or XML ‘envelope’ and then sent over to the output target using the SOAP or other XML messaging protocol.
• A “Use SMTP E-Mail Format”radio button372 directs the transport to package the output data sets into an e-mail format and sends it to the target. Further configuration may be required to actually setup a specific e-mail address for the recipient.
• A “Use SNMP Format”radio button374 directs the transport to use the SNMP transport to communicate with the output target.
• An “Enable Data Encryption” check-box380 enables data encryption such that the data is encrypted before transmission. A “Use Kerberos Security” check-box382 enables Kerberos security. A “Use 128 bit Encryption” check-box384 enables 128-bit encryption for the output data packets.
• An “Enable Transmission Timeout” check-box386 enables transmission time-out on each communication with the target. When enabled, the sender only waits for an amount of time specified in adata field386afor a response from thedata destination124, after which response data received from the target is ignored.
• The example data routing system120 is a modular system made up of a set of components as generally described above. In this case, each component is based on a component technology, such as OLE/COM technology defined by Microsoft Corporation.
• Optionally, each component uses a separate ‘parallel’ ActiveX component to implement all user interface aspects of the main component, also as generally described above. Each ActiveX component may be implemented either within the main component module or separately in its own module. Bundling each object within one module is not required as they may be located at any location (i.e. across a network, and so forth), but doing so may optimize all communication between modules. How and where components are implemented is more of a logistical decision because, once components are built and deployed to the field, it is difficult to update a single component if all components are implemented within a single DLL or EXE module.
• FIG. 19 illustrates that the components forming the data routing system conform to a single interface identified as the IXMCDirect interface. OLE Categories are used to determine how many components fall into a certain group of components. Components used by the example data routing system120 fall into the following categories:
• Data Input Components—Typically, this category includes a single data collector component, but multiple data input components may be used in a large distributed environment.
• Data Source Components—Many data source components are often used at the same time.
• Data Output Components—Many data output components are often used at the same time, with each data output component defining at least part of a data output pipeline.
• Inference Components—One or more inference engine components are used by each data output component.
• Data Formatter Components—One or more data formatter component components are typically used by each data output module.
• Data Transport Components—One or more data transport components are typically used by each data output module.
• The IXMCDirect interface depicted inFIG. 19 is used for most communications between components of the data routing system120. The IXMCDirect interface is made up of the following functions, which are specified in standard OLE/COM IDL format.
• A GetProperty method is used to query a specific property from the component implementing the interface.
• A SetProperty method is used to set a specific property from the component implementing the interface.
• An InvokeMethod method is used to invoke a specific action on the component implementing the interface. An action can cause an event to occur, carry out a certain operation, query a value, and/or set a value within the component implementing the method.
• More detailed descriptions of each of the methods implemented by objects implementing the example IXMCDirect interface are described below.
• The IXMCDirect::GetProperty method is used to query the property corresponding to the property name ‘pszPropName’. Each component defines the properties that it supports. The following table summarizes the GetProperty method implemented by the example IXMCDirect interface:

  Syntax	HRESULT GetProperty( LPCTSTR pszPropName,
  	LPXMC_PARAM_DATA rgData,
  	DWORD dwCount );
  Parameters	LPCTSTR pszPropName - string name of the property to query.
  	LPXMC_PARAM_DATA rgData - array of XMC_PARAM_DATA
  	types that specify each parameter corresponding to the property.
  	For example, a certain property may be made up of a number of
  	elements - in this case an array of XMC_PARAM_DATA items is
  	returned, one for each element making up the property. In most
  	cases a property is made up of a single element, thus a single
  	element array is passed to this method. For more information on
  	the XMC_PARAM_DATA type, see below.
  	DWORD dwCount - number of XMC_PARAM_DATA elements in the rgData array.
  Return Value	HRESULT - NOERROR on success, or error code on failure.

• The IXMCDirect::SetProperty method is used to set a property in the component corresponding to the ‘pszPropName’ property. For the set of properties supported by the component, see the specific component description. The following table summarizes the SetProperty method implemented by the example IXMCDirect interface:

  Syntax	HRESULT SetProperty( LPCTSTR pszPropName,
  	LPXMC_PARAM_DATA rgData,
  	DWORD dwCount );
  Parameters	LPCTSTR pszPropName - string name of the property to set.
  	LPXMC_PARAM_DATA rgData - array of XMC_PARAM_DATA
  	types that specify each parameter corresponding to the
  	property. For example, a certain property may be made up of a
  	number of elements - in this case an array of
  	XMC_PARAM_DATA items is returned, one for each element
  	making up the property. In most cases a property is made up
  	of a single element, thus a single element array is passed to
  	this method. For more information on the
  	XMC_PARAM_DATA type, see below.
  	DWORD dwCount - number of XMC_PARAM_DATA elements in the rgData
  	array.
  Return Value	HRESULT - NOERROR on success, or error code on failure.

• The IXMCDirect::InvokeMethod method is used to call a specific method implemented by the component. For more information on the methods supported, see the description of the specific component. The following table summarizes the InvokeMethod method implemented by the example IXMCDirect interface:

  Syntax	HRESULT InvokeMethod( DWORD dwMethodIdx,
  	LPXMC_PARAM_DATA rgData,
  	DWORD dwCount );
  Parameters	DWORD dwMethodIdx - number corresponding to the specific
  	method to invoke. For more information on the method indexes
  	available, see the set of namespaces defined for the component.
  	LPXMC_PARAM_DATA rgData [optional] - array of
  	XMC_PARAM_DATA types that specify each parameter for the
  	method called. For more information on the XMC_PARAM_DATA
  	type, see below.
  	NOTE: if no parameters exist for the method called, a value of
  	NULL must be passed in.
  	DWORD dwCount [optional] - number of XMC_PARAM_DATA
  	elements in the rgData array.
  	NOTE: if no parameters exist for the method called, a value of 0
  	(zero) must be passed in for this parameter.
  	LPXMC_PARAM_DATA rgData [optional] - namespace associated with the
  	instance of the custom extension module added.
  Return Value	HRESULT - NOERROR on success, or error code on failure.

• This methods supported by each component making up the system120 will now be described. Initially, the general methods supported by the majority of the components forming the system120 will be first be described; the methods supported by each individual component will then be discussed.
• The XMC_DE_BROWSE_GET_COUNT general method returns the number of data items in the browse set supported by the component and is described in the following table.

  Index	8020
  Data In	None
  Data Out	rgData[0] - (number) DWORD, number of browse elements.

• The XMC_DE_BROWSE_GET_ITEMS general method returns the number of data items in the browse set supported by the component and is described in the following table:

  Index	8021
  Data In	rgData[0] - (number) DWORD, maximum number of
  	elements to collect.
  Data Out	rgData[0] - (number) number of elements collected, total
  	number of elements will equal (rgData[0] * 2 + 1).
  	rgData[1] - (string) name of the first browse element.
  	rgData[2] - (number) adt of the first browse element.
  	rgData[1 + n * 2] - (string) name of the n'th browse element.
  	rgData[2 + n * 2] - (number) adt of the n'th browse element.

• The XMC_DE_SYSTEM_CONNECT_CMPNT general method is used to connect one server to another so that they may interact with one another and is described in the following table:

  Index	8000
  Data In	rgData[0] - (number) DWORD, type of component. The type
  	of component is a value that is server specific. For
  	component type information, see the description for this
  	method under each server's description.
  	rgData[1] - (string) LPTSTR, component class id as an ASCII
  	string.
  Data Out	None.

• The XMC_DE_SYSTEM_DISCONNECT_CMPNT general method is used to disconnect one server from another so that they stop interacting with one another and is described in the following table:

  Index	8001
  Data In	rgData[0] - (number) DWORD, type of component. The type
  	of component is a value that is server specific. For
  	component type information, see the description for this
  	method under each server's description.
  	rgData[1] - (string) LPTSTR, component class id as an ASCII
  	string.
  Data Out	None.

• The XMC_DE_DATA_PROCESS general method is called by a client to process data where a data set is input, processed in some way by the server, and then the resulting data is returned as output. The XMC_DE_DATA_PROCESS method is described in the following table:

  Index	8063
  Data In	rgData[0] - (number) DWORD, number of data
  	items input.
  	rgData[1 + n * 2] - (string) LPCTSTR, name of the data
  	item input.
  	rgData[2 + n * 2] - (number or string), value of the data item.
  Data Out	rgData[0] - (number) DWORD, number of data items output.
  	rgData[1 + n * 2] - (string) LPCTSTR, name of the data item
  	output.
  	rgData[2 + n * 2] - (number) value of the data item.

• The XMC_DE_DATA_PROCESS_CONFIGURE general method is used to configure what type of data is returned when processing a given data item. For example in the server may be configured to return the minimal amount of data on each read (i.e. just the data item value), or the server may be requested to return more substantial data. The XMC_DE_DATA_PROCESS_CONFIGURE method is described in the following table:

  Index	8062
  Data In	rgData[0] - (number) DWORD, flag describing the type of
  	data to be returned when processing data. The following
  	flags are supported:
  	XMC_DE_READ_DATA_FLAG_TIMESTAMP -
  	requests that the time stamp recorded when processing the
  	data is returned.
  	NOTE: by default, the data item value is always returned.
  Data Out	None.

• The XMC_DE_DATA_READ general method is called by a client application to poll for data from the server and is defined in the following table:

  Index	8061
  Data In	rgData[0] - (string) LPCTSTR, name of the data item to read.
  Data Out	rgData[0] - (number or string), data item value.
  	rgData[1] - (OPTIONAL number) DWORD, data item
  	time-stamp as a system time value.
  	NOTE: Since the last items are optional, only those items
  	specified when configuring the data to receive are
  	actually sent.

• The XMC_DE_DATA_READ_CONFIGURE general method is used to configure what type of data is returned when reading a given data item. For example, the server may be configured to return the minimal amount of data on each read (i.e. just the data item value) or the server may be requested to return more substantial data. The following table defines the XMC_DE_DATA_READ_CONFIGURE method:

  Index	8060
  Data	rgData[0] - (number) DWORD, flag describing the type of data to
  In	be returned on each read. The following flags are supported:
  	XMC_DE_READ_DATA_FLAG_TIMESTAMP - requests
  	that the time stamp recorded when reading the data is returned.
  	NOTE: by default, the data item value is always returned.
  Data	None.
  Out

• The XMC_DE_DATA_WRITE general method is used to write data to a server and is described in the following table:

  Index	8064
  Data In	rgData[0] - (number) DWORD, number of data items.
  	rgData[1 + n * 2] - (string) LPCTSTR, name of the data item.
  	rgData[2 + n * 2] - (number or string), value of the data item.
  Data Out	None.

• The XMC_DE_EVENT_ENABLE general method enables/disables a previously subscribed data item in the subscription list maintained by the server. Only enabled subscriptions actually fire. The XMC_DE_EVENT_ENABLE method is defined in the following table:

  Index	2892
  Data	rgData[0] - (number) DWORD, cookie (unique identifier)
  In	associated with the subscription. This value is returned to the
  	client when calling the subscription XMCAPI above.
  	NOTE: using a cookie value of zero (0) will enable/disable ALL
  	items subscribed to the server.
  	rgData[1] - (number) BOOL, TRUE to enable the subscription(s),
  	FALSE to disable the subscription(s). Only enabled subscriptions
  	actually fire events.
  Data	None.
  Out

• This XMC_DE_EVENT_RECEIVE_DATA general method is called by the server (and implemented by the client) when each subscribed event fires and is described in the following table:

  Index	8045
  Data	rgData[0] - (number) DWORD, subscription cookie corresponding
  In	to the subscribed data item.
  	rgData[1] - (number or string), data item value.
  	rgData[2] - (OPTIONAL number) DWORD, data item time-stamp
  	as a system time value.
  	rgData[3] - (OPTIONAL string) LPSTR, data item ASCII text
  	name.
  	rgData[4] - (OPTIONAL number) DWORD, data item unique
  	cookie.
  	NOTE: Since the last three items are optional, only those items
  	specified when configuring the data to receive are actually sent. If,
  	for example, one or more data items are NOT requested, then the
  	items are returned in slots shifted up toward rgData[1]. For
  	example if only the data item name is requested in addition to the
  	default data items, the data returned would look like the following:
  	rgData[0] - (number) DWORD, subscription cookie.
  	rgData[1] - (number or string), data item value.
  	rgData[2] - (string) LPSTR, data item name.
  Data	None.
  Out

• The XMC_DE_EVENT_RECEIVE_DATA_CONFIGURE general method is used to configure what type of data is returned on each event that is fired. For example in the server may be configured to send the minimal amount of data on each event (i.e. subscription cookie and data item value), or the server may be requested to return more substantial data. The XMC_DE_EVENT_RECEIVE_DATA_CONFIGURE method is defined in the following table:

  Index	8044
  Data	rgData[0] - (number) DWORD, flag describing the type of data to
  In	be returned on each event. The following flags are supported:
  	XMC_DE_EVENT_DATA_FLAG_TIMESTAMP - requests
  	that the time stamp recorded when reading the data is returned.
  	XMC_DE_EVENT_DATA_FLAG_NAME - requests that
  	the data items ASCII text name be returned.
  	XMC_DE_EVENT_DATA_FLAG_DATA_COOKIE -
  	requests that the unique data item cookie corresponding to the
  	read made for the data item be returned.
  	NOTE: by default, the subscription cookie and data item value are
  	always returned.
  Data	None.
  Out

• The XMC_DE_EVENT_SUBSCRIBE general method subscribes to a given data item activating the event interface when the subscription criteria are met for the data item. All subscribing components use the IXMCDirect interface to receive events received from the server for which they are subscribed. The XMC_DE_EVENT_SUBSCRIBE method is described in the following table:

  Index	2890
  Data	rgData[0] - (number) DWORD, flags describing the initial state of
  In	the subscription. The following flags are supported:
  	XMC_DE_EVENT_FLAG_ENABLED - subscription is
  	immediately enabled upon subscription.
  	XMC_DE_EVENT_FLAG_DISABLED - subscription is
  	disabled upon making the subscription. The Enable function must
  	be called to enable the subscription.
  	rgData[1] - (number) DWORD, number of subscription criteria
  	rules.
  	rgData[2 + (2 * n)] - (number) DWORD, event condition type
  	where the following types are supported:
  	XMC_CNC_EVENTCONDITION_DATA_CHANGE - any
  	data changes in the data type above will trigger the event.
  	XMC_CNC_EVENTCONDITION_DATA_EQUAL
  	XMC_CNC_EVENTCONDITION_DATA_LESSTHAN
  	XMC_CNC_EVENTCONDITION_DATA_GREATERTHAN
  	XMC_CNC_EVENTCONDITION_DATA_AND
  	XMC_CNC_EVENTCONDITION_DATA_OR
  	Each of the conditions above are used in a combined manner.
  	Where the logical condition (=, <, >) are applied for each type
  	respectively.
  	For example, in an array that contains the following items:
  	rgData[2] = 4 (4 condition values)
  	rgData[3] = XMC_CNC_EVENTCONDITION_EQUAL
  	rgData[4] = 3.0
  	rgData[5] = XMC_CNC_EVENTCONDITION_LESSTHAN
  	rgData[6] = 3.0
  	rgData[7] = XMC_CNC_EVENTCONDITION_OR
  	rgData[8] = 1.0
  	rgData[9] =
  	XMC_CNC_EVENTCONDITION_GREATHERTHAN
  	rgData[10] = 5.0
  	the array would be evaluated using the following logic:
  	If (DATA <= 3.0 OR DATA >5.0) then Trigger Event
  	rgData[3 + (2 * n)] - (number) double, the value for the condition.
  	See above.
  Data	rgData[0] - (number) DWORD, cookie (unique identifier)
  Out	representing the subscription.

• The XMC_DE_EVENT_UNSUBSCRIBE general method removes a previously subscribed data item from the subscription list maintained by the

  Index	2891
  Data In	rgData[0] - (number) DWORD, cookie (unique identifier)
  	associated with the subscription. This value is returned to the
  	client when calling the subscription XMCAPI above.
  	NOTE: using a cookie value of zero (0) will unsubscribe ALL
  	items subscribed to the server.
  Data Out	None.

• The XMC_DE_SYSTEM_INITIALIZEHW general method is used to initialize any hardware systems associated with the component and is defined in the following table:

  	Index	500
  	Data In	None.
  	Data Out	None.

• The XMC_DE_SYSTEM_SHUTDOWNHW general method is used to shutdown any hardware systems associated with the component and is defined by the following table:

  	Index	501
  	Data	None.
  	In
  	Data	None.
  	Out

• The following discussion will define which of the general methods implemented are implemented by particular components of the system120.
• Thedata collection component140 implements the general methods described above as indicated in the following table:

  		Not
  Method	Implemented	Implemented
  XMC_DE_BROWSE_GET_COUNT	x
  XMC_DE_BROWSE_GET_ITEMS	x
  XMC_DE_DATA_PROCESS		x
  XMC_DE_DATA_PROCESS_CONFIGURE		x
  XMC_DE_DATA_READ	x
  XMC_DE_DATA_READ_CONFIGURE	x
  XMC_DE_DATA_WRITE		x
  XMC_DE_EVENT_ENABLE	x
  XMC_DE_EVENT_RECEIVE_DATA	x
  XMC_DE_EVENT_RECEIVE_DATA_CONFIGURE	x
  XMC_DE_EVENT_SUBSCRIBE	x
  XMC_DE_EVENT_UNSUBSCRIBE	x
  XMC_DE_SYSTEM_CONNECT_CMPNT	x
  XMC_DE_SYSTEM_DISCONNECT_CMPNT	x
  XMC_DE_SYSTEM_INITIALIZEHW		x
  XMC_DE_SYSTEM_SHUTDOWNHW		x

• The following special notes apply to some of the general methods implemented by thedata collection component140.
• The following component types are valid for the XMC_DE_SYSTEM_CONNECT_CMPNT method as implemented by thedata collection component140; the XMC_DE_CMPNT_TYPE_XMCDSRC, which specifies adata source component142.
• The following component types are valid for the XMC_DE_SYSTEM_DISCONNECT_CMPNT method as implemented by thedata collection component140; XMC_DE_CMPNT_TYPE_XMCDSRC, which specifies andata source component142.
• Thedata source component142 implements the general methods described above as indicated in the following table:

  		Not
  	Im-	Im-
  	ple-	ple-
  	ment-	ment-
  Method	ed	ed
  XMC_DE_BROWSE_GET_COUNT	x
  XMC_DE_BROWSE_GET_ITEMS	x
  XMC_DE_DATA_PROCESS		x
  XMC_DE_DATA_PROCESS_CONFIGURE		x
  XMC_DE_DATA_READ	x
  XMC_DE_DATA_READ_CONFIGURE	x
  XMC_DE_DATA_WRITE		x
  XMC_DE_EVENT_ENABLE	x
  XMC_DE_EVENT_RECEIVE_DATA	x
  XMC_DE_EVENT_RECEIVE_DATA_CONFIGURE	x
  XMC_DE_EVENT_SUBSCRIBE	x
  XMC_DE_EVENT_UNSUBSCRIBE	x
  XMC_DE_SYSTEM_CONNECT_CMPNT		x
  XMC_DE_SYSTEM_DISCONNECT_CMPNT		x
  XMC_DE_SYSTEM_INITIALIZEHW	x
  XMC_DE_SYSTEM_SHUTDOWNHW	x

• There are no special notes for the methods implemented by thedata source components142.
• Thedata store component150 implements the general methods described above as indicated in the following table:

  		Not
  	Im-	Im-
  	ple-	ple-
  	ment-	ment-
  Method	ed	ed
  XMC_DE_BROWSE_GET_COUNT	x
  XMC_DE_BROWSE_GET_ITEMS	x
  XMC_DE_DATA_PROCESS		x
  XMC_DE_DATA_PROCESS_CONFIGURE		x
  XMC_DE_DATA_READ	x
  XMC_DE_DATA_READ_CONFIGURE	x
  XMC_DE_DATA_WRITE		x
  XMC_DE_EVENT_ENABLE	x
  XMC_DE_EVENT_RECEIVE_DATA	x
  XMC_DE_EVENT_RECEIVE_DATA_CONFIGURE	x
  XMC_DE_EVENT_SUBSCRIBE	x
  XMC_DE_EVENT_UNSUBSCRIBE	x
  XMC_DE_SYSTEM_CONNECT_CMPNT	x
  XMC_DE_SYSTEM_DISCONNECT_CMPNT	x
  XMC_DE_SYSTEM_INITIALIZEHW		x
  XMC_DE_SYSTEM_SHUTDOWNHW		x

• The following special notes apply to each of the general methods implemented by thedata store component150.
• The following component types are valid for the XMC_DE_SYSTEM_CONNECT_CMPNT method on the data store component150:
• XMC_DE_CMPNT_TYPE_XMCDCACHE, which specifies a data cache152;
• XMC_DE_CMPNT_TYPE_XMCDC, which specifies adata collection component140 that is connected with events; and
• XMC_DE_CMPNT_TYPE_XMCDO, which specifies a data transport component162 that is connected with events.
• The following component types are valid for the XMC_DE_SYSTEM_DISCONNECT_CMPNT method as implemented by the data store component150:
• XMC_DE_CMPNT_TYPE_XMCDCACHE, which specifies a data cache152;
• XMC_DE_CMPNT_TYPE_XMCDC, which specifies adata collection component140 that is connected with events; and
• XMC_DE_CMPNT_TYPE_XMCDO, which specifies an XMCdata output module134 that is connected with events.
• Thedata store component150 implements the general methods described above as indicated in the following table:

  		Not
  	Im-	Im-
  	ple-	ple-
  	ment-	ment-
  Method	ed	ed
  XMC_DE_BROWSE_GET_COUNT	x
  XMC_DE_BROWSE_GET_ITEMS	x
  XMC_DE_DATA_PROCESS		x
  XMC_DE_DATA_PROCESS_CONFIGURE		x
  XMC_DE_DATA_READ	x
  XMC_DE_DATA_READ_CONFIGURE	x
  XMC_DE_DATA_WRITE	x
  XMC_DE_EVENT_ENABLE	x
  XMC_DE_EVENT_RECEIVE_DATA	x
  XMC_DE_EVENT_RECEIVE_DATA_CONFIGURE	x
  XMC_DE_EVENT_SUBSCRIBE	x
  XMC_DE_EVENT_UNSUBSCRIBE	x
  XMC_DE_SYSTEM_CONNECT_CMPNT		x
  XMC_DE_SYSTEM_DISCONNECT_CMPNT		x
  XMC_DE_SYSTEM_INITIALIZEHW		x
  XMC_DE_SYSTEM_SHUTDOWNHW		x

• There are no special notes for the methods implemented by thedata store component150.
• Thedata output component160 implements the general methods described above as indicated in the following table:

  		Not
  	Im-	Im-
  	ple-	ple-
  	ment-	ment-
  Method	ed	ed
  XMC_DE_BROWSE_GET_COUNT	x
  XMC_DE_BROWSE_GET_ITEMS	x
  XMC_DE_DATA_PROCESS		x
  XMC_DE_DATA_PROCESS_CONFIGURE		x
  XMC_DE_DATA_READ	x
  XMC_DE_DATA_READ_CONFIGURE	x
  XMC_DE_DATA_WRITE		x
  XMC_DE_EVENT_ENABLE	x
  XMC_DE_EVENT_RECEIVE_DATA	x
  XMC_DE_EVENT_RECEIVE_DATA_CONFIGURE	x
  XMC_DE_EVENT_SUBSCRIBE	x
  XMC_DE_EVENT_UNSUBSCRIBE	x
  XMC_DE_SYSTEM_CONNECT_CMPNT	x
  XMC_DE_SYSTEM_DISCONNECT_CMPNT	x
  XMC_DE_SYSTEM_INITIALIZEHW		x
  XMC_DE_SYSTEM_SHUTDOWNHW		x

• The following special notes methods apply to the general methods as implemented by thedata output component160.
• The following component types are valid for the XMC_DE_SYSTEM_CONNECT_CMPNT as implemented by the data output component160:
• XMC_DE_CMPNT_TYPE_XMCINFERENCE, which specifies aninference engine component166;
• XMC_DE_CMPNT_TYPE_XMCDFORMAT, which specifies adata formatter component164; and
• XMC_DE_CMPNT_TYPE_XMCDTRANSPORT, which specifies a data transport component162.
• The following component types are valid for the XMC_DE_SYSTEM_DISCONNECT_CMPNT as implemented by the data output component160:
• XMC_DE_CMPNT_TYPE_XMCINFERENCE, which specifies aninference engine component166.
• XMC_DE_CMPNT_TYPE_XMCDFORMAT, which specifies andata formatter component164.
• XMC_DE_CMPNT_TYPE_XMCDTRANSPORT, which specifies an data transport component162.
• Theinference engine component166 implements the general methods described above as indicated in the following table:

  		Not
  	Im-	Im-
  	ple-	ple-
  	ment-	ment-
  Method	ed	ed
  XMC_DE_BROWSE_GET_COUNT	x
  XMC_DE_BROWSE_GET_ITEMS	x
  XMC_DE_DATA_PROCESS	x
  XMC_DE_DATA_PROCESS_CONFIGURE	x
  XMC_DE_DATA_READ		x
  XMC_DE_DATA_READ_CONFIGURE		x
  XMC_DE_DATA_WRITE	x
  XMC_DE_EVENT_ENABLE		x
  XMC_DE_EVENT_RECEIVE_DATA		x
  XMC_DE_EVENT_RECEIVE_DATA_CONFIGURE		x
  XMC_DE_EVENT_SUBSCRIBE		x
  XMC_DE_EVENT_UNSUBSCRIBE		x
  XMC_DE_SYSTEM_CONNECT_CMPNT		x
  XMC_DE_SYSTEM_DISCONNECT_CMPNT		x
  XMC_DE_SYSTEM_INITIALIZEHW		x
  XMC_DE_SYSTEM_SHUTDOWNHW		x

• There are no special notes for the methods implemented by theinference engine component166.
• Thedata formatter component164 implements the general methods described above as indicated in the following table:

  		Not
  	Im-	Im-
  	ple-	ple-
  	ment-	ment-
  Method	ed	ed
  XMC_DE_BROWSE_GET_COUNT	x
  XMC_DE_BROWSE_GET_ITEMS	x
  XMC_DE_DATA_PROCESS	x
  XMC_DE_DATA_PROCESS_CONFIGURE	x
  XMC_DE_DATA_READ		x
  XMC_DE_DATA_READ_CONFIGURE		x
  XMC_DE_DATA_WRITE	x
  XMC_DE_EVENT_ENABLE		x
  XMC_DE_EVENT_RECEIVE_DATA		x
  XMC_DE_EVENT_RECEIVE_DATA_CONFIGURE		x
  XMC_DE_EVENT_SUBSCRIBE		x
  XMC_DE_EVENT_UNSUBSCRIBE		x
  XMC_DE_SYSTEM_CONNECT_CMPNT		x
  XMC_DE_SYSTEM_DISCONNECT_CMPNT		x
  XMC_DE_SYSTEM_INITIALIZEHW		x
  XMC_DE_SYSTEM_SHUTDOWNHW		x

• There are no special notes for the methods implemented by thedata formatter component164.
• The data transport component162 implements the general methods described above as indicated in the following table:

  		Not
  	Im-	Im-
  	ple-	ple-
  	ment-	ment-
  Method	ed	ed
  XMC_DE_BROWSE_GET_COUNT	x
  XMC_DE_BROWSE_GET_ITEMS	x
  XMC_DE_DATA_PROCESS		x
  XMC_DE_DATA_PROCESS_CONFIGURE		x
  XMC_DE_DATA_READ		x
  XMC_DE_DATA_READ_CONFIGURE		x
  XMC_DE_DATA_WRITE	x
  XMC_DE_EVENT_ENABLE		x
  XMC_DE_EVENT_RECEIVE_DATA		x
  XMC_DE_EVENT_RECEIVE_DATA_CONFIGURE		x
  XMC_DE_EVENT_SUBSCRIBE		x
  XMC_DE_EVENT_UNSUBSCRIBE		x
  XMC_DE_SYSTEM_CONNECT_CMPNT		x
  XMC_DE_SYSTEM_DISCONNECT_CMPNT		x
  XMC_DE_SYSTEM_INITIALIZEHW		x
  XMC_DE_SYSTEM_SHUTDOWNHW		x

• There are no special notes for the methods implemented by the data transport component162.
• All methods exposed by each component in the example data routing system120 use a standard parameter set to describe data used to set and query properties as well as to invoke methods. The standard parameters are in the following format:
• pObj->InvokeMethod(LPXMC_PARAM_DATA rgData, DWORD dwcount);
• Each element in the rgData array corresponds to a parameter, with the first element in the array corresponding to the first parameter.
• The XMC_PARAM_DATA structure can contain either a numerical or a string value and is defined as follows:

  	typedef struct tagXMC_PARAM_DATA
  	{
  	LNG_PARAM_DATATYPE adt;
  	union
  	{
  	double df;
  	LPTSTR psz;
  	};
  	}XMC_PARAM_DATA;

• The ‘adf’ member of the XMC_PARAM_DATA structure describes the data contained within the XMC_PARAM_DATA structure. The values are described below:

  LNG_PARAM_DATATYPE	Description
  LNG_ADT_NUMBER	Use this value when passing a numerical value via
  	the ‘adt’ member of the XMC_PARAM_DATA
  	structure.
  LNG_ADT_STAT_STRING	Use this value when passing a static string value via
  	the ‘psz’ member of the XMC_PARAM_DATA
  	structure. Static strings do not need to be freed from
  	memory.
  LNG_ADT_MEM_STRING	Use this value when passing a string value via the
  	‘psz’ member of the XMC_PARAM_DATA structure.
  	LNG_ADT_MEM_STRING denotes that the string
  	must be freed from memory during cleanup.
  LNG_ADT_NOP	This value is used to ignore items within the
  	XMC_PARAM_DATA array. When specifies, this
  	parameter is not used.

• When querying and setting boolean TRUE/FALSE values, any non-zero value is considered TRUE, whereas a zero value is considered FALSE.
• As described herein, the data routing system120 is designed to collect data from one ormore data origins122, perform some decision logic on the data collected, and then send the data to one ormore data destinations124 based on the outcome of the decision logic run on the data inputs.
• For example, data inputs may be data items describing the current state of a machine tool, automobile or other machine as shown inFIG. 20. The decision logic would then use these data inputs to determine the overall health or efficiency of the machine. Data outputs would be used to describe the machine's health or efficiency. This model thus operates as a data ‘router’, where data is routed from one or more input to one or more output based on the decision logic run on the inputs. Typically this model is used to ‘cook-down’ a wide array of data inputs that are very detailed in nature, to a more general set of data outputs that describe the overall performance, state or behavior of the machine.
• However, this overall model can easily run in the reverse where the data input and output roles are reversed. In such an example, as generally shown inFIG. 21 the inputs are general in nature and then decision logic is used to determine the specific detailed outputs necessary to carry out a given behavior or action or to enter a given state.
• For example using the latter model, a general input to a machine tool may be something like ‘mill a pocket’ at a certain point. The decision logic in turn would then figure out all of the necessary tools, feedrate, spindlerate and moves necessary to create the pocket on the part. Once determined, the decision logic would ‘output’ the values as a set of detailed output values such as the specific feedrate, the specific spindlerate and the move profile to use. Each output would then be sent directly to the machine controller hardware that actually ran the servo algorithms to move the tool and cut the part.
• In another example, general inputs may be used to direct the path for which a car, airplane, ship or other mobile machine moved to a given destination. For example, a general set of instructions would make up the inputs such as follow road ‘x’ to intersection ‘y’, turn left at intersection ‘y’, drive to house ‘b’. The decision logic in this example would then be used to determine how to drive along road ‘x’ (making sure to track the right hand side of the road by following the yellow or white lines painted on the road), decision logic would determine when the intersection sought had been reached, how to negotiate the turn and drive to house ‘b’. When making each of these decisions the decision logic system would more than likely require additional, more detailed input from sensor systems. Each output could then take a more detailed form such as the speed that the car or other mobile should drive, and the steering adjustments needed to track and follow the desired path on the selected road.
• One of ordinary skill in the art will recognize that he present invention may be embodied in forms other than those described above. The scope of the invention should be determined by the following claims and not the foregoing detailed description of the example embodiments.

Claims (22)

1. A data routing system for collecting data from at least one data origin and distributing data to at least one data destination, comprising:

a data input module operatively connected to the at least one data origin, where the data input module is configured to collect data from the at least one data origin; and

a data output module operatively connected to the data input module and to the at least one data destination, where the data collection component is configured to distribute the data collected by the data input module to the at least one data destination.

2. A data routing system as recited inclaim 1, in which:

the data collected by the data input module is distributed to a plurality of data destinations; and

the data output module comprises decision logic that determines how data collected by the data input module is distributed to the plurality of data destinations.

3. A data routing system as recited inclaim 2, in which the decision logic determines:

what data is distributed to which of the plurality of data destinations;

the format of the data to be distributed to each of the plurality of data destinations; and

the method of transporting data to each of the plurality of data destinations.

4. A data routing system as recited inclaim 1, in which the data output module comprises:

an inference engine component for determining how data is distributed to the at least one data destination; and

a data output component for receiving data from the data input module and distributing the data to the at least one data destination based on the determination made by the inference engine.

5. A data routing system as recited inclaim 2, in which the data output module comprises:

an inference engine component for determining how data is distributed to the plurality of data destinations; and

a data output component for receiving data from the data input module and distributing the data to the plurality of data destinations based on the determination made by the inference engine.

6. A data routing system as recited inclaim 5, in which the inference engine maps data to one or more of the data destinations based on logic rules.

7. A data routing system as recited inclaim 6, in which the logic rules determine:

what data is distributed to which of the plurality of data destinations;

the format of the data to be distributed to each of the plurality of data destinations; and

the method of transporting data to each of the plurality of data destinations.

8. A data routing system as recited inclaim 5, in which the inference engine component comprises at least one computer logic system selected from the group of computer logic systems consisting of artificial intelligence systems, fuzzy logic algorithm systems, neural network pattern matching systems, genetic algorithm systems, expert logic systems, and pattern matching systems.

9. A data routing system as recited inclaim 5, in which the data output module further comprises at least one data transport component for transporting data to at least one of the data destinations.

10. A data routing system as recited inclaim 5, in which the data output module further comprises at least one data formafter component for formatting data distributed to at least one of the data destinations.

11. A data routing system as recited inclaim 1, in which the data input module comprises:

at least one data source component associated with at least one data origin; and

a data collection component for controlling the at least one data source to collected data from the at least one data origin associated therewith.

12. A data routing system as recited inclaim 1, further comprising a data cache module for storing data collected by the data input module, where data stored by the data cache module is accessible by the output data module.

13. A data routing system as recited inclaim 1, in which the data cache module comprises:

at least one data cache component associated with a data storage system; and

a data store component for receiving data from the data input module, storing the data in the data storage system associated with the at least one data cache component, retrieving data from the data storage system associated with the at least one data cache component, and delivering data to the data output module.

14. A data routing system as recited inclaim 2, in which decision logic further determines how data requests generated by the data destinations are distributed to the plurality of data origins.

15. A method of routing data collected from a plurality of data origins to a plurality of data destinations, comprising the steps of:

collecting data from the plurality of data origins;

determining how the collected data is to be distributed to the plurality of data destinations based on decision logic; and

distributing the collected data to the plurality of data destinations.

16. A data routing method as recited inclaim 15, in which the decision logic determines:

what data is distributed to which of the plurality of data destinations;

the format of the data to be distributed to each of the plurality of data destinations; and

the method of transporting data to each of the plurality of data destinations.

17. A data routing method as recited inclaim 15, in which the decision logic maps collected data to one or more of the data destinations based on logic rules.

18. A data routing method as recited inclaim 15, further comprising the step of transporting the collected data to at least one of the data destinations based on the decision logic.

19. A data routing method as recited inclaim 15, further comprising the step of formatting the collected data as appropriate for at least one of the data destinations based on the decision logic.

20. A data routing method as recited inclaim 15, further comprising the steps of:

providing at least one data source component associated with at least one data origin; and

controlling the at least one data source to collect data from the at least one data origin associated therewith.

21. A data routing method as recited inclaim 15, further comprising the step of storing collected data before the collected data is distributed to the plurality of data destinations.

22. A data routing system for collecting data from a plurality of data origins and distributing data to a plurality of data destinations, comprising:

a data input module operatively connected to the at least one data origin, where the data input module comprises

at least one data source component associated with at least one data origin, and

a data collection component for controlling the at least one data source to collected data from the at least one data origin associated therewith;

a data cache module for storing data collected by the data input module, where the data cache module comprises

at least one data cache component associated with a data storage system, and

a data store component for receiving data from the data input module, storing the data in the data storage system associated with the at least one data cache component, retrieving data from the data storage system associated with the at least one data cache component, and delivering data to the data output module; and

a data output module operatively connected to the data input module and to the at least one data destination, where data output module comprises

an inference engine component for determining how data is distributed to the at least one data destination, and

a data output component for receiving data from the data input module and distributing the data to the at least one data destination based on the determination made by the inference engine,

at least one data transport component for controlling the transportation of data to at least one of the data destinations,

at least one data formatter component for formatting data distributed to at least one of the data destinations.

Images