While today’s multi-discipline mechatronic systems significantly outperform legacy systems, they are also much more complex by nature, requiring close cooperation between multiple design disciplines in order to have a chance of meeting schedule requirements and first-pass success. Mechatronic system designs must fluently integrate analog and digital hardware — along with the software that controls it — presenting daunting challenges for design teams, and requiring design processes to evolve to accommodate.

What is Mechatronic Design?

Figure 1. Major elements of mechatronic design.
The growing trend toward mechatronic system design is driven by the same things that drive all technological advances: the demand for higher performance and lower costs. The word itself is a portmanteau of “Mechanics” and “Electronics.” As Figure 1 shows, mechatronic design includes a combination of (1) mechanical design elements (e.g., plant, actuators, thermal characteristics, hydraulics/fluids, and magnetics); (2) analog, digital, and mixed-signal electronics; (3) control systems; and (4) embedded software. The intersections in Figure 1 — (a) electromechanical sensors and actuators; (b) control circuits; and (c) digital microcontrollers — reveal the most common areas for interdisciplinary cooperation among mechanical, electrical, and software engineers.

Best Mechatronic Design Practices

Boston-based technology think tank, Aberdeen Group Inc., provided pivotal insight into the importance of incorporating the right design process and tools for mechatronic system design. In a seminal study, Aberdeen researchers used five key product development performance criteria to distinguish “Best in Class” companies, as related to mechatronic design. The results were fairly revealing (see table), and should be of significant interest within the extended design community. In the study, Best in Class companies proved to be twice as likely as “Laggards ” (worst in class companies) to achieve Revenue targets, twice as likely to hit Product Cost (manufacturing) targets, three times as likely to hit Product Launch Dates, twice as likely to attain Quality objectives, and twice as likely to control their Development Costs (R&D).1

The fact that the Best in Class companies performed better isn’t as noteworthy as the degree to which they performed better. Two to three times better on every variable invites the question, “How were they able to achieve these far superior results?” Aberdeen’s research revealed that Best in Class companies were:

  • 2.8 times more likely than Laggards to carefully communicate design changes across disciplines.
  • 3.2 times more likely than Laggards to allocate design requirements to specific systems, subsystems, and components.
  • 7.2 times more likely than Laggards to digitally validate system behavior with the simulation of integrated mechanical, electrical, and software components.

The remainder of this article will explore these “best in class” practices in further detail.

Communicating and Allocating Design Requirements

A mechanical engineer may be interested in dampening vibration by adding a stiffener. This, of course, would add mass and as a result, may impact how fast the control system ramps up motor speed, thus impacting size requirements on the motor as well as power requirements. The benefits of immediate, formal documentation of this design change enables concurrent, cross-discipline design.

Effective partitioning of the multiple technologies present in a mechatronic system is another significant predictor of project success. Subsystem partitioning begins with a common-sense breakdown of the design, using Figure 1 as a highlevel framework. To the degree possible, separate out mechanical subsystems from electrical subsystems, and the same with controls and software. From there, subsystems can further be broken down into subcategories beneath the high-level distinctions, including, for example, digital, analog, and mixed-signal electronics; divisions in mechanical subsystems; and breaking out overlapping areas (e.g., sensors and actuators) as additional subsystems.

Figure 2. Allocation of design requirements through a top-down design process.
Next, subsystems can be assigned to specific job functions and design groups, and input/output requirements can begin to be defined at the boundary crossings between subsystems.2 Figure 2 shows the partitioning process, moving from functional design through implementation.

With this framework in place, the design and analysis can begin for each subsystem — later to be combined and analyzed as a complete system.

Simulation and Virtual Prototyping

In contrast to physical prototyping, virtual prototyping and system simulation allows a system to be tested as it is being designed, and provides access to its innermost workings at every phase of the design process (this is difficult or impossible with physical prototypes). Moreover, simulation provides for analysis of the impact of component tolerances on overall system performance, which is out of the question with physical prototypes.

When employed early in the design process, simulation provides an environment in which a system can be tuned and optimized, and critical insights can be gained, even before components are available and before hardware can be built. After the basic design is locked down, simulation can again be em - ployed to verify intended system operation, varying parameters statistically in ways that would otherwise be impossible with physical prototypes.

Subsystem and Component Modeling

Results summary for the Aberdeen study: “System Design: New Product Development for Mechatronics.”
In order to create a model for a system, each subsystem and component in the real system needs to have a corresponding model. These models are then stitched together (as would be their physical counterparts) to create the overall system model. Using the Department of Defense-initiated VHDLAMS modeling standard (IEEE 1076.1), system integration can begin before physical hardware is available, including embedded software or any other domain that can be described using algebraic or differential equations.

To be specific, VHDL-AMS allows expression of simultaneous, nonlinear differential and algebraic equations in any model; the model creator need only express the equations and let the simulator solve them in time or frequency domain. Domain knowledge from any engineering discipline can be encapsulated in reusable libraries that are accessible by any member of the design team.

The art of creating these models, and knowing exactly what to model and why, are keys to successful simulation. Some modeling include:

  • Which system-performance characteristics are critical, and which can be ignored without affecting results?
  • Does a model already exist?
  • Can an existing model be modified?
  • What component data is available?

Several software simulators exist for simulating mechatronic designs (such as SystemVision from Mentor Graphics). These simulators support VHDL-AMS, SPICE, and embedded C code in providing an environment in which mechanical, electrical, software, and systems engineers can collaborate using common models and a common modeling environment3. In conjunction with proper mechatronic system-design training, careful interdiscipline communication, and deliberate system partitioning, simulation technology can play a key role in mechatronic project success.

This article was written by Bill Hargin, Director of Product Marketing, System-Level Engineering Division, Mentor Graphics Corporation, Wilsonville, OR. For more information, click here .


  1. Aberdeen Group, System Design: New Product Development for Mechatronics, Boston, MA, January 2008. (www.aberdeen.com)
  2. Scott Cooper, Mentor Graphics Corp., Design Team Collaboration within a System Modeling and Analysis Environment, 2004. (www.mentor.com/systemvision)
  3. Ashenden, G. Peterson, D. Teegarden, The System Designer’s Guide to VHDL-AMS: Analog, Mixed-Signal and Mixed-Technology Modeling. San Francisco: Morgan Kaufman Publishers, September 2002. (www.mkp. com/vhdl-ams)

NASA Tech Briefs Magazine

This article first appeared in the May, 2009 issue of NASA Tech Briefs Magazine.

Read more articles from this issue here.

Read more articles from the archives here.