for my classmates who might need a review of my session

1. MECHATRONICS-
DESIGN APPROACHES
ANAND RONALD K

2. Machine design requires effective communication between engineering
disciplines

3. To maintain a leadership position, machine builders are designing
increasingly complex machines

4. Traditional sequential design approaches do not meet today’s machine design challenges, so
designers are switching to mechatronics

5. Challenges in mechatronic design
Both academic and industrial sources have reported on challenges
related to the design and development of mechatronic systems, such as:
• Exchange of design models and data [2,6].
• Cooperative work and communication among the design engineers
[2,5,6,9,10].
• Multidisciplinary modeling [4,7,9].
• Simultaneous consideration
• Early testing and verification [5,7,9].
• Persistence of a sequential design process [2,4,10].
• Lack of tools and methods supporting multidisciplinary design [2,4,5,11].
• Support of the design of control software [3,5].

6. Design Methods
The core of traditional concurrent engineering approaches (see e.g., [15]) is
to consider all phases of the life cycle of the product as early as possible in the
design in order to deal with issues related to later life-cycle phases, such as
production and disposal [16]. But even traditional concurrent approaches have
proven to be limited when dealing with complex design situations, in the sense
that strong interdependencies might have unpredicted effects on the overall
performance [4].
As mentioned by Wikander et al. [4] and Rzevski [14], a typical approach for
the design of Mechatronic systems is to build the system by assembling single-
domain subsystems and by paying special attention to the design of interfaces
among them. Wikander et al. remark that such traditional methods can merely
achieve a sound integration of the components (i.e., “something that works”), but
not a synergetic integration. Therefore, research on mechatronics should also
focus on the interactions of the different engineering disciplines [4] rather than
only on the interactions between the subsystems that are being designed.

7. • In mechanical design, dimensions, shapes, and materials that correspond to
the physical objects are the main interest. Thus, representing abstract
concepts and grouping parts according to other criteria than physical
proximity become problematic.
• In the design of controllers, the physical system, also referred as the plant,
is often abstracted to a black box model. From such point of view it is
difficult to find the explicit connection between the behavior and its
physical causes.
• Electronics deals with the physical implementation of the control. The
software packages for electronic design support predictions of behavior
and execution time through logical and physical simulations.
• Electric engineering commonly designs “bridge” objects from electronic and
mechanical domains, and tools related to it focus on the connectivity of
components and the communication among them.
• Requirement management and capture tools focus on representing textual
requirements information. The link to other design domains is mainly
made through document referring, and it is the job of the user to
(informally) connect such documents with the current design data.

8. ECAD TOOLS

9. The Necessity of MCAD – ECAD
Integration
For companies that design mechatronic products, staying
competitive in today’s market means using design systems that unify the
design process and allow the smooth flow of design data across the
electro-mechanical divide. As the electrical and electronic products and
the processes creating them evolve, the “fundamentally dissimilar worlds
of electronic [and electrical] and mechanical design need to work in
harmony.
Integrated design of mechatronic products can be realized through
the integration of mechanical and electrical CAD systems. One approach to
achieve this type of integration of is through the propagation of
constraints. Cross-disciplinary constraints between mechanical and
electrical design domains can be classified, represented, modeled, and bi-
directionally propagated in order to provide immediate feedback to
designers of both engineering domains.

10. Example of an interdisciplinary constraint
between a MCAD and an ECAD model

11. APPROACH 1: Bond graph method
BG modeling of a mechatronic system can be viewed as an object-oriented
modeling method [7]. The concept of object-oriented modeling means that
different subsystems of a mixed machine can be modeled separately and be
interconnected to create the overall model.
A typical machine has a hierarchical structure. The system may be composed of
some lower-level subsystems and each subsystem may also consist of some
lower-level subsystems. In object-oriented BG modeling, the model of each
subsystem can be considered as an object. Consequently, a general model for
components that commonly appear in mechatronic systems can be established
and reused wherever it is necessary.

12. APPROACH 2: Constraint Modelling
The procedure of the proposed constraint modelling approach is listed as
follows:
STEP 1: List all components of the mechatronic system and their attributes
and classify the components in either the mechanical domain or the
electrical domain.
STEP 2: Based on the attributes of the component, draw the constraint
relationship between the components in the domain and appropriately
label the constraint by the constraint categories.
STEP 3: Based on the attributes of the component, draw the constraint
relationship between the components across the domains and
appropriately label the constraint by the constraint categories.
STEP 4: Construct a table of constraints for the particular mechatronic system.
The table contains a complete list of the every component of the
mechatronic system, the table is to indicate that, when a particular
attribute of the component is being modified, which attribute of which
component (both within the domain and across the domain) would be
affected.

13. Constraint Categories
Constraint in the Mechanical
Domain:
• Geometric Constraints
• Kinematic Constraints
• Force Constraints
• Energy Constraints
• Material Constraints
Constraints in the electrical
domain:
• Electrical Resistance
• Electrical Capacitance
• Electrical Inductance
• Motor Torque
• System Control

14. APPROACH 3: Declarative and
Procedural Modeling
Many early simulation languages were based on the Continuous
System Simulation Language (CSSL) [20]. They were procedural in nature,
meaning that models were defined through assignments as is common in
most programming languages. Assignments express a dependent variable
as a function of independent variables (fixed causality), and have to be
evaluated in the order defined by the user. This limits the reuse of
procedural models and prohibits symbolic manipulation. Declarative or
equation-based languages, on the other hand, do not impose a fixed
causality on the model. In these languages, the model is defined by a set
of equations that establishes relations between the states, their
derivatives, and time. The simulation engine is responsible for converting
these equations into software procedures that can be evaluated by the
computer. The advantage of declarative languages is that users do not
have to define the mathematical causality of the equations, so that the
same model can be used for any causality imposed by other system
components.

15. MEMS

16. APPROACH 4: COLLABORATIVE
MODELING
Design of complex multi-disciplinary systems requires the expertise of a group
of collaborating specialists: Designers with backgrounds in different disciplines
collaborate with analysts, manufacturing engineers, marketing specialists, and
business managers.
To coordinate design processes among geographically dispersed and
multidisciplinary teams, many global enterprises have taken advantage of
computer aided engineering (CAE) technologies that provide sharing,
visualization, documentation, and management of product models [72-77].
However, the aspect of collaborative simulation modeling is still in its infancy. To
support collaborative modeling, design teams need common, shared model
representations, repositories to manage model components, and model
abstraction capabilities to provide different views of models to designers.