2.design mecatrónica

8/10/2019 2.Design Mecatrnica

1/45

1540 Introduction To Mechatronics 1Stefan Williams

Introduction to Mechatronics

Mech-1540

Stefan B. Williams

Research Fellow of Mechatronic Engineering


2/45


Schedule of Events

Q 2 of Assign 2MID SEMESTER BREAK

Spare19/614

Due 13/6Major Assignment12/613

Case Study : Unmanned Air/Land/Sea Vehicles5/612

Case Study : Formula SAE29/511

Active Sensor Systems (Graham Brooker)22/510

Due 16/5Assignment 2 - Control and Modelling15/59

Q 4 of Assign 2System Modelling and Control8/58

Q 3 of Assign 2Computer Software and Design Tools1/57

6

5

4

3

2

1

Week

17/4

10/4

3/4

27/3

20/3

13/3

Date

Computer Hardware

Assignment 1 Design Exercise

Sensors

Actuators

Design Process

Introduction

Content

Q 1 of Assign 2Due 11/4

Q 3 of Assign 1

Q 2 of Assign 1

Q 1 of Assign. 1

Assignment Notes


3/45


What is Engineering Design?

Engineering Design is the systematic,

intelligent generation and evaluation of

specifications for products whose form and

function achieve stated objectives and satisfyspecified constraints

The purpose of design is to derive from a set

of specifications a description of a product

sufficient for its realization


4/45


Why is Engineering Design important?

It provides us with

A methodology to be followed in the search for a

solution to a recognized problem

A set of requirements that characterize asuccessful solution to the problem

A means of managing increasingly complex,

technological problems by breaking the task of

finding a solution into smaller sub-system design

problems


5/45


The Design Process

Problem Identification Systems Design

System Specification

Systems Modelling

Implementation Component Selection

Component Testing

System Integration

System Verification Iteration

Operation and Maintenance


6/45


The Product lifecycle

Concept

Exploration

System

Definition Engineering

Development

System

Qualification

Deployment

Operation &

Maintenance

Production

Disposal


7/45


Design models : The Waterfall

Requirements

Design

Implementation

Testing

Integration

Operation and

Maintenance


8/45


Design models : The Spiral

Determine goals,alternatives,

constraints

Evaluatealternatives and

risks

Develop

and testPlan

Implementation Plan

Integration & Test Plan

Development Plan

Requirements,

lifecycle PlanConcept of

operation

Acceptance test

Validated design

Validated reqts

Detailed

Design

Initial

design

Reqts

Risk analysis

Risk analysis

Risk analysis

Risk analysis

Problem

Identification

Alternatives,

constraints

Alternatives,

constraints

Alternatives,

constraints


9/45


Design

Implement

Integrate

Design

Implement

IntegrateDesign

Implement

IntegrateDesign

Implement

IntegrateFirst Sub-system Tier

System

Integration

Contract Boundary

Verification

Design

Implement

Integrate

Tier n

Concept

Definition

System

Design

Operational

Evaluation

Design Models: The System V


10/45


The Design Process



Systems Modelling


Component Testing

System Integration




11/45


Problem Identification

Identify problem to be solved

talk to the customer

acquire domain knowledge

expertise to be brought to bear Clarify the problem domain

identify the problem boundaries

develop design parameters that allow comparative

judgement of competing designs


12/45



Understanding

operational concept

system context

major states and modes of the system identify other unstated needs

Discussion of potential solutions

proposal of various solution concepts

brain storming

lateral thinking

interaction with customer


13/45



Design constraints must be identified Restrictions or limitations on a behaviour or a

value or some other aspect of a designed objectsperformance

Requirement analysis allows us to verify that we have reached a solution

a description of the requirements that characterisea solution

the criteria to be used to verify that therequirements have been met

produces an understanding of the nature andscope of the remaining activities


14/45


Sources of Requirements

Customer Requirements

Contract documents and standards

Operational Concept Descriptions (OCD) etc.

Derived Requirements To correct ambiguity or incomplete requirements

Implied or transformed from higher-level

requirements

Allocated Requirements Divided or allocated to multiple lower level

requirements


15/45


Planning and Project Management

Managementis the process of achievingorganizational goals by engaging in the fourmajor goals of planning, organizing, leadingand controlling

Involves planning major and minormilestones of design process

Time line and allocation of availableresources to complete the job

Project scope, spending and schedule mustbe estimated and tracked during theremainder of the design process


16/45


Time Lines

ID Task Name Start End Duration

Mar 2003 Apr 2003 May 2003

3/16 3/23 3/30 4/6 4/13 4/20 4/27 5/4 5/11 5/18 5/25

1

2

5

6

7

8

9

5d21/03/200317/03/2003Problem Identification

20d17/04/200321/03/2003Systems Dessign

20d15/05/200318/04/2003Implementation

5d24/04/200318/04/2003Component Selection

15d15/05/200325/04/2003Component Testing

10d29/05/200316/05/2003System Integration

5d5/06/200330/05/2003System Verification

4

3 10d3/04/200321/03/2003System Specification

15d17/04/200328/03/2003System Modelling

Jun 2003

6/1 6 /8 6/15 6 /22

An example of a Gantt Chart a graphical representation of the time line and

interrelationship between tasks


17/45


The Design Process



Systems Modelling


Component Testing

System Integration




18/45


Characteristics of a System

A complex set of interrelated elements

working together to fulfill some designated

need

must be functional and able to respond to thatneed

Sub-systems can be equipment, materials,

software, people, and other systems

A system is contained within some form ofhierarchy

Sub-systems are not necessarily technology-

based


19/45


Systems Engineering

The design of the whole as distinct from the design

of the parts

A structured way of handling complexity

Defines the interfaces between major components of

the system

The best way to maximise probability of a successful

outcome

But it is not.

A silver bullet

A cookbook approach to success

An excuse to stop thinking


20/45


Why do we Need Systems Engineering ?

Simplification of Complex Systems

Control Design Process

Flow down of System Requirements to

Component Level Facilitate Progressive Testing (flow up)

Production and cost approximately 90% ofthe cost of production determined during

design phase ENSURE FINAL PRODUCT MEETS

REQUIREMENTS


21/45


The Systems Engineering as

Front End

System

Design

Design

Implement

Integrate

Design

Implement

IntegrateDesign

Implement

IntegrateDesign

Implement

Integrate

System

Integration

Concept

Definition

Operational

Evaluation

Tier 0

Tier 1

Tier 2

Inte

gratio

n

Decompositio

n

TheFrontEnd


22/45


System Specifications

Specifications are precise descriptions of the

properties of the object being designed

Design specifications articulate in a numerical or

measurable way what a design is supposed to do and

provide the basis for evaluating that designPrescript ive specif icat ions specify values of attributes that

designed object must meet to be successful

Procedural specif ications identify procedures or methods

to be used in calculating attributes

Performance specif icat ions characterise the desired

behaviour or performance of the system


23/45


Interface Specifications

Specifications are also required for the

internal components of the system

The interface between components must be

specified to enable the problem to be brokenup into manageable sub problems

Interface specifications should be formalized

in sufficient detail to minimize ambiguity and

the need to reformulate interfaces in thefuture


24/45


Modular Design

Desirable attributes of modular system

components,

Low Coupling

High Cohesion Well defined interfaces between components


25/45


Modular Design

Definition,

Coupling - a measure of the relative

interdependence between subsystems.

Simple connectivity among subsystems results in a

system that is easier to understand and less prone to aripple effect when errors or changes occur in another

part of the system.

Cohesion - a measure of the relative functional

strength of a subsystem. A cohesive subsystem performs a task with littleinteraction with other parts of the system.


26/45


Modular Design

In summary, develop subsystems with,

single-minded function.

an aversion to excessive interaction with other

subsystems.


27/45


Systems Modelling

Modelling of

overall response of the system

individual components of the system

Models allow us to predict the systembehaviour

Will it meet our design constraints?

Will the system be stable?

What components are required for the system?

What are the characteristics of those components?


28/45


The Design Process



Systems Modelling


Component Testing

System Integration




29/45


Component Selection

Selection of appropriate components to meet

design constraints and fulfil system design

Identification of commercial off-the-shelf

(COTS) and specialised components Verification that components meet the

models formulated during systems design


30/45


l The design of a Component is not affected by the

size or complexity of the System it is used in.

l The design of a component is driven by three

requirements:

l Form

l Fit

l Function

Design of Components

Physical

-Size

-Shape

-Weight

-CG

-Inertia

Interfacing

-Mechanical Interfacing (fixing)

-Electrical Interfacing

-Communication / Data Interfacing- Effect of function

What it does &

How it does it

-Performance

-Environment


31/45


Exercise - Design of Components

Consider 2 components from vastly different systems:

System 1. An electronic automatic garage door.

Component: Actuator to open and close the door.

System 2. A Ship Based Theatre Air Defence System

Component: Actuator to move the missile control fins

Q1. What information is required to design or select an

appropriate actuator for each case?

Q2. How do you determine that information?


32/45


The Design Process



Systems Modelling


Component Testing

System Integration




33/45


Requirements

Analysis

Functional Analysis/

Allocation

Synthesis

Requirements

Analysis


Allocation

Synthesis

RequirementsAnalysis

Functional Analysis/Allocation

Synthesis

Requirements

Analysis


Allocation

Synthesis

Component Implementation

Requirements

Analysis


Allocation

Synthesis



Allocation

Synthesis


Functional Analysis/Allocation

Synthesis

Unit

Verification

Sub-system

Verification

System

Verification

Integrate Correct

Integrate Correct

Integrate Correct

Verification

Criteria

Verification

Criteria

Verification

Criteria

Design

Im

ple

ment

The Implementation Leg


34/45


System Integration

Integration of the individual components toform the system

Verification of individual sub systems

typically undertaken during this stage Do the system components meet the

specifications?

Do the interface specifications accurately

capture the final system configuration?


35/45


Definitions

Integration: The merger or combining of two or morelower level elements into a functioning or unifiedhigher level element with the logical and physicalinterfaces satisfied.

Verification: Confirmation by examination andprovision of objective evidence that the specifiedrequirements to which an end product is built, codedor assembled have been fulfilled.

Validation: Confirmation by examination and

provision of objective evidence that the specifiedintended use of an end product or aggregation of endproducts is accomplished in an intended usageenvironment.


36/45


Design for Integration

Multiple levels of integration and verification

Each level corresponds to the design

hierarchy

The interfaces between all components mustbe defined

The interfaces between the system and

external systems must be defined

Engineering models and prototypes can

assist the design and implementation

process


37/45


The Design Process


Systems Design


Systems Modelling


Component Testing

System Integration

System Verification

Iteration



38/45


System Verification

Verification of the system performance

Does the system meet our requirements?

If the system or some component of the

system does not meet the specification, whynot? Can it be rectified?


39/45


40/45


Integration and Verification

Problems

Plans must cover what to do if integrationproblems or verification failures occur

Corrected at the next level down or design

where necessary Dealing with COTS

Undocumented features

Not developed for the environment

Defined behaviour and interfaces

Support


41/45


The Design Process


Systems Design


Systems Modelling

Implementation

Component Selection

Component Testing

System Integration

System Verification

Iteration



42/45


Iteration

For any subsystems that do not meet thedesign requirements, some iteration may be

required

Iteration can occur at any stage in the design the earlier the better

Changes to design will have a cascading

effect on remainder of system design

Proper and thorough systems design should

minimize the need for change


43/45


The Design Process


Systems Design


Systems Modelling

Implementation

Component Selection

Component Testing

System Integration

System Verification

Iteration



44/45


Installation and Validation

Installation into the operational environment

Interfaces to external systems may require

simulation

Uncontrolled environment - validate inphases

May involve user training

Validation of user manuals

May be used to verify operational

requirements such as availability

Must be well planned


45/45


Once the design has been validated, theproduct must be produced, sold and

maintained

A good design should lead to a product thatis easy to operate and maintain

2.design mecatrónica

Documents