hall waqar young

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 Executive Summary 3 2 Project Context 4

2.1 Question for Semester (Q4S): 4 2.2 Group Learning Objectives 5 2.3 World of 2020 6 2.4 Requirements List for Augmented Method: 7 2.5 Proposed Method 11

3 Project Overview 13 3.1 Report Organization 13 3.2 Project Requirements Summary 13 3.3 Tasks 14

4 Systematic Design 17 4.1 Characteristics and Principles of General Systematic Design Processes 17

4.1.1 Principles of Systematic Design 17 4.1.2 Characteristics of Systematic Design 19

4.2 Information Flow in Systematic Design 20 4.2.1 Pahl & Beitz. Engineering Design: A Systematic Approach. 20 4.2.2 Ullman. The Mechanical Design Process. 23 4.2.3 Comparison Between Systematic Design Processes 25

4.3 Benefits of Systematic Design 27 4.4 Critical Evaluation of Systematic Design 27

5 Description of Self-Organization 29 5.1 Characteristics of SO: 29 5.2 Information Flow: 31 5.3 Decision Processes: 32 5.4 Principles of SO: 33 5.5 Examples of Natural SO Systems: 34 5.6 Examples of Artificial SO Systems: 35

6 Requirements List for SOSDM 42 6.1 Description of Individual Requirements 43 6.2 Critical Evaluation 51

6.2.1 Example 1: CONRO 52 6.2.2 Example 2: Self-Assembly of Electrical Components 53

7 Critical Review of Project Conclusions 57 7.1 Verification and Validation 57

7.1.1 Theoretical Structural Validation (Square 1) 58 7.1.2 Empirical Structural Validation (Square 2) 59 7.1.3 Empirical Performance Validation (Square 3) 59 7.1.4 Theoretical Performance Validation (Square 4) 59

7.2 Utility 60 7.3 Critical Evaluation 60 7.4 Lessons Learned 63 7.5 Closure 68



Appendix A 69 Appendix B 70 Appendix C 71 References 73 Table of Figures: Figure 2.1. Proposed Pahl and Beitz method for the world of 2020. 11 Figure 3.1: Activity Network Diagram for Plan of Action 14 Figure 4.1: Information flow diagram for the Pahl & Beitz process. 22 Figure 4.2: Information flow diagram for the Ullman design process. 25 Figure 4.3: Core transformation diagram for systematic design processes. 26 Figure 5.1: Characteristics of Self-organization. 29 Figure 5.2: Parallel information flow in self-organizing system. 31 Figure 5.3: Information flow bottleneck in centralized control. 32 Figure 5.4: Rules and their associations with states. 33 Figure 5.5: Self-organization in Social Insects. (clockwise from top left) Ant trail, bee dance, firefly synchronization, and termite nest. 34 Figure 5.6: Cross and hexagonal geometries for static self-assembly.(Bowden 1997) 36 Figure 5.7: Lock and key geometries for static self-assembly.(Bowden 1997) 36 Figure 5.8: Assembly process for 3D self assembly.(Breen 1999) 38 Figure 5.9: Encapsulation, Molding, and Finished Products. (Cannon 2005) 38 Figure 7.1: The validation square. 57 Figure 7.2: Information flow through the validation square. 58 List of Tables: Table 2-1: Drivers for our world of 2020. 6 Table 2-2: Requirements List for Pahl and Beitz in the World of 2020 8 Table 5-1: Examples of Self-Organization in Social Insects 34 Table 5-2: Affinity Diagram for Artificial Self-Organizing Systems 35 Table 6-1: Requirements List for SOSDM 42



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 self-organizing 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 self-organizing systems and how they can be fully realized.



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.



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



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 Driver MetricProcess Costs Profitability

Virtual Corporations Time to Market

Web Based Collaboration ConnectednessComputing Power Speed

Customer SatisfactionGlobalization:

Business:

Technology:

Global Consumers

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



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.



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 Requirements Resp

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

10/6/06 10/6/06

10/6/06 10/6/06 10/6/06

10/6/06

10/6/06

D D D D D

D W D D

D D

D W D

D

W

1. Process Steps Design method must be systematic Task clarification stage Abstract problem definition stage Concrete problem description stage Design finalization stage 2. Process Structure Support concurrent engineering practices Support mass customization Support global marketplace Integrate DfX tools (safety, quality, environment, manufacturability, cost, etc.) 3. Information Flow: Parallel information flow Information exchange must accommodate distributed enterprise 4. Information Content: Information must be cultural/language independent Information must be standardized Information must be readily available to distributed design team 5. Team Work Support a multidisciplinary and distributed design team Support reconfigurable enterprises (supply chaining, outsourcing, etc.)

JH, NY and

MW for all



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.



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.



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.



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



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.



• 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



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.



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.



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



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.



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



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 ill-formed problem to well documented solution which is ready for manufacture. Pahl &



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



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.



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 "divergent-convergent" 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.



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



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.



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.



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



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.



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). Self-organization 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.

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.

EFFICIENT

ROBUST

MULTI-STABLE

FLEXIBLE



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



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.

Figure 5.2: Parallel information flow in self-organizing system.

ENVIRONMENT

Agent

Information



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 well-defined sequence and many activities can be performed at the same time.

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

Centralized Leadership

Agents

Information Flow

Information Flow Bottleneck



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.

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.

State n Rule a Rule l Rule b Rule m Rule c Rule n

State n+1

State n+2



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 Ants

Nest Sorting Ants Cooperative Transport Ants Food Source Selection Ants, Bees

Thermoregulation Bees Nest Building Bees, Wasps, Hornets, Termites,

Synchronization Fireflies Feeding Aggregation Bark Beetles,

Web Construction Spiders

Figure 5.5: Self-organization in Social Insects. (clockwise from top left) Ant trail, bee dance, firefly

synchronization, and termite nest.



5.6 Examples of Artificial SO Systems:

Table 5-2: Affinity Diagram for Artificial Self-Organizing Systems

Static Self-Assembly Robotics

2D Arrays CONRO

3D Geometries Multiple Agents

Artificial Self-Organizing Systems

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 self-assembly. 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



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.



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.



Figure 5.8: Assembly process for 3D self assembly.(Breen 1999)

Figure 5.9: Encapsulation, Molding, and Finished Products. (Cannon 2005)



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.



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.



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.



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


11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006

D D D D W W W W W W W D W W D W W

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

SOS Architects



11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006 11/21/2006

W D D D D D D D D D W W W W W W W W W W

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



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



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



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.



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



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 self-organizing systems. The designer has the responsibility for assisting the user in understanding the system life cycle. These systems may include self-destruction, self-recycling, 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.



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 self-organizing 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. Self-organizing 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



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 multi-stability 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 self-organization 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



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



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



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 self-

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



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 alloy- coated 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)



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 multi-agent 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.



• Support iterative development • Process will be systematic • Process will be defined by a series of phases • Design is based on a requirements list



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.

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

1

2 3

4



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



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 self-organization 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 self-organizing 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



difference in complexity between composing a publication and designing a multi-functional 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:



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.



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?



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



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.



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 self-organizing 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



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



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



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.



Appendix A

PEI Diagram for Project Planning



Appendix B

Affinity Diagram for Project Report Requirements



Appendix C

ME6101 Engineering

Design

Requirements List

Self-Organization vs. Systematic Design Page 1 of 2

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.

(source: http://www.science.uva.nl/~venturol/ITS/ITS.html)


10/21/06 10/21/06 10/21/06 10/21/06 10/26/06 10/26/06 10/21/06

10/21/06 10/21/06 10/21/06 10/21/06

10/21/06

10/21/06

10/21/06 10/21/06 10/21/06 10/21/06

D D D W D W D

D D D D

D

D

D D D 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 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 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 4. Design for X Report is easy to read Continuity is present throughout report References are properly cited Target to visual learners (Farrokh & Jitesh)

JH, NY and

MW for all

(Continued on Next Page)



ME6101 Engineering

Design

Requirements List

Self-Organization vs. Systematic Design Page 2 of 2


10/21/06 10/21/06

10/21/06 10/21/06

10/21/06 10/21/06

D D

W W

D W

Demonstrate abstraction and critical thinking Viewed using Microsoft applications 5. Process Tools Apply 7 MP’s Apply DSP 6. Continuous Improvement Identify questions for future research Lead to conference paper

JH, NY and

MW for all



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.



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 Self-Reconfigurable 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. Research-Technology Management, May-June 1992. http://www.newproductdynamics.com/R-TM5-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, Self-Organization, and Evolution. Ullman, D. The Mechanical Design Process. 3rd Ed. New York: McGraw-Hill, 2003.

hall waqar young

Documents