U.S. patent application number 11/386446 was filed with the patent office on 2007-06-14 for web-based robotics simulation.
Invention is credited to Patrick Panesse, Peter van der Meulen.
Application Number | 20070135933 11/386446 |
Document ID | / |
Family ID | 38140461 |
Filed Date | 2007-06-14 |
United States Patent
Application |
20070135933 |
Kind Code |
A1 |
Panesse; Patrick ; et
al. |
June 14, 2007 |
Web-based robotics simulation
Abstract
A programming interface for a hardware system includes an
embedded layer for programmatic access to a physical realization of
hardware, a simulation system for simulation of the hardware, and a
diagnostics engine that analyzes and compares feedback data from
the simulation system and the physical realization. The programming
interface may be usefully employed, for example, in the design,
purchase, and deployment of robotics for semiconductor
manufacturing.
Inventors: |
Panesse; Patrick;
(Lynnfield, MA) ; van der Meulen; Peter;
(Newburyport, MA) |
Correspondence
Address: |
STRATEGIC PATENTS P.C..
C/O PORTFOLIOIP
P.O. BOX 52050
MINNEAPOLIS
MN
55402
US
|
Family ID: |
38140461 |
Appl. No.: |
11/386446 |
Filed: |
March 21, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11302563 |
Dec 13, 2005 |
|
|
|
11386446 |
Mar 21, 2006 |
|
|
|
Current U.S.
Class: |
700/17 |
Current CPC
Class: |
G05B 2219/34256
20130101; B25J 9/1671 20130101; G05B 2219/40311 20130101; G05B
2219/45031 20130101; G05B 2219/33299 20130101 |
Class at
Publication: |
700/017 |
International
Class: |
G05B 11/01 20060101
G05B011/01 |
Claims
1. A system comprising: a simulation system for simulating a
plurality of components; a user interface for specifying a
manufacturing robotics system using one or more of the plurality of
components, the user interface permitting a user to simulate the
manufacturing robotics system in the simulation system and the user
interface further permitting a user to purchase the manufacturing
robotics system.
2. The system of claim 1 wherein the simulation system provides
real time simulation.
3. The system of claim 1 wherein the user interface includes a web
interface.
4. The system of claim 1 wherein the user interface provides cost
information associated with the manufacturing robotics system.
5. The system of claim 1 wherein the user interface presents
simulation results to the user.
6. The system of claim 5 wherein the user interface includes one or
more tools for analyzing the simulation results.
7. The system of claim 5 wherein the user interface includes one or
more tools for comparing simulation results from a plurality of
simulations.
8. The system of claim 7 wherein the plurality of simulations
include simulations of two or more different manufacturing robotics
systems using different ones of the plurality of components.
9. The system of claim 7 wherein the user interface includes two or
more different simulations of the same manufacturing robotics
system under different conditions.
10. The system of claim 7 further comprising a purchasing engine
that receives a purchase order from the user of the user interface
and converts the order into a specification for a product.
11. The system of claim 7 wherein specifying the manufacturing
robotics system includes providing a mechanical relationship among
a plurality of robotic components.
12. The system of claim 11 wherein the plurality of robotic
components includes one or more robotic arm links.
13. The system of claim 7 wherein specifying the manufacturing
robotics system includes providing an electrical relationship among
a plurality of robotic components.
14. The system of claim 13 wherein the plurality of robotic
components includes one or more of a motor, a sensor, and a
controller.
15. A method comprising: providing a simulation system for
simulating a plurality of components; presenting the simulation
system through a user interface adapted for specifying a
manufacturing robotics system using one or more of the plurality of
components, the user interface permitting a user to simulate the
manufacturing robotics system in the simulation system and the user
interface further permitting a user to purchase the manufacturing
robotics system.
16. The method of claim 15 wherein the simulation system provides
real time simulation.
17. The method of claim 15 wherein the user interface includes a
web interface.
18. The method of claim 15 wherein the user interface provides cost
information associated with the manufacturing robotics system.
19. The method of claim 15 wherein the user interface presents
simulation results to the user.
20. The method of claim 19 wherein the user interface includes one
or more tools for analyzing the simulation results.
21. The method of claim 19 wherein the user interface includes one
or more tools for comparing simulation results from a plurality of
simulations.
22. The method of claim 21 wherein the plurality of simulations
include simulations of two or more different manufacturing robotics
systems using different ones of the plurality of components.
23. The method of claim 21 wherein the user interface includes two
or more different simulations of the same manufacturing robotics
system under different conditions.
24. The method of claim 21 further comprising receiving a purchase
order from the user of the user interface and converting the order
into a specification for a product.
25. The method of claim 21 wherein specifying the manufacturing
robotics system includes providing a mechanical relationship among
a plurality of robotic components.
26. The method of claim 25 wherein the plurality of robotic
components includes one or more robotic arm links.
27. The method of claim 21 wherein specifying the manufacturing
robotics system includes providing an electrical relationship among
a plurality of robotic components.
28. The method of claim 27 wherein the plurality of robotic
components includes one or more of a motor, a sensor, and a
controller.
29. A method comprising: specifying a robotic system through a
web-based user interface; simulating the robotic system; reviewing
simulation results through the web-based user interface; and
purchasing the robotic system.
30. A method comprising: receiving a specification of a robotic
system over a data network; simulating the robotic system;
transmitting simulation results of the data network; and receiving
a purchase order for the robotic system.
Description
RELATED APPLICATIONS
[0001] This application is a continuation-in-part of U.S.
application Ser. No. 11/302,563, filed on Dec. 13, 2005 and
entitled "ROBOTICS PROGRAMMING INTERFACE". The entire content of
that application is incorporated herein by reference.
BACKGROUND
[0002] 1. Field of the Invention
[0003] This invention relates to application programming interfaces
for robotic systems, and more particularly, interfaces that
optionally share control of simulated and physical systems.
[0004] 2. Description of the Related Art
[0005] Computer simulation has long been used in a variety of
fields to predict and evaluate behavior of physical systems prior
to incurring the cost of physically realizing such systems in
electro-mechanical form. While simulation has improved with
increases in computational power, little has been done to
systematically provide simulation tools to physical system users
such as design engineers or purchasers and end users of complex
electro-mechanical systems such as manufacturing robotics systems.
There remains a need for improved access to simulation technologies
in commercial and design settings. A need also exists for
simulation systems that operate effectively in real time, such as
during operation of a machine.
SUMMARY
[0006] A programming interface for a hardware system may include an
embedded layer for programmatic access to a physical realization of
hardware, a simulation system for simulation of the hardware, and a
diagnostics engine that analyzes and compares feedback data from
the simulation system and the physical realization. The programming
interface may be usefully employed, for example, in the design,
purchase, and deployment of robotics for semiconductor
manufacturing. In embodiments, the embedded layer and the
simulation system operate simultaneously, allowing real-time,
simultaneous access to tools for computer simulation (e.g., for
diagnostic purposes, for simulating activities of a machine, or the
like) and tools for physical control.
BRIEF DESCRIPTION OF THE FIGURES
[0007] The invention and the following detailed description of
certain embodiments thereof may be understood by reference to the
following figures.
[0008] FIG. 1 shows a physical realization of a robotics
system.
[0009] FIG. 2 shows a software architecture for a robotics
system
[0010] FIG. 3 shows a data repository for data acquisition and
analysis.
[0011] FIG. 4 shows a network.
[0012] FIG. 5 shows a user interface.
[0013] FIG. 6 illustrates a process for purchasing a robotics
system.
DETAILED DESCRIPTION
[0014] Described below is a programming interface for simulation
(optionally including virtual reality simulation), diagnosis and
control of a machine, which may be manufacturing system, such as a
robotic manufacture system, and more particularly may be a robotic
manufacturing facility for semiconductor manufacturing, such as
vacuum-based manufacturing. While such a system may be usefully
employed in semiconductor manufacturing, and the design, purchase,
and use of robotic systems therefore, it will be appreciated that
the inventive concepts disclosed herein are not limited to
semiconductor manufacturing robotics. Rather, the concepts
disclosed herein have wide applicability to any systems that are
amenable to simulation and include a control interface with command
outputs and sensor inputs or feedback. This may include, for
example, food processing systems, manufacturing systems, automated
warehouse management, or any other systems with similar
characteristics, and all such variations and alternative uses are
intended to fall within the scope of this disclosure.
[0015] FIG. 1 shows a physical realization of a robotics system. In
an example embodiment, a robotic system 100 may include a control
system 102, a base 104, one or more arms 106, 108, 110, and an end
effector 112. Robots may be used for various purposes, from working
in harsh environments, to working in specialized environments such
as vacuums, to simple picking and placing work.
[0016] The control 102 may include hardware and/or software to
drive the motors of the various arms 106, 108, 110 and may include
a data storage facility, such as a memory to record path motions,
such as in a path motions file, as well as recording other
operation data for the robotics system 100. The control 100 may be
connected to a base 104 that may be shaped and sized to aid in the
positioning of the arms 106, 108, 110 and the movement and
activation of the end effector 112 in, for example, a manufacturing
process. The base 102 may additionally include various motors for
effecting movement of the arms 106, 108, 110 and end effector 112.
Although three arms are illustrated, it will be appreciated that
fewer or more arms, each of varying lengths, may be employed with
the robotic systems 100 described herein. Multiple arms 106, 108,
111, such as those depicted in FIG. 1, permit the illustrated
robotic arm to reach around or over other objects, and to extend up
to the full length of the combined arms 106, 108, 110. In addition
to arms the base 104 or some other portion of the robotic system
100 may include actuators for linear or other vertical, horizontal,
or other planar motion. In embodiments, positions of other robotic
components, such as wheels, gears, carts, drive mechanisms,
cameras, sensors, and the like may be controlled in a manner
similar to the arms 106, 108, 111.
[0017] In embodiments the end effector 112 may provide for
manipulation of a tool or work piece, such as a wafer in a
semiconductor manufacturing process. The end effector 112 may
include, for example a gripper, a pincer, a fork, a tray, a
platform, a finger, a nozzle, a vacuum grip, a tumble gripper, a
passive centering gripper, or any other tool or tools that might be
useful in the robotic system 100. The end effector 112 may, for
example, be used to move or grab objects within a manufacturing
process. Other components that may be used within the robotic
system 100 include, for example, a valve, an arm, a multi-link arm,
a door, a seal, an elevator, a conveyer, a belt, a chain, a cart or
the like.
[0018] The arms 106, 108, 110 of the robotic system 100 may be
modeled and controlled, for example, using equations of motion,
such as inverse kinematics (IK) equations that describe the motion
of a feature, such as a multi-armed device, in a coordinate system.
Generally, a set of equations may be established that describe each
sub-part of a machine, such as a robot, based on the dimensions of
the machine and its degrees of freedom, such as its ability to
translate, to rotate, or to pivot about one or more points of
pivot. Inverse kinematic equations may be used, for example, to
predict the placement of an end point of a device based on the
motion of the movable components or predict the motion of the
movable components based on the position of the end point. It will
be understood that the term inverse kinematics is used herein as a
short hand for any equations of motion, including inverse
kinematics as that term is generally understood in the art as well
as forward kinematics or any other equations of motion suitable for
characterizing robotics components and related drives and/or work
pieces.
[0019] It will be appreciated that, while FIG. 1 shows a number of
robotic arms 106, 108, 110 that can be modeled as an IK device, any
number of other types of components may also, or instead, be
included in the robotic system 100. For example, a semiconductor
wafer handling system may include chemical vapor deposition
components, etching components, lithography components, vacuum
creation and monitoring components, vacuum isolation valves,
heating or cooling systems, conveyers, elevators, entry and exit
control (e.g., opening, closing, and vacuum sealing doors or other
ports), cleaning systems, and/or other automated or human
inspection systems.
[0020] Further, processing tools may be chained together into
linear or other clusters for various processing steps. In such a
system the robotics system 100 may, in addition to controlling a
variety of process steps and parameters, manage physical movement
of a wafer from tool to tool, and through buffer stations, if
any.
[0021] The robotic system 100 may also include one or more sensors
114. Sensors may be used, for example, to track the position of a
work piece or the operating environment of the robotic system 100.
Thus for example, the sensors 114 may include temperature sensors
(e.g., ambient temperature, process temperature, work piece
temperature, and so on), atmospheric pressure sensors, motion
sensors, proximity sensors, weight sensors, light sensors, voltage
sensors, sound sensors and so on. The sensors 114 may detect the
presence of, or concentration of, a gas or other substance within
the process environment. The sensors 114 may employ a variety of
techniques for detecting position and other parameters, such as
optical beams (with, e.g., emitter/detector beam paths), infrared,
RF, sonar, capacitive and/or magnetic sensing techniques or other
imaging and sensing techniques. The sensors 114 may detect a state
of a component of the robotic system 100 or a work piece, such as a
position of, direction of, or distance to a work piece, or a
distance to an obstruction, a valve status, a seal status, a door
position, or a diagnostic state (e.g., okay, malfunctioning, etc.).
More generally, the sensors 114 may employ any suitable technology
for gathering sensor data consistent with the use of the robotic
system 100. In one embodiment, one or more of the sensors 114 may
be sealed within a processing chamber and communicate with the
control 102 through a wireless data/control link such as IEEE
Standard 802.11b or 802.11g.
[0022] As the foregoing examples illustrate, a wide number of
components, sensors, and actuators may be employed with the robotic
system 100 described herein, and all such components, sensors, and
actuators are intended to fall within the scope of this
disclosure.
[0023] FIG. 2 shows a software architecture for a robotics system.
The architecture 200 may include, for example, an external
programming environment 202, an application programming interface
204, a simulation module 206, a diagnostics module 208, and a
hardware module 210. The simulation module 206 may be instantiated
as a real time simulation input/output 212. The diagnostics module
208 may be instantiated as a diagnostics engine 214 that
interconnects the simulation module 206 and the hardware module
210. The hardware module 210 may be instantiated as an embedded
layer 216 that communicates with a physical realization of hardware
218. The architecture 200 may be used with a variety of robotic and
other hardware and/or control systems, including, for example, the
robotic system 100 described above with reference to FIG. 1.
[0024] The external programming environment 202 may include, for
example, a .NET object layer for user with Microsoft's .NET
software development platform. The .NET framework offers a
development environment for Microsoft Windows and web applications,
as well as more atomic components and web services. While the .NET
framework is one useful programming paradigm for deploying services
and various Internet and intranet applications, it will be
appreciated that other environments may also, or instead, be
usefully employed with the robotics systems described herein. For
example, a distributed computing environment may be supported by
Java EE from Sun or Component Object Model ("COM"), Microsoft's
precursor to .NET. Similarly, the modules 206, 208, 210 may be
packaged as libraries or subroutines for a standalone application,
or may be deployed as a service, such as a web service (such as in
a services oriented architecture), or through a web-accessible
interface. All such software implementations, as well as variations
and combinations thereof, are intended to fall within the scope of
this disclosure.
[0025] The application programming interface ("API") 204 may
communicate with the programming environment 202 using, for example
data messages, a TCP packet stream, or any other message-oriented,
connection-oriented, serial, or other communications protocol. The
API 204 serves as a programming interface for a simulation
environment such as the simulation module 206, controller for
hardware, such as the hardware module 210, and a diagnostic system
such as the diagnostic module 208. In one embodiment, the API 204
exchanges data messages with the .NET object layer of the external
programming environment 202. More generally, the API 204 may
include any set of definitions of the ways an external computer
system (e.g., from the external programming environment 202)
communicates with the internal functional modules of the
architecture 200 (e.g., the modules 206, 208, 210 presented by the
API 204). Thus, any predefined programmatic interface may be used
as the API 204 of the architecture 200, provided the API 204 may be
suitably adapted to the external programming environment 202 on one
hand and the simulation module 206, the diagnostics engine 208, and
the hardware module 210, on the other hand.
[0026] In one aspect, the API 204 may accommodate explicit access
to each of the modules 206, 208, 210, so that a programmer may, for
example, configure, refine, load, customize, analyze, or otherwise
manipulate the simulation, the diagnostics engine, and/or the
embedded controller or other layers of the hardware interface.
Thus, for example, a user may access the simulation module 206
during a teaching phase or automated teaching phase in which
robotic arms and/or other parts are trained to safely operate
within physical boundaries and constraints of an environment. The
results may be transferred to the hardware module 206 (or retained
as constraints within, e.g., the diagnostic module 208) for use in
subsequent control of physically realized hardware 218. In another
aspect, the API 204 may not differentiate between use of the
simulation module 206 and the hardware module 210. In this latter
embodiment, the API 204 may be presented as a simple hardware
controller that provides, in addition to other outputs, diagnostic
feedback summarizing deviations from expected hardware behavior,
i.e., output from the diagnostic module 208. In another aspect, the
API 204 may have two operating modes, a design mode in which full
access is provided, and a user mode configured for distribution to
end users of the robotic system 100.
[0027] The simulation module 206 may simulate the physical
realization of hardware 218, along with the hardware module 210 and
any other control or data interfaces of the hardware 218. In an
embodiment, the simulation module 206 may provide a real time
input/output simulation 212 of the hardware 218 (including any
embedded layer 216), such that the input/output interface of the
simulation module 206 substantially corresponds to the input/output
interface of the hardware module 210. The application programming
interface may, for example, maintain consistency by concurrently
feeding external inputs to the hardware module 210 and the
simulation module 206. In embodiments, the simulation module may
take as inputs three-dimensional models from one or more
three-dimensional visualization modules, such as commercially
available modules available from SolidWorks.RTM..
[0028] A variety of simulation techniques are known, and may be
usefully employed with the simulation module 206. This may include,
for example physical modeling of robotic components and the
environment of the robotic system 100. Physical modeling may
embrace such features of the system and environment as temperature,
heat transfer, wear, sensors and sensor input/output, thermal
dynamics, electrical and magnetic behavior, optical features,
vibration and resonance behaviors, solid state and crystalline
behavior, thermal expansion and contraction, statistical mechanics,
Newtonian physics, inverse kinematics and other behavior of
interconnected physical parts, pressure, fluid flow, gas flow, and
so on. The simulation may also, or instead, employ statistical
models, heuristic models, linear models, qualitative models,
decision analysis models, decision trees and any other modeling or
behavioral techniques useful for characterizing and predicting
responses. The simulation module may embrace elements of the
hardware input and output such as data acquisition, signal
processing, and the like. More generally any aspects of the
hardware 218 and hardware module 210 useful for an accurate or real
time simulation may be usefully incorporated in a simulation
executed by the simulation module 206.
[0029] The simulation module 206 may update using any time base or
time frame. One common time interval for industrial control systems
is twenty milliseconds. Thus, in one corresponding embodiment, real
time operation of the simulation module 206 may be satisfied by any
combination of hardware and software that fully updates simulation
results in twenty milliseconds or less. It will be appreciated that
other faster or slower update times may be employed, according to
particular hardware module 210 behaviors, and the adaptability of
the diagnostic module 208 to asynchronous data from the hardware
module 210 and the simulation module 206. A variety of signal
processing techniques are available for upconversion,
downconversion, and interpolation of time based data to accommodate
timing constraints between these modules.
[0030] In general, the diagnostics module 208 may perform
diagnostic functions, such as based on comparisons of the
differences between operation of the robotic system, as received
from the hardware module 210, and operation of the simulation, as
received from the simulation module 206. In an embodiment, the
diagnostic module 208 includes a diagnostic engine 214 for real
time comparison of simulation and actual data. The diagnostics
module 208 may provide various types of analysis concerning the
relationship of outputs from the hardware module 210 and the
simulation module 206. For example, the diagnostics module 208 may
provide statistical analysis that accommodates small, statistically
acceptable deviations without generating a diagnostic message. The
diagnostics module 208 may also, or instead, provide a direct data
feed of a differential between expected and actual results, which
may be passed through the API 204 for independent analysis and use
by an end user. The diagnostics module 208 may also, or instead
provide analysis of deviations with specific error messages
indicating known and unknown error conditions. This may include,
for example, identification of malfunctioning parts, malfunctioning
sensors, or malfunctioning interfaces. The diagnostics module 208
may optionally embody statistical models for diagnosis and
predictions of faults, including qualitative reasoning methods,
methods based on statistical process control, methods based on
failure mode effects analysis, or models that combine features of
the foregoing, as well as combine any of the foregoing with the
outputs of the simulation module 206.
[0031] In another aspect, the diagnostics module 208 may further
provide control signals to the hardware module, such as based upon
diagnosis of a malfunction. This may include, for example, a signal
to shut down an individual component, a group of related
components, or an entire system, or to otherwise alter the
operation of the foregoing. Shut down commands and other
diagnostic-derived control signals, and triggers therefore, may be
user configured based upon, for example, safety risks,
work-in-progress value and/or cost, expected damage to one or more
work pieces, expected damage to equipment, and so forth. The
diagnostics module 208 may also, or instead, provide predictive
maintenance, such as advance notification of component malfunctions
or the identification of maintenance requirements such as filter
changes, battery replacements, fluid changes, and the like.
[0032] The hardware module 210 may encapsulate, or include an
interface to, the embedded layer 216 of a physical realization of
hardware 218. At this interface, control and command data may be
provided to the hardware 218 through a direct or indirect physical
connection. This may include, for example, low level commands such
as step motor settings, voltages on control lines, and the like, or
this may include higher level commands in computer or human
readable syntax, which may be interpreted by the embedded layer 216
for direct activation of hardware 218. This may also include data
from the hardware 218 including, for example, raw or preprocessed
sensor data, status and control feedback, and the like.
[0033] In one aspect, the hardware module 210 may simplify
programmatic access to the hardware 218 by providing an abstracted
command interface for use at the API 204 level. In another aspect,
the hardware module 210 may implement control systems for operation
of the hardware 218. This may include, for example, discrete
control algorithms implemented as look-up tables or logic, or
analytical control algorithms implementing feedback control and so
on. The API 204 may expose optional use of such control algorithms,
access to parameters thereof, and/or direct programming of
arbitrary control algorithms. Thus, in general, varying degrees of
control abstraction and varying degrees of control intelligence and
automation may be incorporated into the hardware module 210, and
into the simulation module 206 version thereof. It will also be
appreciated that the hardware module 210 may include different
design and runtime instances of a hardware controller. The design
instance may, for example be created in a human readable form, or a
dynamically re-configurable form such as an interpreted programming
language. The runtime instance may, instead, be compiled to execute
on a controller associated with the hardware 218, which may
include, for example, one or more application specific integrated
circuits, microprocessors, microcontrollers, or other programmable
devices.
[0034] The physical realization of hardware 218 may be, for
example, any of the robotic systems 100 described above with
reference to FIG. 1, or more generally, any hardware with a
command, control, data, and/or sensor interface. User commands
received through the API 204, or internally generated commands from
within the hardware module 210, the diagnostics module 208, or
other source, may be transmitted to the hardware 218 through any
suitable interconnection with the hardware module 210, such as
Ethernet, RS-232, or any other direct or indirect input/output,
network, or other interconnection. Sensor data may be provided in
analog or digital form, and may be preprocessed by the hardware 218
to provide, e.g., calibration, serialization, digitization, and so
on.
[0035] According to the foregoing, a method described herein
includes providing a simulation of hardware, providing a physical
realization of the hardware, providing a programming interface to
control the hardware, and interconnecting one or more of the
simulation, the physical realization, and the programming interface
in a communicating relationship. Thus, a robotic system, a
simulation of the robotic system, and a programming interface may
be arbitrarily interconnected to one another. Such a method of
interconnection may allow for independent programmatic access to,
e.g., the simulation process for programming modifications, or
simulated training of the system, alongside independent
programmatic access to the hardware controller for implementation
of new control algorithms, system configuration, or any other
purpose. This method of interconnection may also, or instead,
permit direct comparison of simulation results and hardware sensor
data in real time.
[0036] In another aspect, a method according to the above
description may include controlling a robotic system, receiving
sensor data from the robotic system, concurrently executing a
simulation of the robotic system in real time, receiving simulated
sensor data from the simulation; and comparing the sensor data to
the simulated sensor data.
[0037] It will also be appreciated that a wide range of software
and hardware platforms may be used to create and deploy the
above-described software components such as the simulation module
206, the diagnostics module 208, and the hardware module 210.
Generally, the components may be realized in hardware, software, or
some combination of these. The components may be realized in one or
more microprocessors, microcontrollers, embedded microcontrollers,
programmable digital signal processors or other programmable
devices, along with internal and/or external memory such as
read-only memory, programmable read-only memory, electronically
erasable programmable read-only memory, random access memory,
dynamic random access memory, double data rate random access
memory, Rambus direct random access memory, flash memory, or any
other volatile or non-volatile memory for storing program
instructions, program data, and program output or other
intermediate or final results. The components may also, or instead,
include an application-specific integrated circuit, a programmable
gate array, programmable array logic, or any other device or
devices that may be configured to process electronic signals in a
manner consistent with the systems and methods described
herein.
[0038] Any combination of the above circuits and components,
whether packaged discretely, as a chip, as a chip set, or as a die,
may be suitably adapted to use with the systems described herein.
It will further be appreciated that the above software components
may be realized as computer executable code created using a
structured programming language such as C, an object oriented
programming language such as C++, or any other high-level or
low-level programming language that may be compiled or interpreted
to run on one of the above devices, as well as heterogeneous
combinations of processors, processor architectures, or
combinations of different hardware and software. All such
variations and combinations are intended to fall within the scope
of this disclosure.
[0039] It should also be appreciated that the recurring example
provided above--semiconductor manufacturing robotics--is only one
example of a possible use of the programming and control system
disclosed herein. The system described with reference to FIGS. 1-3
may be employed with suitable adaptations for control and
diagnostics in a variety of real time control contexts, including,
for example automobile manufacturing assembly lines, machining
processes, printing presses, industrial automation control systems
(such as those provided by Invensys, Honeywell, Siemens, et al),
building automation systems, security systems, Computer Numeric
Control ("CNC") machining systems, and so on. The systems and
methods described above may also be used for diagnostics in
human-operated machinery such as an operating automobile, an
operating airplane (military or civilian), an operating tank, an
operating extraterrestrial vehicle (such as a space shuttle, space
station, space dock), and so forth. These and other similar uses
not specifically enumerated herein are intended to fall within the
scope of this disclosure.
[0040] FIG. 3 shows a data repository for data acquisition and
analysis. As illustrated an analysis engine 302 may use data in a
data repository 304 generated from a hardware module 306, a
diagnostics module 308, and a simulation module 310.
[0041] The analysis engine 302 may provide one or more tools for
analyzing data within the data repository 304. This may include,
for example tools for improving diagnostic functions such as
detection of malfunction, tools for statistical analysis of
hardware and simulation data, and deviations among these. The
analysis engine 302 may pool data from a number of robotic systems,
which may include similar or identical robotic systems as well as
disparate robotic system, and provide tools for comparative
analysis thereof.
[0042] In one aspect, the analysis engine 302 may provide a
diagnostics tool kit for identification and analysis of
diagnostically significant relationships. This may include, for
example, statistical analysis tools, linear system modeling tools,
frequency domain analysis tools, and so forth. Using the
diagnostics tool kit, new relationships that are identified from
data in the data repository may be deployed as new diagnostic
analyses current and/or future diagnostics modules. Similarly,
existing diagnostics may be refined and tested against data in the
data repository 304. As diagnostic techniques are developed using
the diagnostics tool kit, they may be back-tested against data in
the data repository using the analysis engine.
[0043] To enhance use of the analysis engine 302 and the
diagnostics tool kit, certain know fault modes, such as a motor
failure, pressure leak, wafer defect, or the like may be copied
into a separate location or otherwise flagged for use and
re-use.
[0044] The data repository 304 may be any mass storage device
suitable for the volume and rate of data acquisition from a system
such as any of the robotic systems 100 described above. This may
include, for example semiconductor memory devices, optical memory
devices such as CD-ROM or DVD-ROM, network attached storage,
storage area network devices, magnetic disk drives, magnetic tape
drives, or any other volatile or non-volatile memory device. The
data repository 304 may also include arrays of such devices such as
farms, RAID arrays, and the like. In addition to the physical media
for storage, the data repository 304 may include a database
management system such as those commercially available from
Microsoft Corporation, International Business Machines, and Oracle,
as well as a number of open source software projects.
[0045] The hardware module 306, diagnostics module 308, and
simulation module 310 may be, for example, the modules 206, 208,
210 described above with reference to FIG. 2. These modules 306,
308, 310 may feed data directly to a local data repository 304, or
may provide data over a local area network, storage area network,
wide area network, private network, or the like. Data may include,
for example, control and command data provided to the hardware
module 306, sensor and other feedback data received from the
hardware module 306 and/or simulation module 310, and diagnostic
information, if any, received from the diagnostics module 308. The
data may include actual and simulated real time data. Data may be
incrementally forwarded to the data repository 304, or locally
cached and forwarded in batches at appropriate times, or
combinations of these. More generally, any suitable technique for
transferring data from the modules 306, 308, 310 to the data
repository 304 may be employed with the systems described
herein.
[0046] FIG. 4 shows a network that may be used to deploy a
web-based business using the simulation systems described herein.
As shown in FIG. 4, a network 400 may include a plurality of
clients 402 and servers 404 connected via an internetwork 410. Any
number of clients 402 and servers 404 may participate in such a
system 400. The system may further include one or more local area
networks ("LAN") 412 interconnecting clients 402 through a hub 414
(in, for example, a peer network such as a wired or wireless
Ethernet network), router 414, or a local area network server 414
(in, for example, a client-server network). The LAN 412 may be
connected to the internetwork 410 through a gateway 416, which
provides security to the LAN 412 and ensures operating
compatibility between the LAN 412 and the internetwork 410. Any
data network may be used as the internetwork 410 and the LAN
412.
[0047] In one embodiment, the internetwork 410 is the Internet, and
the World Wide Web provides a system for interconnecting clients
402 and servers 404 in a communicating relationship through the
Internet 410. The internetwork 410 may include other networks, such
as satellite networks, the Public Switched Telephone Network, WiFi
networks, WiMax networks, cellular networks, and any other public,
private, or dedicated networks that might be used to interconnect
devices for transfer of data.
[0048] An exemplary client 402 may include a processor, a memory
(e.g. RAM), a bus which couples the processor and the memory, a
mass storage device (e.g. a magnetic hard disk or an optical
storage disk) coupled to the processor and the memory through an
I/O controller, and a network interface coupled to the processor
and the memory, such as modem, digital subscriber line ("DSL")
card, cable modem, network interface card, wireless network card,
or other interface device capable of wired, fiber optic, or
wireless data communications. One example of such a client 402 is a
personal computer equipped with an operating system such as
Microsoft Windows XP, UNIX, Linux, or Mac OS X, along with software
support for Internet communication protocols. The personal computer
may also include a browser program, such as Microsoft Internet
Explorer or FireFox to provide a user interface for access to the
internetwork 410. Although the personal computer is a typical
client 402, the client 402 may also be a workstation, mobile
computer, Web phone, VOIP device, television set-top box,
interactive kiosk, personal digital assistant, wireless electronic
mail device, or other device capable of communicating over the
Internet. As used herein, the term "client" is intended to refer to
any of the above-described clients 402 or other client devices, and
the term "browser" is intended to refer to any of the above browser
programs or other software or firmware providing a user interface
for navigating an internetwork 410 such as the Internet.
[0049] An exemplary server 404 includes a processor, a memory (e.g.
RAM), a bus which couples the processor and the memory, a mass
storage device (e.g. a magnetic or optical disk) coupled to the
processor and the memory through an I/O controller, and a network
interface coupled to the processor and the memory. Servers may be
clustered together to handle more client traffic, and may include
separate servers for different functions such as a database server,
an application server, and a Web presentation server. Such servers
may further include one or more mass storage devices such as a disk
farm or a redundant array of independent disk ("RAID") system for
additional storage and data integrity. Read-only devices such as
compact disk drives and digital versatile disk drives may also be
connected to the servers. Suitable servers and mass storage devices
are manufactured by, for example, Hewlett-Packard, IBM, and Sun
Microsystems. In addition to providing an interface for clients 402
visiting a Web site, the server 404 may provide back-end processing
that includes, for example access to the simulation and diagnostic
functions of the architecture 200 described above.
[0050] Focusing now on the internetwork 410, one embodiment is the
Internet. The structure of the Internet 410 is well known to those
of ordinary skill in the art and includes a network backbone with
networks branching from the backbone. These branches, in turn, have
networks branching from them, and so on. The backbone and branches
are connected by routers, bridges, switches, and other switching
elements that operate to direct data through the internetwork 410.
For a more detailed description of the structure and operation of
the Internet 410, one may refer to "The Internet Complete
Reference," by Harley Hahn and Rick Stout, published by
McGraw-Hill, 1994. However, one may practice the present invention
on a wide variety of communication networks. For example, the
internetwork 410 can include interactive television networks,
telephone networks, wireless voice or data transmission systems,
two-way cable systems, customized computer networks, Asynchronous
Transfer Mode networks, and so on. Clients 402 may access the
internetwork 410 through an Internet Service Provider ("ISP", not
shown) or through a dedicated DSL service, ISDN leased lines, T1
lines, OC3 lines, digital satellite service, cable modem service,
or any other suitable connection.
[0051] In an exemplary embodiment, a browser, executing on one of
the clients 402, retrieves a Web document at an address (a Uniform
Resource Locator ("URL"), an IP address, or other identifier) from
one of the servers 404 via the internetwork 410, and displays the
Web document on a viewing device, e.g., a screen. A user can
retrieve and view the Web document by entering, or selecting a link
to, a URL in the browser. The browser then sends an http request to
the server 404 that has the Web document associated with the URL.
The server 404 responds to the http request by sending the
requested Web document to the client 402. The Web document may be
an HTTP object that includes plain text (ASCII) conforming to the
HyperText Markup Language ("HTML"). Other markup languages are
known and may be used on appropriately enabled browsers and
servers, including the Dynamic HyperText Markup Language ("DHTML"),
the Extensible Markup Language ("XML"), the Extensible Hypertext
Markup Language ("XHML"), and the Standard Generalized Markup
Language ("SGML").
[0052] To enhance functionality, a server 404 may execute programs
associated with Web documents using programming or scripting
languages, such as Perl, C, C++, C#, or Java, or a Common Gateway
Interface ("CGI") script to access applications on the server. A
server 404 may also use server-side scripting languages such as
ColdFusion from MacroMedia or PHP. These programs and languages may
perform "back-end" functions such as order processing, database
management, and content searching. A Web document may also contain,
or include references to, small client-side applications, or
applets, that are transferred from the server 404 to the client 402
along with a Web document and executed locally by the client 402.
Java is one popular example of a programming language used for
applets. The text within a Web document may further include
(non-displayed) scripts that are executable by an appropriately
enabled browser, using a scripting language such as JavaScript or
Visual Basic Script. Browsers may further be enhanced with a
variety of helper applications to interpret various media including
still image formats such as JPEG and GIF, document formats such as
PPT and PDF, motion picture formats such as AVI and MPEG, animated
media such as Flash media, and sound formats such as MP3 and MIDI.
These media formats, along with a growing variety of proprietary
media formats, may be used to enrich a user's interactive and
audio-visual experience as each Web document is presented through
the browser. The term "page" as used herein is intended to refer to
the Web document described above, as well as any of the
above-described functional or multimedia content associated with
the Web document.
[0053] In general operation, a server 404 may provide a web site
including one or more web pages to a client 402. In an exemplary
embodiment, the web site may include an environment for specifying
and purchasing robotic systems as described below.
[0054] FIG. 5 shows a user interface that may be used in a client
device to view a Web site. The user interface may be presented, for
example, through a Web page viewed using a Web browser. The page
500 may include a header 502, a sidebar 504, a footer 506 and a
main section 508, all of which may be displayed at a client 402
such as the clients 402 described above. The header 502 may
include, for example, one or more banner advertisements, a title of
the page, and information about a source provider such as a company
providing the page 500. The sidebar 504 may include a menu of
choices for a user at the client 402, such as access to product
catalogs, component specifications, purchasing information, and so
on. The footer 506 may include another banner advertisement, and/or
information concerning the page such as a "help" or "webmaster"
contact, copyright information, disclaimers, a privacy statement,
an the like. The main section 508 may include content for viewing
by the user, such as information about various robotics components
and systems. The main section 508 may also include, for example,
tools for selecting components, inputting parameters, evaluating
costs and order delivery times, and so on. It will be appreciated
that this description is generic, and that the format of an actual
page 500 used as a user interface for a robotics ordering system
may be varied and supplemented in numerous manners. The page 500
may also adapt dynamically to use patterns at a client 402, and/or
according to any available information about the client 402 (such
as display size, media capabilities, etc.) or the user (such as
profile information).
[0055] A Web site including the page 500 may use cookies to track
users and user information. In particular, a client 402 accessing
the site may be accessed to detect whether the client 402 has
previously accessed the page or the site. If the client 402 has
accessed the site, then some predetermined content may be presented
to the client 402. If the client 402 does not include a cookie
indicating that the client 402 has visited the site, then the
client 402 may be directed to a registration page where information
may be gathered to create a user profile. The client 402 may also
be presented with a login page, so that a pre-existing user on a
new client 402 may nonetheless bypass the registration page.
[0056] The site may provide options to the client 402. For example,
the site may provide a search tool by which the client 402 may
search for content within the site, or content external to the site
but accessible through the internetwork 410. The site may include
payment processing through banking and third party transaction
systems including credit card processing, PayPal transaction
processing, wire transfer processing, and the like.
[0057] FIG. 6 illustrates a process for purchasing a robotics
system using the system described above. The process may involve,
for example, a user of a client device, such as any of the clients
402 described above, accessing a server, such as any of the servers
404 described above, through an interface rendered as a Web page,
such as any of the pages 200 described above. The process 600 may
start, as illustrated in step 602, with a user visiting a robotics
purchasing site on a server, such as any of the servers 404
described above, from a client such as any of the client 402
described above. The server may request log on credentials, or
employ any other password-based, certificate-based, or other
authentication or security measures to prevent unauthorized access
to the server. This may be useful, for example, were a provider of
manufacturing equipment wishes to offer customers access to cost
and design information while excluding competitors.
[0058] As shown in step 604, a user may configure a system, such as
a robotic semiconductor manufacturing system. This may include
selection of individual robotic components, as well as
pre-configured assemblies that include a number of different
components. Features such as sensors, control software, and the
like may be selected as options. The interface may permit
pick-and-place arrangement of components into a working system. The
interface may permit physical arrangement of components, as well as
the specification of mechanical and electrical relationships among
components of the system.
[0059] In an embodiment, a user may design custom mechanical
components or electrical circuitry using a Computer Automated
Design ("CAD") system offered through the web site, or may upload
custom components in a CAD format acceptable to the site, such as a
format amenable to either direct simulation, or conversion to a
simulation-ready format. Configuration may include physical
arrangement of mechanical and electrical parts, as well as
provision of control software which may be provided by the user or
by the site, or some combination of these. More generally, the
interface may permit a wide range of user customization, or may
constrain a user to certain configuration parameters, such as
component selections and physical arrangements, specific to an
industrial application for which the site is adapted. Thus, for
example, in a semiconductor manufacturing application, the
interface may specify a discrete number of workstation shapes,
sizes, and entry/exit modes, and a specific collection of robotics
components, such as robotic arms, individual robotic arm links,
conveyers, elevators, actuators, motors, sensors, controllers
(including individual chips and integrated controller systems) and
so forth, to be combined with the workstation(s) for wafer
handling.
[0060] Once a system has been specified in simulation-ready detail,
the site may simulate the system as shown in step 606. The
simulation may use, for example, the simulation module 206
described above. For diagnostic purposes, a hardware module may be
similarly simulated, or hardware module input/output may be
obtained from, or derived from, historical data in a data
repository, such as the data repository 304 described above. The
user may specify operating conditions, duration, speed, work
pieces, and the like, as well as selecting, for example, from an
array of potential fault conditions (e.g., cracked silicon wafer,
environmental vibration, faulty sensor, electro-magnetic noise, and
the like). In an embodiment, fault conditions may be simulated
within a hardware module, and a diagnostics module may be employed
to compare the simulated fault to the non-faulted simulation module
outputs.
[0061] As shown in step 608, the user may review results of the
simulation. In addition to reviewing input/outputs for the system's
software modules, a user may review a number of metrics for
evaluating the design, such as cost per work piece, throughput,
equipment purchase costs, total cost for life of equipment,
maintenance cost, costs for tooling user-specified custom parts,
and so forth. Side-by-side analysis may be performed of alternate
configurations, or of a single configuration under different
operating conditions. The site may also provide an analysis engine,
such as the analysis engine 302 described above to evaluate other
aspects of system performance, and compare performance to
alternative configurations using historical data in the data
repository 304.
[0062] As shown in step 610, a user may determine whether the
results are acceptable. If the results are not acceptable, the
process 600 may return to step 604 where the user may configure or
reconfigure a system.
[0063] If the results are acceptable, a user may proceed to enter a
purchase order as shown in step 612. The process 600 may also
convert the user's configuration into a specification for a
completed product including, for example, a parts list, operating
specifications and capacity, suggested replacement parts, and the
like. The purchase order itself may be executed in any manner, and
may include elements of immediate payment, as well as terms and
timing of additional payments due upon delivery and satisfactory
operation of the system. As shown in step 614, the process 600 may
then end.
[0064] It will be appreciated that the steps of the process 600 may
be varied or supplemented, or their order modified, without
departing from the concepts described herein. For example, a user
may be provided with an option to save a configuration for
subsequent review and modification, and a user may maintain a
library of saved designs. A library of designs may also be provided
to a user, from which a user may select designs for customization
and simulation. As another example data such as cost data may be
provided during the configuration step 604, and certain simulation
results may be displayed in real time during a simulation. The
purchasing step 612 may be omitted entirely from the computerized
process 600, with an actual purchase being conducted off line with
reference to a design configured and saved using the process 600.
Thus the process 600 described with reference to FIG. 6 is an
example only, and in no way limits the generality of the disclosed
business process for web-based design, simulation, and purchase of
robotic manufacturing equipment.
[0065] It will be appreciated that the process 600 may be realized
in hardware, software, any some combination of these suitable for
controlling a web-based design, simulation, and purchasing system.
The server side and client side of the process 600 may be realized
in one or more microprocessors, microcontrollers, embedded
microcontrollers, programmable digital signal processors or other
programmable device, along with internal and/or external memory.
Either the server side or client side of process 600 may also, or
instead, include an application specific integrated circuit, a
programmable gate array, programmable array logic, or any other
device that may be configured to process electronic signals. It
will further be appreciated that the server side or the client side
of the above process 600 may be realized as computer executable
code created using a structured programming language such as C, an
object oriented programming language such as C++, or any other
high-level or low-level programming language (including database
programming languages and technologies) that may be compiled or
interpreted to run on one of the above devices, as well as
heterogeneous combinations of processors, processor architectures,
or combinations of different hardware and software.
[0066] While the invention has been disclosed in connection with
certain preferred embodiments, other embodiments will be recognized
by those of ordinary skill in the art, and all such variations,
modifications, and substitutions are intended to fall within the
scope of this disclosure. Thus, the invention is to be understood
with reference to the following claims, which are to be interpreted
in the broadest sense allowable by law.
* * * * *