ME6101: Engineering Design - the Systems Realization Laboratory

Transcription

ME6101: Engineering Design
Semester Project Report:
Systematic Design for Self-Organizing
Systems
Jordan Hall
Mohsin Waqar
Nathan Young
Prepared for: Dr. Farrokh Mistree and Dr. Jitesh Panchal
14 December 2006
ME6101: Engineering Design
Department of Mechanical Engineering
Georgia Institute of Technology
Atlanta, GA
ME6101A.PRJ.Hall_Waqar_Young
1 of 74
Table of Contents:
1
2
Executive Summary
Project Context
2.1
2.2
2.3
2.4
2.5
3
Project Overview
3.1
3.2
3.3
4
Question for Semester (Q4S):
Group Learning Objectives
World of 2020
Requirements List for Augmented Method:
Proposed Method
Report Organization
Project Requirements Summary
Tasks
Systematic Design
4.1
Characteristics and Principles of General Systematic Design Processes
4.1.1
Principles of Systematic Design
4.1.2
Characteristics of Systematic Design
4.2
Information Flow in Systematic Design
4.2.1
Pahl & Beitz. Engineering Design: A Systematic Approach.
4.2.2
Ullman. The Mechanical Design Process.
4.2.3
Comparison Between Systematic Design Processes
4.3
Benefits of Systematic Design
4.4
Critical Evaluation of Systematic Design
5
Description of Self-Organization
5.1
5.2
5.3
5.4
5.5
5.6
6
Characteristics of SO:
Information Flow:
Decision Processes:
Principles of SO:
Examples of Natural SO Systems:
Examples of Artificial SO Systems:
Requirements List for SOSDM
6.1
Description of Individual Requirements
6.2
Critical Evaluation
6.2.1
Example 1: CONRO
6.2.2
Example 2: Self-Assembly of Electrical Components
7
Critical Review of Project Conclusions
7.1
Verification and Validation
7.1.1
Theoretical Structural Validation (Square 1)
7.1.2
Empirical Structural Validation (Square 2)
7.1.3
Empirical Performance Validation (Square 3)
7.1.4
Theoretical Performance Validation (Square 4)
7.2
Utility
7.3
Critical Evaluation
7.4
Lessons Learned
7.5
Closure
3
4
4
5
6
7
11
13
13
13
14
17
17
17
19
20
20
23
25
27
27
29
29
31
32
33
34
35
42
43
51
52
53
57
57
58
59
59
59
60
60
63
68
1 of 74
2 of 74
Appendix A
Appendix B
Appendix C
References
69
70
71
73
Table of Figures:
Figure 2.1. Proposed Pahl and Beitz method for the world of 2020.
Figure 3.1: Activity Network Diagram for Plan of Action
Figure 4.1: Information flow diagram for the Pahl & Beitz process.
Figure 4.2: Information flow diagram for the Ullman design process.
Figure 4.3: Core transformation diagram for systematic design processes.
Figure 5.1: Characteristics of Self-organization.
Figure 5.2: Parallel information flow in self-organizing system.
Figure 5.3: Information flow bottleneck in centralized control.
Figure 5.4: Rules and their associations with states.
Figure 5.5: Self-organization in Social Insects. (clockwise from top left) Ant trail, bee
dance, firefly synchronization, and termite nest.
Figure 5.6: Cross and hexagonal geometries for static self-assembly.(Bowden 1997)
Figure 5.7: Lock and key geometries for static self-assembly.(Bowden 1997)
Figure 5.8: Assembly process for 3D self assembly.(Breen 1999)
Figure 5.9: Encapsulation, Molding, and Finished Products. (Cannon 2005)
Figure 7.1: The validation square.
Figure 7.2: Information flow through the validation square.
11
14
22
25
26
29
31
32
33
34
36
36
38
38
57
58
List of Tables:
Table 2-1: Drivers for our world of 2020.
Table 2-2: Requirements List for Pahl and Beitz in the World of 2020
Table 5-1: Examples of Self-Organization in Social Insects
Table 5-2: Affinity Diagram for Artificial Self-Organizing Systems
Table 6-1: Requirements List for SOSDM
6
8
34
35
42
2 of 74
3 of 74
1 Executive Summary
We have proposed an augmented and personalized design method based on the Pahl and
Beitz systematic design method in response to the Question for the Semester. We have
used our proposed method as the process for completing our semester project. In this
project report, we chose to compare the systematic design method of Pahl and Beitz to
design methods for self-organizing systems.
Complex and dynamic systems require a self-organizing emergent solution. Effort to date
towards the engineering of SOS has been largely reliant on an ad-hoc approach to design.
Others have called for the need of systematic design as an approach to guarantee the
global behavior of a SOS. In response, we present some general characteristics and
principles of systematic design including Pahl and Beitz and Ullman. Systematic design
processes are superior to ad-hoc or unstructured processes for complex design tasks.
We used current research in self-organizing systems and biological inspired design to
extract general characteristics and principles of self-organizing systems. Multiple
examples of natural and artificial self-organizing systems are used to justify our
observations. Based on this research and our understanding of systematic design and selforganizing systems, we have posed a requirements list for a Self-Organizing Systems
Design Method (SOSDM). We describe each requirement in detail and critically evaluate
our work to address core requirements. We discuss examples that employ core
requirements. These examples include CONRO, a reconfigurable intelligent system, and
the formation of 3D mesostructures which is a static self assembly process.
Our efforts have contributed to research in the area of design of SOS by supporting and
expanding on the body of previous work and detailing the requirements of a design
method tailored to the design of SOS. We believe our effort has integrated the work of
others and brought some concreteness to previous work. In the process, our effort
reinforced the need for systematic design of SOS by reviewing characteristics of
systematic design and emphasizing the benefits of systematic design.
Echoing the words of others before us, we emphasize that there is a lot of future work
needed to achieve a usable methodology. While some authors have proposed design
methods for self-organizing systems, no consensus exists on how to design these systems.
We suggest areas of future research to contribute to formulating the SOSDM. We have
included numerous questions as an invitation to think with us about the future of selforganizing systems and how they can be fully realized.
3 of 74
4 of 74
2 Project Context
In ME6101, the semester project presents an opportunity for us to propose an augmented
design method based on the work of Pahl and Beitz and then validate selected parts of
this method through applying it to a design problem. Our motivation for identifying a
requirements list for a Self-Organizing System Design Method (SOSDM) was based on
the question for the semester (Q4S).
2.1 Question for Semester (Q4S):
We imagine a future in which geographically distributed engineers collaboratively
develop, build, and test solutions to design-manufacture problems encountered in the
product realization process. We recognize that solutions evolve over time. Accordingly,
we will build on what has been done before.
In this context, we have been asked to propose a method to support the realization of
products for a global marketplace through distributed design and manufacture. The Q4S
has been formulated as:
Specifically, how should the Pahl and Beitz systematic design method be
personalized and augmented to support the realization of products for a global
marketplace in a distributed environment?
To augment the Q4S, the key terms must be clearly defined to fully internalize the
concepts of the Q4S.
•
Support – The prescription of guidelines that can be modified to conform to a
desired task. This design process cannot fully encompass every need of the
world of 2020, but will act as a framework for design.
•
Global Marketplace – This term refers to the initiation of new marketplaces
due to expanding job markets in the world of 2020. New marketplaces will
arise from the increased average wages in previously unexploited labor
sources.
•
Distributed – Refers to a design environment that is operable despite
geographic dispersion. Distribution will be the result of globalization and the
necessity for organizations to expand and transform to maintain a competitive
edge.
•
Systematic – This term refers to a set of guidelines that provides sequential
manner to accomplish a goal.
•
Design Method – Provides the process to accomplish a design task.
4 of 74
5 of 74
•
Personalized – Making a design process usable for what we consider critical
to the world of 2020. With this in mind, the process can be used to
accomplish design tasks tailored to our needs.
•
Augmented – Refers to increasing the utility of the P&B design process to
accommodate the requirements of a global marketplace and distributed
environment.
•
Realization – This term encompasses the entire process from the inception of
a product idea to the final distribution of the product.
We have modified the Q4S as given by the course instructors in the follow manner:
How should the Pahl & Beitz systematic design method be augmented and
personalized to support the concurrent realization of technical systems for a
global market place in a distributed environment based on self-organization
concepts?
The rationalization for these changes are:
•
Concurrent - Concurrency reflects our commitment to collaboration and
simultaneous leveraging of group resources.
•
Systems - The change from products to systems highlights the idea that design
processes apply to more than commercialized products and may represent
internally developed components, processes, or systems.
•
Self-Organization Concepts - Self-organization refers to the aggregation of
many generalized units to accomplish a global function through autonomous
or semi-autonomous local interactions.
2.2 Group Learning Objectives
Based on the Q4S, we identified common learning objectives for this project. These
learning objectives helped focus our work to maximize the value we could extract from
the project. By defining these objectives at the beginning of the project, we were able to
promote learning within the group as an intentional activity. The three common
objectives for our group are:
1. Internalize the P&B method and learn how to apply it to a specific design.
2. Learn how to adapt existing design processes to solve novel problems.
3. Internalize the project planning and management tools to learn how to
efficiently manage the design process.
5 of 74
6 of 74
2.3 World of 2020
The world of 2020 is used as a construct to define the requirements for a design method
to answer the Q4S. The world of 2020 can be considered the world of "tomorrow" – the
future which is just beyond the reach of our understanding today. The world of tomorrow
represents the future environment where engineering design will occur. We present
several drivers and metrics in different contexts in the world of 2020 in Table 2.1.
Table 2-1: Drivers for our world of 2020.
Context
Business:
Driver
Process Costs
Virtual Corporations
Globalization:
Global Consumers
Technology:
Web Based Collaboration
Computing Power
Metric
Profitability
Time to Market
Customer
Satisfaction
Connectedness
Speed
Business
Corporations will be driven by the need to continually reduce costs to meet profitability
targets. Cost savings techniques will begin to impact earlier phases of product realization
such as R&D. Profits will remain the metric for understanding how well a company has
responded to cost pressures. In particular, companies will be measured by growth in
profits, not just absolute numbers.
Corporate models will adapt to concepts such as the “virtual corporation” – where a core
group of employees manages a network of outsourced solution providers. Outsourcing
will occur in R&D, manufacturing, customer services, sales, and virtually every other
aspect of running a business. In essence, the concept of a supply chain will be extended
even into the design and marketing of products. The success of these new organizational
structures will be measured by the cycle time of product development – time to market.
In markets which have become highly commoditized, time to market will determine the
profitability of a product. As with profit, time to market will be judged relative to current
state of the art – companies will be forced to continually reduce design cycle times to stay
competitive.
Globalization
Consumer culture will drive the implementation of design methods such as mass
customization. Globalization will increase the consumer base while diversifying
consumer needs. A global marketplace is characterized by multiple cultures and
ethnicities, each with unique market opportunities. Product design in this marketplace
must be supported by rapid prototyping and agile manufacturing for companies to meet
consumer demand and remain profitable. The success of corporations in the global
6 of 74
7 of 74
marketplace will depend on effectively meeting consumer needs regardless of geography
or culture. Success will be measured by how well these diverse needs are met by the
products offered in the marketplace.
Technology
Web-based collaboration is a broad description of tools which are enabled by the network
structure of the internet, focused on the communication and use of information, and
accessible to a global team. They will be measured by the level of connectivity they
provide. They will include conferencing hardware/software, design databases, and
CAD/CAE/CAM software with an emphasis on a single, integrated product model.
Connectivity can be measured by the ease of access (for example, how many steps are
required to access information) and the number of users which can concurrently access
information. As design teams become more dispersed geographically, the ability to
connect quickly and retrieve the correct information without interruption will be
paramount.
These advancements will be driven by increase in computing power and will be measured
by their speed. Speed will be important in terms of processing power and bandwidth. If
the integrated product models includes manufacturing, assembly, form/shape, and
simulation information, it will require faster computers to efficiently sort through the data
and high-bandwidth communication to distribute it to the global team.
2.4 Requirements List for Augmented Method:
Our requirements list for augmenting and personalizing the Pahl and Beitz method is
based on our vision of the world of 2020. In the requirements list given below in Table
2.2, the requirements are defined as either an augmentation or personalization, and a
demand or a wish. In this paper, augmentations or personalizations are defined as:
•
Augmented (A) - Augmenting a process or article involves improving the
current condition of a process/article by adding to it in a constructive and well
thought out manner. For the Q4S, the method needs to be augmented so it
will be better suited for our worlds of 2020. (Raghu 2001)
•
Personalized (P) - The soft side of engineering and design has its place here.
Each one of us values one idea or concept above the others. In
personalization of a design process, we develop a system in-tune with what
we consider critical in the world of 2020. (Raghu 2001)
Demands are requirements that must be satisfied. If a demand cannot be met, it must be
re-evaluated to determine if it is really necessary or the problem must be redefined before
the design can proceed. Wishes are important to customer satisfaction, but are used to
justify increases in cost or added features. The requirement is identified as a demand or
wish in the table and then as a augmentation or personalization in the explanation below.
7 of 74
8 of 74
Table 2-2: Requirements List for Pahl and Beitz in the World of 2020
ME6101
Engineering
Design
Requirements List
Design Method for 2020
Page 8 of 1
Problem Statement:
Construct an augmented and
personalized requirements list for
the Pahl and Beitz design method
in the world of 2020.
Revisions
D
W
10/6/06
10/6/06
10/6/06
10/6/06
10/6/06
D
D
D
D
D
10/6/06
10/6/06
10/6/06
10/6/06
10/6/06
10/6/06
10/6/06
10/6/06
10/6/06
Requirements
1. Process Steps
Design method must be systematic
Task clarification stage
Abstract problem definition stage
Concrete problem description stage
Design finalization stage
D
W
D
D
2. Process Structure
Support concurrent engineering practices
Support mass customization
Support global marketplace
Integrate DfX tools (safety, quality, environment,
manufacturability, cost, etc.)
D
D
3. Information Flow:
Parallel information flow
Information exchange must accommodate
distributed enterprise
D
W
D
4. Information Content:
Information must be cultural/language independent
Information must be standardized
Information must be readily available to distributed
design team
10/6/06
D
10/6/06
W
Resp
JH, NY
and
MW for
all
5. Team Work
Support a multidisciplinary and distributed design
team
Support reconfigurable enterprises (supply chaining,
outsourcing, etc.)
8 of 74
9 of 74
1. Process Steps:
•
Design method must be systematic – Systematic is the salient feature of a
design process. A process should be composed of steps that guide a design
team from task clarification to product realization.
•
Task clarification stage - This stage identifies the core problem and develops
a requirements list for that problem.
•
Abstract problem definition stage (Conceptual Design) – In this stage, the task
is broadened to identify crux of the task. By determining the crux of the task,
the essential problems are identified. A function structure, working structure,
and principal concept are determined.
•
Concrete stage (Embodiment Design) – The concrete stage develops the
construction structure and determines the preliminary form design and
layouts. Upon the determination of best preliminary layout, the construction
structure is defined and a definitive layout is realized through an elimination
of weak spots and preparation of a parts list.
•
Design finalization stage (Detail Design) – The design finalization stage
accounts for the product documentation and detail drawings of the process.
2. Process Structure:
•
Support concurrent design practices (P) – Concurrent design practices will
involve the simultaneous accomplishment of design tasks to reduce the time to
market. This will coincide with the call for increased profitability and
demand of virtual business enterprises.
•
Support mass customization (A) – This requirement is based upon the rapidly
changing consumer culture and subsequent need for agile design and
manufacturing practices.
•
Support global marketplace (A) - Support of a global marketplace responds to
the development of new consumer markets. Products must be realized in such
a way that is benign to geography or culture.
•
Integrate DfX tools (P) – DfX tools refers to various design considerations
that can pertain to any type of design. This requirement represents a modular
input point that will allow further personalization to occur dependent upon the
task description. These considerations will accommodate a variety of the
requirements for our world of 2020: such as consumer satisfaction in a global
marketplace and energy conservation.
9 of 74
10 of 74
3. Information Flow:
•
Parallel information flow (P) - Parallel information flow refers to concurrent
information exchange among a design team. This type of information flow
will enable the horizontal integration of an organization, while reducing the
reliance on a vertically structured enterprise where information trickles down
a hierarchical command chain. This requirement aims to further reduce the
time to market.
•
Information exchange must accommodate distributed enterprise (A) – This
requirement accounts for the future distribution of design teams. Distributed
design teams will be the direct result of globalization and the call for
outsourcing to utilize more cost efficient production resources.
4. Information Content:
•
Information must be cultural/language independent (A) – To accommodate a
distributed design team, language and cultural barriers must be removed to
encourage multi-national collaboration.
•
Information must be standardized (A) – Software must be able to
communicate independent of brand name. Current barriers in information
technology include the restrictions imposed by the limited manipulation of
various data formats. The future advancement of technology will enable this
requirement.
•
Information must be readily available to design team (A) – The speed of
information exchange will be of primary importance in the future. To remain
competitive in a more dynamic marketplace, organizations must develop an
information infrastructure that will continuously supply their design team with
up to the minute data on the product realization process.
5. Team Work:
•
Support multidisciplinary and distributed design team (A) – In the future,
design will be collaborative effort among many individuals dispersed across
the globe. Dispersion will be the result of outsourcing which will be driven
by the necessity to exploit more cost efficient production resources. To
accommodate the realization of all technical systems in this environment,
multidisciplinary design teams must be formed to account the extreme amount
of knowledge required for the development of products and product families.
•
Support reconfigurable enterprises (supply chaining, outsourcing) (A) – To
further reduce the time to market of an enterprise, the core competencies of
multiple enterprises will have to be exploited in response to the demand for
mass customization.
10 of 74
11 of 74
2.5 Proposed Method
Based on the requirements identified for the world of 2020, we have proposed an
augmented and personalized design method using the Pahl and Beitz systematic design
method as our foundation. The Pahl and Beitz method is described in detail in Section
4.2.1. In using Pahl and Beitz as our base method, we have included all of the core
transformations from the original method in the augmented and personalized method
presented in this section. These core transformation as identified in Figure 4.3.
Figure 2.1. Proposed Pahl and Beitz method for the world of 2020.
The discussion below summarizes the primary augmentations and personalization to the
Pahl and Beitz base method. In Chapter 3, we personalize this process for developing our
report. For more in depth discussion on the proposed method, please refer to our
individual Q4S submissions.
Primary Augmentations:
•
Global Marketplace. Ethnographic research accounts for the various
cultures/languages across the world.
•
Distributed/Multidisciplinary Design Team. The subdivision of tasks and DfX
represents a point at which the design focuses are prioritized and delivered to the
most qualified individuals in a design team.
11 of 74
12 of 74
•
Mass Customization. This type of design is already evident in current organization
such as Dell and Nike. It will continue to be a salient feature of successful
enterprises in the future. Our solution to this problem is represented by the
additional continuous improvement phase and the in identification of customer
desires.
•
Reconfigurable Enterprises. This requirement is addressed for the DfX where
outsourcing and supply chain manipulation could occur to accommodate the
production needs of a virtual corporation.
Primary Personalizations:
•
Concurrent Practices. The combination of preliminary and definitive layout
development is an example of concurrent engineering practices.
•
Parallel Information Flow. Subdivision of tasks-We envision a design
environment where information is instantly available to all networks of an
enterprise.
12 of 74
13 of 74
3 Project Overview
Based on our modified Q4S and our group learning objectives, we choose to compare the
systematic design method of Pahl and Beitz to design methods for self-organizing
systems. Briefly, self-organization refers to a system's ability to autonomously organize
or reorganize in response to internal or external stimuli. Swarm behavior in insects is a
representative example of a natural self-organization.
In the project, we used current research in self-organizing systems and biological inspired
design to extract general characteristics and principles of self-organized systems.
Multiple examples of natural and artificial self-organizing systems are used to justify our
observations. Based on this research and our understanding of systematic design, we have
proposed a requirements list for a Self-Organizing Systems Design Method (SOSDM).
Based on these requirements, we suggest areas of future research to contribute to
formulating the SOSDM.
3.1 Report Organization
Thus far, we have provided the Question for the Semester that our team aims to answer,
the process of developing the systematic method used to structure our project, and an
overview of the project including the project objectives and a requirements list for the
project. In chapter 4, we discuss the essential attributes of a systematic design method. In
chapter 5, we discuss the key principles of self-organizing systems, both natural and man
made. We also provide the reader with an overview of the features of self organizing
systems to be engineered. Based on these features of self organizing systems, in chapter 6
we discuss requirements for a design method for the realization of self-organizing
systems. In chapter 7, we provide a critical review of our project, including a gap analysis
between the P&B method and a Self-Organizing Systems Design Method. We also
discuss verification and validation of the P&B method used to structure our project
activities, utility and lessons learned.
3.2 Project Requirements Summary
As a prerequisite to creating a project plan, we formulated a requirements list for the
project. This list represents both our specific objectives in completing the project as well
as identifying important project constraints. It would later serve as a list of evaluation
criteria in reviewing our project status. The full list is included in Appendix A. We have
listed the most critical requirements below:
•
Validate our proposed augmented and personalized design method.
•
Perform a gap analysis between characteristics of P&B & a SO-based design
method.
13 of 74
14 of 74
•
Perform a gap analysis between mechanisms of P&B and a SO-based design
method
•
Provide a platform for individual Q4S augmentations
•
Identify questions for future research.
These requirements capture the macroscopic objectives of the project. Other requirements
addressed how we would work as a team and the format of the report. For example, we
specified that we would work concurrently using the method we proposed in A3. For the
paper, we recognized that continuity was important within the text and that we needed
illustrate our research visually to effectively communicate to our target audience.
We recognized specific focus areas for the project that became requirements list
headings. These included: Process Flow, Content, Compare and Contrast, Design For X,
Process Tools, and Continuous Improvement. All of the requirements were grouped
under these headings using the affinity diagram in Appendix B.
3.3 Tasks
Development of Activity Network Diagram:
The Activity Network Diagram in Figure 3.1 provided a simple yet effective approach
for laying out our plan of action for the project. At a glance, the diagram provides the
sequence of activities in the four major phases of our systematic design process.
Figure 3.1: Activity Network Diagram for Plan of Action
14 of 74
15 of 74
Activities of Planning and Task Clarification:
Major activities during the planning and task clarification phase included developing a
common vision, conducting background research, clarifying the task, planning our
project validation, and developing a requirements list for the project. Developing a
common vision included development of common A0 goals, agreeing upon a Q4S,
common vision of design environment of 2020 and common augmentations to P&B
method. Forming a common vision allowed everyone to have a stake in the project which
was essential for developing a productive team. A validation plan was developed early on
to clarify how the team would verify and validate our execution of the augmented and
personalized P&B method. After taking the audience and the research need and
opportunities of our project into account, the team was able to pose the crux of the task
and transform an open ended and ill posed problem into a problem we could effectively
tackle in the time allotted. The outcome from phase one was a requirements list which
gathered expectations and constraints for our project.
Activities of Conceptual Design:
Major activities during conceptual design included abstraction, identifying and relating
core ideas from our research and developing an outline. All of our personal observations
and reflections on research conducted during the previous phase on the topic of self
organization were brought together for the purpose of abstraction in a group setting.
Through abstraction, the team was able to identify and relate core ideas, mainly the key
characteristics of self organization in social insects and in artificial self-organizing
systems. Through abstraction, feedback within the team and feedback from course
instructors, the team was able to transform the requirements for our project into a report
outline which satisfies the expectations and constraints of our project.
Activities of Embodiment Design:
Major activities during embodiment design included planning and execution of parallel
workflow, planning a strategy for instilling quality into our work and developing a rough
draft of our report. To plan for parallel workflow, the team identified the relationships
between the planned sections of our report in order to assign ownership of sections to
individuals. Defining DfX tools required the team to consider common but all too often
overlooked techniques from technical report writing. By planning these common
technical writing techniques into our project activities, we were building quality into our
work. DfX includes design for readability, continuity, and design for Farrokh and Jitesh.
DfR verified that ideas are articulated well, figures are used when proper, practical
examples are provided for illustration, grammar and punctuation is correct, wordiness is
minimal, etc. DfC verified that the introductory and concluding remarks of each section
flow into previous and following sections. DfF&J verified that the report is targeted
towards visual learners and reflects the critical feedback from the midterm report.
Through use of concurrent report writing, iteration and DfX tools, the team transformed a
report outline into a rough draft, the result of embodiment design.
15 of 74
16 of 74
Activities of Detail Design:
Major activities during detail design included proof reading and refinement, verification
and validation, and final report submission. DfX tools from the previous phase were
utilized even more so during detail design to transformation the rough draft into the final
report. Verification and validation consisted of the team evaluating our execution of the
personalized and augmented P&B method used to structure our project. The outcome
from detail design was a report ready to be bound and submitted for review. As our
activity network diagram shows, submission of the final report for grading is a major
milestone but an end to research on a self-organizing systems design method. Nathan and
Dr. Fathianathan will continue research on closely related topics.
Development of PEI Diagram:
While the Activity Network Diagram proved useful for organizing the sequence of our
activities, the team supplemented our planning efforts by developing the PEI diagram in
Appendix A. The PEI diagram is more useful on a day to day basis because it provides
the duration of each task, ownership of deliverables and due dates for deliverables. It
should be noted that, just like a requirement’s list, this is a living document which is
updated during the design process.
Development of Requirements List for Project:
A general list of requirements for the project report was first generated in a group
brainstorming session. To organize the requirements into groupings based upon the
relationships between each requirement, an affinity diagram was constructed as shown in
Appendix B. The six groupings and the requirements are ordered into a requirement’s list
found in Appendix C. The requirement’s list conveniently provides the problem
statement, requirements, demand or wish designations and date stamps for each
requirement. Our requirement’s list contains six wishes that our team would like to fulfill
in this project report but is not required to. These project wishes include the wish to
provide a platform for individual Q4S personalization and the wish to lead to a
conference paper.
16 of 74
17 of 74
4 Systematic Design
Systematic design processes represent the best practice design methods of the later part of
the 20th century. As described by Pahl & Beitz, these processes are based on a collection
of work starting in the mid-1800's. As described in more detail below, these processes
typically approach a design problem in a sequential, top-down way. They provide an
engineer with a framework for converting an ill-structured and ill-posed problem into a
series of smaller, solvable tasks that will generate the optimum solution at the end of the
process. The later processes, such as Pahl & Beitz, are based on systems theory and rely
on an early abstract problem representation to arrive at a concrete, fully embodied
solution at the end. Ullman has defined a process for mechanical products more recently
which incorporates the same basic information flow as Pahl & Beitz but has added
contemporary concepts such as concurrent engineering and modern quality metrics. In
this work, we will use the Pahl and Beitz method.
In this chapter, we will present some general characteristics and principles of systematic
design. These will be contrasted with the characteristics other methods. Two systematic
design processes will be described in terms of information flow and core transformations.
We will discuss the issue of control and the decision making process in systematic design
and provide examples of practical problems which have been solved using systematic
methods.
4.1 Characteristics and Principles of General Systematic Design
Processes
Both characteristics and principles can be viewed as requirements. They define a
systematic process and provide a convenient reference for comparison with other types of
design process. They will be used with the requirements for design in the world of 2020
to determine how effective a systematic design process will be in this future world.
4.1.1 Principles of Systematic Design
The principles of systematic design describe a framework or philosophy that directs the
flow information through a systematic design process. They are formulated as a guide for
the process of design decisions. These principles are the basis for the characteristics
identified below. The principles are:
•
Explore design alternatives early in the process. Exploring the maximum number
of alternatives increases the chance that the designer will be able to discover the
optimal solution. However, the alternative should be explored at the conceptual
stage since concepts can be evaluated before the designers have invested much
time and resource into embodying them.
•
Reduce or eliminate design changes late in the process. Once a design has
reached the embodiment or detailed design phases, a huge amount of effort has
been invested in the chosen solution. In addition, all of the previous choices have
17 of 74
18 of 74
combined to form an interdependent mesh of solution characteristics. Change
becomes progressively more difficult, complicated, and time-consuming as the
design becomes more defined. This results in a natural barrier to change late in
the process. The later a design change occurs in the process, the more expensive it
will be. Pahl & Beitz have observed that "in the subsequent embodiment and
detail design phases it is extremely difficult or impossible to correct fundamental
shortcomings of the solution principle."
•
Clearly define all design objectives and constraints at the beginning of the
process. The word "systematic" implies a system or purposeful approach to
design. By clearly defining the objectives for the design project, the designer has
a proper framework for decisions. The constraints provide a framework and
boundaries for the solution. They are an important component of narrowing the
project from an ill-defined, unstructured problem into a well-ordered, defined
solution. Finally, the constraints provide a vehicle for explicitly defining the
customers expectations and objective evaluation criteria for selection processes.
The first task of a systematic design method is establish the criteria for decisions
before any decisions are made.
•
Use abstract functional models as a foundation for the completed design solution.
Modern systematic design processes follow a top-down approach which is based
in systems theory. The initial designs are define in terms of "what" must happen,
not "how" it will be accomplished. The focus on function allows the designer to
work at an abstract level and avoid solution fixation.
Functional models tend to encourage modularity in design. Since a particular
function is only described in terms of function, input, and output, it can be
replaced a combination of different functions which perform the same action with
the same input/output relationships. This increases the robustness of the design
since one part of the design can be replaced without causing a global redesign.
•
Use objective evaluation techniques based on predefined requirements to select
between design variants or move between process stages. Systematic design
processes seek optimal solutions. Assuming enough variants have been created,
objective decision processes are important for selecting optimal solutions with the
minimum effort. By using the requirements and objectives defined at the
beginning of the process, the designer can overcome inherent biases and properly
select good alternatives, even if they are counter-intuitive. Systematic decision
processes ensure that all alternatives have been considered in a fair and consistent
manner.
These principles are embodied in the characteristics listed in the next section. These
principles guide the overall flow of information through a systematic design method and
the structure of the decision making processes. These principles are clearly demonstrated
in both the Pahl and Beitz method and the Ullman method, outlined below.
18 of 74
19 of 74
4.1.2 Characteristics of Systematic Design
Some general characteristics of systematic design processes are:
• Systematic design processes do not rely on chance or "trial and error" methods
for achieving an optimum design. A random process is the opposite to systematic
process; the systematic process uses a series of methodical steps to avoid to the
miscommunications, oversights, and errors common to ad-hoc design processes.
•
Systematic design processes are defined by a series of phases. The division into
phases helps direct the design work. Different phases typically focus on different
decisions types and different engineering skills. For example, conceptual design
involves a great deal of creativity in generating innovative concepts whereas the
detail design phases requires great attention to detail and discipline to successfully
complete the product solution. The transition between phases also creates
convenient decision and analysis points. The transition between each phases can
be defined by a "gate" or discrete decision which requires a conscious choice to
move into the next stage.
•
The process starts by identifying an unmet design need. The systematic design
process requires a goal in order to deliver an optimum solution. The identified
need justifies the resources devoted to the project and the directs the convergence
towards a solution.
•
The initial tasks involve clarifying the problem into a form that a designer can use
to move towards a solution. For designers to make intelligent decisions for a
product which will satisfy customer demands, the designers must understand what
the customer wants and what aspects of the final product will be most important
to the customer.
•
Systematic design is based on a requirements list that explicitly documents the
constraints for the design. This list is generated very early in the process and is
foundational to the remaining steps.
•
Most systematic processes are "divergent-convergent" (Ullman 2003). Multiple
solutions are generated in the earlier phases and reduced to an "optimum" solution
which is developed completely.
•
Systematic process move from the abstract to the concrete. The design is
represented early by high-level functional system models which are gradually
converted into well-defined physical designs. Essentially, the systematic approach
encourages a top-down view of design. Pahl and Beitz recognize that "it is always
advisable to proceed from the qualitative to the quantitative, from the abstract to
the concrete, and from rough to detailed designs."
•
Iteration, particularly between phases, is typically the result of encountering
problems and not a planned process. Iteration, particularly in later phases is
discouraged. Systematic design processes attempt to identify the optimum
19 of 74
20 of 74
solution with the least amount of work. Iteration in a systematic process is
essentially rework because the designer must return to an earlier and repeat
process steps which have already been completed.
•
Systematic design focuses on the early stages of the design process. Changes and
iteration are encouraged early in the process to prevent them from occurring near
the end. Even small changes to the product during the detail design phase can
have large consequences in terms of cost, time, and quality.
•
Systematic design processes encourage objective analysis and decision making
processes. Complete information is rarely available, but decisions are made in a
structured and systematic way.
•
The systematic method works particularly well for low and medium complexity
design problems. Highly complex problems such as large system design can pose
problems for systematic design methods. The addition of concurrent engineering
has attempted to alleviate some of these concerns, but the top-down nature of the
systematic process tends to create decision bottlenecks.
The structural characteristics of systematic design processes will be described in terms of
information flow diagrams for several existing processes. While authors have defined
different numbers of phases and use different syntax, the core transformations of
information in each process is the same. Each of these examples also exhibit the
characteristics outlined above.
4.2 Information Flow in Systematic Design
Two systematic design processes are described below. Each of these processes conforms
to most of the characteristics and principles described above. The Pahl & Beitz process
was developed in Germany in the 1970's and is the basis for the VDI and British
Standards design processes. Ullman's process was developed in the United States in the
1990's and is similar in many ways to Pahl & Beitz. Ullman has developed the conceptual
design phase differently and has integrated some modern tools such as QFD (quality
function deployment) and robust design, among others.
A process can be defined as a series of steps with common inputs and outputs connecting
them. In a design process, the design is represented by information. Accordingly, the
processes will be described using an information flow diagram which demonstrates the
core transformations of design information. In each process, the input is a problem
description and the output is a fully defined solution. Both processes are structured
differently but conform to the basic principles described above.
4.2.1 Pahl & Beitz. Engineering Design: A Systematic Approach.
Pahl & Beitz have proposed a four-phase systematic design method which is shown in the
figure below. Within these four phases, information is transformed from an initially illformed problem to well documented solution which is ready for manufacture. Pahl &
20 of 74
21 of 74
Beitz do not include manufacturing in their process and do not consider any work past the
completion of the design. The product of the Pahl & Beitz method is a design description
complete enough to be transferred to a manufacturer with no additional information
required. The process is defined in terms of phases:
1. As shown in Figure 4.1 below, the P&B process starts with a task which is
generated by an identified need from the market or from within the company. The
initial phase, Planning and Clarifying the Task, begins by clarifying the initial
task into a product proposal. Based on this proposal, a requirements list is
generated. These requirements form the basis for the rest of the design process are
focused on constraints on the final design solution. The two main information
transformations are the creation of the task proposal and the generation of the
requirements list.
2. The Conceptual Design phase converts the requirements list into a principal
concept. The requirements list is abstracted to define the crux of the problem – a
solution-neutral statement which summarizes the function of the product. This
overall function is then defined in terms of input and output flows of energy,
material, and signals. Sub-functions are created to accomplish the overall function
and are combined into a function structure by linking compatible inputs and
outputs. Multiple working principles are defined for each sub-function which are
combined to form working structures. These working structures are evaluated
using technical and engineering criteria to select the most promising concept.
3. The Embodiment Design phase converts the concept into a preliminary and then
definitive layout. Layouts are defined as a concrete product design with
dimensioned geometry and material specifications. Multiple preliminary layouts
are created, refined, and reduced to the most promising layout through a selection
process. The preliminary layout is converted to a definitive layout by defining the
design geometry and materials. Cost and quality are used as criteria for
evaluations and refinement at this point. The definitive layout includes enough
information to thoroughly evaluate the design before moving into the detailed
design phase.
Pahl and Beitz do not specify a rigid process for embodiment design but
recognize that flexibility is essentially. Instead, they offer principles and
guidelines for the designer to consider. In this sense, embodiment design is
different from the prescribed, step-by-step process for conceptual design. They
also recognize the necessity of iteration, particularly because of dependencies
between sub-functions. The embodiment phase is a more fluid process which will
not proceed as linearly as the conceptual phase.
4. Detailed Design is the final phase of the P&B process. It is focused on finalizing
the details of the design and creating documentation that can be used to
manufacture the product. At the end of the detail design phase, all of the details of
the design have explicitly specified, including dimensions, materials, production
21 of 74
22 of 74
processes, and costs. The output of the detailed design phases is complete product
documentation. Pahl & Beitz do not consider the manufacture or any tasks which
follow as a part of the design process.
Figure 4.1: Information flow diagram for the Pahl & Beitz process.
22 of 74
23 of 74
Pahl & Beitz emphasize the conceptual design and embodiment design phases. The
strength of the method is the reliance on systematic development of function system
models in the conceptual design phase. These two phases exemplify the "divergentconvergent" characteristics of systematic processes. The design diverges into multiple
solution variants in conceptual design and converges on the principal concept. Multiple
preliminary layouts are used to create the final, definitive layout.
Figure 4.1 does not clearly show the iteration that may be necessary to move through the
process to the solution. However, Pahl & Beitz do recognize that their process is
"essentially sequential" and aims to minimize iteration. The Pahl and Beitz method was
created before the emergence of concurrent engineering concepts. Their method is
compatible with concurrent concepts – the technical and economic criteria used to select
both the principal concept and definitive layout can include manufacturing, quality, cost,
and other criteria. They define metrics and methods for evaluating cost and quality, but
do not explicitly integrate them into their design process.
Pahl and Beitz recognize at least three levels of complexity for design problems: original
design, adaptive design, and variant design. Original design, or the design of products
which requires the creation of a new function structure, is the most difficult and complex.
Adaptive design may reuse a function structure but will redefine specific working
principles. A typical problem for adaptive design is the redesign of existing products to
take advantage of new technology – the basic function structure remains unchanged but
the new technology will replace some of the original working principles. Both original
and adaptive design requires the full use of the conceptual design phase. Variant design is
the least complex since the design is only changed at the embodiment level. An example
is to scaling a product into size ranges. Variant design does not require conceptual design
since the concept is unchanged and may be reverse engineered if necessary.
4.2.2 Ullman. The Mechanical Design Process.
David Ullman has published a systematic design process which is ideally suited to
mechanical product design. Ullman uses the same basic structure as Pahl and Beitz, but
has added many of the newer design process tools. Ullman's process has divided the core
design tasks into different phases than Pahl and Beitz. For example, Ullman defines a five
phase process which includes a post-launch support phase. His process also emphasizes
the stage and gate concept – the end of each phase includes a decision point or gate that
must be passed before beginning the next stage. This gate decision is based on a formal
process and prevents backtracking or committing resources in a unstructured or ad-hoc
way. The phases of the Ullman process are:
1. The process begins with a task clarification stage, called Project Definition and
Planning. The input to this phase is to clarify the product need. Ullman specifies
that a team should be developed as the first task, and then the team defines the
project based on market research and internal company goals. The team approves
the Project Plan as the gate to the next stage.
23 of 74
24 of 74
2. Based on the project plan, a requirements list is generated in the Specification
Definition phase. Requirements are based on customer demands and competitive
benchmarking. These requirements are translated into engineering specifications.
The team approves the Project specification to move into the next stage.
3. Conceptual Design begins by using the specification document to generate
concepts. Ullman defines concept generation as "developing a functional model of
the product" based on customer requirements. A "function is the logical flow of
energy [including static forces], material, or information between objects or the
change of state of an object caused by one or more of these flows." This is
essentially the same idea as the Pahl & Beitz principal function. Ullman does not
explicitly define function structures as an intermediate step towards the final
concept, but does rely on working structures (complete with working principles)
to represent the concept variants. Another critical difference between Ullman and
Pahl and Beitz is that Ullman does not base the creation of the function structure
or overall function on a solution-neutral problem statement, known as the crux of
the problem.
Ullman also recognizes that "because iteration is less expensive during this phase
than in the product design phase, it should be encouraged here, before the product
is too well defined." Based on concurrent engineering principles, multiple
concepts are generated and evaluated in Phase 3. As defined by Ullman, "a
concept is an idea that is sufficiently developed to evaluate the physical principles
that govern its behavior." Concept evaluation and refinement follows the concept
generation process. The design approves the final concept and documents the
result to end Phase 3.
4. Product Development is essentially embodiment design. Ullman does not
differentiate between the preliminary and definitive layout, but instead proposes
an iterative process where the concept is refined and evaluated until it reaches on
acceptable quality level. The primary metrics for quality are: performance,
robustness, cost, and manufacturability. These metrics provide a means for
integrating concurrent design concepts such as design for manufacture or design
for quality. It is important to note that many detailed design activities occur
during the product iterative product development loop mentioned above. Ullman
combines embodiment and detail design, recognizing that the final activity in
Phase 4 before the final product approval is a documentation step.
5. Ullman's process ends with a product support phase. This phase is expected to last
throughout the life-cycle of the product and recognizes that design methods must
support the entire product realization process. Activities here may include
customer support, manufacturing support, and eventually product retirement.
These activities are not present in the Pahl and Beitz method.
Ullman's process also exemplifies the principles and characteristics of systematic design
processes listed above. The initial phases focus on defining the problem and documenting
24 of 74
25 of 74
customer expectations. The concept design phase focuses on functional models first and
then physical processes to realize those functions. The later phases refine the product
design to the point where it can be produced.
Figure 4.2: Information flow diagram for the Ullman design process.
4.2.3 Comparison Between Systematic Design Processes
Based on the discussion above, both systematic design methods have core ideas or
principles which unite them. The points of divergence between them highlight the
flexibility and variety available in system design. Based on the core transforms in each
method, the processes are similar. Figure 4.3 (below) shows these core transformations
and where they occur within each process. While Pahl and Beitz and Ullman have
divided the phases differently, the overall flow of information is the same.
The principles defined above dictate which transformations are essential to a systematic
method. Each method clarifies the task and then records the design constraints in a
requirements list. For the conceptual design phase, functional system models are the basis
for generating concept variants and then selecting the most promising concept for further
development. The final stages focus on finishing the work of converting the abstract
concept to a fully defined product. Ullman has combined the embodiment design and
detailed design whereas Pahl and Beitz define these activities in separate phases.
Regardless, the same actions of defining dimensions, materials, and production processes
are followed by a thorough documentation of the solution.
25 of 74
26 of 74
Ullman has provided several augmentations versus the Pahl and Beitz method. This
occurred for two reasons. Ullman's method was created at least two decades after the first
publication of Paul and Beitz. Secondly, Pahl and Beitz defined their method at a more
abstract and therefore adaptable level. They have provided tools for analysis, decision
making, creative thinking, and other design activities. However, they do not require the
designer to use any of their tools – they are only provided as a part of design toolbox.
Ullman has integrated his tools more explicitly into his process. For example, Ullman
assumes the design process will involve a team and his stage and gate structure depends
on a team of people approving the design at each gate. In contrast, Pahl and Beitz do not
specify the use of a team but their method is compatible with teams or individual
designers. Another example is the explicit reference to concurrent engineering throughout
Ullman's text. Once again, Pahl and Beitz do not mention concurrent engineering but
have defined their method in a way that is compatible with concurrent engineering
concepts. The evaluation methods for concepts in Pahl and Beitz "is based, first of all, on
the requirements list." The suggested requirements list headings include cost, safety,
production processes, and quality – all factors concurrent engineering considers
throughout the design process.
Figure 4.3: Core transformation diagram for systematic design processes.
26 of 74
27 of 74
4.3 Benefits of Systematic Design
In comparison with ad-hoc or random design processes, the systematic methods are
clearly superior. Typically, engineers which follow a purely intuitive design process will
ignore optimal solutions in favor of preconceived solutions (solution fixation) or develop
a limited number of concepts. If the systematic analysis and selection procedures are
ignored, the flaws in the basic design concept are discovered in the embodiment or even
detail design phase. This results in an iteration back to the conceptual design phase. As
Pahl and Beitz observe, "It would be a disaster, for example, if the design team had to
start again at the beginning having reached the end [of the process]."
Another strength of the systematic process is the focus on a requirements list. The
requirements are the basis for all design analysis throughout the process, including
ensuring the accommodation of customer needs. An elegant design that does not address
the customer's requirements will be a practical failure. This will result in a large iteration
loop to bring the design into line with customer expectations. Since much time and effort
was invested in the original design, the designer is rarely given the proper time for
redesign that would result in an optimal design, even with a systematic method.
The early focus on conceptual functional models provides benefits to designers when it is
applied systematically. If a design has been developed from a well made requirements list
and properly executed conceptual design phase, much effort is reduced in the
embodiment, detail design, and post launch phases.
In addition, functional concept models assist with current design paradigms such as mass
customization and strategic design. If a product is understood at the conceptual level,
opportunities for customization with standardized modules are more easily identified.
Strategic design builds on mass customization concepts and extends them into product
families and adaptable product designs. The working structure of design is the key
description of the basic working principles for each function and can be used in strategic
design to identify areas in the product which may need to be upgraded to extend a
product platform or adapt it to new markets with a minimum amount of redesign.
4.4 Critical Evaluation of Systematic Design
Systematic design processes have weaknesses as well. Smith and Reinertsen (1999) have
identified cycle time as the primary disadvantage of a phased product development
process. Cycle time has been identified as a primary metric for design processes in 2020.
Phased processes have a tendency to create decision bottlenecks at decision points. Even
when designs tasks are solved concurrently, the cycle time will be based on the task
which takes the most amount of time. If resources have been devoted to other tasks, they
may have to wait for all tasks to finish before proceeding the review and decision
process.
Decision gates also limit the extent of parallel design tasks, particularly across those gates
and between phases. No project can be solved in a purely parallel process because design
decisions always involve dependencies. However, concurrent engineering can blur the
27 of 74
28 of 74
divisions between phases by considering manufacturing and quality concerns upfront.
With regards to sub-functions and modules, it may be possible to begin embodiment of a
particular sub-system while other aspects of the design are still within the conceptual
phase. Concurrency at this level requires a carefully designed function structure to
increase modularity and limit dependencies between modules.
Smith and Reinertsen also focus on the issue of risk. Phased processes tend to minimize
technical risk, but increase the time required to develop a product. In a dynamic market
place, the risk of developing products too slowly or missing market opportunities can be
equal to the technical risk of product failure. Phased process can effectively manage these
risks, but they require a careful balance of flexibility and structure.
The issues of cycle time and technical risk raised by the authors are closely related to the
issue of complexity. As the complexity of a design problem increases, the technical risk
also increases. Systematic design processes mitigate these risks by following a structured
decision process to ensure that all aspects of the decisions are considered. These
processes then result in a large number of design decisions which are typically routed
through a limited number of teams or design managers. Even when teams are solving
tasks in parallel, complex problems tend to create highly interdependent designs which
require coordination between each team. Extensive testing or model building is another
way to mitigate technical risk with respect to complexity, but can greatly increase
development times. For complex design tasks, systematic design processes are still
superior to ad-hoc or unstructured processes.
28 of 74
29 of 74
5 Description of Self-Organization
In this chapter, we provide the reader with an overview of self organizing systems to be
engineered. In engineering, self-organization is a promising approach to manage complex
chains of interaction in complex systems. A system is complex if the behavior of the
system is difficult to deduce from the behavior of the parts. Generally, complexity scales
with the number of elements, the number of interactions between them, the complexities
of the elements and the complexities of the interactions (Gershenson 2006). Selforganization is most appropriate for systems that cannot be managed with a traditional,
centralized approach which are systems that are constantly changing.
5.1 Characteristics of SO:
There are certain characteristics that are unique to self-organizing systems. These are
characteristics that natural SOS exhibit and that engineered SOS hope to replicate. In this
section the four key characteristics in Figure 5.1 are discussed: efficiency, robustness,
multi-stability, and flexibility.
EFFICIENT
ROBUST
MULTISTABLE
FLEXIBLE
Figure 5.1: Characteristics of Self-organization.
•
Efficiency: The efficiency inherent in a SOS can be attributed to at least three
factors. First, agents are generally less idle and more productive since they are
constantly processing information on the current status of the system. Agents in a
SOS are quick to respond to the system’s needs. Second, a reduction in system
errors reduces wasted time and energy. Errors are reduced due to unambiguous
and reliable information between the agents in the system. This increased
reliability of information can be attributed to two main factors with the first being
a lack of nepotism and the second being a lack of centralized control.
29 of 74
30 of 74
In a given society made up of individuals, the presence of nepotism leads to the
formation of factions and threatens to serve the selfish interests of these factions.
In a SOS however, information is free from bias. By placing the interest of the
collective above personal interests, agents take neutral actions for the benefit of
the system. The second factor for the increase in reliable information is the lack of
centralized control. In effect the errors of a central leader don’t become errors of
the system. Distribution of the decision making process across all the agents
improves the reliability of decisions made and as a result, the reliability of
information itself. Error is effectively reduced when agents independently
evaluate signals from the system and independently decide a course of action. The
third factor contributing to efficiency in a SOS is the division of labor. To put it
simply, the right agent is used for the right job. Work is partitioned among
specialists in SOS. This division of labor may be hardwired into the agents or it
may be driven by demand.
•
Robustness: A SOS is regarded as robust for at least four reasons: ability to self
repair, an effective voting mechanism, back-up fail safe procedures and
anonymous partners. The feature of self repair is inherent in a SOS which is
ideally suited for self repair given that it involves constant monitoring of the local
environment by a large number of agents. A SOS can respond rapidly to
disturbances due to the reliance on local feedback loops between the agents and
the environment. Mistakes made by an agent can be repaired quickly since agents
don’t have to wait for instructions from a central leader.
Second, a SOS contains an effective voting mechanism in which majority
decisions overrule. This voting mechanism encourages productive agent behavior
and discourages counterproductive agent behavior. To adjust to changes in the
environment, agents adapt their local behavior based on local cues. Once enough
agents have adapted their behavior, the growing group begins to influence the
remaining agents until all agents have adapted to the new environment.
Third, agents may use back-up fail safe procedures which is best illustrated with
an example. An example from social insects is ants using not only pheromones as
markers during foraging but also using the branching angles of their foraging trail
networks as cues (Boomsma 2006). Lastly, the fourth factor contributing to
robustness in a SOS is the fact that agents are not bound to interact with
prescribed partners but instead interact with whoever is available.
•
Multi-stability: SO systems behave non-deterministically, meaning the exact
evolution of global features of the system is not predictable. The large number of
agents involved combined with the lack of central control results in an inherent
randomness that is built into the system. Randomness in the behavior of the
agents leads to the desired property of multi-stability which allows multiple
solutions for global features of the system. Since agents behave with little to no
global knowledge of the system, global features of the system emerge from the
behavior of agents using only local information and through local interactions and
30 of 74
31 of 74
local activity. Deviation from expected trends in global features is bound to occur
and is in fact necessary to allow agents to explore the space of solutions and to
react to changes in the system. The characteristic of multi-stability can be
adjusted by balancing of randomness allowed in the behavior of agents to allow
for the emergence of multiple “coherent” solutions for global features.
Randomness is balanced by adjusting the constraints placed to govern the
behavior of the agents.
•
Flexibility: A SOS transitions between a finite number of unique stages or unique
configurations which do not overlap according to the behavior rules of the agents.
Each configuration stimulates the agents with unique cues or signals. A SOS is
flexible in the sense that agents can reconfigure into one of the configurations.
5.2 Information Flow:
In a SOS, agents communicate through their local environment and not directly. This
mode of communication facilitates parallel information flow as depicted in Figure 5.2.
Agents communicate through their local environment based on ‘serendipitous’ interaction
in which agents deposit information in the general environment. Once information has
been made public, ‘semactectonic’ interaction puts the information to productive use.
‘Sematectonic’ interaction is information conveyed implicitly. An agent is able to
independently analyze cues in the environment and interpret an action without direct
instructions. Agents may already know what actions to take and are waiting for their
signal, referred to as “follow through” use of information. It is these modes of interaction
that allow an agent to wander about looking for cues in the environment to independently
take action.
Agent
Information
ENVIRONMENT
Figure 5.2: Parallel information flow in self-organizing system.
31 of 74
32 of 74
The source of information in a SOS is the large number of local feedback loops and not a
central leader. Since a SOS does not rely on central control, there is a natural safeguard
against information flow bottlenecks. A bottleneck would exist if a highly informed
leader is attempting to disseminate instructions to a large work force, as depicted in
Figure 5.3. The result of parallel information flow is that actions do not follow a welldefined sequence and many activities can be performed at the same time.
Centralized
Leadership
Agents
Information
Flow
Information
Flow
Bottleneck
Figure 5.3: Information flow bottleneck in centralized control.
5.3 Decision Processes:
The decision making process in a SOS is distributed. Instead of relying on a central
leader to make a decision, every agent makes its own independent decision. Agents make
decisions based on positive and negative feedback. Positive feedback promotes activity
while negative feedback counterbalances and regulates activity. A feedback is a cue from
the environment and the distinction between positive and negative depends upon an
applicable rule.
In order to make decisions, all agents need a common set of well designed rules,
particularly if the global features of the system are required to converge to desired
features. An algorithm, or set of rules, governs all decision making in a SO system and
provides a framework to orchestrate all activities. Agents respond to the universal
framework in a uniform manner. Each rule associates one of the finite number of
configurations of the system to the activities of the agents. Every configuration has its
own unique rules, as illustrated in Figure 5.4. The nature of the algorithm, the set of
32 of 74
33 of 74
rules, is important because a given algorithm always leads to the system converging
towards a similar global architecture with similar global features. The organization of the
SOS depends on the number of rules. Ultimately, control over the consistency of the
global features depends upon the nature and the number of constraints, or rules, placed on
the system.
State n+2
State n+1
State n
Rule a
Rule b
Rule c
Rule l
Rule m
Rule n
Figure 5.4: Rules and their associations with states.
An important distinction worthy of mention is that the algorithm guiding the behavior of
the agents evolves over time. Rules are allowed to mutate, with rules being modified or
replaced. For example a rule which is not being used may be replaced by a newer rule
with a higher probability of being used.
5.4 Principles of SO:
The core principle in a SOS is distributed control describes how the collective is
organized without administrators directing the behavior of agents. In dynamic systems, a
highly informed leader would be unable to determine the system state rapidly enough or
to effectively communicate with a large labor force. Instead, agents are organized from
the bottom up by simple reiterated feedback loops.
Another core principle in SOS is stigmergy, a term coined originally in the study of
termite nest construction. However stigmergy can be extended to any SOS with a large
number of agents. The term describes indirect communication between agents that occurs
through the environment. The behavior of agents in a SOS is in response to changes in
the environment and an agent’s own response leads to changes in the environment. Task
coordination is achieved through the mechanisms of positive and negative feedback
which is received through the environment, not necessarily directly from other agents.
33 of 74
34 of 74
The resulting interaction between agents, from the presence of stigmergy, is referred to as
uncoupled and anonymous because agents do not know one another in advance.
5.5 Examples of Natural SO Systems:
Self-organization is a phenomenon that takes place in several biological multi-agent
systems. By self-organizing their activities, social insects achieve goals that overcome by
far their capabilities as individuals (Mamei 2006). Examples of SO in social insects are
numerous. Ants use pheromones to mark trails leading to the shortest path to food. Bees
dance to denote distance and direction to a food source. Termites use pheromone laden
pellet deposition to coordinate the development of structures within a termite colony.
Honeybees form well organized pattern of combs based upon location of brood. Table 1
is a non-exhaustive list of examples of self-organization in social insects and Figure 5.5
depicts selected examples from social insects.
Table 5-1: Examples of Self-Organization in Social Insects
Self-Organizing Behavior
Agents
Path Formation
Nest Sorting
Cooperative Transport
Food Source Selection
Thermoregulation
Nest Building
Synchronization
Feeding Aggregation
Web Construction
Ants
Ants
Ants
Ants, Bees
Bees
Bees, Wasps, Hornets, Termites,
Fireflies
Bark Beetles,
Spiders
Figure 5.5: Self-organization in Social Insects. (clockwise from top left) Ant trail, bee dance, firefly
synchronization, and termite nest.
34 of 74
35 of 74
5.6 Examples of Artificial SO Systems:
Table 5-2: Affinity Diagram for Artificial Self-Organizing Systems
Artificial Self-Organizing Systems
Static Self-Assembly
Robotics
2D Arrays
CONRO
3D Geometries
Multiple Agents
With respect to artificial self-organizing systems, there are two primary divisions that
comprise current research efforts. These divisions include static self-assembly and
robotics. Due to their relative simplicity static assemblies will be outlined first.
Static Self-Assembly:
To completely understand, the nature of static self assembly a definition of self-assembly
must be articulated.
“Self-assembly (SA) is a parallel manufacturing technique where structures of any
size are organized according to a highly preferential thermodynamic
configuration, seemingly self-directed.” (Cannon 2005)
Current attempts at creating static self-assembling systems utilize a combination of
hydrophobic surfaces, interlocking geometries, and aqueous environments. This working
principle combination has been used for two primary types of static assemblies. These
assemblies include two dimensional (2D) arrays and three dimensional (3D) structures.
The 2D arrays are simpler systems that better display the introductory concepts of selfassembly.
Self-Assembly of Mesoscale Objects into Ordered Two-Dimensional Arrays:
In 2D static self assembly, the driving force behind the entire process is energetic
stability. There are three important factors that are used to achieve energetic stability.
These features include geometry selection, bonding method, and motility of the
individual geometries.
With respect to geometry selection, various thin geometries have been used. In
successful tests, crosses, hexagons, and lock and key shapes were used. The selection of
a specific shape controls the type of assembly. For instance in Figures 2 and 3, the
crosses, hexagons, and lock and key geometries develop a grid of open network, close
packed, or chain-like interconnecting arrays, respectively. Along with this geometric
35 of 74
36 of 74
guidance mechanism, the bonding interface is another integral way that the 2D arrays
form.
Figure 5.6: Cross and hexagonal geometries for static self-assembly.(Bowden 1997)
Figure 5.7: Lock and key geometries for static self-assembly.(Bowden 1997)
The bonding mechanism for this type of static self assembly system is hydrophobic
surface interaction. Hydrophobic surfaces require an aqueous environment for the
bonding process to occur. Once placed in an aqueous environment, the solution and 2D
geometries are agitated to promote the random interaction of the hydrophobic surfaces to
achieve energetic minimization. This process can be augmented to further control the
bonding process by determining which surfaces are hydrophobic and the degree of
hydrophobicity. Since bonding requires hydrophobic surface interaction, an aqueous
environment must be present, as stated above. The aqueous environment is used as the
bonding mechanism. Along with this, the bonding environment provides a medium for
the arrays to aggregate.
36 of 74
37 of 74
The 2D geometries are completely immersed in the aqueous medium and shaken. The
shaking inputs energy into the system which encourages the aggregation of the
geometries into an array. Ultimately, the aqueous medium is the primary driver behind
the self-assembly process as it provides a means for bonding and aggregation. With this
in mind, the bonding and aggregation medium is not solely limited to 2D self assembly as
they are also the operating principle of 3D structure formation.
Design and Self-Assembly of Open, Regular, 3D Mesostructures:
As in the 2D array self-assembly, an aqueous environment and hydrophobic surface
interaction is used as the framework for the assembly process. The primary difference in
this process is the practical application of the research. This practical application arises
from the use of heterogeneous structures with electrical components, permanent bonding
processes, and final working products.
Heterogeneous geometries are used to guide the bonding process of individual geometries
and facilitate the appropriate assembly of components. In King’s research, electrical
components are encapsulated in a carrier structure. This carrier structure has low
temperature solder bonding sites which allows thermal input into the aqueous medium to
finish the bonding process.
After the geometries aggregate into an acceptable structure, the medium is heated to
finish the bonding process. Once the bonding process is complete, the structure is
removed from the medium and immersed in a separate dissolving solution to remove the
carrier structure.
By removing the carrier structure, the final product remains in a fully assembled format.
Figures 5.8 and 5.9 collectively display this process with a pictorial representation.
37 of 74
38 of 74
Figure 5.8: Assembly process for 3D self assembly.(Breen 1999)
Figure 5.9: Encapsulation, Molding, and Finished Products. (Cannon 2005)
38 of 74
39 of 74
Robotics:
There are two basic types of robotics that have resulted in plausible explanations for the
physical implementation of self-organizing principles. These types include entities
comprised of modular units and stigmergic multiple agent systems.
Entities with Modular Units:
Currently, two types of modular robots are in use, chain and lattice. Both types of robots
typically use decentralized control to allow identical modules to account for their
neighbor’s activity to determine their current role. With this in mind, each of the two has
advantages and disadvantages, but current forms of chain robots seem to display more
robust operating capabilities.
Chain Robots:
Chain robots are usually comprised of modular identical units that are capable of similar
functions. The identical units must cooperate directly to accomplish a global task. Chain
robots directly attach their modules in a chain or branched chain. In most cases, chain
robots use hinges at their module interfaces to dock. This poses a significant problem
when implemented in a physical environment. This problem is positional docking error.
The overall positional error tends to build through subsequent chain modules. The
requirement of high docking accuracy relates to yet another problem that arises with
chain robots: slow self assembly. Despite these shortcomings, the chain robots
movement seems to have more practical applications such as climbing, crawling, or
rolling. One of the most functional examples of a chain robot is CONRO. (Mackenzie
2003) CONRO was created by Wei-Min Shen and Peter Will at the University of
Southern California. CONRO is described in the following quotes:
“The CONRO robots are built from a set of homogenous, autonomous, and self
sufficient modules..” (Khoshnevis 2001)
“Each CONRO module is a miniature robot with sensors, actuators,
microprocessors ,batteries, and communication devices, and reconnectable
joints.” (Khoshnevis 2001)
“For example, a complex CONRO robot may disassemble itself into a set of small
robots that crawl under the door of a closed room.” (Khoshnevis 2001)
From this, CONRO is a modular robot that has the ability to dynamically adapt to
environmental stimuli. This ability arises from its decentralized control system. Each
module monitors its neighbor to determine its own activity. This monitoring technique is
not specific to chain robots. It is also present in lattice robots which operate in a slightly
different manner. Aside from chain robots like CONRO, there are lattice robots that
operate in a slightly different manner.
39 of 74
40 of 74
Lattice Robots:
A lattice robot contains cube like modules. It extends and retracts the faces of its cubes
to dock with identical cubic modules. The modules assemble in a grid where modules
must touch before they can compete for a space. Therefore, the modules must account for
only its neighbors and not the entire population. Also, the modular robots can reconfigure
themselves into any shape based upon the number of modules. The extension and
retraction of the faces gives rise to the ability to collectively move by the careful
coordination of various modules. The modules do not seem to have an individual means
of motility. Their nature of formation limits them to only attach modules that are nearby
(within docking arm length) to the collective group. From this, the lattice robots do not
display the same practical uses that the CONRO robot has proven.(Mackenzie 2003)
Multiple Agent Systems:
As of now, multiple agent systems are being investigated using the principal of stigmergy
which is common in natural systems. The primary idea behind the use of multiple agent
systems is collective intelligence. A definition of collective intelligence was proposed by
Sulis.
“Collective intelligence consists of a large number of quasi-independent,
stochastic agents, interacting locally both among themselves as well as with an
active environment ,in the absence of hierarchical organization, and yet which is
capable of adaptive behavior.” (Sulis 1997)
In essence this definition is referring to random interactions of a group. With respect to
robotics, there are three factors as to why stigmergy might be useful. These factors have
increased the interest for stigmergy in collective robotics and were proposed by Torres:
“There are several reasons for this increased interest, among others: (a) some
tasks may be inherently too complex for a single robot to accomplish, (b)
performance, robustness and flexibility benefits, (c) to yield insight into
fundamental problems in the life and social sciences.”(Torres 2004)
As in stigmergy in termites, one of the major advantages that could be applied to
mechanical systems seems to be generalized units. Loss of one of these units will not
result in the failure of the system as one of the other units can account for the job of any
other. Also, the generalized, relatively simple units might be able accomplish tasks that
were too complex for single robots. This could arise from their ability to adjust to
environmental stimuli in parallel instead of in series. This parallel adjustment
significantly increases the complexity of the system. This complexity lends itself to
computer simulation; hence the advantages of collective robotics have been viewed
through simulation and observation, yet the proposed solutions to realizing these
advantages have not resulted in a final ideal working product. Some of the most
plausible approaches include the embodied, evolutionary, and continuous-time dynamical
systems.
40 of 74
41 of 74
Embodiment Approach:
The embodiment approach accounts for the specific physical principles that will have to
be employed to realize a stigmergic robot system.
Evolutionary Approach:
The evolutionary approach uses evolutionary mechanisms to account for the complexity
of the environment stimuli with respect to a self-organizing process.
Continuous-Time Dynamical System Approach:
The activity of collective robots is considered a dynamic system because they account for
environmental variations and neighbor interactions. The following explanation of a
dynamic systems approach was proposed by Torres:
“A dynamical systems perspective on autonomous agents emphasizes the
importance of internal state to an agents operation. This way, unlike a reactive
agent, an agent can initiate behavior independently from its immediate
circumstances and organize its
behavior in anticipation of future
configurations of its environment.” (Torres 2004)
With this in mind, the individual units can make decisions about their current condition to
evaluate input not only from its environment but from its neighbor. This would develop a
network of data from many simple units possibly capable of complex environmental
interactions.
41 of 74
42 of 74
6 Requirements List for SOSDM
Based on our observations from self-organizing systems, we have proposed a
requirements list for a SOS design method. As shown in Table 6.1, this list is derived
from the Paul and Beitz systematic design method. Due to its flexible nature,
requirements relating to Paul and Beitz are included within many design categories with
SOS requirements. These categories include design method structure, task clarification,
design for self-organizing agents, reconfiguration, and DFX. Design method represents
the first of these categories as it pertains primarily to Paul and Beitz.
Table 6-1: Requirements List for SOSDM
Revisions
11/21/2006
11/21/2006
11/21/2006
11/21/2006
11/21/2006
11/21/2006
D
W
D
D
D
D
W
W
11/21/2006 W
11/21/2006 W
11/21/2006 W
11/21/2006 W
11/21/2006 W
11/21/2006 D
11/21/2006 W
11/21/2006 W
11/21/2006 D
11/21/2006 W
11/21/2006 W
Requirements
Resp
Design Method Structure
1. Support iterative development
2. Process will be systematic
3. Process will be defined by a series of phases
4. Design is based on a requirements list
5. Method supports continuous documentation
6. Full documentation of the solution is provided
at the end
Information Flow
1. Capable of making meaningful choices based
on "soft" information
2. Capable of making meaningful choices based
on incomplete information
3. Must be able to use large data sets for
decision processes
SOS
Architects
Task Clarification
1. Requirements list includes customer
requirements
2. Define metrics for evaluating
macroscopic/global behavior
3. Define metrics for evaluating microscopic/local
behavior
4. Define robustness targets (how robust?)
5. Define robustness metrics (evaluation criteria)
6. Define accuracy and precision of each
requirement
7. System performance is verified prior to
product release
8. Value of self-organization is clear based on
method output
42 of 74
11/21/2006 W
11/21/2006 D
11/21/2006 D
11/21/2006
11/21/2006
11/21/2006
11/21/2006
D
D
D
D
11/21/2006 D
11/21/2006 D
11/21/2006 D
11/21/2006 W
11/21/2006 W
11/21/2006 W
11/21/2006 W
11/21/2006 W
11/21/2006 W
11/21/2006 W
11/21/2006 W
11/21/2006 W
11/21/2006 W
43 of 74
9. Defines the global/macroscopic system
function
Design for Self-Organizing Agents:
1. Defines Interaction rules between agents
2. Defines interaction rules between agent and
environment
3. Defines functions/capabilities of each agent
4. Defines number of agents (few/many)
5. Defines intended environment for system
6. Defines the decision structure (hierarchy vs.
autonomous)
7. Defines how information will be transmitted
and distributed within the self-organized
system
8. Supports various system architectures
Reconfiguration
1. Support reconfigurable system design
2. Support reconfigurable function structures
3. Reconfiguration does not lead to unexpected
system behavior; resulting in failure
DFx
1. Design method is effective for complex
systems
2. Method is based on concurrent engineering
concepts
3. Method enables mass customization
4. Method enables multi-disciplinary design
5. Method support design for manufacturing
throughout process
6. End of product life-cycle is addressed
7. Emerging technologies are identified and
utilized
8. Products must be safe
6.1 Description of Individual Requirements
The following discussion describes each requirement in detail. The requirements are
grouped by the list headings as shown in Table 6.1 above.
Design Method Structure
1. Supports Iterative Development
43 of 74
44 of 74
Due to the unpredictable and highly coupled nature of self-organizing systems, the
designer will perform multiple iterations to converge on the optimum design. Emergent
behavior, the aspect of self-organization that creates significant macroscopic/global
affects from the aggregation of seemingly mundane local/microscopic interactions
between agents, is particularly hard to predict. Fromm 2006 suggests a self-organizing
design method which is essentially the scientific method – a system is proposed and
multiple experiments are performed to determine the actual performance and unknown
rules. Gershenson 2006 also considers iteration, coupled with simulation, a critical aspect
of the design self-organizing system.
2. Process is systematic
The word "systematic" implies a system. This includes a process with defined steps,
specific order, and information flow. The alternative to a systematic method is random
trial and error or ad-hoc processes. Self-organization behavioral research into nest
building in multiple wasp species indicates that basic algorithms determine whether the
nest built is "coherent" or simply random (Bonabeau 1997). The researchers concluded
the number of coherent algorithms was very small compared to the number of possible
alternatives. Systematic methods are essential to direct design work in a meaningful
direction avoiding the proverbial "needle in the haystack" problem inherent in trial and
error approaches. A systematic process is a framework which assists the designer by
organizing the workflow.
3. Process is Defined by Series of Phases
All proposed self-organizing systems design methods are defined by a basic set of steps
which can be considered design phases.(Fromm 2006, Gershsenson 2006, Capera 2003).
Dividing a process into phases recognizes the different skills, decision types, and mindset
needed during the design process. For example, different tools and skills are needed for
task clarification versus embodiment design. Skills such as task planning and market
analysis are needed earlier in the process. Some parts of the process, particularly digital
verification or simulation, will require technical specialists.
4. Design is Based on a Requirements List
For the designer to work systematical, he or she must be directed by a requirements list.
In this sense, design for a self-organizing system is no different from other system design.
No design is free from constraints – physical laws provide basic limits. In addition, every
system has an intended purpose which directs the designer throughout the process. The
requirements list is an essential component of the process by which a designer transforms
an ill-posed problem into an orderly set of tasks. Design work which proceeds without
first considering the constraints and customer expectations is not systematic but trial and
error.
5. Method Supports Continuous Documentation
44 of 74
45 of 74
Design for self-organizing systems will be a complex process. An efficient yet thorough
method for documenting design work is crucial for designers to leverage team work and
identify critical lessons from development work. Emergent behavior is difficult to
predict; early observation which may seem insignificant at the time may become an
integral part of the final solution. A process of continuous documentation will provide
designers with a method for capturing the knowledge they are generating without creating
too much overhead. This requirement is particularly important for developing
documentation tools.
6. Full Documentation of the Solution Available at the End of the Process
Due to the complex nature of self-organized systems, designers may be able to create a
system which is not well defined. For robotic systems with embedded intelligence, the
designer may have only designed or predicted a sub-set of the system capabilities and
behaviors. If several iterative loops have occurred where multiple changes were made
within the system, it may be unclear which system parameters are important and which
are not. The effective documentation of the system is necessary for reliably recreating
desired system behavior and conforms to the ideals of systematic process.
Information Flow
1. Capable of making meaningful choices based on “soft” information.
In the early iterations of design, the designer will be forced to make “soft” decisions
based directly upon customer requirements. With respect to a SO system, the importance
of this decision will be amplified because it will directly affect the development of
control algorithms for the SO system. This is where knowledge and experience must be
used to determine whether SO is appropriate for the application, which macroscopic
requirements are relevant and which requirements are omitted, the degree to which the
real world physical agents and environments are idealized in the simulations, decisions
on which exact parameters to tune based on simulation results, and ultimately the
decision on when requirements have been achieved.
2. Capable of making meaningful choices based on incomplete information.
Designers must be able to make critical decisions in the absence of all system parameters.
This type of decision making will be used to achieve concurrency and adaptivity in both
the system and design process.
3. Must be able to use large data sets for decision processes.
Due to the increasing complexity of SO systems, decisions will be based upon some type
of computational foundation. One instance will be the activity of reiterating and
adjusting the system based on the results of simulations. Especially in later iterations,
these decisions will have a stronger influence on the embodiment of the design as they
45 of 74
46 of 74
may be based on mathematical equations that are functions of the global properties
observed in the simulation.
Design for Self-Organizing Agents
1. Defines interaction rules between agents.
Most self organizing artificial SO systems are comprised of multiple units or agents. In
many cases, rules are used to govern interactions between these agents. By designing and
implementing rules, a self-organizing system can be created. Examples of this include
self assembly and multi-agent robotics. Although self-assembly pertains to unintelligent
self organization it is still constrained by simple physical principles such as free surface
energetic stability and induced rules such as lock and key interface geometries. Like self
assembly, multi-agent robotic systems use rules to govern their behavior. For multi-agent
systems, the robots are controlled by a variety of algorithms which are inherently
comprised of logical instructions and rules which govern the agent’s behavior.
2. Defines interaction rules between agents and environment.
As stated in previous requirement, many artificial SO systems are designed with rule
based behaviors. With this in mind, the SO systems often operate on or react to their
environment. This type of behavior is inspired by the principle of stigmergy in social
insects, as shown Table 5.2. By employing this method of control, a collective
intelligence can be created to achieve adaptive behavior; thus expanding the robustness to
environmental stimuli and complexity of accomplishable tasks.
3. Defines functions/capabilities of each agent.
When designing the embodiment of a SO system, the functionality and capabilities of
each component must be clearly defined to accommodate the pre-defined rules set by the
control algorithms and complexity of interactions. An illustration of the importance of
defining capabilities for each agent is the positional error of the CONRO chain type
robot. The positional error adds up when bonding sequential modules or agents.
Knowledge of this inherent limitation is of supreme importance as it contributes
significantly to the overall accuracy of the robot.
4. Define the number of agents.
As stated by the previous requirement, the complexity of interactions is of supreme
importance when designing a SO system. This design of complexity in SO is itself a
balancing act whereby a final product is the result of a balance between complexity of
individual interactions and the number of agents.
5. Define the intended environment for system.
46 of 74
47 of 74
As in the design of any robust system, the intended environment must be considered to
create a generalized forecast of possible environmental conditions that might be
encountered to generate the functional and algorithmic constraints for a system. An
example of this is illustrated by the design of fixture assemblies. The designer knows the
realized product will be a fixture assembly of a manufacturing process; hence, many of
its rules and parameters are based upon the degree of robustness required.
6. Defines the decision structure (hierarchy vs. autonomous).
Since the design of SO systems involves distributed decision making amongst multiple
agents, the decision structure must be elaborated to aid in the specification of information
flow. Examples would be a completely flat structure in which individual agents make
their own decisions or a more hierarchical structure in which specialized agents delegate
tasks. This structure must be accounted for to explore all possible design combinations
for the system.
7. Defines how information will be transmitted and distributed within the self-organized
system.
As mentioned in the previous requirement, a separate information flow must be specified
to account for possible information bottle necks that could occur within the system. This
specification reveals system vulnerabilities and limitations as SO systems are highly
dependent upon information exchange.
8. Supports various system architectures.
In this context, architecture refers to the variety of possible embodiments, decision
structures, and information flow that can result from the implementation of autonomously
self-organizing systems. In simple terms, architecture can be viewed in terms of the
number of agents and the complexity of their interaction. The most complex architecture
is a multi-agent system with complex interaction between agents. Systems with few
agents but complex interactions may be designed differently than system with very many
simple agents. Systems with few agents and no complex interactions may be effectively
designed using existing systematic design processes. These concepts are expanded from
Ulrich [8] in relation to self-organizing systems.
Design For X
1. Design is Effective for Complex System Design
The issue of complexity is central to self-organizing design. Gershenson 2006 defines
complex a system as consisting of multiple agents or multiple interactions so that the
global/macroscopic behavior is not obvious from the individual agents or interactions.
This is also a basic definition for self-organization/emergence. Any method for the design
of self-organizing systems must be specifically adapted to complex problems. This may
47 of 74
48 of 74
include recognizing that iteration is an important process tool, numerical simulations may
dominate analytical models, and design teams need to be multi-disciplinary.
2. Method is Based on Concurrent Engineering Concepts
Concurrent engineering is the foundation for most of the "Design for X" methods. It
utilizes parallel workflow within an integrated systematic process (ESA 2006). The
parallel workflow increases efficiency, particularly for a distributed design team.
Integration addresses the need to consider aspects such as manufacturing early in the
design process so that decisions are made based upon an integrated product model.
3. Method Enables Mass Customization
Self-organizing behavior is ideal for mass customized systems. Most self-organized
systems will adapt to external stimuli and produce different results as their environment
changes. If the self-organizing system is designed to respond to the end-user, mass
customization will occur on a user by user basis. The system may become reconfigurable
in that it can continuously self-organize in response to the user.
4. Method Supports Design for Manufacturing Throughout Process
Physically implementing a self-organizing system design is a challenge. Even when the
right mix of agent capabilities and behaviors can be verified with simulation,
fundamental technology barriers may exist for the real system. Stimergy is used by many
natural self-organizing systems to regulate agent behavior. Stimergy can be used in
artificial self-organizing system as well. However, it is limited by technology and the
system environment. If the self-organizing behavior requires features which cannot be
produced, the design will fail. Self-organizing systems present many of the same
challenges to manufacturing as MEMS – they are often small, complex, and require a
multi-disciplinary approach to manufacturing.
5. Method is Compatible with Multi-disciplinary Teams
Concurrent engineering, complex system design, and design for manufacturing imply the
need for multi-disciplinary teams.
6. End of Product Life-Cycle is Addressed
For complex systems such as self-organizing systems, it may unclear when the system
has reached the end of its lifecycle. Reconfiguration may extend the lifetime of selforganizing systems. The designer has the responsibility for assisting the user in
understanding the system life cycle. These systems may include self-destruction, selfrecycling, or self-deactivation behavior. End of life conditions could be due to damage,
lack of power/energy, or even planned obsolescence. The designer has the capability to
design these behaviors into the system.
48 of 74
49 of 74
7. Emerging Technologies are Identified and Utilized
Self-organizing system design must be strategic. Self-organization will challenge current
design and manufacturing practices. Many of the barriers to implementing efficient selforganizing systems are due to the lack of technology. Since self-organizing design is
multi-disciplinary, it will be able to utilize a diverse range of technologies and
innovations. The design process for self-organizing systems must be able to predict,
identify, and integrate these technologies. The strategic design concepts identified by
Seepersad et al 2002 provide a general example for product design.
8. Products Must be Safe
Pahl and Beitz identify safety as one of the three rules of embodiment design. Selforganizing systems are emergent and global/macroscopic behavior is not always
predictable. A system which has been designed must meet certain functional
requirements, but complex systems may not be fully understood, even at the end of the
process. This uncertainty elevates the need for a thorough consideration of the safety of
the resulting system. Significant risk may be present for users of the system. The design
process must ensure that safety has been considered at all stages of the process,
particularly for systems which interact with people.
Task Clarification
1. Requirements list includes customer requirements
To ensure the value and usefulness of the SOS, the design team must verify the market
segment and identify the fundamental needs of the market. The variations in user needs
must be understood as well as the needs of stakeholders such as partners and regulators.
Customer requirements determine whether robustness or whether accuracy and precision
of macroscopic/global behavior are weighted more heavily.
2. Define metrics for evaluating macroscopic/global behavior
Macroscopic behavior of a SOS consists of macroscopic properties which have to be
maintained. An example of a macroscopic property in natural SOS is the shape of a
pheromone path in an ant trail. A macroscopic property may be influenced by multiple
quantified macroscopic variables. An example of a macroscopic variable in natural SOS
is the concentration of pheromones. [1]
3. Define metrics for evaluating microscopic/local behavior
Similarly to the case of macroscopic behavior, microscopic behavior of a SOS consists of
microscopic properties and microscopic variables which may be used as performance
indicators during development. An example of microscopic variable in natural SOS is the
strength of a pheromone. [1] Metrics for microscopic behavior are defined early on in the
development process and are crucial during development. However metrics for
49 of 74
50 of 74
macroscopic behavior of the SOS determine whether the customer requirements are
satisfied in the end.
4. Define robustness targets (how robust?)
As stated earlier, customer requirements determine the level of robustness needed in the
SOS. Designers exercise control over robustness by imposing tight or loose macroscopic
and microscopic metrics constraining the system. Robustness of the SOS must be
balanced with control over macroscopic behavior of the SOS, since the two are
effectively inversely proportional.
5. Define robustness metrics (evaluation criteria)
Robustness metrics quantify the degree to which the system continues to function in the
face of disturbances. Robustness is a function of the complexity of the interaction rules
and the complexity of the agents. While robustness allows the system to withstand
changes without losing its function or purpose, it comes at the cost of control over
macroscopic behavior.
6. Define accuracy and precision of each requirement
Since SO systems behave non-deterministically, the exact evolution as well as final
values for requirements may not be predictable. A requirement of the SOS may be
defined as a range for a quantified macroscopic or microscopic variable. To ensure higher
accuracy and precision for the value of macroscopic or microscopic variables, additional
constraints must be imposed on the SOS which in turn reduces the robustness and multistability properties of the SOS.
7. System performance is verified prior to hardware implementation
Before physically implementing a SOS, the designers must be able to guarantee that the
desired macroscopic behavior has been met. This may be demonstrated with use of
computer simulations since it is generally accepted that it is impossible to model a
complex system formally and prove the macroscopic behavior analytically. One reason is
because you cannot model all possible behaviors of a system. [1] The simulated system is
observed at both global and local levels. Both global and local changes are made and the
relationship between global and local behaviors is analyzed. [3] In order for the abilities
of the system to reflect the present state of the art of engineering technology, simulations
must be designed to simulate physical real-world hardware as closely as possible,
including the effects of noise.
8. Value of self-organization is clear based on method
Self-organization is not a universal solution and the method must justify the use of selforganization for the application. The method will clearly identify what problems a SOS
will directly address. Use of the requirements list is one way to indicate exactly how a
50 of 74
51 of 74
SOS is the optical choice. The requirements list may indicate a need for decentralized
control due to a highly dynamic environment, need for easy redeployment between
different environments, self-X properties such as self-configuring or self-healing, and
robustness. [2]
9. Defines the macroscopic/global system function
As mentioned above, customer requirements determine whether robustness or whether
accuracy and precision of macroscopic/global behavior are weighted more heavily.
Identifying the overall function of the SOS helps determine the balance between these
two properties. Thus, customer requirements determine the macroscopic system function
early on in the process.
Reconfiguration
1. Support reconfigurable system design
The ability to reconfigure is a likely customer requirement for a given SOS under
development. A SOS transitions between a finite number of unique stages or
configurations, each of which contains unique cues or signals. A reconfigurable SOS is
flexible in the sense that agents can reconfigure into any one of the unique
configurations. Such SOS exhibit cyclical behavior, as repeated patterns are observed in
the behavior of agents. Lattice robots containing cube like modules are examples of
reconfigurable SOS. These lattice robots reconfigure themselves into any shape based
upon the number of modules.
2. Support reconfigurable function structures
There is a correspondence between the function structure of the SOS and its current
configuration. The system is aware of its configuration and given a function, can
reconfigure to attain that function. Thus the function structure is dynamically adaptable.
3. Reconfiguration does not lead to unexpected system behavior; resulting in failure
Any SOS, whether reconfigurable or non-reconfigurable, is liable to make mistakes in an
unpredictable environment. Any attempt to build a "perfect" system is futile since it is not
possible to predict all possible future interactions with its environment. Any
reconfigurable SOS must be designed to contain a proper amount of robustness along
with the ability to learn from its mistakes. [4]
6.2 Critical Evaluation
Following the development of the SOSDM requirements list, critical evaluation is
necessary to ensure that specific core requirements have been identified. A requirements
list is comprised of demands and wishes, with core requirements being deemed as
51 of 74
52 of 74
demands and loftier requirements as wishes. In the following, we discuss examples that
employ the most critical demands from our requirements list which are not inherent in
P&B. These examples include CONRO, a reconfigurable intelligent system, and the
formation of 3D meso structures, a static self assembly process.
6.2.1 Example 1: CONRO
“The most advanced chain robots at present are Yim’s PolyBots and the CONRO
robots built by Wei-Min Shen and Peter Will of the University of Southern
California in Los Angeles.” (Mackenzie 2003)
As stated above, CONRO is a chain type robot created by Wei-Min Shen and Peter Will
at the University of Southern California. A chain robot is usually comprised of identical
modules which attach in sequence or branch off to form bifurcations. This type of
structure lends itself to a biologically inspired means of locomotion analogous to a snake
or centipede. The robot can also attach end to end and form a wheel. (Mackenzie 2003)
This type of reconfiguration is promoted by the docking capability of the collective
modules. Each module has two hinge points, an infrared communication system, and a
physical latch to attach to neighbors. This morphology gives CONRO an interesting
ability as stated below.
“CONRO has an especially spectacular ability to adapt on the fly…If you break a
snake robot, apart, it will start crawling as two snakes. Stick a snake’s tail in its
mouth, and it will figure out what happened and roll like a tank tread. Finally, if
you attach snakes to the sides of a snake, they will realize that they are now legs
and change gait accordingly.” (Mackenzie 2003)
This type of functionality encourages more practical applications such as crawling,
rolling, or climbing. Although functional, CONRO is not completely autonomous as
stated by the following quote.
“So far, no modular robot has stepped, rolled or slithered out of the laboratory to
prove its mettle in the real world.” (Mackenzie 2003)
Since the robot is not entirely autonomous, it cannot determine when it is advantageous
to reconfigure. Despite its inability to reconfigure, the robot has encouraged significant
research in autonomous robotic systems and multi agent systems, leading to a demand for
a systematic design method in the field of self organizing man-made systems. Hence,
requirements for the design of SOS are the starting point towards the realization of a
systematic design method.
CONRO in the Context of our Requirements List:
•
Define accuracy and precision of each requirement
52 of 74
53 of 74
A critical requirement of CONRO is the determination of its positional accuracy. Since it
is a chain robot, its error builds as the chain grows. An accurate approximation of this
error would be required to ensure that the system operates as expected. The designers
must determine if positional accuracy is a suitable global variable that can act as a useful
performance measure of the SOS. Next, the designers must determine how tightly or
loosely to constrain the values of positional accuracy during development of the SOS.
•
•
Defines interaction rules between agents
Defines functions/capabilities of each agent
Interaction rules are determined by the functional capabilities of each CONRO module.
Each module is capable of hinging at two points, communicating through infrared ports,
and tracking the actions of its neighbors. This limits each module to a specific set of
actions or rules which allow it to form a collective entity.
•
•
•
Defines the decision structure (hierarchy vs. autonomous)
Defines how information will be transmitted and distributed within the selforganized system
Support Reconfiguration
In self-organizing multi-agent robotics, the decision structure of the system must be
evaluated to determine the robustness of the information infrastructure. For CONRO, the
decision structure is completely decentralized as each module only accounts for its
neighbor. Designers determine what information is transmitted between modules, how it
is transmitted and how this information is used by the receiving module. The existing
decision structure in CONRO was likely created to allow reconfiguration and reduce
processing power.
6.2.2 Example 2: Self-Assembly of Electrical Components
This research was performed by William King at the Georgia Institute of Technology.
The self assembly of 3D geometries was employed to create small electrical assemblies.
These systems differ from self-organizing multi-agent robotic systems in the sense that
the agents are mindless or unintelligent.
In this self assembly project, electrical components were encapsulated in a molded
polymer substance. This polymer was molded into identical geometries. Interface
surfaces were coated with a hydrophobic low temperature solder alloy to encourage the
bonding of the geometries within an aqueous solution. This solution was necessary to
encourage the bonding of the hydrophobic surfaces. The solution was then heated to
bond the alloy surfaces. After the structure was bonded, the polymer case structures were
exposed to a chemical to dissolve the case material and leave a formed set of electrical
components. Initial structures proved successful as demonstrated by the illumination of a
LED.
53 of 74
54 of 74
Using this method, there are several design considerations that must be taken into
account, three of which are outlined by the authors below
“An important element of design in these systems was the shape of the alloycoated surfaces of the mesoscopic objects (Fig. 2). Minimization of the area of
the interface between the alloy and the aqueous KBr solution requires that the
shapes of opposed faces between two objects match.” (Breen 1999)
From this, the shape of the alloy surface is critical to the formation of structures. This
can be likened to the positional accuracy and docking mechanisms of multi-agent robot
systems. Related to the shape of the alloy surface is the overall shape of the component
piece. The following quote from Breen articulates this idea.
“Design of component pieces that self-assemble into open arrays of specified
design requires two structural features to be correctly chosen: (i) the 3D shapes
of the pieces, and (ii) the positions and shapes of the alloy-coated faces on the
surfaces of the objects.” (Breen 1999)
The shape of the component must allow the interface surfaces to be “available” for
bonding. Also geometries can be used as secondary bonding mechanisms which guide the
interactions between components. The shape of the geometry, as stated above, is a key
design consideration. Along with this, the overall control of the shape, placement of the
interface surfaces, and shape of the interfaces must be collectively considered as
articulated below.
“Successful design requires control of the shape of the objects, the placement of
the surfaces supporting liquid alloy, and the shape of these surfaces.”
(Breen 1999)
Based on this, it can be inferred that the interaction between components is strongly
related to the physical characteristics of the components.
Self Assembly in the Context of our Requirements List:
•
Define metrics for evaluating macroscopic/global behavior.
In the formation of 3D mesostructures, it is typically easy to identify defects in the
structure due to the system’s lattice. The ‘number of defects’ in the structure may be one
macroscopic variable defining the overall macroscopic behavior of the system. As stated
by the authors, defects are currently accounted for during the evaluation of a structure’s
accuracy.
“We have observed reproducible formation of defect-free lattices of at least 100
pieces.” (Breen 1999)
54 of 74
55 of 74
While the authors do not elaborate on what defines a defect, there are obvious
characteristic features of a defect that can be quantified. Possibilities of these metrics
include the number of defects, the average size of defects, distribution of defects, etc.
•
Defines interaction rules between agents.
The interaction rules are quite different for self assembly than self-organization of multiagent robotic systems. Interaction rules for self assembling systems are dominated by
physical principles such as the minimization of area between the solution and interface,
shear forces, and geometric relationships. Thus, these systems are much simpler but still
require a pre-determined set of interactions to develop a global product. Designers must
configure the SOS such that the elements, whether mindless or intelligent, behave in an
expected manner.
•
•
Defines interaction rules between agents and environment.
Defines intended environment for system.
Once again, the interaction rules between the agents and environment are different for
self assembly rather than self-organization of multi-agent robotic systems. This
difference arises from the role of the environment. In multi-agent robotics, the
environment is a stimuli to induce a reaction; whereas, self assembly uses the
environment as a means of bonding and aggregation. Despite the difference, the
environmental and agent interaction must be defined and accounted for during the design
process.
•
Defines the number of agents.
In the design of self assembling systems, the number of agents is critical to determine the
size and type of structure that can be created. For 3D mesoscale structures, the size of the
structure was limited by the number of agents. The complexity of the system can also be
determined by the number of heterogeneous elements in the system.
•
Supports various system architectures.
Since self assembling systems are dependent upon the hydrophobicity of their interfaces,
the architecture of the SOS can be manipulated by the selective activation of geometry
interfaces. Relative to the existing architecture, the number of agents and the complexity
of interactions supported may be different in the resulting architecture. Various structure
formations across a range of complexity must be enabled by the design process.
Design Method Structure:
In addition to the requirements illustrated by the examples above, the following set of
requirements, first introduced and described in section 6.1, is also a high priority. Clearly,
this set represents some of the core principles of P&B. Since P&B is the foundation of
our requirements list, the salient features of P&B will be present in a SOSDM.
55 of 74
•
•
•
•
56 of 74
Support iterative development
Process will be systematic
Process will be defined by a series of phases
Design is based on a requirements list
56 of 74
57 of 74
7 Critical Review of Project Conclusions
As with any design method, it is necessary to justify both the internal consistency and
external utility of a design method. In this context, we have employed the validation
square to systematically allocate internal consistency and utility. To extend beyond the
scope of this report, we identify overall utility and future research questions to identify
the current, past, and possible future progression of this project.
7.1 Verification and Validation
Within this project report, we have proposed an augmented and personalized design
method based on the Pahl and Beitz systematic design method in response to the Q4S.
We have used our proposed method as the process for completing our semester project.
At this point, we will validate this method using the validation square (Pedersen 2000)
shown in Figure 7.1 below.
1
4
2
3
Figure 7.1: The validation square.
The validation square is a systematic method for justifying the utility of a proposed
design method. Following the conventions of the validation square, verification is
concerned with the internal consistency of a method. Validation is more comprehensive
and addresses the overall suitability and utility of a method. Validation of design methods
have been limited by the reality that design methods are not based on fundamental
physical principles and therefore cannot be validated using the traditional "logical
empiricist" methods. Instead, the validation square seeks to build confidence in the
proposed method with respect to a stated purpose. Utility is the focus, not an absolute
judgment of truth or falsehood.
The process is described in detail by the information flow diagram in Figure 7.2 below.
Square 1 primarily addresses the internal consistency of a method. This is established
through literature references, information flow charts, logical arguments, and
comparisons to existing methods. In Square 2, examples problems are proposed which
focus on characteristics of the proposed method and generating data to support validity
claims. In Square 3, the result of the examples problems are evaluated in terms of
57 of 74
58 of 74
requirements generated at the beginning of the process. The focus is on using reliable and
unambiguous data to demonstrate that the method contributed to the success of the
example problem. In Square 4, all of the previous conclusions from Squares 1-3 are used
to generalize the utility of the method beyond the example problems. The success of the
example problems and the internal consistency of the method provide the foundation for
the "leap of faith" required for potential user to accept the validity of the new method.
Figure 7.2: Information flow through the validation square.
7.1.1 Theoretical Structural Validation (Square 1)
Since we have not proposed a new method but have chosen the Pahl and Beitz method as
a base for augmentation and personalization, building confidence in the internal
consistency of our proposed method is simplified versus a new method. By retaining the
core transforms of Pahl and Beitz, we maintain internal consistency. As shown in greater
detail in Section 3, the process includes the four phases and the individual core
58 of 74
59 of 74
transforms within those phases such as task clarification, a requirements list, creation of
function structures, preliminary layout, definitive layout, and a detailed documentation
phase. In addition, requirements for the proposed method were generated as a preliminary
step to proposing the augmentation and personalizations. These requirements are shown
in Table 2.2. Finally, we have discussed an additional method from Ullman which
confirms that have considered the basic principles and characteristics of a systematic
design process.
7.1.2 Empirical Structural Validation (Square 2)
We proposed this semester project of comparing systematic design to design for selforganization as an example to demonstrate the validity of our method. The project began
with an ill-posed, open-ended question. The project required teamwork and time was an
important constraint. Since no generally accepted design method exists for selforganizing systems, the project required a process suitable for original design.
In terms of evaluation, the project was expected to provide appropriate feedback to
determine if the process was suitable for solving this particular problem. The report and
project will be evaluated at the end of the semester for completeness and quality.
Shortcomings in either characteristic could indicate a deficiency in the method.
7.1.3 Empirical Performance Validation (Square 3)
As defined in our Network Activity Diagram (Figure 3.1), we used our proposed method
for completing our project. This method was essential to meeting our targets for quality,
timing, and content. By defining our requirements first, we were able to remain on task
and ensure that our deliverables were contributing the overall success of the project. By
developing an outline as a working structure, we were able to focus our embodiment
efforts in the correct areas and reduce iteration (i.e., rework). The parallel workflow
within the embodiment phase reduced our development time and allowed us to add more
value to the content of the paper. The final phase has allowed us to review the paper and
check for errors. We are expecting our post-realization activities to add value to our
learning experience from ME6101 even after the semester is officially over.
7.1.4 Theoretical Performance Validation (Square 4)
Based on the internal consistency (Square 1), characteristics of the example problem
(Square 2), and performance of the method with respect to the example problem (Square
3), we propose that our method is generally useful for engineering design problems.
Based on our example problems, it is particularly suitable for technical research papers.
The Network Activity Diagram represents a highly personalized version of our method
specifically adapted for developing scientific publications.
For more general applicability, more example problems are needed to confirm the
performance of the process. These problems should have the same general characteristics
of an open problem statement, time constraint, the necessity for teamwork, and requiring
original design. One area that needs validation is solving a more complex problem. The
59 of 74
60 of 74
difference in complexity between composing a publication and designing a multifunctional system such as a vehicle or inspection scanner is obvious. In addition, these
types of problems have more definite, qualitative performance criteria that can be used in
the Empirical Performance Validation. The performance of this paper will be judged
primarily by the opinion of the course instructors.
7.2 Utility
Complex and dynamic systems require a self-organizing emergent solution. Effort to date
towards the engineering of SOS has been largely reliant on an ad-hoc approach to design.
Gershenson, De Wolf, and others have called for the need of systematic design as an
approach to guarantee the global behavior of a SOS. These authors have suggested the
possible structure of a systematic design method specifically for the design of SOS. Work
reviewed by our project team does not describe full-fledged complete methodologies but
instead has served as a starting point.
Our efforts have contributed to research in the area of design of SOS by supporting and
expanding on previous work and detailing the requirements of a design method tailored
to the design of SOS. We believe our effort has integrated the work of Gershenson, De
Wolf, and Fromm and brought some concreteness to previous work. In the process, our
effort reinforced the need for systematic design of SOS by reviewing characteristics of
systematic design and emphasizing the benefits of systematic design.
The requirements list for the design of SOS developed in this report leads naturally to a
full life-cycle design methodology to guide designers of SOS. Our requirements list for
the design of SOS may be used to augment an adaptable design methodology such as
P&B in the future. Augmentations to the information flow and core transforms of such a
method are more readily achievable with use of our requirements list. Echoing the words
of others before us, we emphasize that there is a lot of future work needed to achieve a
usable methodology.
Another notable contribution has been the demonstration of the use of P&B to structure
the report writing process. Our project shows how a requirements list developed early on
in the writing process serves as an effective tool during the actual writing process. We
found the requirements list helped us develop our report outline and helped ensure the
completeness of our report. Our project shows how an activity network diagram may be
used to break down the task into phases and plan the entire process from research to
writing. The approach to report writing demonstrated in this project can be used as a
model for large reports including an Master’s thesis or Ph.D. dissertation. Finally, our
contribution includes the identification of future research in the design of SOS which is
discussed in Section 7.3.
7.3 Critical Evaluation
Gap Analysis:
60 of 74
61 of 74
What are the similarities between P&B and a SOS design method?
1. Both methods are systematic. Each consists of a series of phases and a specific
order and flow of information. Design of SOS proceeds in a methodological
manner: planning and task clarification, design, implementation, analysis,
iteration.
2. Planning and task clarification is necessary upfront for both methods. For
example, design of SOS requires the identification of an unmet design need and
generation of constraints upfront.
3. Design is based on a requirements list for both methods. Constraints on the SOS
and customer expectations are among the requirements identified early on during
design.
4. Both methods require a detail design phase with similar tasks. Detail design in the
design method for SOS may be focused on finalizing the details of the design
omitted from the computer simulations. The phase may also focus on creating
documentation used for manufacturing. At the end of the detail design phase, all
of the details of the design will be explicitly specified, including dimensions,
materials, production processes, and costs.
5. Both methods support development of prototype before physical implementation.
Global and local behavior of a SOS system is simulated and analyzed using
computer simulations.
6. Both methods integrate manufacturing information early in the process.
Considering manufacturing during design and analysis of SOS secures the real
world feasibility and improves quality of the system.
7. Information flow in both methods moves from abstract to concrete. During design
of SOS, early decisions tend to more qualitative and focused on global behavior
while later decisions tend to be more quantitative and focused on local behavior
of the SOS.
8. Both methods utilize the human machine cyborg. Computers are required due to
the computationally heavy nature of the design of SOS. Computation is used for
narrowing choices but in the end humans make strategic decisions based on
results of computation. ‘Soft’ decisions based on qualitative or incomplete
information are required during design of SOS. Knowledge and experience of
designers plays a significant role in both methods.
9. Both methods utilize parallel workflow through a combination of top-design
design and concurrent engineering. Design of SOS may include design of
interaction rules, mode of communication, environment and agents which
proceeds concurrently.
61 of 74
62 of 74
10. Both methods utilize multi-disciplinary teams. Design of SOS requires
collaboration between designers from different disciplines including computer
science, artificial intelligence, electrical engineering, computer engineering, and
mechanical engineering.
What are the differences between P&B and a design method for SOS?
1. Iterations are planned for design of SOS. A constant feedback loop between
design and analysis is used to converge to the optimum design. Each iteration of
the method may consist of design, implementation and analysis.
2. Design method for SOS accommodates emergent behavior on the global level of
the SOS. Due to the high amount of interaction between agents, the correlations
between parameters tuned on the local level of the SOS and the global behavior of
the SOS are not always clear. In this way, the designer has indirect control over
global behavior of the SOS. The designer cannot predict exact evolution of global
variables over time but can predict trends.
3. Design method for SOS doesn’t require the generation of multiple solutions in
earlier phase which are to be reduced to an optimum solution. Instead the designer
develops a single preliminary system which then evolves through iteration.
4. Design method for SOS does not contain distinct conceptual design and
embodiment design phases. The first iteration of the design phase may be seen as
conceptual design and future iterations seen as embodiment design.
5. While the highly adaptable P&B may be used for a multitude of systems, the
design method for SOS is more rigid. The design method for SOS is targeted to
dynamic multi-agent systems only.
6. Design method of SOS utilizes a reconfigurable function structure. As SOS
reconfigures, the function structure changes.
Future Research Questions:
In the following list, we have included numerous questions as an invitation to think with
us about the future of SO systems and how they can be fully realized. While some
authors have proposed self-organizing systems design method, no consensus exists on
how to design these systems. Before a comprehensive method can be proposed, several
questions must be answered:
•
What are the core information transforms of a self organizing systems design
method?
•
What are the guidelines for selecting suitable macroscopic variables?
62 of 74
63 of 74
•
What technologies are currently available to develop these types of systems?
•
What is the best way to achieve decentralized autonomous decisions?
•
What are the prospects for hybrid systems which retain limited aspects of self
organization or use self organization on selected subsystem levels and not system
wide?
•
Can the system function structure be dynamically reconfigured? Can this occur
autonomously?
In self-organizing systems, the emergent behavior is governed by the local interactions.
Understanding the rules which govern these interactions is critical to designing selforganizing systems. The following questions focus on these interaction rules:
•
Is there a way to concurrently design the algorithm and agents for a system? In
essence, is the algorithm somewhat generic to SO systems?
•
How do few complex interactions compare to many simple interactions in terms of
a global product?
•
How are interaction rules best determined? Top Down or Bottom Up?
•
Is there a set of interaction rules that can both govern autonomous formation and
reconfiguration?
Self-organizing system design will present new challenges for a systematic design
process. It will raise these questions with respect to the details of the embodiment and
detail design phases:
•
What tasks must occur between manufacturing of the SOS and release to customer
to verify system performance?
•
Is there a best geometry for agents?
7.4 Lessons Learned
After presenting a comparison between Paul & Beitz and SOSDM, we have gained
insight into the necessity and utility of systematic design and SOS design. In the
following text, we have summarized both our collective and individual goals for our
insights into this project. With respect to each goal, we analyze the value gained by
completing the project.
63 of 74
64 of 74
Collective goals
1. Internalize the P&B method and learn how to apply it to a specific design.
2. Learn how to adapt existing design processes to solve novel problems.
3. Internalize the project planning and management tools to learn how to
efficiently manage the design process.
Group Lessons beyond goals
Jordan Hall Value with respect to A0 Goals
1. Learn tools for effective management of the design process. This project was a
good test of our project management skills. Through working in a team, I have a
better understanding of the practical issues in design process management. We
learned how to effectively communicate even when one of us was out of town and
to use the technology we had such as laptop computers, email, and cell phones to
stay on task on when we weren't in group meetings. I also have a clearer
understanding for the need for better software for collaboration and file sharing.
For example, it has been a challenge merging and formatting our separate report
sections. This process could be improved and made more user friendly. Finally, I
was skeptical about the 7MP before the project began. However, the network
activity diagram, affinity diagram, and PEI diagram worked very effectively for
us. I plan on integrating them into my design toolbox.
1. Learn the core concepts of the Paul & Beitz systematic design method. This
project had great value for me personally because it reinforced and improved my
understanding of the Pahl and Beitz method. Using the method to structure our
report taught me about the overall structure of the method and the core
transforms. Comparing P&B to self-organizing systems design forced me to
critically evaluate P&B. This second level of study has forced me to think more
deeply and go beyond the overview type of analysis that was required in A1.
2. Learn how to adapt an existing design process to solve novel design problems.
Looking at self-organizing systems design was interesting to me because it is a
novel design problem that can be solved by adapting existing methods. Through
my critical evaluation of Pahl and Beitz and comparison with the Ullman process,
I have begun to appreciate how adaptable P&B is. As stated in the report, I
believe this is because P&B have defined their process in a more abstract,
systems-based terminology. I have begun to learn how to adapt a process like
P&B to fit specific problems that I may encounter. It is a refreshing change from
undergraduate design classes where we were forced to use a design method as
given instead of critically evaluating it first and then modifying the method based
on our analysis.
64 of 74
65 of 74
3. Learn how to better integrate my engineering science skills with a systematic
design process such as Paul & Beitz. While this class has focused more on the
design process than the engineering science such as analysis or simulation skills, I
have learned where to apply these skills within the process. In the context of selforganizing systems design, it is clear from the background research that
simulation is critical to verifying the design of a self-organizing system. These
simulations will be inherently multi-physics and require a global understanding of
system behavior.
4. Learn the current and future challenges in engineering design to be ready to lead
design teams in a rapidly changing work environment. Through looking at the
world of 2020, I was forced to think about the future of engineering design. In
looking at the requirements for self-organizing systems design, it is clear that
there will be many challenges in the future. Self-Organizing systems design is just
one aspect of engineering in the world of 2020. By beginning my graduate studies
with a focus on the future, I better direct my learning based on the future I am
anticipating. It is clear to me that design will be primarily a team activity in 2020.
Concurrent engineering implies more than one person – parallel workflow
requires multiple people. Even where single designers may own a small design
firm, they will be collaborating within a network of application specialists. Once
again, working within a team on this project has help all of us to appreciate the
challenges of leading a team through a complex design task.
Mohsin Waqar Value with respect to A0 Goals
1. Learn how to tackle the design of a complex system. With the completion of this
project, I realize the design of complex systems requires the design to evolve. I
have learned complex system design benefits from top-down design and iteration.
I realize design of complex systems benefits from a top-down engineering
approach in which ‘big picture’ requirements for the system are declared first.
The design of complex systems also benefits from a feedback loop between
analysis and design. This highly iterative nature of the design method facilitates
evolution of the design.
2. Learn how to design products or processes that succeed in a global marketplace.
To succeed in a global marketplace, products must respond to customer
requirements and changes in the marketplace. From this project, I have realized
the same can be applied to self-organizing systems. For such systems to be useful
and succeed in the global marketplace, designers must properly define the role of
the system and the customer requirements. Strategic design, design for quality and
design for manufacturing are all approaches that can be extended to design of
self-organizing system to secure success in a global marketplace.
3. Learn techniques for nurturing creativity in both local and distributed design
environments. Creativity is the ability to generate new ides and concepts that are
useful. There is no secret formula to increase individual and team creativity.
However I have identified some general pointers from ME6101. A designer must
65 of 74
66 of 74
abstract to reach the crux of the task, understand the problem solving process, be
knowledgeable, be an active learner, be resourceful, practice time management
and apply the methods recommended for triggering intuitive thinking. This
project provided me with an opportunity to practice abstraction during project
planning and conceptual design and to practice time management from beginning
‘till end. I feel this project has helped me further develop and enhance my
creativity.
4. Learn techniques for increasing productivity of local and distributed design
teams. Early on in the project planning phase, I read about Peter Senge and the
idea of a Learning Organization. I was able to identify the individual’s
responsibility in a Learning Organization and how a team can create an
atmosphere which encourages learning. For example, I learned a collective vision
and ‘learningful’ conversations are crucial for creating an environment within a
group where learning and personal growth are encouraged. Our project team
formed a collective vision early on during the planning phase and dedicated our
meetings during conceptual design to ‘learningful’ conversations. One lesson I am
carrying away from this experience is the realization that I need to continue
practicing “learningful” conversations. Being a reflective learner, it is more
natural for me to solve problems in isolation and then offer my solutions to the
group. As I balance my learning style during graduate study and become more of
an active learner, I will rely less on this less efficient approach.
5. Learn the requirements for the world of 2020. My experience in this project was
an integral part of shaping my world of 2020. My world of 2020 is an integration
of knowledge from undergraduate study, the workplace, ME6101 lectures, best
practices from previous ME6101 students, and from my teammates in this project.
Nathan Young Value with respect to A0 Goals
1. To learn the fundamental principles of self-organizing systems. Once I have
sufficiently internalized these concepts, I will continue to build upon the knowledge of
my predecessors. Ultimately, I will apply this new knowledge to my research into the
computational synthesis of adaptive systems. By participating in this project, I have
discovered many of the fundamental principles of self-organizing systems. In doing
this, I have developed a foundation to launch my research to the next level, adaptive
mechanical systems. I will further develop this foundation in my response to the
Q4S. Through this, I will educate myself in the concepts of complexity and
adaptivity as they pertain to self-organization and global emergent behavior.
2. To learn how to analyze a pre-existing engineering system. By completing this, I
will acquire sufficient knowledge to understand a systematic way to “reverse
engineer” a product. This will give a deeper insight into the nature of adaptive
design. During the research I performed for this project, I have learned how to
analyze ideas and reverse engineer the function structures of the ideas to obtain a
thought process. By reverse engineering the ideas of others, I have realized ways in
66 of 74
67 of 74
which I can conduct my own research to contribute to the scientific community.
Some of these ways include intense literature searches, attending seminars, archiving
and transmitting my knowledge, and instilling my passion for learning in others to
develop a critical thinking network.
3. To learn critical thinking skills pertaining to the development of new knowledge. I
will use these skills to critically evaluate my work and the work of others to perform
gap analyses. As mentioned above, I am interested in creating a critical thinking
network. During this project, I have begun this process through developing a stronger
relationship with my group members and advisor. By building this network, I have
formed a core group of individuals that I can rely on to contribute to support me in
innovative thought. Through these individuals, I have already learned valuable
lessons with respect to the critical evaluation of my own work. These lessons include
the necessity to effectively articulate ideas for building context, questioning
everything, and progressively searching for new avenues of evaluating my own ideas.
4. To learn the requirements of the future. I will use this knowledge to realize the
ways in which I will have to continuously adapt myself to be proficient throughout my
professional career. In developing the world of 2020, I have thought about the future
in the context of engineering design. Since I am focusing my graduate studies in
engineering design, I am investing in my own future. This investment arises in my
knowledge of what the future will be like particularly in academia. I have discovered
the future will require even more interdisciplinary collaboration, concurrency in
design, and a clever combination of generalists and specialists. With respect to these
requirements, I find that the increasing complexity of systems will force design teams
to integrate many engineering disciplines together. For instance, mechanical,
electrical, chemical, and biomedical engineering are all integral in the advancement
of medical research. This example also applies to a combination of generalists and
specialists. Generalists will be very important to tie specialists together. Generalists
will likely be the thought leaders of the future due to the variety of knowledge that
will be required for complex systems. Finally, concurrency is a term that refers to
parallel completion of design tasks. I learned that this is integral to the reduction of
time to market.
5. To internalize the concepts of the P&B design process. With this knowledge, I will
be fully prepared to construct a new design method to fit my future needs. Since this
project required a comparison between P&B and SOS, I further internalized the
concepts of P&B and realized that it is extremely flexible. I discovered this
flexibility by applying it to report writing to produce our gap analysis of P&B and
SOS. After completing the report, I find that all products have fundamental
information transformations that link them together. This is evident by developing a
method to write a report with a mechanical design process. I will likely use this same
process to produce my thesis.
Through comparing P&B and SOS, I also realized that detail design is rooted in the
effective communication of ideas. Extreme care must be taken to ensure that a
67 of 74
68 of 74
document is formatted and written in such a way that it compliments the conveyance
of information.
7.5 Closure
As complexity of engineered systems continues to rise, designers are finding themselves
ill equipped to manage the complex chains of interaction involved in such systems.
Treating a complex system during design as a self-organizing system is a promising
approach that may bridge the gap between current design abilities and the realization of
complex systems. To construct such a bridge to get designers to where they eventually
want to be, a well thought-out approach to design of self-organizing systems is needed.
In this report, we have identified characteristics and principles of systematic design and
showed how it is an effective approach to the design of self-organizing systems. In this
report, we used current research in self-organizing systems and biological inspired design
to extract general characteristics and principles of self-organizing systems. Once we
understood the systems to be designed, we were able to pose a requirements list for
SOSDM, Self-Organizing Systems Design Methodology. This brings us to our
personalized Question for the Semester:
How should the Pahl & Beitz systematic design method be augmented and
personalized to support the concurrent realization of technical systems for a
global market place in a distributed environment based on self-organization
concepts?
Significant work remains before augmentations to the P&B method can be articulated
and, perhaps more importantly, formally reasoned. Due to time constraints, our project
team’s efforts have focused on the laying down a proper foundation for the eventual
realization of a design method for self-organizing systems. The requirements list for
SOSDM posed in this report serves as the proper foundation. We have taken several steps
towards answering the Question for the Semester, including understanding systematic
design and self-organizing systems and developing a requirements list. Our requirements
list for SOSDM will help construct the bridge for closing the gap between current design
abilities and the realization of complex systems.
68 of 74
69 of 74
Appendix A
PEI Diagram for Project Planning
69 of 74
70 of 74
Appendix B
Affinity Diagram for Project Report Requirements
70 of 74
71 of 74
Appendix C
ME6101
Engineering
Design
Requirements List
Self-Organization vs. Systematic Design
Problem Statement:
Deliver a comparison between
the Pahl & Beitz (P&B)
systematic design method and
a self-organizing design
method for autonomous
assembly of man-made
systems.
Page 1 of 2
(source: http://www.science.uva.nl/~venturol/ITS/ITS.html)
Revisions
D
W
10/21/06
10/21/06
10/21/06
10/21/06
10/26/06
10/26/06
10/21/06
D
D
D
W
D
W
D
1. Process Flow
Use augmented method from A3
Validate augmented method from A3
Use concurrent work flow
Provide platform for individual Q4S personalization
Helps achieve common A0 goals
Value is clear
Meets semester deadline
10/21/06
10/21/06
10/21/06
10/21/06
D
D
D
D
2. Content
Based on published research
Identify augmentations to P&B based on SO
Describe P&B in detail
Include principles of SO based on social insects
10/21/06
D
10/21/06
D
10/21/06
10/21/06
10/21/06
10/21/06
D
D
D
D
Requirements
3. Compare and Contrast
Perform gap analysis between characteristics of
P&B & a SO-based design method
Perform gap analysis between mechanisms of P&B
and a SO-based design method
Resp
JH, NY
and
MW for
all
4. Design for X
Report is easy to read
Continuity is present throughout report
References are properly cited
Target to visual learners (Farrokh & Jitesh)
(Continued on Next Page)
71 of 74
ME6101
Engineering
Design
72 of 74
Requirements List
Self-Organization vs. Systematic Design
10/21/06
10/21/06
D
W
D
D
Demonstrate abstraction and critical thinking
Viewed using Microsoft applications
10/21/06
10/21/06
W
W
5. Process Tools
Apply 7 MP’s
Apply DSP
D
W
6. Continuous Improvement
Identify questions for future research
Lead to conference paper
Revisions
10/21/06
10/21/06
Requirements
Page 2 of 2
Resp
JH, NY
and
MW for
all
72 of 74
73 of 74
References
Bonabeau, E., et al. Self-Organization in Social Insects. Tree. 12 (1997): 12-16.
Bonabeau, E., Guerin S., et al. Three-dimensional Architectures Grown by Simple
‘Stigmergic’ Agents. BioSystems. 56 (2000): 13-20.
Boomsma, J. J. and Franks, N. R. Social Insects: from selfish genes to self organization
and beyond. TRENDS in Ecology and Evolution. Vol. 21 (6): June 2006 (303-307).
Bowden, N., Terfort, A., Carbeck, J., Whitesides, G. (1997). Self Assembly of Mesoscale
Objects into Ordered Two-Dimensional Arrays. Science 276: 233-235.
Breen, T. L., Tien, J., Oliver, S., Hadzic, T., Whitesides, G. (1999). Design and Self
Assembly of Open, Regular 3D Mesostructures. Science 284(May 1999): 948-951.
Capera, D., M Gleizes, and P. Glize. Self-Organizing Agents for Mechanical Design.
AAMAS, 2003.
Cannon, A. H., Hua, Yueming, H., Henderson, C.L., King, W.P. (2005). Self-Assembly
for Three Dimesional Integration of Functional Electrical Components. Micromechanics
and Microengineering 15: 2172-2188.
Wolf, T., Holvoet, T., and Samaey, G. Engineering Self-Organizing Emergent Systems
with Simulation-based Scientific Analysis.
http://www.maia.ub.es/~maite/AEIpapers/2005esoa05proc.pdf
De Wolf, T., and T. Holvoet, Towards a Methodolgy for Engineering Self-Organising
Emergent Systems, In Self-Organization and Autonomic Informatics (I), Volume 135 of
Frontiers in Artificial Intelligence and Applications. H. Czap, R. Unland, C. Branki and
H. Tianfield (editors), pp 18 - 34. ISBN: 1-58603-577-0, IOS Press. Proceedings of the
International Conference on Self-Organization and Adaptation of Multi-agent and Grid
Systems (SOAS 2005), Glasgow, Scotland, UK
(ESA) European Space Agency. Concurrent Design Facility.
http://www.esa.int/SPECIALS/CDF/SEM1OF1P4HD_0.html. 2006.
Franks, N. and Deneubourg, J-L. Self-Organizing Nest Construction in Ants: Individual
Worker Behavior and the Nest’s Dynamics. Animal Behavior. 54 (1997): 779-796
Fromm, J. On Engineering and Emergence.
http://arxiv.org/ftp/nlin/papers/0601/0601002.pdf. Non-Linear Sciences: 2006.
73 of 74
74 of 74
Gershenson, C. A General Methodology for Designing Self-Organizing Systems.
http://uk.arxiv.org/abs/nlin.AO/0505009. Working paper, submitted to ECCO 2005,
revised February 2006.
Khoshnevis, B., Kovac, R. Shen, W, Will, P. (2001). Reconnectable Joints for SelfReconfigurable Robots. Intelligent Robots and Systems.
Mackenzie, D. (2003). "Shape Shifters Tread a Daunting Path Toward Reality." Science
301(8/8/2003).
Mamei, M., et al. “Case Studies for Self-Organization in Computer Science.” Journal of
Systems Architecture." 52 (2006): 443-460.
Pahl, G. and W. Beitz. Engineering Design: A Systematic Approach. 2nd Ed. Trans. K.
Wallace, et al. London: Springer-Verlag, 1996.
Pratt, S. C. “Decentralized Control of Drone Comb Construction in Honey Bee
Colonies.” Behavioral Ecology and Sociobiology. 42: 1998 (193-205).
Pedersen, K., J. Emblemsvåg, R. Bailey, J. K. Allen, F. Mistree. Validating Design
Methods and Research: The Validation Square. Proceedings of DTEC '00. 2000 ASME
Design Engineering Technical Conferences. September 10-14, 2000, Baltimore Maryland
Raghu, A. (2001). Designing the answer to the question for the semester. Development of
the Dynamic Systematic Design Methodology (DSDM). Atlanta,GA, Georgia Institute of
Technology: 1.
Seepersad, C. C., F. S. Cowan, M. K. Chamberlain, F. Mistree. Strategic Design:
Leveraging and Innovation for a Changing Marketplace. Atlanta, GA: Systems
Realization Laboratory (Georgia Institute of Technology): 2002.
Smith, P., and D. Reinertsen. Developing Products in Half the Time. ResearchTechnology Management, May-June 1992. http://www.newproductdynamics.com/RTM5-92/R-TM5-92.pdf.
Sulis, W. (1997). "Fundamental Concepts of Collective Intelligence." Nonlinear
Dynamics, Psychology, and Life Sciences 1(1).
Theraulaz, G. and E. Bonabeau. “Coordination in Distributed Building.” Science. 269 (4
August 1995): 686-688.
Torres, E. (2004). Collective Intelligence in Multi-Agent Robotics: Stigmergy, SelfOrganization, and Evolution.
Ullman, D. The Mechanical Design Process. 3rd Ed. New York: McGraw-Hill, 2003.
74 of 74

ME6101: Engineering Design - the Systems Realization Laboratory

Transcription

Similar documents

Research Seminar Jan Harmeson

Greater Kashmir Inner Pages

International SOS Offices worldwide

FIRPA Presentation

The Full Picture - Army Technology

View our current Newsletter

researchquestionsDelvaux

day/night emergency road flare