Mechatronic system integration and design
www.mentor.com
3
[
5
]
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 design changes across disciplines
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, and power requirements. The benefits of immediate, formal documentation of this
design change enables concurrent, cross-discipline design.
allocation of design requireMents to specific systeMs,
suBsysteMs, and coMponents
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 high-level 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.
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. 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.
Figure 2: Allocation of design requirements through a top-down design process.