Patent Grant
7725200
The claimed subject matter relates generally to industrial control systems and more particularly to module class components that are defined to facilitate validated software use and detect pertinent configuration changes that affect the validation.
One type of industrial control process is referred to as a batch process, which involves subjecting raw materials to processing steps using one or more pieces of equipment to produce a “batch” of product. Efforts to automate batch processing have led to the formation of standards committees by members of industries involved in batch processing and suppliers of batch processing equipment, among others. The general purpose of these standards committees has been to define uniform standards for automated batch processing. One such standard has been promulgated by the International Society for Measurement and Control, an international organization concerned with issues of process control. This standard is entitled Batch Control Part 1: Models and Terminology and is often referred to as the ISA S88.01-1995 standard (or “S88” for purposes of this application).
The S88.01 standard defines models of equipment and procedures for use in automated batch processes, as well as terminology for use in referring to those models and their elements. The S88.01 standard defines a “batch process” as a process that leads to the production of finite quantities of material by subjecting quantities of input materials to an ordered set of processing activities over a finite period of time using one or more pieces of equipment. A “batch” is defined as the material that is being produced or has been produced by a single execution of a batch process.
Batch-processing equipment (i.e., controllable elements such as valves, heaters, mixers, and so forth) is operated according to procedures to produce a batch. Generally, such equipment is referred to synonymously as equipment, equipment modules, processing equipment, or physical elements. The procedures to operate such physical elements are often referred to by the S88.01 standard as the “procedural model.” According to the S88.01 standard, the procedural model is structured as a hierarchical ranking of procedures, with the highest level encompassing each of the lower levels, the next highest level encompassing each of the levels below it, and so on. Typically, the levels of the S88.01 procedural model of a particular application are, in descending order: the “procedure;” the “unit procedure;” the “operation;” and the “phase.”
The term “procedural element” generally refers to components that employ any of the levels of the S88.01 procedural model, not just to those of the “procedure” level or any other single level of the procedural model. The highest-level procedural element of interest is referred to as a procedure, which is made up of one or more unit procedures. Each unit procedure is in turn made up of one or more operations, which are each in turn made up of one or more phases. The S88.01 procedural model does not preclude definition and use of other hierarchical levels, nor does it require that each level be present in particular applications. Rather, the standard is intended to provide a broad, standardized model for describing the procedures followed in automated batch-process control.
Heavily regulated industries such as pharmaceuticals often have Federal Validation requirements to ensure that products are manufactured to desired standards. Validation is a very expensive proposition during installation to properly document and show that the system indeed meets the applicable standards. Once a system has been validated, any changes made to the system can cause the entire system to be re-validated if it is not clear how the change may have impacted the system.
The following presents a simplified summary in order to provide a basic understanding of some aspects described herein. This summary is not an extensive overview nor is intended to identify key/critical elements or to delineate the scope of the various aspects described herein. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.
The invention relates to automatic monitoring of a system for configuration or other changes. Such monitoring can be performed at a modular level, where comparisons are made between the validated system and the present system. If a change is detected within the system, automated notifications can be sent and reports can be generated identifying the impact to the system. The reports can mitigate re-validation requirements for the changed system. Configuration data can be segmented into data which is aligned with specific roles in a production facility. By storing an authorized copy of the configuration, and comparing to the current configuration over time, the system is able to inform the user of configuration changes.
To the accomplishment of the foregoing and related ends, certain illustrative aspects are described herein in connection with the following description and the annexed drawings. These aspects are indicative of various ways which can be practiced, all of which are intended to be covered herein. Other advantages and novel features may become apparent from the following detailed description when considered in conjunction with the drawings.
An automation control system can be efficiently developed and maintained as a hierarchical arrangement of configured components that pass process control parameters received from a control component and return reports back to the control component. In particular, control components compare a current configuration to a validated, saved configuration in order to report a configuration status as to whether a process can be conducted as validated. Yet, changes to the configuration of the automation control system that do not affect a validated portion do not preclude continued validated processing, avoiding expense and delay of re-validation.
These features are enhanced as being part of a programming environment of module class subsets in which portions of a given module that were previously coded by hand have been identified and generated automatically for the designer in view of an identified class. The identified class represents an analysis of functional elements within the module that can be generically provided before system design/implementation. For example, Equipment or Phase Modules (or other type modules) can be decomposed into sub components and classes, thus allowing commonality between equipment modules and other points of a module's extension to be identified. This allows building a limited number of equipment modules from the respective classes to address the large (virtually infinite) number of process or discrete applications. Example Equipment Modules provided include Generic, Material Transfer, and Equipment Verification. Respective Equipment Modules can communicate with associated Phase Modules which have also been developed according to a class structure. By identifying common portions of modules and codifying the respective portions in advance, code generation and development for the common portions identified is mitigated which in turn conserves resources for system designers and end users.
It is noted that as used in this application, terms such as “component,” “module,” “model,” and the like are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution as applied to an automation system for industrial control. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program and a computer. By way of illustration, both an application running on a server and the server can be components. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers, industrial controllers, and/or modules communicating therewith.
Referring initially to
Detection provides opportunities for mitigation without necessitating full re-validation of the system 12. For example, should the automation control system 10 include an unconfigured component 36 that is not utilized as part of the validated processing system 12, the unconfigured component 36 can be ignored without reporting. In addition, should a configured component 20 have been modified by a changed parameter, then the validated saved configuration data structure 28 can be readily restored before proceeding. If the changed configuration pertains to a change in code, then configured component 20 can be instantiated with a validated version. If the changed configuration pertains to a hardware change, then simplified revalidation procedures may be appropriate, such as confirming that the new equipment has been unit tested to return the automation control system 10 to a validated status or that a certified replacement has been installed.
It should be appreciated with the benefit of the present disclosure that the monitoring may be distributed. Configuration changes can be detected by the same component or detected by a higher level component monitoring subservient components. Moreover, the configuration data structure may include identification of functions that are disabled to retain a validated state (e.g., preventing parameter changes via a human-machine interface (HMI)).
In
In
In general, the phase components 108 send control commands to the module components 102 and receive status there from. As will be described in more detail below with respect to
Generally, module class subsets include portions of a given module or phase that were previously coded by hand and have been identified and generated automatically for the designer in view of an identified class. The identified class represents an analysis of functional elements within the module or phase that can be generically provided before system design/implementation. For example, Equipment or Phase Modules (or other type modules) can be decomposed into sub components and classes, thus allowing commonality between equipment modules and other points of a module's extension to be identified. This allows building a limited number of equipment modules from the respective classes to address the substantially large number of process or discrete actions.
A limited number of equipment modules and equipment phases may be used with minimal customization to satisfy the majority of process action requirements although it is to be appreciated that other modules can be added to the subset. Behavior can be a determining factor in the classification of Equipment Modules, for example.
The module components 102 or phase components 108 can be an association of logic with one or more resources. The logic includes program code that can alter the state of a resource for example, ladder code, function chart, script, JAVA, C code, and so forth. The resources are those components or elements that perform an activity in a system including equipment and personnel that perform work in a system. Other examples of types of resources include Equipment, Material, Personnel, Segments and Storage. Personnel and equipment (machines) can perform activities in a system. Resources that can perform work can be classified as active resources (e.g., CNC machine, Injection molding machine), whereas other equipment resources can be considered passive resources (e.g., sensor, material). In general, the modules hide the user from internal interfaces, messages, and logic specific to the resources yet provide standard or generic interfaces to external systems or between components.
Modules may include other modules including nested modules where standard module behaviors and attribute patterns can be represented using common data model representations for module classes, module templates and module inheritance. Module classes and templates can be maintained in libraries which facilitate access to desired system functionality and further promote system integration. Resources can have various states associated therewith such as common S88 state classifications including idle, hold, abort, run, reset, stop, restart, and so forth where the module can present logic to represent state machines that manage the state of the resource. During application, resource modules (described below) can take on the name of the resource that is the primary focus on the module. For example, an Equipment module is primarily focused on coordination of equipment but may involve personnel in the process. Similarly, a Personnel module is focused on coordination of personnel but may involve other resources in the process. A Control Module that manages a material may be referred to as a Material Control Module and so forth.
It is noted that components associated with the system 100 can include various computer or network components such as servers, clients, programmable logic controllers (PLCs), communications modules, mobile computers, wireless components, control components and so forth which are capable of interacting across a network. Similarly, the term PLC as used herein can include functionality that can be shared across multiple components, systems, and/or networks. For example, one or more PLCs can communicate and cooperate with various network devices across the network. This can include substantially any type of control, communications module, computer, I/O device, sensor, Human Machine Interface (HMI) that communicate via the network which includes control, automation, and/or public networks. The PLC can also communicate to and control various other devices such as Input/Output modules including Analog, Digital, Programmed/Intelligent I/O modules, other programmable controllers, communications modules, sensors, output devices, and the like.
The network can include public networks such as the Internet, Intranets, and automation networks such as Control and Information Protocol (CIP) networks including DeviceNet and ControlNet. Other networks include Ethernet, DH/DH+, Remote I/O, Fieldbus, Modbus, Profibus, wireless networks, serial protocols, and so forth. In addition, the network devices can include various possibilities (hardware and/or software components). These include components such as switches with virtual local area network (VLAN) capability, LANs, WANs, proxies, gateways, routers, firewalls, virtual private network (VPN) devices, servers, clients, computers, configuration tools, monitoring tools, and/or other devices.
Referring now to
Referring now to
At 220, a Unit interface provides a linkage to/from a respective Unit such as described in a typical S88/S95 procedure. This interface 220 determines how the EM 200 interacts with the Unit. A standard Unit interface 220 may be created that applies to all Equipment Module classes. Equipment Modules 200 should be aware of their Unit, where the propagation of mode and faults may be facilitated via the Unit interface 220.
An Equipment interface 230 provides a linkage to/from Equipment (Subordinate EM's and control modules (CM's)). This interface 230 determines how the EM 200 interacts with Equipment. A standard equipment interface can be created that applies to the Equipment Module classes.
At 240, coordination control, and sequencing of equipment refers to the logic associated with commanding the state of subordinate Equipment/Control modules. Generally, coordination and sequencing is facilitated via the Equipment Interface 210. Coordination and Sequencing may be achieved using a number of different methods, such as via hard coded logic or sequencer. The method is generally not considered part of the Equipment Module. Typically, coordination and sequencing is implementation dependant, and should not be used to determine the definition of class(es).
At 250, behavior describes the functional behavior of a particular Equipment Module 200. A number of the behaviors 250 exhibited by an Equipment Module 200 are common to Equipment Modules. Some equipment modules 200 may exhibit unique behavior. For instance, a Material Transfer may require the ability to restart in addition to under tolerance. Some differences in behavior 250 may be masked on/off using configuration commands. Generally, behavior 250 is a determining factor in establishing the definition of Equipment Module class(es).
At 260, parameters (e.g., process parameters) are data items which are provided by the recipe phase, via the Equipment Phase to the Equipment Module 200. Report (process results) data items at 260 are produced by the Equipment Module 200, and published to the Recipe Phase via the Equipment Phase interface at 210. Generally, equipment modules 200 inherit recipe parameters from Equipment Phases, and process these parameters. Equipment modules 200 produce report data at 260 and provide this data to the Equipment Phase via the interface 210. A standardized data structure may be created for parameter data within the Equipment Module 200. The Equipment Module 200 can also provide the capability to customize this data structure. A standardized data structure may be created for report data within the Equipment Module 200 which can also provide the capability to customize this data structure. Depending on the number of unique data sets required for report/parameters, the processing and production of this data may be a determining factor in the definition of Equipment Module class(es). As shown at 270, other class components in the equipment module 200 can include mode data, permissive data, and command/status data that can be passed to/from the respective interfaces associated with the equipment module.
Configuration commands that change the Behavior 250 are reflected in the class components 270 (e.g., mode, permissives, and command/status) and thus can be compared to a saved validated configuration data structure (validated configuration) 275 for a self determination of a changed configuration, warranting a notification via the report/parameters component 260. The validated configuration 275 may also capture such data for components linked to the unit or equipment interfaces 220, 230. The monitoring of other components can compensate for legacy devices not capable of self-monitoring for configuration changes.
Turning to
A phase interface 310 provides a linkage to/from a respective Recipe Phase (not shown) to control a process. This interface 310 determines how the EP 300 interacts with the Recipe Phase. A standard Phase interface may be created that applies to all Equipment Phase classes, which supports the S88 state model, or subset of the S88 state model, for example. The phase interface should also provide a component to pass report/parameter data.
At 320, an Equipment Module interface provides a linkage to/from the respective Equipment Module such as depicted in
At 330, parameters (process parameters) are data items which are provided by the recipe phase, to the Equipment Phase 300. The Equipment Phase 300 then provides this data to the Equipment Module. Report (process results) data items are produced by the Equipment Module, and published to the Equipment Phase 300. The Equipment Phase then provides this data to the Equipment Phase. Generally, Equipment modules inherit recipe parameters from Equipment Phases. Such modules also produce report data and provide this data to the Equipment Phase 300. Depending on the number of unique data sets required for report/parameters 330, the processing and production of this data may be a determining factor in the definition of Equipment Module class(es).
At 340, behavior describes the functional behavior of a particular Equipment Module. Generally, the Equipment Phase 300 should support the S88 state model, a subset of the S88 state model, or similar models. Typically, all Equipment Phases exhibit similar behavior. Differences in behavior may be masked on/off using configuration. Behavior 340 is generally not a determining factor in establishing the definition of Equipment Module class(es) described above. As shown, one or more S88 states may be controlled at 350.
In
In
The highest level of the control architecture, such as the process cell 414, may set the mode. As an example, modes may include Auto, Semi-Auto and Manual. Based on configuration information modules at a lower level in the hierarchy may inherit this mode from the module above. The validated configuration, for instance, may require an Auto mode be inherited by the rest of the architecture, or other modes based on configuration information.
An example of a control module 402 is a Two State Valve Control Module used to operate and monitor a standard mechanical valve used in production facilities. This type of valve opens and closes based on commands issued by this module. The control module also monitors feedback from the valve, if present, to indicate whether it is open or closed. This device functions via the control system in auto and manual mode. Commands are provided to allow auto and manual mode control for the device. A separate set of Open/Close commands exist for each mode. Auto commands are only issued by controller logic, and manual commands are only issued from the HMI. Violation of this operation will result in a fault of the device. By modifying a control module instance's configuration data, the behavior of a particular module instance can be modified. An example of this would be changing a valve from type “Normally Open” to type “Normally Closed” via the Reverse Acting configuration bit. Once all device configurations are considered valid, an individual of appropriate authorization level may save the current settings. If the control module's configuration settings ever deviate from the saved setting, an indication will appear on the HMI faceplate. An authorized individual will then have the opportunity to save the current configurations or restore the previously saved configuration.
An illustrative data structure for tracking the configuration pertinent to an control module 402 is provided in Table 1.
An illustrative data structure for tracking the configuration pertinent to an equipment module 404 is provided in Table 2. An Equipment Module—General as defined by S88 is the following: An equipment module is a functional group of equipment that can carry out a finite number of specific minor processing activities. An equipment module is typically centered around a piece of process equipment (e.g., a weigh tank, a process heater, a scrubber, etc.). This term applies to both the physical equipment and the equipment entity. Examples of minor process activities are dosing and weighing. By modifying an Equipment Module—General instance's configuration data, the behavior of a particular module instance can be modified. Once all module configurations are considered valid, an individual of appropriate authorization level may save the current settings. If the Equipment Module—General configuration settings ever deviate from the saved setting, an indication will appear on the HMI faceplate. An authorized individual will then have the opportunity to save the current configurations or restore the previously saved configuration.
An illustrative data structure for tracking the configuration pertinent to an unit module 412 is provided in Table 3. A Unit is an element of the physical model within the ISA S88.01 standard. As an example each vessel, tank, mixer, machine, etc. . . . within the control system would be considered a Unit. A Unit module is based in a Programmable Logic Controller. Within S88 hierarchy the Unit exists above the Equipment Modules and Control Modules. The Unit is responsible for managing the equipment that is associated to that unit. These responsibilities include, but are not limited to, the following: Mode propagation; Fault propagation; Vessel Management; Batch Campaign Management.
In order to avoid unauthorized changes to the configuration that would defeat validation or create other problems, degrees of security codes are incorporated into the various layers of the hierarchy. In particular, a high degree of clearance is required to save a configuration.
Referring now to
Returning to
Referring now to
Attributes presented below are represented associations from the module to objects which may be internal in a common data model or elsewhere (e.g., CAD Files). At 820, standard public interfaces can be provided. These interfaces 820 publish verbs 824 that are available to external systems and are documented activities that hide the complexity of the underlying code used to implement the interface. Interfaces 820 can be considered into at least two common usage scenarios. For example, interfaces 820 can be used as access points that can be used to hook in real time diagnostics, security and so forth.
Public verbs 824 initiate an action within the module. The activity is described to clients of the interface 820. The implementation is considered private and is not presented to clients—for example, Open, Stop, Abort, Shut, and so forth. A data value property 810 provides public access to information that is used by the module during its operation and can be provided by request values and/or internal values (or an equivalent). The association of logic to transfer request values to internal values and vice versa are referred to as get and set logic for the value. It is noted that in a controller, if there is not a set routine to transfer request values to internal values, the internal value can overwrite the request value on the next scan providing read only capability.
In general, the properties 810 can be considered in at least two classifications. States have special significance for production systems and can have a specific set of values that can be represented by range or enumeration. A state can represent the current status of the primary resource being encapsulated by the module e.g., Percent open, Mode, Service (in, out), and so forth. Information that is used by the module during its operation includes access to data that is provided by interfaces 820. e.g., Conversion Map, Name, Description, expiry date, personnel contact information. Some properties 810 can be common to all instances of resource modules (e.g., scanned copy of resource specification documents), whereas other properties 810 are specific to each module instance (e.g., Status, percent open).
At 830, internal resource interfaces include interfaces from logic 840 in the module to the resource being managed at 850, where the logic includes code and/or configuration that processes a command and/or updates state and data properties. In some cases, this can be hardware such as I/O interfaces, or in other cases it is to subordinate resource control modules that have direct interfaces. Some examples include I/O mapping, material management logic routines, and so forth. These interfaces 830 are internal to the module enabling the module's public interfaces 820 and properties 810 to be the boundary to other system components. Modules that wrap different resources but support the same public properties/interfaces can be exchanged without disrupting interfaces to other components. Generally, I/O mapping and system messaging interfaces are exposed during deployment bind processes. When bound, external interfaces 820 to runtime systems may then consider these interfaces as internal.
At 860, alarm and event messages can be provided which include messages that exposed as runtime messages visible to external systems during the execution of the module. This includes alarms and events explicitly coded by the developer and system messages promoted to be visible by external systems. At 870, one or more artifacts include information that document the operation and structure of the resource such as for example, wiring diagrams, warranties, payroll, parts supplier information, and so forth. Visualization aspects include associated graphics that present the resource state and properties to applications interacting with the resource. For example: faceplates, icons, state overlays, edit dialogs, help files. At 880, system messages allow modules to listen for and publish data model messages to external components. Inbound messages are typically used to manage modules (configure, initialize, propagate properties, and so forth) and publish messages on module activity (resource state, data model messages, and so forth).
Turning to
At 910, an Equipment Control Module (Common name=“Control Module”) CM. The simplest form of basic regulatory control of equipment. Encapsulating the equipment and its control such as control of values, drives, and so forth. At 920, a Material Control Module (MCM) can be provided. Management of Material resource instances which are represented as sub-lots including change in location, quality status, availability, order status, logic that can be performed on material sub-lots, generation of material events such as consumed, produced and moved events, sub-lot combination, expiry dates, and so forth.
At 930, a Personnel Control Module (PCM) is provided. This includes management of individual people such as Active, Idle, Break states directly or via shift schedules. This also includes data associated with people such as shift time patterns, for example. Other attributes that may be managed by PCM 930 are a person's location in a plant (GPS), qualification checks, or current assignment, for example. At 940, a Segment Control Module (SCM) includes manipulation of simple segment tasks such as piping paths, AGV paths, device state machines, robotic sequences and so forth. The SCM 940 typically performs an action on one segment such as next step to execute after the current step. At 950, a Storage Control Module (STGCM) includes Manipulation of simple storage logic such as buffer capacity and ordering into and out of a queue for the respective storage unit or requirement.
Before proceeding it is noted that other types of modules are possible than shown. For instance, a configuration module may include management definitions and configuration of resources—personnel, segments, equipment, segments, storage, and so forth. Another type of module includes nested modules where a module references other modules. These modules may be children of a parent module or shared from one module to another. Resource modules may include resource control modules however resource control modules should not include resource modules. Modules can include modules focused on other resource types, for example an equipment module may include equipment modules and material modules.
At 1140, a Segment Module provides coordination of segment modules and segment control modules and to execute sequences of tasks represented by segments. Segments define resource requirements and ordering that can represent most production and process activities. This module provides access to more complex tasks that require specific sequences to be followed e.g., Process Analytics Technology (PAT) integration, electronic signatures collection, defect, process deviation and fault recovery processing. The segment module 1140 may also construct a sequence to be followed that can be applied as manual, automatic or semi automatic sequences (e.g., Route, recipe execution) At 1150, a Storage Module provides coordination of storage related activities, allocation of storage to requesters, modeling of inventory calculations and so forth. This also includes interaction with higher-level systems that manage storage and inventory information.
Resource capabilities 1210 include the resource 1220 required to perform work in a production system. Consequently, resources 1220 are at the centre of efficiency, capacity, scheduling and arbitration considerations. A resource's ability to work or be available to allow work to commence is represented as resource capability at 1230. The existence of capability 1230 associated with a resource 1220 does not make the resource available for production; the resource's capability 1230 is associated with organizational units 1240 that are will support the respective resource capability. For example, an operator (personnel resource) may have qualifications for a Mixer in line 1, where this qualification capability is only in effect with that specific mixer unless explicitly directed. Resource arbitration algorithms can search for resource capabilities 1230 in the scope of organizational units 1240 they are to be executed within.
Resources 1220 publish capabilities to organizational units 1240 for use by system processes in a given scope. Modules are a type of resource and can be accessed directly by published capabilities 1210. However, a more common interface to Resource Modules is via verbs that are supported by the Resource Module noted above. These verbs are Resource Control elements (phases, operations, procedures . . . ) which are segments. A published capability of a resource module is typically one of the phases supported the module. Resource control interfaces are published (made available) to the outside world as capabilities 1210. Resource modules provide the ability to promote a command to become a resource control interface.
Some process control systems are built using only Resource control modules (especially control modules). Examples of this are continuous processes such as petrochemical and heavy chemical plants. In order to initiate, the process takes a plant up to its running state or makes a change to the state of a series of commands that are initiated and coordinated to achieve the new state. It is also possible to promote commands from resource control modules to appear as capabilities that can be accessed as “tuning knobs” for tweaking the system between system states. As shown in the model 1200, the resource 1220 and capability can be associated with a higher-level class or abstraction 1250.
What has been described above includes various exemplary aspects. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing these aspects, but one of ordinary skill in the art may recognize that many further combinations and permutations are possible. Accordingly, the aspects described herein are intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the term “includes” is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.
This application claims the benefit of U.S. Provisional Patent Application No. 60/862,403 entitled MODULE CONTROL AND STATE PROPAGATION, and filed on Oct. 20, 2006, the entirety of which is incorporated herein by reference. This application also claims the benefit of U.S. Provisional Patent Application No. 60/890,973 entitled MODULE CONTROL AND STATE PROPAGATION, and filed on Feb. 21st, 2007, the entirety of which is incorporated herein by reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4118635 | Barrett et al. | Oct 1978 | A |
| 4215396 | Henry | Jul 1980 | A |
| 4519027 | Vogelsberg | May 1985 | A |
| 4570217 | Allen et al. | Feb 1986 | A |
| 4602324 | Fujawa et al. | Jul 1986 | A |
| 4910691 | Skeirik | Mar 1990 | A |
| 4990057 | Rollins | Feb 1991 | A |
| 5058043 | Skeirik | Oct 1991 | A |
| 5068778 | Kosem et al. | Nov 1991 | A |
| 5214577 | Sztipanovits et al. | May 1993 | A |
| 5255197 | Iida | Oct 1993 | A |
| 5262954 | Fujino et al. | Nov 1993 | A |
| 5388318 | Petta | Feb 1995 | A |
| 5420977 | Sztipanovits et al. | May 1995 | A |
| 5450346 | Krummen et al. | Sep 1995 | A |
| 5555179 | Koyama et al. | Sep 1996 | A |
| 5673194 | Cipelletti et al. | Sep 1997 | A |
| 5751582 | Saxena et al. | May 1998 | A |
| 5920717 | Noda | Jul 1999 | A |
| 5946212 | Bermon et al. | Aug 1999 | A |
| 6008985 | Lake et al. | Dec 1999 | A |
| 6289252 | Wilson et al. | Sep 2001 | B1 |
| 6397114 | Eryurek et al. | May 2002 | B1 |
| 6449624 | Hammack et al. | Sep 2002 | B1 |
| 6459944 | Maturana et al. | Oct 2002 | B1 |
| 6501995 | Kinney et al. | Dec 2002 | B1 |
| 6527018 | Yamauchi et al. | Mar 2003 | B2 |
| 6535769 | Konar | Mar 2003 | B1 |
| 6615091 | Birchenough et al. | Sep 2003 | B1 |
| 6662061 | Brown | Dec 2003 | B1 |
| 6675324 | Marisetty et al. | Jan 2004 | B2 |
| 6708104 | Avery et al. | Mar 2004 | B2 |
| 6760630 | Turnaus et al. | Jul 2004 | B2 |
| 6832118 | Heberlein et al. | Dec 2004 | B1 |
| 6853920 | Hsiung et al. | Feb 2005 | B2 |
| 6859755 | Eryurek et al. | Feb 2005 | B2 |
| 6865432 | Brown | Mar 2005 | B2 |
| 6996741 | Pittelkow et al. | Feb 2006 | B1 |
| 7058712 | Vasko et al. | Jun 2006 | B1 |
| 7089155 | Hegel | Aug 2006 | B2 |
| 7089530 | Dardinski et al. | Aug 2006 | B1 |
| 7117504 | Smith et al. | Oct 2006 | B2 |
| 7123978 | Hartman et al. | Oct 2006 | B2 |
| 7149595 | D'Mura | Dec 2006 | B2 |
| 7162534 | Schleiss et al. | Jan 2007 | B2 |
| 7171281 | Weber et al. | Jan 2007 | B2 |
| 7249356 | Wilson et al. | Jul 2007 | B1 |
| 7254457 | Chen et al. | Aug 2007 | B1 |
| 7289861 | Aneweer et al. | Oct 2007 | B2 |
| 7307986 | Henderson et al. | Dec 2007 | B2 |
| 7313453 | Kline | Dec 2007 | B2 |
| 7415708 | Knauerhase et al. | Aug 2008 | B2 |
| 7424331 | Patel | Sep 2008 | B2 |
| 20010049562 | Takano et al. | Dec 2001 | A1 |
| 20020010908 | Cheng et al. | Jan 2002 | A1 |
| 20020042896 | Johnson et al. | Apr 2002 | A1 |
| 20030051071 | Stefansson et al. | Mar 2003 | A1 |
| 20030149756 | Grieve et al. | Aug 2003 | A1 |
| 20030177018 | Hughes | Sep 2003 | A1 |
| 20040095833 | Marisetty et al. | May 2004 | A1 |
| 20040158713 | Aneweer et al. | Aug 2004 | A1 |
| 20040172612 | Kasravi et al. | Sep 2004 | A1 |
| 20040181294 | Deitz et al. | Sep 2004 | A1 |
| 20040243260 | Law et al. | Dec 2004 | A1 |
| 20050004781 | Price et al. | Jan 2005 | A1 |
| 20050015769 | Gegner | Jan 2005 | A1 |
| 20050227217 | Wilson | Oct 2005 | A1 |
| 20060101433 | Opem et al. | May 2006 | A1 |
| 20060230383 | Moulckers et al. | Oct 2006 | A1 |
| 20060265688 | Carlson et al. | Nov 2006 | A1 |
| 20070061125 | Bhatt et al. | Mar 2007 | A1 |
| 20070089100 | Morris et al. | Apr 2007 | A1 |
| 20070100486 | Burda et al. | May 2007 | A1 |
| 20070101193 | Johnson et al. | May 2007 | A1 |
| 20070162268 | Kota et al. | Jul 2007 | A1 |
| 20070186090 | Yu et al. | Aug 2007 | A1 |
| 20070261027 | Dhanakshirur et al. | Nov 2007 | A1 |
| 20070269297 | Van Der Meulen et al. | Nov 2007 | A1 |
| 20080120129 | Seubert et al. | May 2008 | A1 |
| 20080126407 | Shimaoka et al. | May 2008 | A1 |
| 20080188960 | Nixon et al. | Aug 2008 | A1 |
| Number | Date | Country |
|---|---|---|
| 1770464 | Apr 2007 | EP |
| Number | Date | Country | |
|---|---|---|---|
| 20080097626 A1 | Apr 2008 | US |
| Number | Date | Country | |
|---|---|---|---|
| 60862403 | Oct 2006 | US | |
| 60890973 | Feb 2007 | US |
