MECHATRONICS-DESIGN

APPROACHESANAND RONALD K

Machine design requires effective communication between engineering disciplines

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

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

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].

Design MethodsThe 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.

• 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.

ECAD TOOLS

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.

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

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.

APPROACH 2: Constraint ModellingThe 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.

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

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.

MEMS

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.

CASE STUDIES

CASE STUDIES