IEEE/ASME TRANSACTIONS ON MECHATRONICS, VOL. 1, NO.
1, MARCH 1996
What is Mechatronics?
David M. Auslander
Abstract-With the explosively increasing costlsize-effectiveness
of computers, mechatronic systems are becoming common in any
engineering discipline dealing with the modulation of physical
power. In this article, I attempt a definition of mechatronics that
will allow for its differentiation as an identifiable field of
engineering and then follow this direction to discuss some of the
associated design philosophy. The definition draws on the
centrality of computing in mechatronic systems.
I. WHAT’S UNIQUE?
I F mechatronics is to be recognized as a discipline we
must articulate the aspects of it that set it apart from other
engineering activities. A definition that is too broad, by
encompassing everything, encompasses nothing. Likewise, to be
too narrow does not do justice to the richness of the field. I
believe that the uniqueness associated with mechatronics comes
from its exploitation of computation to create systems that are
qualitatively unlike any that came before. Although the name
implies that to be “mechatronic” a system must only contain
mechanical and electronic elements, that definition appears
much too broad to be useful. In other respects it is too
narrow. I see mechatronics including many physical systems,
not just traditional mechanical systems. It also begs the question
of what software is and ‘how it fits in, which is understandable
since control software was not a significant
factor in the early 1970’s when the term was coined. Software is
currently implemented using electronic deviczs,
but is really a medium in itself, independent of implementa-
tion. It is the source of unparalleled complexity-for better or
worse! Engineering systems with software based control can
work miracles, but the technology also brings risks. New
technologies call for new methodologies but people don t
change their ways of thinking easily.
I think that this at least lays the groundwork for a
definition of mechatronics that fits current technology and
has some hope of covering future developments as well.
11. DEFINITIONOF MECHATRONICS
The application of complex decision making to the
oper-ation of physical systems.
“Complex decision making” covers today’s software and
distinguishes modern mechatronics from earlier attempts at
complexity. It identifies as “mechatronic” systems that depend
for their unique functionality on software. It also identifies as
practitioners of mechatronics those who have the skills and
understanding to create and manage the complexity.
Manuscript received October 11, 1995; revised December 12, 1995.
The author is with the Department of Mechanical Engineering, University
of California, Berkeley, CA 94720-1740 USA.
Publisher Item Identifier S 1083-4435(96)02287-9.
10834435/96$05.00 0 1996 IEEE
5
This definition is a generalization of the original definition
of mechatronics which encompassed mechanical components
and electronically based decision making (digital and analog
circuitry). The term “mechatronics” has been attributed to the
Yaskawa Electric Co. in the early 1970’s, although I have not
seen any authority for that attribution. It makes sense in the
context, for example, of the brushless dc motor which uses
electronics for its commutation decisions rather than relying
on mechanically based decision making and, in the process,
results in a motor with dramatically different properties than
the original.
With the advent of computing as the preferred decision-
making medium, the definition needed to be broadened. It has
also become evident that a wider variety of physical systems
can be encompassed than just mechanical motion. Examples
of these include traditional mechanical systems such as
machine tools, manufacturing automation, as well as vehicle
control (automotivie, airplanes), process systems, thermal and
environmental control, building vibration control, etc.
Finally, it seems likely that while software (algorithmic
languages) is the current decision-making medium, other
tech-nologies could supplement or supplant it. Current
candidates include artificial neural nets and fuzzy logic. Thus,
the defi-nition points to the centrality of decision making
rather than the means of realizing it.
A. Examples
Some examples can flesh out this definition. In the auto-
motive area, for example, mechatronic engine controls have
enabled the modern automobile to simultaneously meet emis-
sion, fuel economy, and drivability specifications that could
not be duplicated using the traditional engine controller, the
carburetor. This is an example in which a mechatronic
solution produces essential pegormance improvements.
Another example is the modern machine tool. The CNC
controller defines the operation and use of such a machine.
The entire manufacturing process has been affected, from
designing the parts to be manufactured to the potential for
fully automatic, untended operation of the machines. This is a
case in which the introduction of mechatronics to an existing
technology resulted in a qualitative improvement.
The above examples show the application of mechatronics
to existing technologies. An example of a technology that is
impossible without mechatronics is the automated teller
machine (ATM) used to deliver cash to bank customers. Such
a machine is not even conceivable without mechatronics.
Finally, as noted above, new technologies carry new risks with
them. A recent spectacular example of the risk at work is the
baggage handling system for the new Denver International
6 IEEEIASME TRANSACTIONS ON MECHATRONICS, VOL. 1, NO.
Airport [3] .Failures attributed to the software controlling the
highly automated baggage-handling system caused nearly a
year-and-a-half delay in opening the airport at a cost of the
order of a billion dollars.
111. CONTEMPORARYREALIZATION
Computers of all sizes and capabilities are used as the
decision making elements in products affecting virtually every
resident in the developed world. From a numerical perspective,
the most common type of computer in use today is the micro-
controller-very small, highly integrated microprocessors used
as decision-making elements in engineering systems. Several
hundred million of these are sold every year!
The following item from a daily newspaper highlights
the extent to which embedded computing in a mechatronics
context is entering daily life and consciousness:
SIDEBAR: USA Today, May 1, 1995, page 1B
USA SNAPSHOTS-A look at statistics that shape
your finances
Micromanaging our lives
Microcontrollers-tiny computer chips-are now run-
ning things from microwave ovens (one) to cars (up to
IO) to jets (up to 1000).
How many microcontrollers we encounter daily:
1985 less than 3
1990 10
1995 50.
IV. A DESIGNPHILOSOPHY
The unique factor in mechatronics is its dependence on
sophisticated real-time computation to define the nature of
the engineering system in which the computation is em-
bedded. Successful mechatronic system designs require an
organized approach to the design of such software. As part of
the introduction of mechatronic principles, a focused design
methodology will be followed so that conceptualization and
documentation of mechatronic software can be done indepen-
dent of the medium used for its implementation.
A. A History of Increasing Complexity
Technological history shows that there has always been a
striving for complexity in mechanical systems. The follow-
ing list shows some examples of machines that show the
marvelous ingenuity of their inventors:
(not strictly chronological!);
Watt governor;
Jacquard loom;
typewriter;
mechanical adding machine;
pneumatic process controller;
carburetor;
sewing machine;
tracer lathe;
cam grinder.
A diagram of the Watt steam engine speed control (gover-
nor) is shown in Fig. 1. As the engine speeds up, the flyballs
1, MARCH 1996
K -
Steam
Engine Main Sha?
Fig. 1. The Watt speed governor
I 1
software. eledronics
Fig. 2. Mechatronic system elements.
spin outward, moving the linkage so as to close the steam
valve and thus slow the engine. This oft-quoted example of an
early feedback control system is typical of the systems on this
list-its decision making (computation) is done in the same
medium as the major power flows in the system. This makes
these systems premechatronic for reasons discussed below.
B. Mechatronic System Organization
The developments in electronics have made it possible to
energetically isolate the four central components making up a
controlled mechanical system, Fig. 2:
Computation: At the center;
Actuation: Controlling power delivery;
Instrumentation: What's happening;
Target System: What all the fuss is about!
In addition, the peripheral elements connect the mechatronic
system to the world of its operators and managers:
Operator Integace: Normal and emergency;
Other: Communication with other systems, etc.
Once isolated from the instruments on one side and the
actuators on the other, computation could be implemented
using the most effective computing medium, independent of
any needs to pass power through the computational element.
That medium has been the digital computer, and the medium
of expression for digital computers is software.
This ability to isolate is recent. Watt's speed governor, for
example, combined the instrument, computation and actuation
into the flyball element. Its computational capability was
severely limited by the necessity that it pass power from the
power shaft back to the steam valve. Other such examples, where
computation is tied to measurement and/or actuation, include
automotive carburetors, mastered cam grinders, tracer
AUSLANDER: WHAT IS MECHATRONICS?
Fig. 3. Operational amplifier; computing configuration.
lathes, DC motor commutation, timing belts used in a va-
riety of machines to coordinate motions, rapid transit car
couplings (which are only present to maintain distance; cars
are individually powered), and myriads of machines that use
linkages, gears, cams, etc., to produce desired motions. Many
such systems are being redesigned with software based
controllers to maintain these relationships, with associated
improvements in performance, productivity (due to much
shorter times needed to change products), and reliability.
C. Amplijiers and Isolation
The development of electronic amplification techniques
opened the door to mechatronics. Operational amplifier (op-
amp) based circuits, such as that shown in Fig. 3, could provide
both isolation and generation of a wide variety of linear and
nonlinear, static and dynamic computing functions.
Fig. 4 shows an alternate operational amplifier configu-
ration, which provides even stronger isolation, but cannot
perform as flexible computation.
Developments in power electronics provided the same kind of
flexibility and isolation on the actuation side that op-amps
provide on the signal side, and gave a means for translating
commands computed in electronic form into action.
Digital electronics added enormously to the range of com-
putational functions that could be realized. Digital electronics
also formed the basic technology for implementing
computers, but with the use of computers it is software rather
than electronics that represents the medium of expression.
Although mechatronics based on electronic computing
elements opened a new world of mechanical system control,
software has extended that world in unimaginable ways.
Because this software must operate within timing and
response constraints imposed by the system under control, it
is known as real time software and, by the present definition,
is at the heart of mechatronic systems.
V. REAL-TIMESOFTWARE
Real-time software differs from conventional software in
that its results must not only be numerically and logically
correct, they must also be delivered at the correct time. A
design corollary following from this definition, is that real
time software must embody the concept of duration, which,
again, is not part of conventional software. An example
showing the need of on-time delivery of results is given in
Fig. 5. In the masterless cam grinder the rotation of cam must
be precisely coordinated with transverse motion to cut the
noncircular cam profile.
4
Fig. 4. Operational amplifier; follower configuration.
Grindstone
/"'\
Fig. 5. Masterless cam grinder.
This is an excellent example of how mechatronics can
change the way thlat problems are approached. In a conven-
tional, mastered, cam grinder the motion is controlled by a
mechanical system which traces the contour of a master cam.
The mechanical tracing mechanism must fill the role of
computation (transmission of the desired contour) but also
carry enough power to operate the follower mechanism. This
is a limit to performance, and causes considerable loss of
productivity since the time to change the machine from one
cam profile to another is considerable.
In the mechatronic-based cam grinder, the profile is stored
as an array of numbers in software, so the machine's
performance is limited only by its inherent mechanical
properties and the ability of the control computer to store and
process the data. Changeover is also much faster since it only
requires loading of new data.
The real-time software used in most mechanical system
control is also safety-critical. Software malfunction can re-
sult in serious injury and/or significant property damage. In
discussing software-related accidents which resulted in
deaths and serious injuries from clinical use of a radiation
therapy machine (Therac-25), [4] established a set of
software design principles, ". . . that apparently were violated
with the Therac-25 . . ." Those are the following.
Documentation should not be an afterthought.
Software quality assurance practices and standards
should be established.
Designs should be kept simple.
Ways to get information about errors-for example, soft-
ware audit trails-should be designed into the software
from the beginning.
The software should be subjected to extensive testing
and formal analysis at the module and software level;
system testing alone is not adequate.
8 IEEE/ASME TRANSACTIONS ON MECHATRONICS, VOL. 1, NO. 1, MARCH 1996
In particular, it was determined that a number of these
prob-lems were associated with asynchronous operations,
which while uncommon in conventional software, are the
heart and soul of real-time software. Asynchronous operations
arise from preemptive, prioritized execution of software
modules, and from the interaction of the software with the
physical system under control.
Because of preemptive execution, it becomes impossible to
predict when groups of program statements will execute
relative to other groups, as it is in synchronous software.
Errors that depend on particular execution order will only
show up on a statistical basis, not predictably. Thus, the
technique of repeating execution until the source of an error
is found, which is so effective for synchronous (conventional)
software, will not work with for this class of real time error.
In a like manner, there are errors that depend on the
coincidence of certain sections of program code and events
taking place in the physical system. Again, because these
systems are not strictly synchronized, they can only have
statistical characterization.
A. Nasty Software Properties
Software complexity tends to increase exponentially with
size. What starts out as a small, manageable project, can ex-
pand into something which, quite literally, never gets
finished. To compound this problem, the economics of
software based products is that over the lifetime of the
product, maintenance costs dominate the total expense.
Both the complexity and the asynchronous nature of real-
time software lead to situations in which bugs can remain
dormant for long time periods, waiting to do their dirty work
at the most inopportune time.
The antidotes to these problems flow from adopting an
engineering perspective so that code writing (programming)
should not be viewed as a creative activity!
On the engineering side, a method must be found to
describe in detail how the control software should behave. This
allows both for the needed engineering review function and
enables the act of code production to become much more routine
since the creative engineering part has been done at the
descriptive level.
The second way of avoiding at least some of the
complexity problems is to modularize the software and its
production process. In this way, specific pieces of software
are directly connected to certain machine functionality.
System malfunc-tions can thus be traced to the relevant
software more quickly, system changes can be made with
reasonable assurances that the changes will not adversely
affect some unexpected part of the machine, and individual
software elements can be tested more easily.
B. Engineering DesignKornputational Perj4ormance
Too often, the only detailed documentation of real-time
software is the program itself. Furthermore, the program is
usually designed and written for a specific real-time target
environment. The unfortunate consequence of this is that the
engineering aspects of the design problem become inextricably
intertwined with the computation aspects. This situation
relates directly to the first design principle listed above,
“documenta-tion should not be an afterthought.” If the
system engineering is separated from the computational
technology, then the documentation will have to exist
independent of the program; otherwise, documentation can be
viewed as an additional burden.
The following definitions will be used to separate these
roles as they appear in the proposed methodology:
System engineering: Detailed specification of the relation-
ship between the control software and the mechanical sys-
tem.
Computational technology: A combination of computa-
tional hardware and system software that enables
application software based on the engineering specification
to meet its operational specifications.
Using these definitions, the engineering specification de-
scribes how the system works; the computational specification
determines its peformance. As a result of this separation, if a
suitable paradigm is adopted to describe the engineering
specification, a much broader discussion and examination can be
brought to bear because, the details of the engineering can be
discussed by project participants familiar with the problem, not
just those familiar with computing languages and real time
programming conventions. This provides for meaningful design
review of projects that are software intensive.
C. Software Portability
In mechanical system control, portability has consequences
both for product lifetime and for the desigddevelopment
cycle. The mechanical part of the system can have a
commercial lifetime of anywhere from 5-20 years. On the
other hand, the computational technology used for its control
only has a lifetime of 3-5 years. To remain competitive, new
versions of the product need to use new computers to take
advantage of the ever-increasing computational capability.
Doing this cost-effectively requires software that will “port”
easily from the original target processor to new ones.
Software portability seriously affects the de-
sigdimplementation cycle as well. Early stages of the
software tend to be simulations, done to test hypotheses and
to substitute for hardware not yet built. Later stages use
laboratory prototypes, then pilot prototypes, then, finally, the
actual production system. If software can’t migrate from step-
to-step in this process, the whole process can become greatly
elongated as new software must be created for each step, and
there are significant possibilities for introducing new bugs at
each stage.
Portability is complicated by the real-time constraints.
If real-time software environments are used as aids in
meet-ing those constraints (kernels, schedulers, real-time
operating systems), software written for one environment
can require substantial rewriting to run in another.
Crossing the full spec-trum from simulation to production
traverses environments in which program structure itself
is incompatible. The proposed methodology provides a
layer of abstraction one higher than
AUSLANDER: WHAT IS MECHATRONICS?
the real-time environments, so offers a means of bypassing
these incompatibility problems.
Further portability challenges arise from the operator inter-
face section of the program, and the interprogram communica-
tion for those solutions implemented with multiple processors.
D. Control System Organization
A two-level organization is used on both the engineering
and computational sides of the control software design. On
the engineering side, a job is organized into
tasks
states
and, on the computational side, into
processes
threads.
The breakdown of the engineering specification into tasks
and then states is a subjective process, requiring considerable
engineering judgment. This stage is the primary creative
design step.
Tasks represent units of work; they are the functional sub-
units of the job. Tasks can often be designed by breaking a
system down along both time scales and physical components.
For example, there might be separate tasks to handle the high-
level part of controls for several motor-driven axes, and other
tasks to handle the higher-speed operations associated with
measurement and actuation of those same motors.
Tasks, in general, are active simultaneously. They are used
to describe the parallelism inherent in the physical system.
Internally tasks are organized in a strictly sequential manner
into states [l], [2], [5] , and [ 6 ] . States describe specific
activities within the task; only one state can be active at a time.
The active state controls the current activity of the task.
The primary reason for this distinction between the nature
of tasks and states is that sequential activity is a part of many
mechanical systems. Even for systems that do not seem to be
fundamentally sequential, such as process or web systems,
the sequential breakdown within tasks seems to work quite
well. During normal operation, tasks tend to stay in only one
or two states. However, during start-up and shutdown, the
taskhtate structure describes the operation very well.
The sequential state structure also serves as one test for
appropriate task definition. If tasks are aggregated to much,
they will end up with parallel operations which cannot be
described effectively by states. Breaking the task into several
smaller tasks solves the problem.
On the computational side, processes describe computa-
tional entities that do not share an address space (this includes
independent processors). Threads are computational entities
that share an address space but can execute asynchronously. A
thread can contain one or more tasks; a process can contain one
or more threads.
9
The organization into processes and threads is purely for
performance purposes. As is noted below, there is no theoret-ical
necessity for such organization at all. The organization serves
only to meet performance specifications when the chosen
processor is not sufficiently fast to meet the specs with a single-
thread structure. It does this by shifting processor resources from
low-priority to high-priority tasks. As a further note, the
portability requirements enumerated above imply that several
different computational organizations will be used in the course
of a development project.
VI. CONCLUSION
I have presented an approach to the definition of what
constitutes the field of mechatronics and an approach to the
design of systems based on that definition. The purpose for
doing this is to establish the central skills and experience that
are expected of those who are or wish to be mechatronics
specialists. If that is not done, mechatronics will remain a
loosely defined “mterdisciplinary” area which will greatly
hamper attempts to move the field forward in a reasonably
orderly way and will make it difficult to define educational
paths that will lead to this specialty. I expect that not all
readers share this vision of mechatronics but I hope that this
article might lead to enough further discussion so that a
consensus definition will emerge-perhaps in the pages of
new journal.
REFERENCES
D. M. Auslander and P. Sagues, Microprocessors for Measurement and
Control. Berkeley, CA: OsborneiMcGraw-Hill, 1981.
D. A. Dornfeld, I).M. Auslander, and P. Sagues, “Programming and op-
timization of mull i-microprocessor controlled manufacturing
processes,” Mech. Eng., vol. 102, no. 13, pp. 34-41, 1980.
W. W. Gibb, “Software’s chronic crisis,” Sei. Amer., pp. 8 6 9 5 , Sept.
1994.
N. G . Leveson and C. S. Turner, “An investigation of the Therac-25
accidents,” IEEE Computer, July 1993.
M. J. Simms, “Using state machines as a design and coding tool,”
Hewlett-Packard J., vol. 45, no. 6, Dec. 1994.
P. T. Ward and S . J. Mellor, Structured Development for Real-Time
Systems. Englewood Cliffs, NJ: Prentice-Hall, 1985.
David M. Auslander completed undergraduate
studies at the Cooper Union and graduate studies at
MIT, both in mechanical engineenng.
He is currently a Professor of Mechanical
Engineenng at the University of California at
Berkeley, and has interests in dynamic systems and
control. His research and teaching interests include
bloengineenng, mechanical control, and real-time
software. Current projects in these areas are cardiac
signal analysis, nanometer mechanical positioning,
design methodology for real-time control software,
and control of bioregenerative life-support systems He conwlts in industrial
servo control systems and other control and computer applications.
Dr. Auslander is a member of ASME.