All Lectures
Uploaded by
jdif0001All Lectures
Uploaded by
jdif0001MEC5883
Lecture 2:
Introduction to Systems
Engineering
DAVID BURTON
DEPARTMENT OF MECHANICAL AND AEROSPACE ENGINEERING
MONASH UNIVERSITY
This Lecture
Update on Design Projects
Understand what systems engineering is.
V- Diagram
Why systems engineering is important.
Understand the meaning of systems engineering hierarchy and its elements.
Define system building blocks: functional and physical elements
Boundaries, interactions and interfaces
References
ISO15288: 2015
Kossiakoff, A., Sweet, W., Seymour, S., Biemer, S., Systems Engineering Principles and Practice,
2011, 2nd. ed, John Wiley and Sons
NASA Systems Engineering Handbook, 2007 (Rev 1) and 2016 (Rev 2)
REV1:
http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20080008301.pdf
REV2:
https://www.nasa.gov/sites/default/files/atoms/files/nasa_systems_engineering_handbook_0.pdf
US Dept Defense – Systems Engineering Fundamentals, 2001
http://www.dau.mil/publications/publicationsDocs/SEFGuide%2001-01.pdf
This presentation is based on the above texts.
Engineering and Systems
Engineering (Kossiakoff)
the application of scientific principles to practical ends; as the design, construction and
operation of efficient and economical structures, equipment, and systems.
In this definition, the terms “ efficient ” and “ economical ” are particular contributions of
good systems engineering.
Systems (Oxford Dictionary)
A set of things working together as parts of a mechanism or an interconnecting network;
a complex whole.
A key element of a system is that the individual parts, acting together, achieve
something of utility that is more than the sum of the individual parts themselves.
Design of complex systems
Today, as technology advances, engineering systems are increasing in
complexity.
Specific fields of design, for example, electronics / propulsion / software /
materials / etc., require a greater depth of understanding.
So how do we design a complex engineering system?
Examples of complex systems?
How do we design something complex like an aircraft?
Where do we start?
ENGINEERING
SYSTEMS CAN BE
COMPLEX!!!
Systems Engineering - Objectives
The function of systems engineering is to guide the
engineering of complex systems.
The more complex the system, and the greater the number of
interactions (internal and external) the more important systems
engineering is to achieving a successful project.
Process is important in managing complex systems:
Humans have limitations: breadth of expertise and depth of
knowledge.
Projects cannot be completed by a single person.
Resources and workforce need to be divided and allocated.
Image – Dr Seuss
What is Systems Engineering?
Systems Engineering is:
“an interdisciplinary approach encompassing
the entire technical effort to evolve and verify
an integrated and life-cycle balanced set of
system people, product, and process solutions
that satisfy customer needs.”
“a branch of engineering which concentrates
on the design and application of the whole as
distinct from the parts, looking at a problem in
its entirety; taking account of all the facets and
all the variables and linking the social to the
technological”
(Ramo, S., in Weiss, A., Conquering Complexity: Lessons for Defence Systems
Acquisition)
What is Systems Engineering?
A fundamental aspect of a system is that its performance
is not defined from the performance of its individual
components, nor can it be derived from the individual
components
It is the way that these components / subsystems interacts
that determines the performance of the overall system.
e.g.
What is function of a car?
Components working individually.
What car has best brakes, engine, etc.
http://www.axiscades.com/automotive.php
Problem Definition
We fail more often because we solve the wrong
problem than because we get the wrong solution
to the right problem
Understand the problem!
Problem Definition
Most of the time we as engineers think of ourselves as problem solvers… which
is great! But…. who defines the problem?
A core aspect of systems thinking is problem definition – setting the boundaries
for the problems to be solved. This is as important as solving the problem.
If we can break the system into smaller problems that are well defined we go
a long way to being able to solve the larger problem
Note: to do this requires a recursive solution development approach, i.e. we cannot
break a problem down unless we have some idea of the solution.
Development of systems engineering
Context of the development of modern systems engineering
1. Advancing Technology
New technology has led to increasingly complex and multi-disciplinary systems
The need to stay competitive drives the adoption of new technology creating
risk and the need to manage the implementation of the new technology
Development of new technology also creates risk in circumstances where it is
not adopted – in this case the design risks becoming outdated
2. Specialization
Increase in complexity and technology drives increases discipline specialisation,
this creates a need to segment projects into subsystems with specific in-depth
expertise – in-turn leading to interface issues with other specialised subsystems
3. Competition
The need to ensure superiority of design / capability
Competition in delivering engineering services, increasing need for cost-
effective and efficient solutions
Project Management and Systems
Engineering
Complex engineering projects tend to have a
dedicated project or program team – led by
a project manager
Systems engineering is a critical part of the
engineering project management process
Systems engineering is an inherent part of
project management — the part that is
concerned with guiding the engineering effort
itself.
The management of the planning and control
aspects of the project financial, contractual,
staffing, resources and customer relations is
supported by systems engineering but is
usually not considered to be part of the
systems engineering function.
NASA Systems Engineering Handbook, p4
Top Down Approach
The systems engineering process is a top-down approach
It is a comprehensive, iterative and recursive problem solving (and
defining) process, applied sequentially through all stages of development,
that is used to:
Transform needs and requirements into a set of system product and process
descriptions (adding value and more detail with each level ofdevelopment),
Generate information for decision makers, and
Provide input for the next level of development.
Requirements flow from the top level (system) down to component level
Bottom up Approach
An alternative is bottom up.
Opposite (almost) of top down
Goals of system are still defined.
Approach is from component, assembly, subsystem to system level
Adopted for existing / legacy system or upgrades.
Top down is developing a solution to meet the needs of the problem as has been defined.
Bottom up is modifying the solution (existing) to the problem
Both are valid and necessary approaches!
Design and Systems Engineering
A hierarchical structure can be used to
compare the roles of systems engineer
and the engineering specialist within the
systems engineering framework.
Component specification and interface
identification is the role of the systems
engineering.
Systems engineer should have
knowledge of the system at the highest
level down to the component level
Design and systems engineers
knowledge levels overlap at the
component level
Systems Engineering - Cost
Once a purpose is defined an objective of systems engineering is to
ensure the design is completed in the most cost-effective manner.
Performance
Cost
Schedule
Risk
A cost-effective approach must balance performance, cost, timing
and risk.
At each cost-effective solution:
To reduce cost at constant risk, performance must be reduced.
To reduce risk at constant cost, performance must be reduced.
To reduce cost at constant performance, higher risks must be accepted.
To reduce risk at constant performance, higher costs must be accepted.
Projects can be budget and resourced constrained (the company
NASA Systems Engineering
cannot spend what it does not have) Handbook, p17
In other circumstances timing can be fixed / performance are fixed.
Complex Systems
A diversity of disciplines is required to
engineer solutions to complex problems
Subsystems tend to be discipline focussed
Different subsystems within system are
required to work together seamlessly so must
be integrated and cannot be designed in
isolation
System engineering must deal with the
complex set of physical and functional
interactions between the separately
designed elements.
Kossiakof, p37
Complex Systems
Interactions and interfaces must be designed
in such a way that the function of each
relevant subsystems can be achieved.
Complexity is added to this task when
multiple organisations or discrete parts of an
organisation are involved.
Systems engineers require a breadth of
knowledge of the relevant disciplines to
ensure appropriate decision making
Kossiakof, p37
Characteristics of Systems Engineering
Systems engineering concentrates on the engineering of the entire system, as opposed to the
specific parts of it.
Importantly systems engineering translates project goals (and hopefully customer
requirements) into more specific technical engineering tasks.
It provides for the allocation and priority of engineering tasks, and supports those allocated
tasks in understanding the interactions of their components or subsystems with others.
Systems engineering and its elements are iterative and recursive processes.
Meaning: you do not get it right first time!
Life Cycle
• It has broad coverage over the life
of the product, including phases
such as:
• Design and development.
• Verification and validation.
• Manufacturing.
• Deployment.
• Operation.
• In service monitoring and
maintenance.
• Training.
• Disposal.
• All these must be taken into
account during the requirements
definition and design stages.
Characteristics of Systems Engineering
• the fundamental systems engineering activities are:
• Requirements Analysis,
• Functional Analysis and Allocation, and
• Design Synthesis
• Fundamentally, systems engineering is a method for turning stakeholders or customers
needs and requirements (what must this system do) into a design solution, by
translating those needs into engineering requirements (system requirements) and
iteratively developing concepts to meet those requirements
• Systems requirements are written from the perspective of the designer / supplier – it is
what characteristics, attributes, functional and performance requirements that the
systems is to posses in order to meet the stakeholder requirements
Dept Defense (US), Systems
Engineering Fundamentals,
2001, p31
Systems Engineering V- Diagram
ops.fhwa.dot.g
ov
MEC5883
Lecture 3:
Introduction to Systems
Engineering II
DAVID BURTON
DEPARTMENT OF MECHANICAL AND AEROSPACE ENGINEERING
MONASH UNIVERSITY
Administrative
Refer to weekly lesson / teaching
This Lecture
V- Diagram
Systems engineering hierarchy and its elements.
Define system building blocks: functional and physical elements
Boundaries, interactions and interfaces
Requirements
Systems Engineering V- Diagram
ops.fhwa.dot.g
ov
Systems Architecture – Building Block
Approach
We can break down complex engineering problems
(systems) into smaller problems (subsystems):
Problems are smaller and easier to solve
Can engage experts in specific areas relevant to the smaller
problems
This approach creates new challenges:
New problems or subsystems must interface with one another
Resource allocation (including system resources)
Performance allocation
Idea is that if all subsystems meet their allocated
requirements then the overall system will achieve its
requirements (noting interfaces are part of this requirement) www.business2community.com
Systems Hierarchy
Systems are often broken into the following
hierarchical building blocks:
Subsystems
Components
Sub-components
Parts
Note: These classifications are not absolute
(different terminology and meanings
common)
Kossiakoff, p45
System or Subsystem
The definition of a “ system ” is widely applicable
to various levels of complexity of component
combinations
Public transport system, train network, the train
system
Most systems could be considered subsystems of
other systems
System of Systems
A useful approach is to regard a system as
holding the following properties:
possess the properties of an engineered system, and
www.contionline.com
perform a significant useful service with only the aid
of human operators and standard infrastructure
Sub-systems
A sub-system is the next level down in the
hierarchy from the system.
It is a self-contained system and major
portion within the larger system.
Performs a subsets of the overall system
functions.
Subsystems can be complex and involve
multiple disciplines.
www.avl.com
Components, Sub-Components, Parts
Components
A functional element, being a division of a subsystem.
Combination of items performing a necessary function for the subsystem operation.
Sub-Components
The level below the components composed of entities which perform elementary
functions and are composed of several parts.
Parts
The most basic, lowest level representing elements, often commercially available that
perform no significant individual function.
System Building Blocks
An approach to developing a system model based on building
blocks (differentiate):
1. Functional dimension: define what something does or how it performs /
or should perform
What something does..
Fastens components together; maintains ambient temperature
2. Physical dimension: are parts or collection of parts, the physical
embodiment
What something is…
Nut and bolt; radiator; thermostat and fan
System Building Blocks
The functional design of a system can be defined, in a detailed
manner, by first defining the overarching functions, then
incrementally defining the “sub-functions”.
This enables the system to be partitioned by:
understanding the functional aspects of the system
breaking down functions into a physical hierarchy
Functional Elements
Functional Building Blocks: Functional Elements
System functional element classes:
1. Signal Elements, which sense and communicate information;
2. Data Elements, which interpret, organize, and manipulate
information;
3. Material Elements, which provide structure and transformation
of materials;
4. Energy Elements, which provide energy and motive power.
Sub-systems
Components
Physical Building Blocks: Components
System physical building blocks (component elements) are the
physical embodiments of the functional elements
The classes into which the component building blocks have been
categorized are based on the different design disciplines and
technologies that they represent.
The components are referred to by their primary function however
represent the physical items rather than the process of achieving
the function.
Issues for component design include reliability, form and fit,
compatibility with the operational environment, maintainability,
manufacturability, testability, safety, and cost.
Component design must achieve / and not violate the functional
design.
Components
MEC5883
Lecture 4: Business
Analysis Tools
DAVID BURTON
DEPARTMENT OF MECHANICAL AND AEROSPACE ENGINEERING
MONASH UNIVERSITY
SWOT Analysis
SWOT
Strengths
Weaknesses
Opportunities
Threats
SWOT analysis is used to broadly evaluate a project (or business) and
understand risks and its likely successes
It can be performed at various levels and stages of a project, i.e., it can
be used to consider the business, strategy or even the engineering
solution or concept.
SWOT
Very Important. Define the context of the analysis.
What perspective are you conducting the analysis from?
Business, system, customer perspective, etc.
SWOT is conducted at various project stages
Consider project life cycle
SWOT Analysis
Strengths:
Characteristics of the project that are advantageous
Comparison to other options or projects
Can be real or perceived!
Considerations examples:
Distinctive (eg newer facilities / distinctive product);
Proven reputation (previous success, acceptance in the market place);
Established relationships (clients);
Leadership (regarded as a leader);
Strategy / Organisation (is there a clear strategy, is there an organisational structure in place)
Location (influence of location);
Competition (is there significant competition, is it isolated from competitors)
Technology (is there intellectual property that gives an advantage)
Financial resources (does the company have the financial backing that gives it advantage, eg parent company / deep
pockets)
Cost (can it produce / sell / provide for lower cost than others)
Economies of scale (Is the able to produce multiple components)
SWOT Analysis
Weaknesses:
Characteristics of the project that are disadvantageous
Considerations:
Not Distinctive (eg similar products, or competitors have distinctive products (eg Apple));
No or poor reputation (previous failures, new venture);
Few established relationships (with clients, customers, brand loyalty);
Leadership (follower, behind in research and development, not state of the art);
Strategy / Organisation (no clear strategy, not a priority within organisation, inappropriate organisational structure)
Location (location disadvantage, eg Australia export to Europe versus local manufacturers);
Competition (significant competition, competitor advantages)
Technology (behind in r and d, key IP not known or held)
Financial resources (low or inappropriate financial resources, small company, low cash flow)
Cost (expensive)
Poor economy of scale (few clients, lack of manufacturing capability (eg even if successful))
SWOT Analysis
Opportunities: elements that the project could exploit to its advantage.
Expansion (eg, new customers)
New market segments
Expand product / service capability to better meet needs
Diversification (related fields)
Add complementary products or services
Competitor approach (eg complacency, lack of development in competitors)
Market growth
SWOT Analysis
Threats: elements that threaten the success of the project.
New competitors
Decrease of market size / slowing of growth
Adverse government policies
Business and social cycles (recession, etc)
Suppliers (bargaining power, capability, viability)
Customer and retailer (bargaining power, etc)
Changing customer needs or requirements
Demographic changes
SWOT Example – Australian
Automotive Supplier Performance
Australian Automotive Supplier Performance – Strengths, Weaknesses and
Opportunities - 2008
http://www.asea.net.au/publications/ASEA-Stage-2-ReportWeb.pdf
SWOT Example – Australian
Automotive Supplier Performance
Strengths
http://www.asea.net.au/publications/ASEA-Stage-
2-ReportWeb.pdf
SWOT Example – Australian
Automotive Supplier Performance
Weaknesses
http://www.asea.net.au/publications/ASEA-Stage-
2-ReportWeb.pdf
SWOT Example – Australian
Automotive Supplier Performance
Opportunities Developing technology - a significant number of
improvements were recommended around companies
either developing their proprietary technology and
investigating international markets, or becoming more
active in the region within their global corporate group
along technology lines.
Reducing costs – there are numerous opportunities for
extracting cost from business operations, both through
measures aimed at improving efficiency, and also by
being more conscious of competitive sourcing
arrangements.
Developing true supply chain activity – greater
collaboration between tiers 1, 2 and 3 with the customer
base to explore design for manufacture opportunities,
and drive greater innovation through the local industry.
Reducing waste – many companies have a large
opportunity to improve productivity and reduce waste,
lead-times, work-in-process and inventory through the
implementation of well established ‘lean’ principles.
http://www.asea.net.au/publications/ASEA-Stage-
2-ReportWeb.pdf
SWOT Example – Australian
Automotive Supplier Performance
Threats
Lack of risk management – most companies are aware of the issues
facing the industry, but in some cases there is little evidence of companies
implementing comprehensive risk management strategies.
Reliance on a small number of customers – little evidence exists of any
systematic approach to achieving greater scale across the supply chain.
Few companies are being proactive in seeking out business beyond the
automotive space, or in developing their capabilities in this direction.
Balance sheet adjustment – in the majority of occasions where a
company had undergone a significant downturn in its turnover, it had not
taken the next step of adjusting its fixed cost base accordingly
http://www.asea.net.au/publications/ASEA-Stage-
2-ReportWeb.pdf
SWOT Analysis - Australian Renewable
Sector Education Analysis
Strengths
High awareness due to Climate Change impact
Self promoting to the general public due to Climate Change
High demand for trained and qualified people in Australia
High demand for trained and experienced R&S technology teachers
High demand for quality training courses and materials in R&S
technology
http://issinstitute.org.au/wp-content/media/2011/05/ISS-FEL-
REPORT-de-la-TORRE-low-res.pdf
SWOT Analysis - Australian Renewable
Sector
Weaknesses
Lack of financial support of the development of training
Not given the required level of priority for immediate development
Urgency and timeliness not recognised nor addressed
Implementation too haphazard at present
Not enough Government policy support nor financial support incentives or
investments
TAFE institutes work in competition with each other rather than collaboration
Lack of manufacturing capacity in Australia regarding R&S technology
components
http://issinstitute.org.au/wp-content/media/2011/05/ISS-FEL-
REPORT-de-la-TORRE-low-res.pdf
SWOT Analysis - Australian Renewable
Sector
Opportunities
R&S technology set to become a huge growth industry (similar to the initial
computer technology boom)
Potential for financial investors from Australia and Internationally
Potential for more Government investment in training and development
Potential for new ‘green’ jobs and transition to ‘green’ jobs
Potential for Australian and Overseas investors for manufacturing in Australia
Potential for all TAFEs to work collaboratively on R&S technology projects
Skills and knowledge is required NOW in Australia and Internationally
Need to learn from countries leading the renewable and sustainable drive, how
to proceed with more speed , efficiency and effectiveness
http://issinstitute.org.au/wp-content/media/2011/05/ISS-FEL-
REPORT-de-la-TORRE-low-res.pdf
SWOT Analysis - Australian Renewable
Sector
Threats
Massive effort is required at all levels of government and industry in order to slow down
climate change
Australia is at least 20 years behind many European countries in many elements of the
use of renewable and sustainable technologies
TAFEs working in isolation on training and development rather than collaboratively
The global financial crisis is being used as an excuse not to proceed
Lack of R&S technology training facilities and supporting resources
Impact on industry of not having appropriately qualified training and development
people
Slow and haphazard implementation of R&S technology systems
Lack of manufacturing capacity in Australia for R&S technologies due to current lack of
vision
http://issinstitute.org.au/wp-content/media/2011/05/ISS-FEL-
REPORT-de-la-TORRE-low-res.pdf
SWOT Analysis - TESLA
TESLA SWOT ANALYSYS
Refer to recording
PESTLE Analysis
PESTLE Analysis
A business tool for mapping and understanding the environment in which a
business will operate.
PESTLE Analysis
PESTLE
Political
Economic
Social
Technological
Legal
Environmental
Variants: PEST Analysis
Pestle
Political
What is the political environment that affects the relevant product, business or service, and
might this change?
Political situation in relevant states / countries (volatility)
Attitudes of government in power (may change)
Government policy and decisions
Funding, grants, etc
Lobbying
International arrangements (export and import policies)
Taxes
Example is support for renewable energy target, solar and wind support, insulation schemes
Pestle
Economical
What is the relevant economic environment and what will happen if it
changes?
What economic factors affect the product / service
Exchange rates;
Interest rates;
Customer demand cycles;
Inflation;
Economic growth;
Recessions; etc
Pestle
Social
What are the relevant social considerations relevant to the product and
service?
Demographics
Cultural / social trends
Population
Health
Safety
Ethics
Image
Major events, etc
Pestle
Technological
What is the technological environment of the product and services and
how is it changing?
Research and development
Growth of technology
Maturity of technology
Alternative technology development
Potential for innovation
IP
Technology affecting use of or need for product
http://www.wired.com/2014/06
/supercomputer_race/
Pestle
Legal
What is the legal environment of the product and services and how might
this change?
Current legislation and regulation affecting the product
Areas where legislation may change
Changing legislation / regulation can affect demand for a product or service
Pestle
Environmental
What are the environmental factors relevant to the product or services
Weather
Extreme weather / natural events
Climate change
Awareness of climate change
Pestle / SWOT
PESTLE & SWOT
These methods can be combined such that for each element of the
PESTLE analysis a SWOT study is performed.
As an example, one starts by analysing the strengths, weaknesses,
opportunities and threats to the project that are related to the political
element, this is repeated for economic and so on.
PDSA
Implementation of the key
Plan – Do – Study – Act
Plan: plan the change or the
experiment.
Do: carry out the activity.
Check: obtain data relating to the
activity.
Act: analyse the results and take
appropriate action.
PESTLE
Further reading:
Chapter 3: Warner, A. G. (2010). Strategic analysis and choice : A
structured approach. http://ebookcentral.proquest.com
Refer to course materials section for this chapter.
MEC5883
Needs Analysis &
Benchmarking
DAVID BURTON
DEPARTMENT OF MECHANICAL AND AEROSPACE ENGINEERING
MONASH UNIVERSITY
This Lecture
This Lecture:
Needs Analysis
Benchmarking
Website
Systems Engineering Website
https://www.sebokwiki.org/
Needs Analysis
Customer Needs
Understanding the needs of customers is imperative to good design.
We try to answer the question:
What does the customer need?
One technique is to perform a Needs Analysis
Needs Analysis
Needs analysis
An analysis aimed at specifying / defining the end user’s needs.
Related to achieving customer satisfaction.
Is useful in design projects to focus the considerations on what the user wants, as
opposed to the designer.
Often from the perspective of gap identification, i.e., the difference between what is
done and what should or is desired to be done.
Differs from requirements analysis
it is user-centric, attempts to understand what the user wants, their goals, hopes for
the system.
Output of analysis becomes an input into the requirement analysis process.
Needs Analysis
Needs analysis
Who are the users?
Define the use.
What is their experience level?
What are their tasks?
How do they think the system should work?
What do they want from the system?
What do they think the system should do?
Needs Analysis
6 Principles of Needs Analysis
The opinion of end users is essential to unify a diverse, opinionated design team, and their opinion
should transcend the desires of your design team.
Market research is essential to unify end user opinions, and to use quantitative and qualitative research
to find the best direction for product or service designs.
Appeal to the lowest common denominator in end user needs. Marketing to the lowest skill levels
results in the largest potential market. In other words, follow the KISS principle – “keep it simple, stupid”.
Do comprehensive beta tests (pre-release testing) of your products over a long period of time to allow
adequate adjustments before “freezing” your product for the final manufacturing stage.
Continue to monitor user feedback after the product launch, and address defects quickly and keep
an accurate record to apply to future releases, if they cannot be addressed immediately in the current
product.
Elegant designs are the end product of successful needs analysis, and will put your product head and
shoulders above industry peers.
Leo Sun, 6 Principles of Needs
Analysis
Stakeholder Needs
Once stakeholder, including customer needs,
are identified they need to be analysed and
prioritized.
Are they reasonable?
Are they consistent?
Are they conflicting?
What is their cost (complexity, time, $, risk ,etc.)
Which needs are to be met?
Benchmarking
Benchmarking is the process of investigation, measurement and analysis
of another similar system, usually for the purpose of:
Definition of targets
Evaluating performance
Developing new understanding, such as how a produce achieves
Idea generation
Benchmarking
Learning by borrowing from the best and by adapting their approaches to fit
your own needs is the essence of benchmarking
What works?
What doesn’t work?
You do not need to limit yourself to the same system. For example, if you are
benchmarking the performance of a finance company, ideas and
approaches from other businesses may be relevant, e.g., lean systems
A benchmarks is some reference point usually taken from the performance of
an external system, i.e., a measurement of the performance of another system
to be sued as a reference.
Benchmarking
Ford Motor Company – Henry Ford example (https://www.best-in-
class.com/)
Henry Ford visits an abattoir
Toyota
Toyota mission to US in 1950s
GM joint venture with Toyota in 1980s
Types of Benchmarking
Benchmarking Types
process benchmarking (often a business process),
strategic benchmarking (higher level strategic analysis), and
performance benchmarking
Performance Benchmarking
Performance Benchmarking
Performance benchmarking enables managers to assess their competitive
positions through product and service comparisons.
Performance benchmarking usually focuses on elements of price, technical
quality, ancillary product or service features, speed, reliability and other
performance characteristics.
Reverse engineering, direct product or service comparisons and analysis of
operating statistics are the primary techniques applied during performance
benchmarking.
The automotive, computer, financial services and photo copier industries,
among others, regularly employ performance benchmarking as a standard
competitive tool.
Competitive Set
A common starting point for different attributes of systems (often very hard
to do) can be to define the intended outcome in terms of the
competitive set (e.g. mid-class, best in class, etc).
This is a useful tool for defining some more complex requirements. For
example, how we define the top speed required of a new motor boat to
be released. One approach:
Define competitor group / set;
Define competitor performance;
Determine what is required of the new motor boat relative to the competitor
set (i.e, best in class); and
Set the benchmark.
Best in class
Due to the widespread nature of the automotive industry a number of
companies are involved in different types of benchmarking.
Vehicle tear down and detailed performance analysis, including reverse
engineering.
https://www.fev.com/en/what-we-do/powertrain-development-
electrification/benchmarking.html
Vehicle reliability is often reported by independent agencies:
Take a look at : https://www.jdpower.com/cars/ratings
Examples
4000 metre men’s pursuit
Olympic Cycling event (4 riders)
Almost linear decrease in times over last 30
years
Challenge is what is the targe time to wind
gold medal in 2024.
https://www.youtube.com/watch?v=Y58zt-
atDAc
250
WORLD RECORD TIME (SECONDS)
245
240
235 2016
Olympics
230
225
220
1-Jan-92 23-Jun-97 14-Dec-02 5-Jun-08 26-Nov-13 19-May-19
2024
DATE
Benchmarking – Project Context
We are going to use performance benchmarking in your project for the
purpose of:
Understanding different potential solutions to the problem;
Considering subsystem solutions / options; and
Defining targets / requirements.
By understanding how another product or system achieves its outcome
(or doesn’t) we can use this to inform our design.
No need to re-invent the wheel!
Benchmarking – Project Context
Competitive benchmarking
Who are competitors / supplying equivalent products?
What are the competitors supplying products with a similar use?
Electric bikes
Electric scooters
Bikes
????
What sub-systems or design elements also share similarities with other products or systems?
What are the key attributes for your project?
Assess the competitors for these attributes
Use the evidence and information that is available to you.
You may need to make assumptions.1
MEC5883
Systems Engineering –
Requirements
DAVID BURTON
DEPARTMENT OF MECHANICAL AND AEROSPACE ENGINEERING
MONASH UNIVERSITY
Overview
What is a requirement?
External inputs and stakeholders
System requirements
Types of requirements
Writing requirements
Verification and validation
ISO15288 – Technical Processes
Requirements
What is a requirement?
A requirement is a statement of what the system must do, a condition or
capability.
A constraint on a system may also be a requirement.
A precise, single, written articulation of the above.
Requirements
Requirements should:
Explain what the system must do (functional requirements).
Quantify how well the system must perform those functions (performance
requirements).
Describe the environment in which the system must perform those functions.
Define other constraints or limitations.
Requirements analysis establishes the basis for the functional and physical
designs.
Requirements
Main inputs are the customer’s requirements and the project constraints.
Requirements within the system should be defined at all levels with
increasing specificity:
system,
subsystem,
component,
sub-component, and
part
Requirements Context
We have been looking at external requirements,
including stakeholders requirements.
The goal is to understand the functional and
operational requirements, including constraints so
that we can define the technical requirements of
the system.
Once the system requirements are defined,
decisions must be made, and a systems
architecture developed.
As we move through the process the designs
become more detailed
This allows a steady cascade of requirements to
sub-systems and below.
Requirements Context
A successful approach to requirements definition
and the subsequent execution of design to those
(cascaded) requirements will result in verification
of the performance of the requirements at the
various levels.
This approach is necessarily iterative and
recursive.
If the requirements are appropriately defined,
and these are met at the lower levels then the
system requirements will be met when it is
recomposed.
Further to that, if the system requirements are
verified, then the ultimate aim is to meet the
stakeholder needs. (this is validation of the
system)
Requirements Context
The goal of systems engineering is to
develop a solution that meets the needs of
stakeholders.
Determining and defining the needs that are
to be met
Defining the relevant requirements to meet
those needs
Designing a system or solution to meet those
requirements
Verifying that the system achieves the
requirements
Validating that the systems meets
stakeholder needs.
Stakeholder Requirements
Stakeholder requirements:
Stakeholder sourced requirement.
Stakeholder may be an individual or a stakeholder class.
Aim is to define the user (and other stakeholder) needs in a defined
environment.
Express the intended interaction the system will have with its operational
environment.
Not necessarily technical.
Stakeholder requirements become a reference for validation,
validation evaluates whether the system meets the stakeholder needs.
Stakeholder Requirements
Stakeholder requirements are from the perspective of the stakeholder, often the user.
The combined users’ perspective of what the system must do.
Stakeholder needs and wants are analysed.
A stakeholder need does not necessarily become a requirement.
In some cases stakeholder agreement is required, although agreement is not
necessarily from the source of the requirement.
e.g., it is difficult to obtain agreement from customers.
What are the measures of effectiveness (how is the success of the system to be
evaluated?)
House of Quality
J. Hauser and D Clausing (from May 88), The House of Quality, Harvard Business Review
https://hbr.org/1988/05/the-house-of-quality
Concept Definition
As you move through the systems engineering process you need to evaluate options and
make decisions.
An important step is the development of a or multiple “concepts of operation.”
An explanation of the operational steps required to achieve the outcome from the user’s
perspective.
Step by step
Requires imagination of how the future system will operate and how it will be used.
How will the system operate and interact with its users and the external environment?
This comes from understanding stakeholders requirements, project scope and constraints
and developing different concepts that might achieve that outcome.
The necessary task, action or activity that must be accomplished.
Moon landing example
Mission was to land a human on the moon and return safely.
Operational concept:
Launch (crew, landing vehicle and return vehicle) into space and moon
trajectory using multi-stage rockets.
Position return vehicle in moon orbit
Landing crew leave return vehicle via landing vehicle and land on moon
Crew conduct moon activities and return to landing vehicle
Landing vehicle returns to return vehicle
Return vehicle returns to earth lands in ocean
System Requirements
Next step is to define the requirements of the systems
System requirements:
Define the system from an engineering / technical perspective.
What the system must do (as opposed to what the system is).
Often considered as a technical articulation of what the system must do
The idea is once defined the systems should be able to be designed without
reference outside of these requirements.
Systems requirements are cascaded to lower level requirements, e.g.,
subsystem, component, etc.
Must be able to be engineered and verifiable.
System Requirements
The outcomes of the systems requirement definition process are:
the system is described for a system solution (this includes system interfaces,
functions and boundaries);
systems requirements and design constraints are defined;
critical performance measures are defined;
system requirements are analysed;
enabling systems or services needed are identified and available; and
Traceability of system requirements to stakeholder requirements are
established.
If not linked then why is it there?
Dept Defense (US), Systems
Engineering Fundamentals,
2001, p31
Other External Inputs
The development of system requirements is based upon external inputs.
External inputs are those that are determined outside the relevant
organisation or otherwise fixed.
Key is to ensure that all these inputs are identified, understood and
agreed.
IEEE P1220 Standard provides a useful method for analyzing requirements
and capturing different inputs and considerations.
Includes a list of 15 tasks (not necessarily evaluated sequentially)
Other External Inputs
IEEE P1220
1. Customer expectations 9. LIfe cycle
2. Project and enterprise constraints 10. Functional requirements
3. External constraints 11. Performance requirements
4. Operational scenarios 12. Modes of operation
5. Measure of effectiveness (MOEs)
13. Technical performance measures
6. System boundaries
14. Physical characteristics
7. Interfaces
15. Human systems integration
8. Utilization environments
Developing Systems
Requirements
Requirements analysis
A process / exercise for defining the
requirements of each level of the system
hierarchy
Systems requirements are developed
from the various inputs and serve the
basis for the subsequent system design
NASA Systems Engineering Handbook, NASA/SP-2007-6105
Rev1, https://www.nasa.gov/sites/default/files/atoms/files/nasa_systems_engineering_handbook.pdf
Requirements
System Requirements
A key part of the systems engineering process is getting to the point of having
systems requirements defined.
System requirements define and constrain the system from a functional
perspective (although not all requirements need to be functional)
This means once the system requirements are defined the system should be able to be
designed without further reference outside those requirements.
Feedback (e.g., to stakeholders) is allowed where a requirement cannot be met, or
an opportunity is identified, but this needs to go through the process again.
Requirements
Requirements can be loosely divided into: Most Important: Requirements should cover all
Customer / Stakeholder requirements; requirements of system
Functional requirements; Also: useability (quality of the system); operational
(human factors, ergonomics, maintenances,
Performance requirements; reliability, security, safety), modes, adaptability,
Design Requirements; physical constraints, design limitations (e.g., legacy
Derived Requirements; elements), environmental (temp, vibration, motion,
impact), logistical (packaging, sustainment – spare
Allocated Requirements; parts, training, shipping, transport), policies and
Interface requirements; and regulations, cost and schedule.
Other requirements (can be aspects of
environmental, regulatory, serviceability,
maintainability, recoverability, scalability).
Customer Requirements
Statements of fact and assumptions that define the expectations of the
system in terms of mission objectives, environment, constraints, and
measures of effectiveness and suitability.
Purpose:
Required characteristics and context of use are defined.
Constraints are defined and understood.
Traceability of requirements to stakeholders is achieved.
Basis for system requirements is defined.
Basis for performance validation is defined.
Functional Requirements
The functions the system/subsystem/component must perform.
The necessary task, action or activity that must be accomplished.
What has to be done. These refer largely to what the system should do.
Top level functions for functional analysis.
These requirements should be action oriented and should describe the
tasks or activities that the system performs during its operation.
During the system requirement phase they refer to the system as a whole
Refined at later stages.
Functional Requirements
Cover all intended uses of the product over its lifecycle.
Functional analysis is used to draw out both functional and performance requirements.
Requirements are partitioned into groups, based on established criteria (e.g., similar
functionality, performance, or coupling, etc.), to facilitate and focus the requirements
analysis.
Functional and performance requirements are allocated to functional partitions and
subfunctions, objects, people, or processes.
Sequencing of time-critical functions is considered.
Each function is identified and described in terms of inputs, outputs, and interface
requirements from the top down.
Functions are arranged in a logical sequence (cascade / hierarchy) such that specified
usage of the system can be traced in an end-to-end path to indicate the sequential
relationship of all functions.
Performance Requirements
Performance requirements – requirements on how well a
system/subsystem/component must perform its function.
These refer largely to how well the system should perform its requirements
and affect its environment.
Should be objective and quantitative.
These are sometimes called specifications and are often associated with
a functional requirement.
The extent to which a mission or function must be executed; generally
measured in terms of quantity, quality, coverage, timeliness or readiness.
Performance Requirements
Take into account:
the degree of certainty in their estimate,
the degree of criticality to system success, and
relationship to other requirements.
Examples:
a. The vehicle shall accelerate to 100km/h in less than 6 seconds.
b. The plane shall reach a cruising speed of 900km/h.
Design Requirements
The “build to,” “code to,” and “buy to” requirements for products and
“how to execute” requirements for processes expressed in technical data
packages and technical manuals.
Limitations on design, such as due to legacy.
May also go to design capability.
Environmental Requirements
Requirements relating to the environment that the system will operate in,
or may be required to operate in.
Can be natural environment – temperature, weather, etc.
Can be self-induced or other external environment: temperature,
vibration, noise, electromagnetism, shock, etc.
Can be societal environment (eg changes to PESTLE)
Other Requirements
Cost and timing requirements;
Legal and policy requirements;
Adaptability requirements (e.g., scalability);
Modes requirements (operational modes);
Physical (mass, size); and
Quality and useability requirements.
Allocated Requirements
A requirement that is established by dividing or otherwise allocating a
high-level requirement into multiple lower-level requirements.
A 100-pound item that consists of two subsystems might result in weight
requirements of 70 pounds and 30 pounds for the two lower-level items.
It could be allocation of a higher level temperature measurement requirement
(the device shall measure temperature in the range 0 to 20 degrees) to a
specific piece of hardware (the *** hardware shall measure temperature in the
range 0 to 20 degrees)
Derived Requirements
Requirements that are implied or transformed from higher-level
requirement.
Write a new requirement based on a parent requirement, incorporating
new or different details.
a requirement for long range or high speed may result in a design requirement
for low weight.
The engine shall produce 300kW (derived from acceleration requirement)
The vehicle shall weigh less than 2000kg
Interactions
An interaction is a connection, through an interface, of the system with:
A system (and its elements) its environment and other systems;
System element with each other.
The interaction specification describes the nature of the interaction,
including how one system affects the other.
Interfaces
The system boundary of the subject system where an interaction with
another system occurs.
Where one or both systems affect each other.
Can be physical, but does not necessarily need to be:
Tyre – road interface
Communications (wifi) interface
An interface specification describes that “physical” boundary whereas
the interaction describes how elements affect each other.
Interface Requirements
Interface requirements – requirements on how interacting
systems/subsystems/components coordinate activities or mate.
The crane shall attach to a lifting point of internal diameter of 30mm.
The signals from the speed sensors shall be analog voltage outputs in the range
of +/- 10V.
Writing Requirements
How do we write a requirement?
What does a requirement look like?
The vehicle shall cost under $15,000.
Good. Clear. Simple.
Writing Requirements
Requirements can be thought of from different perspectives, in terms of
expression there are two types of requirements:
Requirements that must / shall be met
Requirements that should be met or targets
Writing Requirements
Clear Verifiable
Without ambiguity Need not a solution
Singular Consistent language through
Consistent with other requirements (no conflict) Extensive – define all operational
Correct conditions and environments
Traceable Consistent with other requirements –
Achievable eg interfacing / interacting, early
conflict resolution, no contradiction.
Feasible
Appropriate for the level in hierarchy
Complete
Affordable Not repeated
Writing Requirements
The nature of requirements that are written need to be balanced with the
various project factors including complexity, resources, time, budget, risk, etc.
Often basic outlines of requirements are termed requirements definition documents.
More formal detailed specifications are requirement specifications.
these usually list all the requirements of the particular system, sub-system, component, etc. to
which the specification relates.
The complexity, documentation and requirements management process will
depend on the nature of the system.
Note: specifications, in other contexts, usually refer to how something will be
achieved or what it is, e.g., design or product specifications.
Requirements Documents
Requirement ID.
The requirement.
Level (system, sub-system, etc.)
System element (what is the system
element this belongs to – cooling sub-
system)
Rationale – why the requirement?
Traceability / parent requirement.
Owner (person or group).
Verification category.
Verification method.
Verification level.
Requirement Allocation Sheet (RAS)
The allocation of requirements
is developed during the
requirements and functional
analysis stage
Is expanded through the
design synthesis phase
Provides traceability of
requirements
All requirements should be
traceable to the system level
US Dept Defense – Systems Engineering
Fundamentals, 2001
Cascading Systems Requirements
The systems requirements need to be
cascaded / decomposed to subsystems
and below.
requirement hierarchy
This decomposition process, requires an
increasingly developed system
architecture.
The lower level system architecture needs
to be developed for each successive step
of the requirements decomposition
process.
This will be iterative.
As requirements are decomposed and
allocated, traceability to higher levels is
maintained.
The allocated requirements and functions
are the basis for the synthesis of the
technical solution.
As internal components are developed,
additional interfaces are defined and
interface requirements are established.
NASA Systems Engineering Handbook, NASA/SP-2007-6105
Rev1, https://www.nasa.gov/sites/default/files/atoms/files/nasa_systems_engineering_handbook.pdf
Verification and Validation
Requirements must have a method of verification assigned to them.
There is a common mixing of the terms verification and validation.
The most technical difference is:
Requirements are verified. Answer question: Does the system (or system
element) meet this requirement.
Needs are validated. Does this system achieve what the stakeholder wanted?
Is it designed right? Is it the right design?
Verification and Validation
Verification category. (e.g., simulation, analysis, test, inspection, judgement, demonstration)
Verification method. (e.g., wind tunnel test, crash test at 50km/h)
Verification level. (at what level will this be verified)
It may be appropriate to verify higher level requirements together
The nature of the verification will depend on the importance of the requirement:
Is it critical?
What will happen if it fails?
What confidence level applies?
How expensive is the verification method, availability, etc.
What is the technical capability of the team?
Stakeholder requirements
References
ISO15288: 2015
Kossiakoff, A., Sweet, W., Seymour, S., Biemer, S., Systems Engineering Principles and
Practice, 2011, 2nd. ed, John Wiley and Sons
NASA Systems Engineering Handbook, 2007
http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20080008301.pdf
US Dept Defense – Systems Engineering Fundamentals, 2001
http://www.dau.mil/publications/publicationsDocs/SEFGuide%2001-01.pdf
This presentation is based on the above texts.
MEC5883
Systems Engineering –
Functional Analysis
DAVID BURTON
DEPARTMENT OF MECHANICAL AND AEROSPACE ENGINEERING
MONASH UNIVERSITY
Functional View
Two views of a system:
Functional view:
What the system must do or will do.
focuses on WHAT the system must do to produce the required operational behavior.
includes required inputs, outputs, states, and transformation rules.
functional requirements, in combination with the physical requirements are the
primary sources of the requirements that will eventually be reflected in the system
specification.
Physical view
What the system is, i.e., its physical make-up of parts and components.
Functional / Non-functional
Requirements
Functional requirements:
Describe what the system must do…
Non- Functional requirements:
Describe how the system will do it…
Functional Analysis
What is functional analysis?
An analysis process by which the system is defined in functional terms.
Functional analysis can be used to bridge the gap between high level
requirements (eg stakeholder requirements or system requirements) and lower
level requirements.
Leads to allocation of functions to functional groups and hardware (ie to the
physical view) – functional allocation.
Useful link NASA presentation contains examples of functional analysis:
https://kscddms.ksc.nasa.gov/Reliability/Documents/Functional_Analysis_Module_V10.pdf
Functional Analysis
Aim of the functional analysis stage is to
identify the functional, performance and
interface design requirements
Transform the high level requirements
into a coherent description of system
functions
Cascading / decomposing requirements
Dividing into sub-functions
Identifying at each lower level the
functions required to achieve/perform the
higher level function
Guides design synthesis – the next step
NASA Systems Engineering Handbook, 2007
Functional Analysis
Progressively provides more detailed functional and performance
requirements
Defines all interface (internal and external)
Partition functions into related groups to minimise interfaces (functional
partitioning)
Identifying existing components / design capabilities and incorporating
Account for life cycle considerations
Trade-off studies
Revisit high level requirements – are they achievable, are they
appropriate… (the requirements loop)
Functional Analysis
A functional statement begins with a verb and follows with a direct object
Fly airplane, Surf internet, Enter password, Pay debts
Naming Functions
Function name should identify the action or transformation accomplished by the function
Avoid the pitfalls of “provide” and “accept” functions
Functional Analysis
Functions are intended to be taken literally as we attempt to bring clarity in describing WHAT a
system actually does
Important to use active Verbs rather than passive Verbs
Examples
Determine Resolution to Resolve Problem
Submit Budget to Budget Expenses
Develop Exhibits to Exhibit Products
Seek Approval to Approve Procedures
Provide Support to Support Weight
Functional Analysis
Good Not so good
Perform bit Provide diagnostics
Control utility power distribution Provide utility power
Compute aircraft position Provide aircraft position
Store pre-flight data Accept pre-flight data
Monitor system status Accept status
Interpret crew inputs Accept crew inputs
Milk Carton
What are the functional requirements of a milk carton:
Milk Carton
What are the functional requirements of a milk container (carton):
1. Store milk
2. Balance container
3. Protect milk
4. Pour milk
Anything else?
Functional Analysis
Functional Decomposition Primary Steps
Brainstorm functions performed
Pick out the five to ten truly top level functions and arrange in sequence (if appropriate)
Place the other functions below the top-level functions
Functional Tree Diagram
Helmet
Functional Requirements of helmet
Protect head.
What are the subfunctions
Prevent cuts
Reduce force
Increase impact time
Spread load
Hold position
Adjust length
Connect straps
FAST DIAGRAM
FUNCTION ANALYSIS SYSTEM TECHNIQUE (FAST)
A logic diagram relating the function of the object being studied
Clarifies project scope and “purpose and need”
Helps group reach consensus on project scope so everyone agrees on meaning of
terminology
Helps identify functions that are needed vs. wanted, and those that are unwanted
FAST DIAGRAM
Basic Function:
Principal reason for the product’s existence
Has value to the Customer
Loss of Basic Function results in total loss of market value for the design
May be Performance or Esteem based
What is the basic function of a car?
Secondary Function:
Assist in, or necessary for, the realization of a Basic Function
Targets for modification and/or elimination to:
Reduce cost
Reduce design complexity
Achieve Breakthrough in design
FAST DIAGRAM
FAST Diagram
Visual layout (Tree Diagram) of the product’s Functions
Starts with the Basic Function, and builds to the right with supporting or Secondary
Functions
Why do a FAST Diagram?
Help understand which functions provide the best opportunities to be eliminated, or
improved, to deliver the Basic Function(s)
FAST DIAGRAM
VA In Depth, Functional Analysis System Technique, Value Aalysis Canada,
https://www.valueanalysis.ca/fast.php
References
Kossiakoff, A., Sweet, W., Seymour, S., Biemer, S., Systems Engineering Principles and Practice, 2011, 2nd. ed, John Wiley and Sons
NASA Systems Engineering Handbook, 2007
http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20080008301.pdf
US Dept Defense – Systems Engineering Fundamentals, 2001
http://www.dau.mil/publications/publicationsDocs/SEFGuide%2001-01.pdf
AS/NZS15288:2003 (ISO 15288) Systems engineering – System life cycle processes
Available through Monash library database catalogue (Standards Online)
http://athena.ecs.csus.edu/~grandajj/ME296J/1.%20Lectures/5.%20Scope%20&%20Conops%20Module/5.Scoping&ConOps_Module_V1.0.pdf
Boeing Functional Analysis: http://soliton.ae.gatech.edu/people/dschrage/TAI/SE-G_Functional_Analysis.pdf
NASA functional Analysis: https://kscddms.ksc.nasa.gov/Reliability/Documents/Functional_Analysis_Module_V10.pdf
http://www.egr.msu.edu/classes/ece480/capstone/fall08/group02/Six%20Sigma/SixSigma4.pdf
http://design.transportation.org/Documents/TC%20Value%20Engineering/2015%20VE%20Workshop/2015%20PPPs,Papers/Functions%20and%20
Fast%20Diagrams.pdf
This presentation is based on the above texts.
MEC5883 & 6883
Decision Making
Lecture
DAVID BURTON
DEPARTMENT OF MECHANICAL AND AEROSPACE ENGINEERING
MONASH UNIVERSITY
[email protected]
03 9905 5865
2
Project Review
don’t getting caught up in the technicalities of the system engineering stages.
don’t get bogged down, rather step back and ask, at each stage, what you are trying
to achieve?
in the systems requirement stage we transform stakeholders’ requirements, use functional
analysis, consider each life cycle stage, etc…
in the end systems requirements just define at the highest level what the system must do
for the system to be able to be designed without looking externally. Defining what the
system must do?
As you progress you need to make decisions and move through the project
In this unit we are focusing on using systems engineering processes as a tool for defining
the requirements of the system including the required functions; identifying verification
methods; determining an appropriate systems architecture; and ultimately presenting a
design of the system.
You will get feedback and have the opportunity to update your requirements
3
Decision Making
“The core activities of the engineering design process are transforming a
functional description, derived from the requirements list, of a proposed
product into a physical description that can be manufactured.”
Ken Wallace, Stuart Burgess, Methods and tools for decision making in engineering design, Design Studies, Volume 16, Issue
4,1995, Pages 429-446,
4
Decision Making
Decisions are made at many levels during an engineering project.
At the most basic level the company or entity undertaking the project
needs to make the decision to proceed and fund the project.
This may require preliminary studies, and at the very least will require the
consideration of many factors.
However, decisions are also made as to which is the appropriate bolt to
use to hold two parts together.
5
Decision Making
What are the criteria for assessment of performance?
What is the relative weighting of the criteria?
Who is assessing the criteria, what is their knowledge / experience /
preferences?
How are their opinions to we weighted / prioritised
What information is at hand or required to make the assessment?
What cannot be violated – for each criteria is there a level of
performance that renders the solution unacceptable?
Sensitivity of decision, risk, certainty, rationality.
6
Decision Making
Decision making example.
Challenger Disaster
1986 NASA mission fails killing 7 astronauts
Blow-by of O-rings
Concern was low temperatures
Known problem
Political climate at the time (VP visit)
7
Decision Making
Decision as to whether to proceed given
the temperature (-1 to 3 degrees C)
Designed for higher temperatures
Design flaw (performance) too sensitive to
ambient temperature
Design or requirement flaw?
Group thinking
Waived launch constraints relating to O-
rings
Mission proceeded on basis that the O-
rings had not failed at temperatures
above expected launch temperature
8
Objectives
The aim of decision making in design is to identify the design solution the
performs the best considering all the aspects of the design.
This obviously depends heavily on how the assessment is conducted,
especially when there are multiple criteria.
Objectives often refer to goal such as minimising cost, increasing reliability,
performance measures, etc.
Often forgotten are risk of success / cost, likelihood of success and complexity.
Fundamental objectives are those that are inherent in the need for the
system: maximise profit, maximise safety.
They are what is trying to be achieved and not the means of achieving it.
9
Strategies
We make decision every day – what we eat, what we do, how we spend
money, whether work on our project, what we do in our personal lives,
etc.
Equally, in design of systems we must make many decisions.
But, how do we make these decisions?
What are our strategies?
10
Strategies
Choice Strategies (Hastie and Dawes, Rational Choice in and uncertain
world, 2001)
Dominance, Additive Linear, Additive Difference, Satisficing, Disjunctive,
Lexicographic, Elimination by Aspects, Recognition Heuristic
Different strategies are appropriate for different decision making problems.
It is important to understand / recognise the decision making strategies that are
being used
11
Dominance
Decision-making by dominance is where one can choose or eliminate
decision on the basis of one always being better or worse than another in
the relevant criteria.
Selected: always better or equal to the alternative.
Eliminated: always worse or equal to the alternative.
For example, if we have criteria related to weight, reliability, cost, and
performance of a component.
If one solution performs better than all the others in terms of weight and
reliability, and is equal to others on cost then it is dominant.
12
Dominance
Make criteria
appropriate resolution:
- what resolution
matters,
- how accurately
can you measure;
- noise / variation;
- environmental
factors
13
Additive Linear
Additive linear method is one of the most common used to find best
alternative.
Determine relevant attributes.
Assign a weighting to each attribute.
Score each alternative for each attribute (eg %)
Calculate the weighted sum.
Sensitive to scoring and weighting.
Question for review: is this outcome reasonable or is this is an artefact of my
process?
14
Additive Difference
Similar to additive…
Compare two alternatives at a time
Estimate difference between two (using some scoring method) on each
attribute.
Can using weighting
Calculate the total difference.
Repeat for all alternatives.
15
Satisficing
Satisficing involves aiming for an adequate solution rather than the best
Quite common, often not consciously implemented.
For example, a component is designed then if it meets all requirements
and constraints then the design is complete.
If not, the component is re-designed until it meets the requirements.
Process continues until all requirements are met.
Problem with this method is that it does not lead to the “best” design, but
is particularly useful on time constrained projects.
16
Disjunctive
A minimum acceptable value is set for each attribute (cut-off)
Consider only those that meat the cut-off
Select one attribute (e.g., cost / timing / performance / etc) and select
the best alternative.
Outcome is that you chose the alternative that meets the minimum
requirements and is the best on one category.
This does not necessarily provide the overall best outcome, but, goes a
step further than satisficing.
17
Lexicographic
This method works down from the performance in the most important
attribute.
Select best alternative in that attribute, if only one select that.
If more than one best, eliminate others, then..
Identify next most important attribute and repeat.
Doesn’t consider trade offs with other attributes so can be flawed.
18
Elimination by Aspects
Identify most important attribute, determine minimum acceptable value
Eliminate alternatives not meeting cut-off.
Identify next most important, eliminate those below the minimum
acceptable and so on…
Repeat until one alternative remains.
Again, does not often deal with attribute trade-offs.
19
Recognition Heuristic
Choose first alternative that is recognised.
This approach relies on inferences made by a person without defined
formula.
Simplistic
Is common in the psychology of decision making, but not a
recommended primary decision making method.
20
Multi-Criteria Decision Making
When a decision-maker is concerned about multiple factors, it makes the
decision far more difficult.
Common examples are cost, safety and performance (often in multiple ways)
Decision makers may not have a single most important objective, so is left with
a multiple criteria decision
Four main types of multi-criteria decisions:
# Solutions is small and #criteria small;
# Solutions large and #criteria small;
# Solutions is small and # criteria large; and
# Solutions is large and # criteria large (most complex).
21
Pugh Matrix
A range of methods for making multi-criteria decisions
One of which is the Pugh Matrix or selection method.
Pugh Matrix is useful when many attributes and little information.
The concepts are evaluated with respect to a datum, the datum can be
the existing system (solution) or the best concept at each iteration of the
matrix, or another performance point (e.g., target)
22
Pugh Matrix
Example:
Take solution/ options, A to D;
SOLUTION / OPTION
Each to be evaluated against CRITERIA DATUM / BASELINE A B C D
four criteria 1 to 4; 1 0 1 1 1 1
2 0 0 1 -1 1
Compare each alternative to 3 0 -1 0 1 -1
4 0 1 1 1 -1
the baseline for each criteria; SUM 1 3 2 0
Better gets “+”, same “0”, worse
“-”
23
Pugh Matrix – with weighting
Example:
Weighting can be added SOLUTION / OPTION
CRITERIA DATUM / BASELINE WEIGHT A B C D
1 0 10 1 1 1 1
2 0 6 0 1 -1 1
3 0 4 -1 0 1 -1
4 0 7 1 1 1 -1
SUM 13 23 15 5
24
Pugh Matrix – deeper evaluation
Example:
DATUM / SOLUTION / OPTION
Can increase the range of CRITERIA BASELINE WEIGHT A B C D
assessment values, 1 0 10 2 1 2 2
2 0 6 0 1 -1 2
Here +2 to -2 has been applied 3 0 4 -2 0 2 -1
4 0 7 2 2 2 -1
Note the outcome is now
SUM 26 30 36 21
different!
25
Weighting and Performance Matrix
Example:
Assign a percentage
performance to each criteria.
DATUM / SOLUTION / OPTION
Can be based on any reference, CRITERIA BASELINE WEIGHT A B C D
i.e. best performing solution gets 1 0.5 10 0.85 0.65 0.95 1
100%, or best possible; 2 0.5 6 0.5 0.65 0.25 1
3 0.5 4 0.05 0.4 0.9 0.4
Try to apply an objective 4 0.5 7 1 1 0.8 0.4
measure. (e.g., low mass – 100% SUM 18.7 19 20.2 20.4
is 5kg, 50% is 10kg, 0% is15kg)
Can be linear or non-linear.
26
Key Factors
If a design does not satisfy a specification (mandatory requirement) then
it should not be considered a potential solution.
Who decides criteria?
Who decides weighting?
Who makes the assessments?
Multiple assessments (ie by different people)
Should they be equally weighted, weighting by experience
Partial assessments (i.e. experts only consider their field)
27
Key Factors
Assess SENSITIVITY
Consider standard deviation of the assessments and weightings
Have assessors give an assessment together with upper and lower bounds
There is no point using highly accurate and detailed criteria if the method
of assessment is not itself accurate.
DATA
An outcome of decision making is often the need to have more information.
Is testing required, what is the cost of testing in terms of time and $$$.
Is that reasonable or necessary given the options being evaluated?
28
Key Factors
RISK
Is the decision a risky decision? What happens if we are wrong?
Do you confidence in the criteria / scoring / weighting?
Do you have confidence in the result?
RATIONALITY
Always ask the question of the solution – do we think this solution is rational!
Not always a single right solution, but there are wrong solutions, and there are good and
bad solutions.
Different methods will give different results.
29
References
Jeffrey Herrmann, Engineering Decision Making and Risk Management,
John Wiley & Sons, 2015
Chapters 1 to 4
Available through the library online.
(Hastie and Dawes, Rational Choice in and uncertain world, 2001)
MEC5883
Introduction to Reliability
DAVID BURTON
DEPARTMENT OF MECHANICAL AND AEROSPACE ENGINEERING
MONASH UNIVERSITY
Reliability References
References:
This lecture is based on the following text:
Kapur, K., and Pecht, M., Reliability Engineering, John Wiley & Sons, 2014
Chapters (1 – intro), 2 and 3.
Chapter 17 – Design for Redundancy
Also of interest:
Chapter 10, 11 & 13.
Stapelberg, R. F, Handbook of Reliability, Availability, Maintainability and
Safety in Engineering Design, Springer, 2009
Reliability
The concept of reliability can be thought of as a
characterisation of the tendency of a system to
continue to work as intended
i.e., the probability that the system will not fail.
This can be expressed in relation to the
probability of a component failing or that of a
system.
When a large data set is obtained, or by using
other estimates the reliability of a component or
a system can be modelled using a number of
different probability functions (such as http://www.daimler.com/dccom/0-5-1322446-1-
exponential and Weibull distributions). 1323352-1-0-0-1322455-0-0-135-0-0-0-0-0-0-0-0.html
Reliability
Life cycle cost is determined in the
earliest stages of the project.
The majority of funds are typically spent
in the operation and support phases of
the system life cycle.
A consequence is that design for
reliability (earlier investment) can lead
to lower in service costs
Reliability
Reliability
Probability system (or subordinate) will perform as intended for a given period of time
Failure
System or subordinate does not perform as intended.
Prob system will not perform as intended.
Maintainability
Prob system can be repaired with a period of time.
Availability
Prob that a repairable system is available / operational at a given point in time given
certain environment
Reliability
When a product is acquired it is expected that the
product will continue to perform its function for a
reasonable length of time:
What that is depends on the product, the use of it
(environment) and the component
On a complex system it may be acceptable
(expected even) for a component to fail at a given
time:
If it is not a critical item (to safety or performance)
If the system continues to perform its key functions
If it is replaceable or repairable, within a reasonable http://www.daimler.com/dccom/0-5-1322446-1-
time 1323352-1-0-0-1322455-0-0-135-0-0-0-0-0-0-0-0.html
Modelling Reliability
Consider basic approach to modelling
system reliability
Some key concepts:
Reliability R(t)
Unreliability Q(t)
Hazard rate h(t)
Time to failure function (f(t))
(Kapur and Pecht)
Probability Basic Concepts
Histogram – is a bar chart of the number of
occurrences (frequency) within defined ranges (or
bins).
In terms of reliability this usually is the number of
working items or failures.
Discrete Probability distribution
Expresses the likelihood that a value will take on a
discrete value (or fall within a defined range)
Cumulative distribution
Expresses the likelihood that a value will fall within zero
(smallest value) and the reference value (Kapur and Pecht)
9
Probability Density Function
Probability density function
Defined here as f(x)
Used where the data is continuous, or effectively continuous
Because it is continuous the probability of occurrence of a precisely
defined point approaches zero!
thus, P(10) = 0
This is an important distinction between probability distributions and density
functions
We need to define our probability as a range:
𝑥2
𝑃(𝑥1 ≤ 𝑋 ≤ 𝑥2 ) = න 𝑓 𝑥 𝑑𝑥
𝑥1
𝑓 𝑥 : 𝑝𝑟𝑜𝑏𝑎𝑏𝑖𝑙𝑖𝑡𝑦 𝑑𝑒𝑛𝑠𝑖𝑡𝑦 𝑓𝑢𝑛𝑐𝑡𝑖𝑜𝑛 𝑜𝑓 𝑣𝑎𝑟𝑖𝑎𝑏𝑙𝑒 𝑥
Flood Manager E-learning
http://daad.wb.tu-harburg.de/?id=271
10
Probability Density Function
We need to define our probability as a range:
∞
𝑃(−∞ ≤ 𝑋 ≤ ∞) = න 𝑓 𝑥 𝑑𝑥 = 1
−∞
Cumulative probability distribution (continuous)
Non-exceedance
Probability that a value will be less than the reference value
Cumulative probability of x, is 𝐹2 𝑥 , where:
𝑥
𝐹2 𝑥 = න 𝑓𝑥 𝑦 𝑑𝑦
−∞
Where y is a dummy variable for integration and −∞ can be replaced by zero
Probability a sample X, will exceed a value x:
𝐹1 𝑥 =𝑃 𝑋 > 𝑥 = 1 − 𝐹2 𝑥
Flood Manager E-learning
http://daad.wb.tu-harburg.de/?id=271
Reliability
Reliability (R(t)) is the probability that the system will be still operating as intended at a
particular time (t)
It is often thought of in terms of unreliability (Q(t)), where Q(t) is the number of failed
components at time (t), i.e.:
R(t) = 1 – Q(t) where:
𝑛𝑓𝑎𝑖𝑙𝑒𝑑
Q(t) =
𝑛𝑡𝑜𝑡𝑎𝑙
𝑛𝑓𝑎𝑖𝑙𝑒𝑑 - estimate of number failed items out of a subset.
𝑛𝑡𝑜𝑡𝑎𝑙 – total of the subset.
The random variable used to measure reliability is the time to failure (t) random variable.
Reliability
Reliability
Reliability estimates (and the accuracy of these estimates) depend greatly on
properties such as sample size, and can be highly variable.
By increasing the sample size we increase the confidence in the estimate, as the
sample size approaches infinity our estimate becomes exact.
If, in the previous example, a different random sample of transmissions had been
taken then it is likely the number of faulty units would also be different.
If all transmission units were checked (the sample size greater) we would have
much more confidence in the accuracy of the reliability estimate of the system.
Also, if the sample size was decreased there may have been no transmissions
identified as faulty.
Bathtub Curve
Failure rates are generally high at the start of the product life,
are low and approximately constant once the product is worn
in and those early non-conforming products are removed, then
failure rate increases again as the product ages
The “Bathtub curve” provides an idealised modelling of risk of
failure of products with time shown as a hazard rate
It contains three distinct zones:
Infant mortality – where failures occur due to inherent problems
such as manufacturing during the early life of a product (defective
products)’
Constant failure rate during normal life;
An increase failure rate at the end of life due to wear out / age.
Note this is highly idealized, but does present the different “modes”
of failure.
Hazard rate
Hazard rate h(t) is a relative rate of failure.
0.12
A probability of failure at a point in time, given that 0.1
component has survived to that point
0.08
If we have 1000 items and have a hazard rate of
f(t)
0.1 per week (discrete), then we have 100 fail in first 0.06
week, 90 in second week and so on. 0.04
Note this leads to an exponential distribution. 0.02
Probability density function (f(t)), where hazard 0
0 5 10 15 20 25 30
rate is a constant (𝜆). time (weeks)
𝑓 𝑡 = 𝜆𝑒 −𝜆𝑡
Failure rate
f(t) is failure rate as a function of total set of samples.
Often used, incorrectly, interchangeably with hazard rate
Effectively same as hazard rate but not normalized by
remaining:
𝑓(𝑡)
ℎ 𝑡 =
𝑅(𝑡)
Integral from 0 to infinity gives total failures (which equals total
components)
Reliability is the integral of probability density function from t to
infinity
∞ 𝑡
𝑅 𝑡 = න 𝑓 𝑡 . 𝑑𝑡 = 1 − න 𝑓 𝑡 . 𝑑𝑡
𝑡 0
Time to Failure
Time to failure
MTTF (mean time to failure)
Expected life of non-repairable system
∞
0 𝑡(𝑓 𝑡 .𝑑𝑡 ∞
𝑀𝑇𝑇𝐹 = ∞ = 0 𝑡(𝑓 𝑡 . 𝑑𝑡
0 (𝑓 𝑡 .𝑑𝑡
MTBF (mean time between failure)
repairable system
excludes repair time
MTTR (mean time to repair)
MTBDE (mean time between downing event)
MTBDE = MTTR + MTBF
Distributions
Reliability and failure rates are often estimated /
modelled by fitting a set of data to multi-parameter
exponential functions, such as Exponential and
Weibull.
Note: these typically do not model the three stages
of the bathtub curve.
More complex or separate equation may be required
Distributions
Reliability and failure rates are often estimated by fitting a set of data to multi-parameter
exponential functions, such as Exponential and Weibull:
Exponential Distributions Weibull Distributions
Infant Mortality
Infant mortality is of great damage to customer satisfaction
The positivity associated with their new equipment (or phone) gives way to
frustration (or worse) when faced with a malfunctioning product
The product manufacturer must determine methods to eliminate the defects.
Quality management approaches have been shown to assist in reducing
failures.
Appropriate testing can identify and assist in ensuring product robustness.
Premature failures are caused by:
Design defects
Process defects
Quality defects
Assembly defects
The failures should be investigated and design improvements should be made to
improve product robustness
Infant Mortality
Approaches to reducing failures:
Eliminate root cause (best approach):
Requires identification of the problem (knowledge of problem
occurrence);
It is usually most cost-effective to run 100% stress screens only for
early production, then reduce the screen to an audit (or entirely
eliminate it) as root causes are identified, the process/design is
corrected and significant problems are removed.
Identification of potential failing units:
Design an appropriate quality control process (may include burn-in)
Unfortunately, some companies put 100% burn-in processes in
place and keep using them, addressing the symptoms rather than
identifying the root causes. They just keep scrapping and/or
reworking the same defects over and over. For most products, this is
not effective from a cost standpoint or from a reliability
improvement standpoint.
Redundancy
Infant Mortality
Infant Mortality
Redundancy
Redundancy
Duplication of components or functions for the purpose of increasing system reliability.
Allows system to function in the case of component or sub-system failure, because a secondary
element can perform function.
Active Redundancy
All items are operated, but system can be operated with less items available.
Usually re-distribution only, example water flow through multiple pipes – pipe failure
Stand-by Redundancy
Items beyond the required number of items are not operated, irrespective of whether failed or not.
New item is switched on when required, i.e. when failure occurs.
Needed when delays in passive approach are unacceptable
This typically extends reliability, as item is not wearing.
Passive Redundancy
Applies only when failure occurs, e.g, tyre blow out – spare tyre.
Typically apply to non-critical items.
Differs from stand-by in that systems is completely switched off, i.e. is not automatically switched in /
ready to go.
Example
MEC5883
Introduction to Lean
Thinking
DAVID BURTON
DEPARTMENT OF MECHANICAL AND AEROSPACE ENGINEERING
MONASH UNIVERSITY
Overview
History of manufacturing 20th
century
Intro to Lean principles /
thinking
Component of unit is largely
self guided.
Lots of web-based information
Examinable – basic principles
and applications
Note: MEC5897
Lean References
References:
James Womack – author of the Machine that changed the
world
International Motor Vehicle Program at MIT
James Womack, Daniel Jones and Daniel Roos, The Machine
that Changed the World, Free Press, New York, 2007
http://dl1.cuni.cz/pluginfile.php/218097/mod_resource/conten
t/0/womack_the_machine_that_changed_the_world.PDF
Read it!
Oppenheim, B., LEAN FOR SYSTEMS ENGINEERING WITH
LEAN ENABLERS FOR SYSTEMS ENGINEERING, John Wiley and
Sons Inc, 2011
LEAN
“All we are doing is looking at the time line from the moment the customer
gives us an order to the point when we collect the cash.* And we are
reducing that time line by removing the non-value added wastes.”
Taiichi Ohno, Toyota’s original “father” of Lean
*actually…. they are looking at more than that.
History of Lean
History of lean production can be traced by
comparison with alternative approaches
Despite earlier attempts, Karl Benz is usually with
credited with the design of the first modern car
in 1885-1886
1896 Henry Ford built quadricycle
In 1903 there were about 1000 auto
manufacturers and Ford founded and built the
model A. (sold a total of 3?)
http://www.daimler.com/dccom/0-5-1322446-1-
These were manufactured by a craft approach 1323352-1-0-0-1322455-0-0-135-0-0-0-0-0-0-0-0.html
Craft Manufacturing
What is craft manufacturing?
http://www.daimler.com/dccom/0-5-1322446-1-
1323352-1-0-0-1322455-0-0-135-0-0-0-0-0-0-0-0.html
Craft Manufacturing
Craft production refers to the process of
manufacturing where the final product relies
significantly on the skills and expertise of the
fabricators and those assembling the
components
It requires significant part re-work / modification,
generally with basic tools (drills, etc)
Generally very low production and high
personalisation
High cost and high skilled form of manufacture
(not necessarily high reliability – in fact often the http://www.daimler.com/dccom/0-5-1322446-1-
opposite) 1323352-1-0-0-1322455-0-0-135-0-0-0-0-0-0-0-0.html
Mass Production
What is mass-production?
http://www.daimler.com/dccom/0-5-1322446-1-
1323352-1-0-0-1322455-0-0-135-0-0-0-0-0-0-0-0.html
Mass Production and Henry Ford
In 1908 Henry Ford revolutionised production with
the Model T Ford
He moved the cars past the men, rather that the
men to the cars. Often said to have created the
assembly line (although not correct)
The assembly line is often misconceived as the
main advancement of mass production.
What was the most significant advance?
Mass Production and Henry Ford
Part interchangeability
Most importantly Ford insisted on quality and it was
in 1908 that he achieved part interchangeability.
It was this focus on quality through accurate and
standardised parts that meant that the assembly
line process could be implemented.
In other words, mass production cannot be
implemented unless parts are interchangeable.
Mass Production and Henry Ford
Mass production: Production and assembly of
standardised components on-mass
Time to assemble lowered from 12.5 hours to 93
minutes and required manpower was reduced.
Over the life of the Model T, 15 Million were
produced, and the price was lowered from $850 to
$300.
Arguably the most successful and significant
vehicle in history.
Mass Production and Henry Ford
Video
https://www.youtube.com/watch?v=S4KrIMZpwCY
Mass Production Problems
However, in taking up mass production a philosophy was adopted,
perhaps inadvertently, that more was better.
Idea that the greater the volume the lower the cost
For example:
high cost stamping machines would produce huge volumes of stampings
the assembly line would run at or near maximum production rate irrespective of
sales
Companies pursued increasing vertical integration, even to the extent of
vehicle manufacturers purchasing mines
Toyota Production System
Taichi Ohno - "father" of toyota production system, embarked on
study to improve competitiveness of Toyota versus US
manufacturers
He analysed the techniques employed by US manufacturers and
identified many weaknesses that are to be avoided.
Slow time to market
Inadequate upfront investment and empowerment
Drive not to stop production line – extensive re-work to
components
Large stock of errors
Expensive and slow machine set-up changes – particularly
stamping
Move away from idea that success was measured by volumes
that could be produced http://cdn2.hubspot.net/hub/326641/file-2341276990-
png/Blog_Pictures/7_wastes.png?t=1431439625841&width=615
Lean
Lean thinking and approaches are derived from this Toyota
approach.
The concept of Lean is used very widely – no longer is limited
to manufacturing – is inherent in the system that is wider.
“Lean” coined by John Krafcik in 1988
http://fuse.blue2.co.uk/st-andrews-lean-consulting/wp-
content/uploads/sites/83/2016/12/Triumph-of-the-Lean-
Production-System.pdf
Toyota did not use this term, it is just what they do.
Lean
Lean thinking is about creation of value for least waste
Value is what customer thinks it is, considers important and will
pay for
Concept of Waste and approach to eliminate is critical to
Lean
Waste is anything beyond the minimum amount of resources
that are absolutely essential to create value
Categorise activity / work:
Value Add
Not Value Add
Required / necessary (e.g law, contract, etc.)
Waste
Lean Principles
Value – capture value defined by customer
The external customer defines value
Capture with precision, clarity and completeness
Note: short schedules – benefits – if customer needs change
Map the Value Stream
Understand, develop and map the processes to achieve and realise the
customer needs
Flow
Work flows through is planned and streamlined value adding steps, without
stopping, rework, idle time, backflow.
Pull
Let the customers pull the work through, just in time delivery
Is there an established need for the task
Complete when needed, not excessively early
Lean Principles
Perfection
Pursue perfection in every process
Continuous improvement
Must be bounded by value (success, cost, schedule, etc)
Output focussed (not improvement for improvements sake)
Otherwise this can lead to a waste
Respect for People
Culture of mutual respect and trust
Confidence in identifying problems and developing solutions
Lean Production / Engineering
Lean production/ engineering is an approach to engineering
modelled on the Toyota Production System
Implementation of lean systems can be motivated by many
reasons – including waste reduction, quality improvement,
cost reduction, production speed, time to market, etc.
What is core to lean engineering?
Efficient
Focussed on understanding the system and identifying value
adding
Reduction of waste (Muda)
Ongoing process
Lean Production / Engineering
Five steps have been identified as core to the implementation of lean
techniques
1. What is the value to the end customer for each product? What does
customer want?
2. What steps are in the value stream of each product – what steps do not
create or add to value (ie eliminate not value adding steps)
3. Create flow by aligning the value creating steps into a tight and efficient
sequence ensuring the product will flow smoothly toward the customer.
(Lean Flow is about how things (incl people) move from the first step to the
last in a process, with the intention of being as quick and efficient as
possible without any risk to quality and customer satisfaction)
4. Establish pull by having customers (those downstream) pull value from the
next upstream step.
5. Aim for perfection – continue to cycle through the steps to reduce /
eliminate waste, etc
Toyota Production System
7 wastes as part of the system (DOTWIMP)
1. Defects
2. Overproduction
3. Transportation
4. Waiting
5. Inventory (capital outlay unrealised)
6. Motion (movement of personnel or product between
operations)
7. Processing (over-processing – products more complex
than required by customer) http://cdn2.hubspot.net/hub/326641/file-2341276990-
png/Blog_Pictures/7_wastes.png?t=1431439625841&width=615
Pull vs Push
Pull:
Push systems - where the preceding process pushes the product (of
that process) to the next stage - and eventually to the customer
Pull system - the following process withdraw from the preceding
process what is needed, when is it needed
Kanban (kan - sign ; ban – board/card)
A Kanban system / philosophy:
cards signal pull of work
is a workflow management method designed visualize your work,
maximize efficiency and be agile.
Not unlike Trello –Kanban board
Visualizing workflow, setting work in progress limits, managing flow,
ensuring explicit policies and collaborative improvement
regular feedback loops
Stability
Heijunka – production levelling
Eliminating variation or unevenness (mura) in
production and demand by being flexible
Demand levelling – increasing / decreasing
demand
Kaizen (make it better – continuous improvement)
– continuously eliminate waste
Just in time – small batches eliminate waste,
reduce inventory
Eliminate unreasonableness (muri) – through
standardisation
Create system stability – eliminate downtime
Jidoka
Jidoka – one of the pillars of the Toyota
production system
Termed – autonomation / automation with
“human touch”
Detect errors and fix, stop and respond to
abnormalities
Quality at the source
Compare to the philosophy that you cannot
stop the line
Build a culture of stopping to fix a problem –
this leads to getting quality right first time
Compare to mass production
Design for lean
Lean principles can and should be applied to both design and
manufacturing – in addition to other areas (supply chains, employment,
finance, etc)
Approach – upfront investment
Empowering future product teams
Focus on engineering investment in product development early in cycle
Lean
Lean engineering / production is examinable!
You need to understand the basic principles in the context of mechanical
systems design.
MEC5883
Quality Management
Systems
DAVID BURTON
DEPARTMENT OF MECHANICAL AND AEROSPACE ENGINEERING
MONASH UNIVERSITY
Overview
Basic introduction to the concept of quality
What quality means.
Benefits of a quality based approach
Quality Management Systems and ISO9001
Quality References
References
ISO9001:2015 Quality Management Systems – Requirements
QUALITY
Quality refers to many things.
What is quality (standard definition)?
How good or bad something is.
A measure of the standard of something (characteristic or feature).
QUALITY
What is quality?
Quality is a measure of how a product or the system achieves the needs and
expectations from the perspective of the evaluator (usually the customer).
Quality is the the totality of characteristics (people, processes, products,
environments, standards, and learning) of an entity that bear upon its ability
to satisfy stated and implied needs
Quality is not reliability – reliability is
just one (important) aspect of
quality.
QUALITY
Quality is a relative term.
Quality is evaluated within a context.
Expectations of characteristics (including performance) will be different
for different applications.
Sometimes thought of as how well the requirements are met.
But, is more than that, because it takes into account how well the
requirements are defined.
In the end is it a perception.
DISCIPLINE OF QUALITY
In business and engineering quality has become an entire research field,
large companies often have a department, within a business, dedicated to
the pursuit of quality. In some cases a discipline of quality exists.
QUALITY
How is quality achieved?
Quality comes from a commitment across an organisation to
achievement of that goal.
Drive from top down, i.e. requires support of top level management
Defining aims and effectively translating these to action items
Putting in place systems to allow that to happen.
Quality assurance systems
Culture: one of improvement.
QUALITY
“Quality in a product or service is not what the supplier puts in. It is what the
customer gets out and is willing to pay for.”
It might be true that customers decide if they got quality results, but in the
practical business world you have to embed quality into products and
services so that customers can then experience it.
QUALITY MANAGEMENT SYSTEMS
Quality management / Quality Management systems are systems and structures that are
put in place to achieve quality within a business.
Aim to set-up processes geared to make an organisation perform for its stakeholders,
including:
improving products, services, systems and processes,
Managing quality means constantly pursuing excellence: making sure that what your
organisation does is fit for purpose, and not only stays that way, but keeps improving.
You need to develop a well rounded and in-depth understanding of those requirements.
Quality is not just about preventing failures; nor
Achieving one aspect of the goal (trains running on time)
www.quality.org
QUALITY MANAGEMENT
How do you define acceptable quality?
Question for stakeholders.
All stakeholders with an interest in the success of the organization.
Again, this will differ for different stakeholders, even within a group.
Customers will be the most important group of stakeholders for the majority of businesses,
but investors, employees, suppliers and members of our wider society are stakeholders too.
Delivering an acceptable level of quality in your organisation means knowing who your
stakeholders are, understanding what their needs are and meeting those needs (or even
better, exceeding expectations), both now and in the future.
Stakeholder Analysis
www.quality.org
QUALITY MANAGEMENT SYSTEMS
What is a quality management system?
A system designed to achieve quality within an organisation.
A formalised system that documents and records, processes, procedures,
responsibilities relevant to achieving quality objectives.
ISO9001
ISO9001 gives guidelines for how a quality management system should be
formed.
It is not the quality management system, rather defines the requirements for
such a system
Compliance does not guarantee quality.
ISO 9001 - QUALITY
When to implement.
Company need to (demonstrate its ability to) consistently provide a
product / service that meets customer and regulatory needs
Company need to address customer satisfaction through the effective
application of the system, including process for continual improvement
and the prevention of non-conformity.
Company draws benefits from compliance.
To deal with some gov. and industry as a supplier compliance must be
demonstrated.
ISO 9001 - QUALITY
ISO 9001
Identify the processes needed for the QMS.
Determine sequence and interaction of these processes.
Determine criteria and methods required to ensure the effect operation and
control of these processes.
Ensure the availability of the information necessary to support the operation
and monitoring of these processes.
Measure, monitor and analyse the process, and implement actions necessary
to achieve planned results and continual improvements.
Manage the processes in according with the Standard.
ISO 90001 - QUALITY
Who needs the system.
Company need to demonstrate its ability to consistently provide a
product / service that meets customer and regulatory needs
Company need to address customer satisfaction through the effective
application of the system, including process for continual improvement
and the prevention of non-conformity.
ISO 9001 - QUALITY
PROBLEMS
Quality management system does not guarantee quality
System must be efficient and lean
Can lead to over-prescriptive procedures if not correctly implemented
If it is not well thought out and structured the effort can outweigh the
benefits
ISO 9001 - QUALITY
SO WHAT DOES A QUALITY SYSTEM LOOK LIKE
QMS will have a requirement for documentation.
i.e., the Quality system must be described and recorded.
QUALITY MANAGEMENT SYSTEM
Example of a medical
device quality management
system (note: not ISO9001)
Oriel Stat a Matrix
Medical Device Regulatory / Quality Training & Consulting
www.orielstat.com/blog/medical-device-qms-overview/
UniTech
Quality
Management
System
https://eng.th-
unitech.ru/info/
You might also like
- Evaluation in The Face of Uncertainty Anticipating Surprise and Responding To The Inevitable 1st Edition Jonathan A. MorellNo ratings yetEvaluation in The Face of Uncertainty Anticipating Surprise and Responding To The Inevitable 1st Edition Jonathan A. Morell83 pages
- Project Management Canvas - A Systems Thinking Framework To Address Project ComplexityNo ratings yetProject Management Canvas - A Systems Thinking Framework To Address Project Complexity27 pages
- Instant Download Complexity Theory and The Social Sciences The State of The Art 1st Edition David Byrne PDF All ChapterNo ratings yetInstant Download Complexity Theory and The Social Sciences The State of The Art 1st Edition David Byrne PDF All Chapter78 pages
- Tissue Stem Cells 1st Edition S. Potten Christopher - Read The Ebook Online or Download It For The Best Experience100% (1)Tissue Stem Cells 1st Edition S. Potten Christopher - Read The Ebook Online or Download It For The Best Experience72 pages
- AAE - 3156 - Avionics - System Engineering LectureNo ratings yetAAE - 3156 - Avionics - System Engineering Lecture33 pages
- Ordered Complexity From Dissipative and Chaotic Systems, Including The Human Brain and Society and The Universe Relevance of The Second Law of ThermodynamicsNo ratings yetOrdered Complexity From Dissipative and Chaotic Systems, Including The Human Brain and Society and The Universe Relevance of The Second Law of Thermodynamics4 pages
- Cross Impact Presentation Victor Le CozNo ratings yetCross Impact Presentation Victor Le Coz35 pages
- Preventing Prison Violence - An Ecological Perspective - CF Wicked Chap-227-237No ratings yetPreventing Prison Violence - An Ecological Perspective - CF Wicked Chap-227-23711 pages
- A Guide To Good Systems Engineering Practices:: The Basics and BeyondNo ratings yetA Guide To Good Systems Engineering Practices:: The Basics and Beyond22 pages
- Lecture 1 - Intro To Systems EngineeringNo ratings yetLecture 1 - Intro To Systems Engineering18 pages
- Nhóm 6. Digital Twins For Collaborative Robots A Case Study in Human-Robot InteractionNo ratings yetNhóm 6. Digital Twins For Collaborative Robots A Case Study in Human-Robot Interaction20 pages
- Systems Engineering Is A Multidisciplinary Field That Guides The DesignNo ratings yetSystems Engineering Is A Multidisciplinary Field That Guides The Design19 pages
- Chapter 1 - Industrial System EngineeringNo ratings yetChapter 1 - Industrial System Engineering30 pages
- Research Variant Internet and Web TechnologyNo ratings yetResearch Variant Internet and Web Technology52 pages
- Lecture in Systems Engineering (AutoRecovered)No ratings yetLecture in Systems Engineering (AutoRecovered)9 pages
- The Practice-Based Learning of EducatorsNo ratings yetThe Practice-Based Learning of Educators17 pages
- Complexity and Healthcare Organization: A View From The Street.100% (22)Complexity and Healthcare Organization: A View From The Street.23 pages
- Systems Engineering Management: MSE607B Chapter 6 Part I of II System Engineering Program PlanningNo ratings yetSystems Engineering Management: MSE607B Chapter 6 Part I of II System Engineering Program Planning41 pages
- Imagine There Are No Leaders: Reframing Leadership As Collaborative AgencyNo ratings yetImagine There Are No Leaders: Reframing Leadership As Collaborative Agency45 pages
- Lecture 3, Fundamentals of Systems (عرض تقديمي)No ratings yetLecture 3, Fundamentals of Systems (عرض تقديمي)12 pages
- Limits of Traditional Project Management Approaches When Facing ComplexityNo ratings yetLimits of Traditional Project Management Approaches When Facing Complexity22 pages
- A Systemic Approach For Modeling Soil FunctionsNo ratings yetA Systemic Approach For Modeling Soil Functions10 pages
- Leadership and Systems Thinking: Col. George E. Reed, USANo ratings yetLeadership and Systems Thinking: Col. George E. Reed, USA4 pages
- IEC-EN 60204-1-And-81346-September-2010No ratings yetIEC-EN 60204-1-And-81346-September-201014 pages
- System Simulation: Modeling and AnalysisNo ratings yetSystem Simulation: Modeling and Analysis20 pages
- MERE5001-Module 3 - Systems EngineeringNo ratings yetMERE5001-Module 3 - Systems Engineering22 pages
- System Engineering A Management Perspective100% (2)System Engineering A Management Perspective22 pages
- SWE2003 - Requirements Engineering and ManagementNo ratings yetSWE2003 - Requirements Engineering and Management11 pages
- 6 - Malabay - CCR210 - 102018 - SYSTEM - ENGGINEERING PDFNo ratings yet6 - Malabay - CCR210 - 102018 - SYSTEM - ENGGINEERING PDF16 pages
- SEM Fall 2010 Introduction To System Engineering: Sahar IdreesNo ratings yetSEM Fall 2010 Introduction To System Engineering: Sahar Idrees68 pages
- 2.2 - Relevance and Benefits of Systems EngineeringNo ratings yet2.2 - Relevance and Benefits of Systems Engineering8 pages
