Parametric Design Constraints Management Using the Design Structure Matrix: Creation of an Electronic Catalog for a Safety Belt System by Jerrold I. Lavine M.E., Mechanical Engineering Cornell University, 1993 B.S., Mechanical Engineering State University of New York at Binghamton, 1991

SUBMITTED TO THE SYSTEM DESIGN AND MANAGEMENT PROGRAM IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE IN ENGINEERING AND MANAGEMENT AT THE MASSACHUSETTS INSTITUTE OF TECHNOLOGY February 2000 @ Jerrold I. Lavine 1999. All rights reserved. The author hereby grants to MIT permission to reproduce and to distribute publicly paper and electronic copies of this thesis document in whole or in nart

Signature of Author Uystem Design and Management Program December 1, 1999

Certified by el E. Whitney Senior Research Scientist Center for Technology, Policy, and Industrial Development Thesis Supervisor

Certified by Ali A. Yassine Research Scientist Center for Technology, Policy, and Industrial Development Thesis Supervisor

Accepted by Thomas A. Kochan LFM/SDM Co-Director -Rrri M Rtinkirrnf=nnnr nf Management

Accepted by Paul A. Lagace L"..--LFM/SDM Co-Director Professor of Aeronautics & Astronautics and Engineering Systems MASSACHUSETTS I TITUTE OF TECHNOLOGY

JAN 2 01

LIBRARIF.R Parametric Design Constraints Management Using the Design Structure Matrix: Creation of an Electronic Catalog for a Safety Belt System

by

Jerrold I. Lavine

Submitted to the System Design and Management Program On December 1, 1999 in Partial Fulfillment of the Requirements for the Degree of Master of Science in Engineering and Management

ABSTRACT

A framework was developed for a comprehensive evaluation of a product development process that encompasses the physical system and system level requirements to assure their coordination for efficiency and optimization. With this analysis, efficient information flows and requirements can be incorporated into the process so that the optimum product will be delivered, consistent with the organizational structure, while satisfying system and sub-system level constraints. An evaluation of this form also identifies required enablers for process and product improvement. Traditional systems engineering relies on a top-down product and target-setting decomposition process with aligned organizations. For modular products that have standard interfaces and with experienced organizations with established procedures, this process is appropriate. For integral products and processes, this approach is not effective at delivering an optimized system in performance, program or organizational metrics. An approach that allows system development to occur in parallel with sub-system system design is preferred. Based on process, product and requirement metrics, a preferred alternative and improvements can be identified.

The case study presented in this thesis involves the design and development of automobile safety belts constrained by regulatory location requirements. Based on a Design Structure Matrix evaluation of the process, an electronic catalog of parametric constraints was created that allowed process changes, resulting in a 90% staffing requirements reduction while improving quality and consistency. This new process also supports system level performance optimization by allowing effected sub-system design and development to occur based on the full envelope of permissible locations.

Thesis Supervisor: Dr. Daniel E. Whitney Thesis Supervisor: Dr. Ali A. Yassine Title: Senior Research Scientist Title: Research Scientist

2 Acknowledgements

Dr. Dan Whitney and Dr. Ali Yassine from the Center for Technology, Policy and Industrial Development at MIT have been instrumental in the development of this thesis' topic and content. Their desire for knowledge and teaching demonstrates their commitment to education and industry.

I would like to thank Ford Motor Company for their support while pursuing this degree. Ford's support financially and professionally of individuals who are continuing their education demonstrates the importance of people to its organization. With these types and levels of support, and the people it develops, Ford will continue to be a world class organization.

My wife Faith supported my countless hours of school and work with encouragement and motivation. I will always be grateful for her help, patience and understanding. My parents and in-laws have instilled in me a work ethic that has allowed me to thrive both academically and professionally.

3 Table of Contents Page Title Page 1 Abstract 2 Acknowledgements 3 1. Introduction 5 A. Product Development Process 7 B. Types of Design Processes 9 C. Ford's Product Development Process 14 D. C3P Initiative 18 E. Safety Belt Design 19 2. Original Safety Belt Sub-System Design Process 21 3. Design Structure Matrix Methodology (DSM) 26 A. DSM Process Example 26 B. Process Evaluation and Development 30 4. Use of DSM for Safety Belt Validation Process 33 A. Data Collection 33 B. Matrix of the Original Process 37 C. Development of an Improved Process 40 D. Additional DSM Insight 44 E. DSM Limitations 46 F. Re-Engineering Framework Using DSM 47 5. System Engineering and Process Evaluation 50 A. System Types and Evaluation 50 B. Level of Decomposition 52 C. Connectivity Map 54 D. Safety Belt Application 57 6. Electronic Catalog Initiative 65 A. Catalog Concept 65 B. Catalog Hierarchy 66 C. Catalog Item Life Cycle 69 D. Safety Belt Application 71 E. Parametric Constraints 78 F. Item Naming and Numbering Convention 78 G. Launching the Catalog 79 H. Additional Potential Applications 80 7. Conclusion 82 8. References 85

4 1. Introduction

The product development process develops and delivers a system on the basis of fulfilling a customer need. The organization and management of the process is dependent on the industry's infrastructure and experiences. Traditionally, complex mechanical systems development begins with decomposing the system into functionally organized sub-systems. The components that make up the sub- system are then optimized for select criteria and integrated to form the system.

This top-down approach works well for modular systems with a well-established architecture. When sub-systems are tightly coupled to provide system level attributes, this approach can result in sub-system optimization with non-optimal system level performance. The systems engineering approach and process selected must account for the interactions between the sub-systems and their ability to deliver system level performance. An interconnected sub-system and system mechanical design process insures that constraints are satisfied while allowing for system level multi-attribute optimization. For design problems that are utilizing already available sub-systems or concepts, the use of a selection design process can facilitate this. This thesis investigates a thorough and proactive approach for driving the design process based on using sub-system selection and requirements to define feasible boundaries for the affected system level designs.

The case study documented as a part of this thesis involves the automobile safety belt and child seat anchorages design and development process. The

5 primary constraints used to drive this process are regulatory location requirements. These requirements were selected because they are defined spatially, and demonstrating compliance to regulatory requirements is a prerequisite to product market availability. Thus, without exception, they must be satisfied. In addition, these constraints are interrelated with the system level comfort and performance attributes. The original design and development process was evaluated using the Design Structure Matrix (DSM) methodology in order to capture the sub-system interactions, information flows and requirements, along with organizational interactions. Based on an objective evaluation of this model, improvements were identified that resulted in a new process being developed that uses the associativity of CAD files and an electronic catalog of parametric requirements. As a result, the staffing resource requirements to demonstrate compliance with safety belt and child seat anchorage regulatory location requirements have been reduced 90%, saving over $1 million annually.

This new process and tools also assure consistent interpretation and demonstration of compliance to the requirements, reduced interfacing system design changes, and improved system level performance.

This thesis addresses the problem of how to address systems engineering problems by developing a holistic evaluation of the process, physical system, and functional requirements in order to develop and implement a new process that supports system level performance optimization based on the spatial envelope of permissible locations. This desired approach allows system development to

6 occur in parallel with sub-system design. In addition a new concept called a

Connectivity Map was developed. It presents in one array the relationships between the process steps, the functional requirements addressed by each step, and the physical components that participate in delivering those requirements. It is an original approach for identifying the system architecture type, and causes and types of process iteration.

The remainder of this chapter provides an overview of the product development process and types of design processes that are a part of it. In addition, information about Ford Motor Company's product development process is presented with background information regarding the key enabler tool set and safety belt design process.

A. Product Development Process

Product development is the focal point of the enterprise that links the customer with the internal and external resources of an organization to deliver a product and to generate revenue. It consists of multiple phases that typically are initiated by the identification of a customer need. They are ideally performed sequentially, but in most cases, due to uncertainty or interactions, the process is iterative.

Figure 1 is in overview of the product development phases.

Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 Phase 6 Specification Conceptual System ub-System Testing and Production Development Design Level Design Refinement Design I Figure 1 - Phases of Product Development

7 This typical and traditional process relies on system level design requirements

cascading down to the sub-system level (Phase 3 -> Phase 4). Commonly,

when the components of the sub-systems are designed, they are optimized for a

specific metric (e.g. weight, cost or performance criteria). This does not always

result in an optimized system based on the customer need because "a degree of

coupling usually exists between these subsystems so they cannot be optimized

independently" [1].

A variation to this approach, is a bottom up process in which sub-system

requirements are used to provide boundaries for the system level design. This

allows the system to be optimized versus the typical sub-systems' metric specific

optimization. By adding a phase that defines sub-system constraints, the system

and sub-system detailed designs can occur in parallel. This alternative is

detailed in Figure 2.

5a SPhase System Phase 1 Phase 2 Phase 3 Phase 4 Design and Phase 6 Phase 7 Specification Conceptual Sub-System Sub-System ptimization Testing and Production Development Design Concept Constraint Phase 5b Refinement Selection Definition Sub-System Level Design

Figure 2 - Bottom Up Sub-System Design Driven Process

The system and sub-system design phases are the most time consuming components of the process. They require significant resources for cascading

8 and communicating requirements and boundaries between the sub-systems and system while developing detailed designs. For mature industries with an entrenched supply base and a rigid organizational structure, boundary specification occurs along functional areas. This type of functional decomposition is common and permits organizations to develop their core competencies and leverage economies of scale within the supply base. The drawbacks to this approach are as follows.

1. It does not promote architectural changes/evaluation of a product.

2. It is slow to respond to market changes.

3. It places limitations on system level performance.

B. Types of Design Processes

System, sub-system and component design can be conducted using numerous approaches to support the product development process. "The design process is a map for how to get from the need for a specific object to the final product" [2].

Selection of a particular approach is dependent on the type of problem, existing knowledge base and organization. The following are the most common approaches [2]:

1. Selection design - evaluate available alternatives and select the design that

best fulfills the specified requirements, "making choices from discrete sets of alternatives" [3]:

9 * Lends itself to a catalog selection approach where requirements are

inputs, and designs that fulfill these requirements are identified based on a search algorithm.

* Requires clear and consistent definition of requirements.

2. Configuration design - assembly of existing sub-systems to satisfy system level constraints:

* Bottom-up approach primarily concerned with packaging and sub-system interfaces.

" Primarily for spatial and modular design problems.

* Can use a catalog to select among existing sub-systems.

3. Parametric design - specification of variables that generate feasible design

solutions, relating design parameters that are defined over continuous intervals:

* Requires rules and relationships between variables.

* Parameter values must be specified before designs are developed.

" Parametrics can also be used to define requirements, alternative solutions and sub-system interfaces.

4. Original design - creation of something that is completely new and unique:

" Equations and relationships are not available.

* An existing design that can be modified to fulfill the need is not available.

5. Re-design - modification of an existing design to fulfill a new unique need:

* Existing design fulfills similar need, and modification permits fulfillment of new and or unique need.

10 An example of a parametric design problem is the volume of a rectangular tank, as follows.

Volume = Length x Width x Height

If three of the four variables are specified or known, the fourth can be calculated.

When less than three are known, the relationships between the unknown variables can be specified to develop a range of alternatives. In addition to the equation, parametric constraints can be specified between subsets of the variables. An example relating the length of the tank to its width is as follows.

Length > 2 x Width

Conditional relationships can also be specified.

If Length < Width then Height = Width else Height = 2 x Length

Figure 3 is an example of a conditional relationship for the European safety belt regulations integrated into a CAD system. Variables (e.g. Seat-angle) are assigned values to determine the value of the parametric variable (i.e. S) that then uses the conditional relationships to determine the values of other variables

(e.g. CY and BR).

11 Figure 3 - European Upper Anchorage Zone Equations

Selection design commonly utilizes a catalog of feasible alternatives. One potential form for a catalog is in hardcopy where the specifications of the alternatives are listed with the available selections. Here the user must manually evaluate and select among the alternatives. An electronic catalog requires user input for the required attributes. It utilizes a heuristic or rule-based search algorithm to identify designs that fulfill the requirements.

12 A common use of catalogs is for the selection of standard parts (e.g. screws, nuts and bolts). Examples of required attributes and feasible alternatives are:

Type - hex-head bolt, outside drive bolt, washer

Length - 10 mm, 15 mm, 1.25 inches

Unit - metric or standard

Material - steel, stainless steel

Finish - painted, corrosion protection

Combining parametric and selection design methodologies results in shorter design times, the integration of sub-system and system level designs, and complexity reductions. This approach also facilitates "a flexible problem decomposition that facilitates the reintegration of sub-problems so that integrated global modeling and optimization is possible" [4].

The safety belt application presented in this thesis demonstrates combining these methods. The catalog hierarchy in Figure 4 combines parametrics (generic parts and requirements) and supports selection design. It is a generic framework that can be applied to a wide range of systems. The hierarchy has branches of the tree containing individual sub-systems to support and be aligned with the organizational structure. The requirements are a child of the parts so that they can have common search attributes and be grouped along functional requirements. When developing a catalog the user terminology, organizational structure and responsibilities need to be considered.

13 System

Sub-System 1 Sub-System 2 Sub-System 3

Generic Parts: Generic Parts: Generic Parts: Components of * Components of * Components of sub-system 1 sub-system 2 sub-system 3

E E E E E E

Figue 4 G C Hr rh CD a) a) (D (DU

'-0 -0 '0"- '-0

Figure 4 - Generic Catalog Hierarchy

C. Ford's Product Development Process

The Ford Product Development Process (FPDS) is one of the core processes in

Ford Motor Company's Automotive Operations. It is used to plan, design, develop and build new vehicles. The previous process, World Class Timing required 60 to 80 months to develop a completely new vehicle. With FPDS and the implementation of key enablers, a new vehicle program can be delivered in approximately 41 months. The exact amount of time for a specific program is a function of the amount of new content in the vehicle. Key areas of focus to achieve the targeted areas of improvement include:

* Reusability - parts, tooling, processes and knowledge

14 * Systems approach - top-down cascade of targets and bottom up

verification (Figure 5)

Vehicle System

Cascade Targets Sub-Systems Design Verification

Components

Design Optimization Figure 5 - FPDS Systems Engineering Approach

" Process Management - eliminates non-value added tasks, and use

of consistent program metrics and procedures across programs

" Consumer Focus - delivers brand strategy while fulfilling identified

customer needs

The systems methodology is similar to what was presented as a part of a traditional product development process. It is explained graphically in Figure 6, with an example of a vehicle level attribute, water leaks. The example is of a vehicle level water leak warranty (typically expressed in repairs/1 000 vehicles) target being cascaded to the affected sub-systems and components. A shortcoming of this approach involves a target and responsibility not being specified for the boundaries between the sub-systems or components. An example of this type of issue is the door interfaces to the body shell. Since these sub-systems are the responsibility of separate organizations (closures and body shell) during traditional decomposition, their interface is not accounted for in target setting, even though the interface contributes to the system level attribute.

15 Vehicle A Water Leaks 0.30 R/1 000

Closures Fixed Glass Static Sealing 0.15 R/1000 0.10 R/1000 0.05 R/1 000

Front Doors Windshield 1_ Body Shell 0.05 R/1000 0.05 R/1000 0.04 R/1000

Rear Doors Rear Glass Underbody 0.05 R/1000 0.05 R/1000 -- 0.01 R/1000

Trunk 0.05 R/1000

Figure 6 - Vehicle Level Attribute Cascaded to Sub-Systems

Interface issues are identified late in the program during system level evaluations, with their corrective actions being based on political, and what, at the point, is a feasible alternative versus what is best for the system and could have occurred earlier in the process. Another issue is that sub-system targets are typically based on historical data, with an across-the-board assigned improvement factor (e.g. 10% reduction in warranty) that assumes consistent improvement is possible across all sub-systems and optimal. Through the use of an associative CAD system that informs affected sub-systems when changes occur and utilizing parametrics to define boundaries, sub-system interfaces can be managed throughout the process. The safety belt case study presented in this thesis demonstrates a framework for establishing such a process.

16 FPDS differs from the process it replaced in that it focuses on managing the process versus the methods of developing the actual deliverables of a vehicle program. Since it relies heavily on new enablers (technology and strategy), it is considered to be a dynamic process that will evolve as the enablers mature and lessons are learned and shared. This type of process, which is concerned with what actions and management practices are taken to produce deliverables, and not just the form of the deliverables is focused on identifying systemic issues and promoting consistency. It aims to deliver a consistent, structured and repeatable process by managing the sequence of the tasks and their interrelationships. The desired product development process benefits of this approach are:

0 Reduced development time

0 Improved quality

* Improved development productivity

* Alignment of goals and objectives

* Facilitation of internal corporate knowledge sharing.

In FPDS, a system engineering approach, focus is placed on specification development and evaluation to reduce testing as a means of evaluating designs that would often require re-design. CAD (Computer Aided Design), CAE

(Computer Aided Engineering), CAM (Computer Aided Manufacturing) and PIM

(Product Information Management) enhancements are key analytical enablers of

FPDS to support this approach.

17 D. C3P Initiative

C3P is an acronym for a software tool set and infrastructure initiative that is used to design, develop, analyze and manage information as a part of FPDS. The components are:

" CAD - Computer Aided Design

" CAE - Computer Aided Engineering

" CAM - Computer Aided Manufacturing

* PIM - Product Information Management

These tools are enhancements and additional applications to the previous product development infrastructure. The initiative integrates data models and product information to reduce design times through concurrent analysis and manufacturing feasibility during detailed design and improving quality by analytical evaluations. Some of the business implications and goals of the C3P initiative include:

* Five year $200 million project

0 35% to 40% engineering productivity improvement

0 Reduced prototype costs by 35% to 40%

0 3,000 to 5,000 positions eliminated over 10 years [7].

Previously at Ford, a variety of software tools were used by internal design activities and full service suppliers, thus making the exchange and access of information difficult. As part of this initiative, all internal and external design and

18 analysis activities are based on the I-DEAS solid model being the master. By having a single electronic model as a master, the process and participants no longer require drawings or information in hard copy form. With the transition from wire frame design to solid modeling, the model data is better defined and can be used to calculate physical part properties (e.g. mass and moments of inertia).

Solids also allow surfaces to be extracted (for numerical control machining) and can be used to create virtual prototypes.

Information management is an integral part of C3P and the initiative's ability to deliver the benefits of the new technology. The goals of an information management system are to reduce the time required to identify and store information, store data in a central master location, control access to data and retain data for future re-use. Metaphase is the product information management software that allows access to, and use of, the archived master. It is the common link between the Team Data Managers (TDM), local program specific storage systems. The TDMs coordinate local work groups' data according to a standard product code decomposition (Corporate Product Systems

Classifications). The I-DEAS/Metaphase Interface (IMI Bridge) links the TDMs to

Metaphase.

E. Safety Belt Design

As a part of the product development process, a dedicated computer aided design group is responsible for coordinating the designs of safety belt sub-

19 systems for vehicle programs in order to insure adherence to regulatory location requirements. This organization is now in transition from the previous process and design tool set to FPDS and the C3P tool set. It requires information from multiple internal and external organizations to fulfill its responsibilities.

This thesis provides a framework for evaluating a product and process in order to identify an efficient and effective system engineering approach. It is presented within the context of an automobile safety belt sub-system design problem that must satisfy regulatory location requirements. The framework is appropriate for use in other applications. The following are the contents of the forthcoming chapters:

Chapter 2 - Original Safety Belt Sub-System Design Process Background information on case study's original process.

Chapter 3 - Design Structure Methodology (DSM) Methodology overview and application for process evaluation and

development.

Chapter 4 - Use of DSM for Safety Belt Validation Process Application of DSM to the case study and re-engineering process.

Chapter 5 - System Engineering and Process Evaluation Objective framework for evaluating physical system, functional

requirements and their coordination with the development process.

Chapter 6 - Electronic Catalog Initiative Overview of key enabler for the new safety belt case study process and

framework.

Chapter 7 - Conclusion

20 2. Original Safety Belt Sub-System Design Process

Typically, safety belt sub-system design and development leverage available components from full service restraint suppliers who provide sub-systems to multiple manufacturers in the auto industry. Vehicle specific components (e.g. mounting brackets and webbing length) are unique to the end item provided for that vehicle and are dependent on both individual program metrics and interfacing sub-systems. The metrics used to evaluate a safety belt sub-system are:

* Performance - contribution to safety system's occupant protection

* Quality - long term reliability and non-safety related performance

(e.g. sound and feel characteristics)

* Comfort - subjective evaluations based on anticipated usage

" Cost - affordability of technology vis-&-vis program objectives

" Complexity - number of unique end items at vehicle assembly

plants.

The development process requires interactions between multiple sub-systems, with the goal of optimizing the system based on the above system metrics.

Design activities must satisfy their unique requirements based on the evaluation criteria presented in Table 1.

21 As a part of this process, a dedicated Ford design activity integrated product information from the responsible full service suppliers, in-house design activities and regulatory requirements to create and archive drawings demonstrating

Sub-System Requirements Evaluation Criteria Sheet Metal 1. Packaging 1. Manufacturing 2. Attachment points feasibility 2. Structural performance Safety 1. Performance 1. System level performance Seating 1. Packaging 1. Comfort 2. Attachment point 2. Structural performance Interior Trim 1. Clearance 1. Appearance

Table 1 - Sub-System Interactions compliance to the applicable requirements. The group did not create any part geometry and its primary responsibilities involved coordination and monitoring to insure that affected organizations had the required information to complete their designs and communicated with each other. They also facilitated the interpretation of the regulations between engineering and the safety office to verify that requirements were accurately defined and adhered to. Their span of responsibility included all Ford vehicle programs designed in North America.

Typically, their involvement began at the beginning of the pre-program design phase and ended at engineering sign-off (completion of detailed designs and verification). Resources were assigned based on the complexity of the program,

22 e.g. level of new content, market availability for the program and the number of regulations that required compliance verification. The group required the information presented in Table 2 to complete its responsibilities.

Organization Information Provided Seat supplier Seat surface Safety belt attachments, if applicable Restraints supplier Safety belt retractors and buckles in vehicle position Child seat anchors in vehicle position Attachment types Sheet metal design Attachment points and type Vehicle package Seat package information Safety office Applicable regulations Regulatory interpretations Engineering Product market offerings Compliance concurrence

Table 2 - Information Requirements CAD Compliance Activity

Information is shared between organizations and tasks throughout the process.

By identifying who creates, provides and requires information the process can be evaluated using the DSM. This objective evaluation can determine an optimum ordering of tasks (based on potential iteration), organizations' roles and responsibilities, and strategic changes that would improve the process. A preferred process creates required information before it is needed, the information is aligned with the functional requirements, the sub-systems are well defined and an infrastructure exists to manage the boundaries.

23 Various methods exist for demonstrating compliance, from physical validation tests to computer based analytical evaluations. As in most industries, there are cases when the manufacturers self-certify their compliance based on in-house procedures and policies. In other instances, formal documentation and possibly witnessing organizations are involved. The compliance to safety belt anchorage location requirements, which involves a combination of these alternatives, is dependent on the markets where the vehicle will be sold.

The original process was highly iterative, personnel-dependent, and culminated in a two-dimensional drawing that showed the necessary components and regulations so that compliance could be verified visually. Regulatory requirements are often difficult to interpret and require extensive knowledge of and experience with the regulations, as well as seat and restraint systems. With the original process, a designer could be dedicated to a program for up to a year.

If that program did not contain a certain market, the designer's knowledge of the market's requirements was typically lost; either because the regulation has changed or it has been forgotten. Also, no formal means existed for training the design staff in this process and communicating requirements.

Information was exchanged on an "as requested" basis through an informal communication network. The process was iterative, partially because of groups working with outdated information, and the effect of sub-system design changes on their mating components, as well as their impact on compliance to the

24 regulations. All of the design work in the original process was conducted in

Product Design Graphics System (PDGS), a proprietary wire frame design tool.

As a part of a corporate-wide initiative the design organizations are in transition to a new tool set, including 1-DEAS (1-DEAS Master Series is a solid modeling and analysis product from Structural Dynamics Research Company) and

Metaphase (a Structural Dynamics Research Company product management information software).

The restraints computer aid design departments at Ford is represented by the

United Auto Workers (UAW), and is a core organization that supports all programs. To utilize the new tool set, each designer received the necessary cross-functional training. The reduced staffing requirements of the new process allowed designers from this section to be re-assigned to other program specific design sections. Transferring personnel helped distribute within the organization, an understanding of parametrics and the use of catalogs to support design.

The Design Structure Matrix methodology, discussed in the next chapter, is a comprehensive method for evaluating a process to identify information flows and organizational interactions. Based on the data gathered and objective evaluations, a more efficient ordering of de-coupled tasks can be developed. For coupled tasks, appropriate strategic actions can be identified and developed to improve the process.

25 3. Design Structure Matrix Methodology

The Design Structure Matrix (DSM) is a powerful methodology for objectively modeling and improving a process through the identification of tasks that create iteration loops. It can also be used as a communication tool to represent the tasks of a process and the relationships between the tasks. An "X" in a task's row signifies that a relationship exists with that column's task. "Xs" above the diagonal in the DSM signify that information is required from a task that occurs either in parallel or in the future for that row's task. These needs and flow of information are what causes interactions and creates iterations. The farther off the diagonal, the greater is the potential impact of the iteration in terms of the potential number of tasks affected. "Xs" below the diagonal represent feed forward information, where information for a task is completed by a preceding task. The DSM can also be used to reveal which organizations interface and during which tasks. This type of information can be used to determine milestones and deliverables to insure coordination between activities.

Knowledge of information requirements for a process can be used to develop an improved process, to determine a required tool set, and participant capability requirements. These types of information can also be used to help determine an organization's structure and resource allocations.

A. DSM Process Example

Figure 7 is an example of a process DSM that contains ten tasks. The sequential

26 ordering (rows and columns) represents the order in which the tasks are performed.

U a) W -1 -

Cd Cd Cd Cd Cd CU CU CU CU CU

TaskA X X Task B X X Task C X X TaskD X X _ Task E X X TaskH X X X Task G _ Task H _ X

Figure 7 - Initial Process DSM Example

In this example, task A requires information from tasks D and H. Since these tasks occur after task A, they are coupling, i.e. task A depends on tasks D and H, and tasks D and H depends on A. This is not obvious from Figure 7, but can be clearly seen in Figure 8. This type of relationship between task A, and D and H, can cause task A to be repeated (i.e. an iteration). A typical motivation for a

DSM is to revise the order of the tasks in an attempt to reduce potential iterations. For this example, Figure 8 contains the re-sequenced DSM.

Simply changing the order of the tasks has reduced the number of potential interactions causing iteration (number of "Xs" above the diagonal) from eleven to three. This re-sequencing, also knows as partitioning, of a DSM can be performed as a project/process management tool to identify tasks that can be done in series, or parallel or tasks that are coupled. The above example demonstrates that tasks I and E can be performed in series; tasks E and J are

27 0-4 WZ Q 0. 14 -4 H Hj 4 Hn H6 H HA H4 HA

Task I _ I _ _ i _ _ _ i _ I__I Task E X Task J Task H X x Task D Task A Task C Task G X I I I I X Task B 1 1 I I I I X X Task F X

Figure 8 - Re-Sequenced Process DSM Example coupled; and no tasks can be done in parallel, i.e. each task is dependent on its preceding task. Table 3 summarizes how to identify relationships between tasks, and their sequencing, by inspecting a DSM model.

Relationship Ordering of Tasks DSM Characteristics Dependent Series Tasks: Tasks need to be A "X" below the diagonal in Information is required from scheduled the row of the dependent the preceding task for the sequentially task and the column of the following task to be initiated succeeding task that provides information Independent Parallel Tasks: Tasks can occur at No "X" at the intersection of No information is required the same time the tasks' columns and from either task for the other and/or be scheduled rows to occur independently Interdependent Coupled Tasks: Duration of tasks "Xs" above and below the Tasks require information overlap diagonal in each of the row from each other and can and column intersections cause iteration for the tasks

Table 3 - Task Relationships

28 To create a DSM model, data is gathered to learn about the process and understand objectively what drives iterations. A clear understanding of the reasons behind iteration allows for the determination of the following:

" Preferred task sequences, if available (as in the previous example), in

order to eliminate iterations or reduce the chances of their occurrence

* Identify potential actions that can improve the process, as will be

demonstrated by the safety belt application.

Coupled tasks that have "Xs" above the diagonal represent feed-forward information requirements that cannot always be improved on by re-sequencing.

In these instances, strategic actions need to be undertaken to re-engineer the process to de-couple, eliminate these tasks or to arrange other means for carrying them out together. Table 4 details the metrics that can be used to evaluate a DSM from these perspectives.

Managing resources through the use of a DSM model, along with standard project management tools, helps control, plan and delegate resources. It is typically not practical for upper management to be intimately knowledgeable about each aspect of all processes in their organization. In this application, a

DSM model can be used as a presentation tool to justify the need for resources because it is easily understood and concise. In addition, a higher level process

DSM can be created, with the individual tasks being represented and evaluated by a DSM model. For a thorough explanation of the DSM methodology for

29 improving and documenting product development processes, see Eppinger et al.,

1994 [5].

Task Relationships DSM Metrics Potential Actions (fewer is better) Number of interactions Number of tasks Develop effective between organizations involving different communication forum, organizations reassign responsibilities to one organization Potential impact of task Distance above the Specify information at the on entire process diagonal where "Xs" beginning of the process, occur, number of coupled develop a consistent, tasks, number of tasks common strategy requiring information from a task High information Number of cells Integrate resources and requirement from multiple containing information centralize shared organizations to complete requirements for a task information atask and numberof organizations involved Number of tasks from Number of cells showing Re-sequence or combine which information is relationships between tasks to complete required tasks in the entire matrix information before it is required

Table 4 - Metrics for Evaluating Coupled Tasks

B. Process Evaluation and Development

Understanding the information flows and organizational interactions allows a process to be developed and managed effectively. Along with the information,

30 the type of communication, frequency and motivation need to be identified. A team that created and participates in a successful process is often the optimal one suited for its evolution, but seldom for creating its replacement [3]. Support for this heuristic varies from a pride of ownership ("not invented here syndrome") to job security. Both of these issues need to be addressed during data acquisition to eliminate participant bias with the existing process and not to limit the range of potential improvements. It is also necessary to focus interviews on what actually does happen, rather than what participants think does or should occur. For these reasons, interviews of all of the participants should be conducted, with cross-referencing of the data to assure its accuracy and completeness. Comparisons should not be made between the original process and what individuals think is possible with the new one, because using comparisons and making assumptions about what is possible will limit the range to potential incremental improvements. It is also necessary to separate what information is required from the medium that provides it. For example, a two- dimensional drawing (medium) shows anchorages within a regulatory zone

(information). What is required is verification that the anchorages are within an allowable zone, and the medium can be of any type. In order to identify appropriate future actions, it is also necessary to verify the true status of implementation for the current software as well as for processes for the involved activities to insure what is developed is feasible. During this project, multiple cases were identified where what was published on the corporate Intranet as

31 current process, was actually what is to be expected in the future with functionality improvements.

Process evaluation and development actions support creating metrics and an implementation plan for the new process. The maturity of supporting processes and organizations' capabilities is required for developing a process deployment plan to insure coordination during the transition. These process metrics are appropriate for the control and reporting of information and organization requirements that are significant to the overall process and relevant to other organizations.

Presented in the next chapter, is the DSM methodology applied to the safety belt design and development process. The DSM revealed that the original process was an inefficient generate-and-evaluate method with many iterations and information exchanges between organizations. In-depth analysis identified the evaluation tasks, who conducted them and what information was required to perform them, revealing the opportunity for an electronic catalog of parametric constraints and generic parts.

32 4. Use of DSM for Safety Belt Validation Process

As part of the product development process at Ford, a dedicated CAD group had responsibility for coordinating the designs of safety belt sub-systems for vehicle programs in order to insure adherence to regulatory location requirements. The process was highly iterative, personnel-dependent and required information from multiple internal and external organizations. In addition, the CAD activity was transitioning to the new product development process and tool set. The DSM methodology was used to capture, evaluate and present the safety belt validation process' information flows and organizational interactions. The identification of information flows and organizational interactions were objectively analyzed in an effort to reduce iteration by optimizing the order of the tasks. Since the process was found to be highly coupled this was not feasible. Additional evaluations of the DSM revealed strategic actions that improved the process by revealing the opportunity for an electronic catalog of parametric requirements and generic parts. This transformed the process from an inefficient generate-and evaluate method to one where sub-system boundaries and requirements were specified and eliminated the evaluation tasks.

A. Data Collection

Organizations that participate in the restraint validation process include full service suppliers (seats and restraints), Ford engineers (restraints), design

(restraints CAD and vehicle package) and others (assembly and manufacturing

33 personnel, safety office personnel and project management). Data was gathered by interviewing personnel from each organization involved in the process. This proved to be a difficult task due to the number of full service suppliers and engineers involved, each with varying levels of experience and expectations due to the uniqueness of their vehicle program. In addition, some programs that are currently underway are based on the previous product development process,

World Class Timing or a hybrid of FPDS. The different product development processes contain unique milestones and full service supplier responsibilities.

Also, since not all programs had clear or consistent statements of work to which they agreed before sourcing of the sub-system, responsibilities were continually being negotiated throughout the process.

During the interview, when individuals were asked about their organization's participation and information flows, it was necessary to define what was meant by each task. Part of the reason for this is that each supplier's internal organization structure and processes are unique. Due to personnel changes as a result of career development and typical attrition, both at Ford and at full service suppliers, there was typically only one or two experts for each organization. Since individuals typically focus on information that they assume is common between organizations, vis-a-vis their unique information requirements

[6], their complete information needs were not always reported during the interview. It was necessary to re-interview some organizations when downstream information requirements were identified that apparently had no

34 provider. In addition, the same type of information inventory needed to be conducted in the reverse case when information was being provided without an identified recipient. Instances where information was being generated and distributed, but was not being used, was most commonly a result of a change in process or organization that was not clearly communicated. Design manuals and design specifications were also reviewed, but this did not provide sufficient levels of detail for developing a set of tasks and involved organizations. With the implementation of the new product development process, the organizational structure was also modified. This was not yet captured in the design manuals.

The Ford CAD activity has responsibility for supporting all Ford programs and has established relationships with the involved activities. This central perspective was ideal for capturing data from each involved organization.

To help conduct the interviews and gather the data it was necessary to predetermine the level of decomposition at which the process was to be evaluated. Aggregating the process at too high a level would have resulted in a model that did not accurately capture the organizational interactions.

Specifically, it would infer a level of coupling that is too high. It was necessary for the interviewer to have extensive knowledge of the existing procedures so that each sub-task could be defined during the interviews to insure consistent data.

Each organization had a unique expectation and flow of information for the process, commonly with the flow of information being in multiple steps, with the

35 intermediary organization simply transferring information. An example of this is the restraints CAD section requesting seat package information from the seat supplier. Since the seat package is actually the responsibility of vehicle package, the seat supplier would request this information from that activity, and then forward it to the restraints CAD section. There was also obvious inconsistent and unclear direction for responsibilities and considerable duplication of effort both at

Ford and externally. Vehicle package, the restraints full service supplier, and restraints CAD activities each independently, and in some cases with contradictory results, created the seat belt anchorage regulatory zones. Vehicle package created this information early in the program to support vehicle architecture studies; the supplier created the zones to help develop mounting brackets; and the CAD section created the same zones to monitor regulatory compliance.

During the interviews, it was identified that each organization had a unique and conflicting perspective on what the tasks were, when they occurred and who was responsible for providing what information. It was also apparent that individuals were more aware of the information they required than the information they provided to other organizations. This is partially due to the informal communications networks that develop in a large organization that are focused on getting the job done, versus following a process. The most common form of communication was an informal e-mail or voice mail that did not always provide for an actual origination of the data (where the data is mastered and created).

36 The data then requires some form of translation to become a part of a completely associative electronic process. For the instances (e.g. seating reference points) when information is requested of an organization, but originates in another, what is shown in the DSM is where the data actually originated and is used. These types of two-step interactions are best addressed and improved through process training of the individuals involved in the process and establishing a formal communication network (e.g. regular program module team meetings).

B. Matrix of the Original Process

The DSM methodology was used to create a model of the information flows of the current safety belt anchorage location design process, with the intent of capturing the information that is created and used by an organization, along with that information's impact on preceding and succeeding tasks. Traditionally, a task DSM is created in an effort to optimize the order of events by reducing the number of iterations or to help identify actions that will allow iterations not to occur, or to occur at a faster rate. Typically, this is accomplished by re- sequencing tasks to have required information completed by preceding tasks.

For this application, altering the order of events did not create opportunities for improvement due to the interdependent relationships of the tasks.

The tasks are linked through the exchanges of information within and between the various organizations involved in the process. A "X" in a quadrant of a task cell graphically signifies that an organization participates in creating and/or requiring information for that event to occur. Information created or modified during a

37 downstream task that is coupled with a preceding task can cause iteration. This is a result of the preceding task either not being able to be fully completed without the required information, or working with an assumption for the succeeding task that, in the future, is identified as incorrect. Tasks with this characteristic have a

"X" above the diagonal. Figure 9 is the task DSM for the original process, which was decomposed into seventeen sub-tasks. The design procedures, organizational roles and responsibilities and the overall product development process determined the boundaries of the individual tasks.

38 Design Engineering A B C D E F G H I J K L M N 0 P Q FSS Others Define Seating Hardpoints A X X (SgRP and Seat back angles) Determine Seat Travel X

(up/down and fore/aft) X X _ Safety Belt Product Assumptions CX X X (i.e. SIR or structure attached) X X X X X X X X X X Specify Market Availability for D Program X X X X X -n Determine Applicable Safety Belt X X X X X X Regulations E_ X_ X

Interpret Regulations F X X X X X 0

Style and Develop Exterior of Seat G X X X Determine Anchorage Points H X X X X X X X X X X (i.e. attachment and take-off) X X X X X X X X X XX X X X (D Package Safety Belt Sub-System I X X X X X X X Uomtort X X Considerations/Evaluations J U X X X X -i (,pot And -,fPtv hX1tXX X Determine Assembly Process K X X X X CAE Performance Evaluations X X X X X (vehicle level evaluations) L X X X

Safety System Development M X X X X X

Prototype Build Evaluations N X X X _ X X X X X X X X X X X Verify/Document Compliance X X X X X X X X X X (upper anchorages) X X X X X X X X Verify/Document Compliance P X X X X X X X X X X (lower anchorages) X X X X X X X X X Verify/DocumentCompliance X X X X X X X X X X X (child seat anchorages) X X X X X X X X X X An example of how to evaluate a task as a part of the DSM; the first task (row A),

"Define Seating Hardpoints," requires information from the task, "Determine Seat

Travel" (column B). The organizations involved in these tasks are engineering, which insures that corporate design specifications are adhered to, and design

(vehicle package), which is concerned with the overall vehicle layout of which seat packaging information is a part. An example of a highly iterative step is the

"Determine Anchorage Points" (row H) task that requires information from seven tasks that occur after it is scheduled. The last three tasks of the original process,

"Verifying and Documenting Compliance" for the anchorages, have the potential for causing iterations for three (C, G, and H) different tasks in the process. The iterative effect of these tasks are similar to the design, test and then fix process, where compliance to requirements is performed at the conclusion of the process.

With the new process, these step are no longer required, since the process now analyzes the requirements and specifies the feasible location envelopes in advance of the tasks requiring this information. These actions are representative of the preferred systems engineering approach analyzing requirements, completing the detailed designs, and verifying adherence to requirements.

C. Development of an Improved Process

The re-engineered process is documented in a DSM model that does not require all of the tasks of original process, but does contain a task unique to the new process. Since re-sequencing the tasks did not reduce the potential iterations for

40 this application, strategic actions were initiated to address the tasks with the

greatest iterative impact and resource requirements. Any task that has "Xs"

above the diagonal has the potential to cause iterations. Resource requirements

are correlated to the number of inputs required to complete a task, the amount of

interaction between organizations, and the quantity and magnitude of outputs.

Inspection of the original process using the metrics in Table 4 (Chapter 3) reveals

that there are nine instances of interaction between the full service suppliers and

design activities that can create iterations. The verification and documentation

tasks (rows 0, P and Q in Figure 9) can also be seen to have high information

requirements because they require information from eight preceding tasks as

well as being coupled with three tasks. These tasks also require significant

interaction between all of the organizations, as represented in the DSM. For these reasons, the process re-engineering focused primarily on these tasks. In addition the tasks of determining the applicable regulations and interpreting the

regulations (rows E and F in Figure 9) were found to cause potentially significant

re-work because they are coupled with nine tasks.

Figure 10 is the new re-engineered process DSM. This new process contains

28% fewer instances of potential iteration (21 task interactions above the diagonal for the re-engineered process versus 29 for the original process) based on the specification of the compliance zones early in the process.

41 Design Engineering A B D E F G H I J K L M N

FSS Others Define Seating Hardpoints A (SgRP and Seat back angles)

Determine Seat Travel B (up/down and fore/aft) X X

Define Allowable Anchorage Locations C (electronic parametric constraints) X X Safety Belt Product Assumptions D X X (0 (i.e. SIR or structure attached) DX X X X X X X XX X

Specify Market Availability for Program E 0 Determine Applicable Safety Belt F X X X X X X

Regulations _ X X X Interpret Regulations G X X X o Style and Develop Exterior of Seat H __ ___X 0 ______0 Determine Anchorage Points X X X X X X (i.e. attachment and take-off) ______X X X X X X X X X

PackageSafety Belt Sub-System J X X X X X X X X Comfort Considerations/EvaluationsK X (seatand safety belt) K X X X X X X X

Determine Assembly Process L X X X X

CAE Performance Evaluations M X X X X X X (vehicle levelevaluations) XXX

Safety System Development NX X X X X Prototype Build Evaluations 0 X IX X1 _X X X X X X X X X X The initial objective of identifying an order of the tasks for the process that is

optimal based on the number of iterations was not feasible because the tasks in

this process are highly coupled. Prior to the interviews and DSM model, it was

assumed to be a highly coupled process but not understood why. The DSM

model proves this by not allowing re-sequencing of the tasks to reduce the

potential iterations. Instead, objective evaluations of the process DSM were

conducted to identify potential strategic actions that would re-engineer the

process in order to reduce the number of iterations and organizational

interactions. The identified primary needs of the action were to eliminate the

requirement compliance verification at the end of the process and to reduce the

participants' required knowledge regarding regulatory requirements. To address this, an initiative to create and deploy an electronic catalog of parametric

constraints was undertaken for the new process. In addition, the issue of

organizations working with out-dated information was identified as a significant

cause of re-work that needed to be addressed by the new process through the

electronic association of CAD files. Even with the new process, it is still too tightly coupled to have the order of the tasks reduce the potential iterations. The

DSM models also objectively identify each organization's perspectives of the

process, from the origination and use of required information.

Additional information gained during the DSM creation was individuals'

perspectives on their own and other's roles, responsibilities and deliverables.

This information was used to develop a pro forma for sourcing agreements and

43 CAD deliverables. The standardized agreements stipulate data format, data

exchange application requirements, responsibilities and timing. The DSM

models also proved useful as a communication tool at Ford, as well as externally

when interfacing with the full service suppliers. Providing a graphical

representation of the interactions of tasks and users of information reinforces the

importance and implications of the events.

D. Additional DSM Insight

The ability to define, create and implement strategies or tools that address the

iterative nature of the process captured in the DSM was crucial to the successful

acceptance of the methodology. It was also necessary for the DSM models to be

readily understood by individuals who are not part of the process. For this

application, the need for an electronic catalog of parametric constraints was

identified, along with its effects on the re-engineered process. The same metrics that were used to identify the need for the electronic catalog, also provided supporting evidence for a corporate-wide initiative regarding safety system

product assumptions. The initiative specifies what type of restraint system components will be released for vehicle programs and will reduce the number of iterations for the Safety Belt Product Assumptions task. To support this initiative the electronic catalog contains generic safety belt retractors and anchor plates.

As the corporate-wide strategy is further implemented, additional parts will be added to the catalog.

44 New Process Staffing

Original Process

Timing

Figure 11 - CAD Restraints Staffing Requirements

Based on the identification of what and when information is available during the

DSM task research it was determined from what parameters the constraints would be developed. It also helped identify the users of this information, which had an impact on the manner in which the catalog was structured and its availability. Implementation of the electronic catalog has reduced the staffing requirements by 90% for the Ford CAD restraints organization without creating additional work for another activity. The original process required dedicated support for the life of the program due to the frequent interaction and iteration.

The new process only requires support at the beginning of the program to define the allowable anchorage locations, and at the end, if needed, to satisfy documentation requirements (Figure 11).

The DSM model has also been used as a communication tool for upper management presentations as well as supplier interface meetings. It allowed, at a glance, an explanation of what information was to be required, who was to provide it and who would uses it. In this manner, it helped define the boundaries

45 of the individual tasks' interfaces. It has also been used to justify and evaluate

the need for resources. In most situations, it was not realistic to present a

complete process map and the single page DSM effectively summarized the

process.

E. DSM Limitations

One significant source of iteration that is not adequately identified by the DSM is

the use of incorrect information, due either to an error during its generation or

being out of date. Since each step of the original process required verifying its

status (up-to-date versus a previous version) a verification sub-task could have

been modeled for each task. However, this is not an efficient method for

capturing this aspect of the process, since the verification step would be coupled with the task, and applying the DSM would not identify an improvement. Since

each individual verification task is completely coupled with the step of which it is

a part, re-sequencing is not possible. The issue of working with up-to-date

information can be addressed by communication. If it is effective, it will eliminate this as a source of iteration. To insure that a communication method is 100%

effective for providing the status of information, it must be attached to the data

and, in the case of when it is out-of-date, provide a means for updating. For these reasons, an associative CAD process is effective, and is a component of the new process. This eliminated the need for these additional rows and is another benefit of the new process that is not adequately captured in the process

DSM.

46 Additional barriers to success are a result of the number of different safety system architectures, unique program directions, number of full service suppliers, and each supplier's unique internal procedures. In each program's situation, a reasonable case can be made that the individual car program does not match the task DSM. These models attempt to capture the general process, and should be considered a template for the specific scenarios. The individual programs must identify what is unique for their program and modify the DSM accordingly.

F. Re-Engineering Framework Using DSM

Evaluating an existing process with the DSM methodology identifies the relationships between the tasks and creates a baseline for improvement. With an understanding of the task relationships, an efficient process can be developed, and the required improvement actions can be determined. For the safety belt application, significant benefits were realized by modeling sub-system requirements at the beginning of the process, versus the original end of process verification. This structured process evaluation also identified the significant benefits of an electronic catalog that contains parametric requirements to facilitate coordination of resources between the involved organization and to eliminate duplication of effort. Based on the DSM's easily understood format, it is effective for explaining a process and the identification of an organization's needs and information flows.

47 By capturing a process in a DSM model, task relationships and an ordering preference can be identified. Tasks that are coupled can be objectively evaluated to determine appropriate actions reducing their impact on the overall process. The final improved process can then be captured in a DSM and used as a communication and project management tool. The following, Figure 12, is a generic framework for re-engineering a process using the DSM methodology.

Capture Existing Process in a DSM Model: * Interview involved activities to capture information requirements and sources

Identify Relationships between the Tasks Using Interview Information: * Marks in rows and columns of the DSM

Re-Sequence Tasks to Reduce the Potential for Iteration: * Perform independent or sequential tasks when required information is available

Evaluate Coupled Tasks to Identify Potential Strategic Actions: " Changes in roles and responsibilities * Tool and process functionality requirements

Implement Actions and Capture New Process in a DSM Model: SUse DSM model as a communication tool and to monitor and control the new process

Figure 12 - Generic Process Re-Engineering Using a DSM Model

In addition to a DSM process evaluation, a physical system and its requirements must be decomposed and analyzed. The DSM is effective for improving a

48 process by capturing the information flows and identifying process iterations.

Using a Connectivity Map to relate the tasks of the process to the physical elements through the functional requirements determines the causes and types of iteration. This additional information is required to determine a systems engineering approach, product architecture and evaluation criteria. This also measures their coordination and identifies efficiency and performance improvements. A procedure for creating a Connectivity Map and its analysis is detailed in the next chapter.

49 5. System Engineering and Process Evaluation

The development process must be coordinated with the physical system and its functional requirements. By decomposing each perspective of the system and analyzing them together their coordination can be evaluated. Process decomposition results in tasks that are defined by the existing procedures and deliverables. The physical system decomposition is concept specific and often aligned with the organizational structure and product architecture.

Decomposition of the functional requirements is along performance and need criteria. A Connectivity Map presents in one array the relationships between the process steps, the functional requirements addressed by each step, and the physical components that participate in delivering those requirements. It is an approach presented in this chapter for identifying the system architecture type, and causes and types of process iteration.

A. System Types and Evaluation

A system is defined as a combination of elements, such that together they achieve more than what is possible for them individually. A systems approach

"focuses on the system as a whole, particularly when making value judgements

(what is required) and design decisions (what is feasible)" [3]. Elements can be part of a process, product or function, and when combined, can form either a system or sub-system. The relationships between the elements and the

50 definitions of their boundaries determine the system's architecture as modular,

integral or a hybrid of the two.

Modular Architecture [8

* Elements provide one or a few functions in their entirety

" Interactions between elements and their boundaries are well defined

Integral Architecture [81

* Functions require the integration of multiple elements

* A single element provides multiple functions

" Interactions and boundaries of elements are not clearly defined.

For design problems, the development process, physical system (concept based)

and functional requirements can be decomposed early on and in parallel.

Evaluating the decomposition from these multiple perspectives, individually as well as together, captures an understanding of system level behaviors and

element interactions so that coordination can be measured and achieved

between the development process, physical system and functional requirements.

1. Process decomposition - identification of tasks that encompass the process

to determine what is done, when it is done and who does it. Evaluated using

the Design Structure Matrix approach to determine task relationships and an

efficient ordering. Primary objective is to reduce iterations by accounting for

information flows in the ordering of tasks.

2. Form decomposition - physical decomposition of the system to its basic

components. Hierarchical evaluation is architecture concept-specific and

51 used to determine complexity of components and sub-system interfaces. A

prerequisite for the detailed design phase.

3. Functional decomposition - partitioning of system and sub-system

requirements to determine the relationship between physical elements and

functional requirements. Functional requirements are design-neutral and

technology-independent, and allow for flexibility during product development

and design. A pre-determined concept (phase 2 of the product development

process) has a one-way mapping from function to form.

A holistic evaluation of the above decompositions and their relationships can be used to select and develop a system engineering approach. The desired approach must be developed to optimize system level attributes, while at the same time, satisfying sub-system constraints and accounting for organizational structure and information flows.

B. Level of Decomposition

As a system is decomposed, the level of abstraction decreases. To compare various perspectives of a system, a consistent level of abstraction must be obtained. In an effort to determine the actual relationships, decomposition should occur at the lowest level that participants in the process make a decision regarding a consistent metric, established components or process concept. The following are three decomposition heuristics that should be followed [3]:

1. Choose elements so that they are as independent as possible.

52 2. Elements should have high internal cohesion and low external complexity.

3. Elements that are related should be grouped and those that are not should

be segregated.

Physical elements should be decomposed to a level that supports detailed design, and process decomposition needs to occur to a level that supports assigning organizational roles and responsibilities. Performance criteria that can be used to evaluate physical designs are an outcome of functional requirement decomposition. It is important to consider the organizational structure and competencies during partitioning so that identified actions can be implemented within the existing infrastructure or the necessary strategic actions are identified.

Functional and form decompositions result in a tree structure with connections that represent boundaries and interfaces, whereas process decomposition results in a flow chart with interactions between the elements representing information flows and dependencies. The number of connections between elements and the number of elements are measures of a decomposition's complexity. A classical tree's hierarchy complexity is the number of elements, and its flexibility is the unique connections between layers. The real world problem with systems engineering is that physical components provide multiple functions for multiple sub-systems and this is not always adequately captured in a physical system decomposition. If the physical system and process are partitioned and are completely de-coupled, parameters that support axiomatic

53 design will be identified. Since organization and communication problems commonly cause interactions this further hinders system level optimization.

C. Connectivity Map

A connectivity map relates the development process to the physical product through the functional requirements. It is a matrix model; with one axis being the tasks that comprise the process and the other axis being the components that aggregate to form the physical system. Where the process and product interact to fulfill requirements, the functional requirements are represented by a functional requirement element at the intersection of the row and column (Figure 13). In a completely de-coupled process with an axiomatic design solution, there will only be one item in each row and in each column. Ideally, if the process can be conducted in a manner so that the tasks can be performed either in parallel or sequentially, all of the relationships will be contained along the diagonal of the map.

Physical Elements

Functional Requirements (Process and Physical Links)

L

Figure 13 - Generic Connectivity Map

Prior to creating a connectivity map, a DSM evaluation of the process should occur to identify opportunities for improvement (ordering and elimination of

54 tasks). The independently optimized process is one axis of the map, with the individual tasks being represented by individual rows. One focus of the map is to determine if each task of the process is value-added and satisfies a functional requirement, either partially or completely. The physical system is evaluated to determine its value based on its relations to functional requirements. If tasks or components are identified that cannot be related to a functional requirement, they should be investigated with respect to related systems to determine if they are non-value added and, therefore, can be eliminated. The tasks should be evaluated to determine if they are an integral part of the process for delivering the functional requirements or can be conducted outside of the process, potentially coordinated to a corporate initiative or in coordination with another process.

Table 5 provides metrics for a comprehensive evaluation of the complete system perspectives in order to create an appropriate organizational structure, development process and tool set that result in system level optimization through an efficient and effective process. In addition to these metrics the physical system and functional requirements should be evaluated for complexity. Similar to the DSM, the connectivity map identifies appropriate strategic improvement actions. Ultimately, the process and physical system will be coordinated, permitting optimization of the functional requirements with an efficient use of resources and compatibility with the infrastructure. Understanding the relationships between the functional requirements and the physical components identifies corrective actions when needed and requirements for re-design.

55 Characteristic Metric Implication (less is better) Component requires Number of cells in an Requires process multiple tasks to element's column that management and complete detailed design demonstrate relationship verification to insure between physical system coordination and and development compliance, high process likelihood process is iterative One physical element Number of functional Integral product satisfies multiple requirements in a column architecture requirements Functional requirement Number of times System level dependent on multiple functional requirement performance is physical components appears in model in dependent on multiple different columns components Multiple tasks and Number of process and Highly coupled process components required to product interactions and product design satisfy functional required to fulfill requirement functional requirement Task does not interact Row of matrix is blank Task is not required for with physical system the process to be completed or it can occur outside of the process Physical component does Column of matrix is blank Either element is not not satisfy a functional needed or provides a requirement, partially or function as part of completely another system

Table 5 - Connectivity Map Metrics

56 D. Safety Belt Application

Figure 14 depicts a decomposition of the physical safety belt system. The number classification for an element identifies the grouping and level of abstraction. The elements at the lowest level are those defined as a part of the

______yF_ - Attachment 1.1.1.1 Underbody 1.1.1 1 _ Panel 1.1.1.2 Body Structure 1.1 BodyShell Attachment 1.1.2.1 _ 1BodyShell _ 1.1.2 _ Panel 1.1.2.2

Mechanisms Track 1.2.1.1 1.2.1 Recliner 1.2.1.2

Upho__s__ry Foam 1.2.2.1

1.2.2 T Fabric 1.2.2.2 Seat Assembly Safety-Belt System 1.2 1.0 F ~Frame 1.2.3.1

Seat Attachments Structure 1.2.3.2 1.2.3 Restraint Attachments 1.2.3.3

Buckle Mechanism 1.3.2.1 1.3.1 Restraint Attachment 1.3.2.2 - Assembly Retractor 1.3 1.3.2 Anti-Rotation D-Ring Feature 1.3.2.3 1.3.3 _tWebbing 1.3.2.4 Figure 14 - Physical System Decomposition

57 detailed design phase. One example is for the Underbody (1.1.1) Attachment

(1.1.1.1) that requires an attachment type, along with the required physical

attributes (e.g. hole shape and size) that are determined as a part of the detailed

design. The physical decomposition is unique to the concept and components that define the system, with the level of abstraction being representative of the organization structure, and roles and responsibilities.

Figure 15 illustrates a functional requirements decomposition for the same system. Here, the elements represent evaluation criteria that can be used to evaluate a physical system's and sub-system's performance. Based on the

requirements, detailed designs and concepts can be analyzed and optimized.

The physical and functional decompositions for this system have a flexibility of 1

(unique connections between the layers). If a higher level system was evaluated that included mating sub-systems, this number would be higher. The complexity for these decomposition is the number of elements, 27 for the physical system and 15 for the functional requirements.

Since the DSM methodology was already applied to improve the process, only the new process is represented in the mapping. The process decomposition is from the process DSM that was presented in Chapter 4. It contains 15 tasks that are required to design and develop a safety belt system.

58 Elastically A.A.A Absorb Energy A.A Plastically A.A.B

Re-Direct Energy . A.B.A

Retain Occupant Convert Energy A.B -=1A.B.B Accommodate Seating Protect an Occupant A.B.C A =4 Vehicle Acceleration A.C.A Sense an Event A.C Webbing Acceleration A.C.B

Package A.D.A

Compatibility Comfort A.D A.D.B

.4 Regulatory A.D.C

Figure 15 - Functional Decc mposition

The call outs in the cells of the connectivity map represent the elements of the functional requirements that relate the process to the physical system. A blank cell means that column's physical element is independent of that row's task.

Where multiple functional requirements are called out, the task is providing and/or manipulating information for that component that is intended to support multiple requirements. Figure 16 is the connectivity map for this application.

59 -A :ZL :- K) A, .. '

Define Seating A.B.C A.B.C A.B.C Hardpoints A.D.B A.D.B A.D.B

A.B.C A.B.C Determine Seat Travel A.D.B A.D.B

Define Allowable A.D.CA.B.C A.B.C A.D.C A.D.C A.D.C A.D.C A.D.C Anchorage Locations A.D.C A.D.C

Safety Belt Product A.D.C A.D.C A.D.C A.D.C A.B.A A.B.A A.C.A A.B.A A.D.C 0 Assumptions A.C.B m Specify Market Availability Determine Applicable Safety Belt Regulations

0) 0 Interpret Regulations

0 Style and Develop A.D.B A.D.B A.D.B A.D.A o Exterior of Seat A.D.C

M Determine Anchorage A.B.C A.B.C A.B.C A.B.C A.D.C A.D.C A.D.C A.D.C A.D.C A.D.C Points A.D.C A.D.C A.D.B A.D.B

Package Safety Belt A.D.A A.D.A A.D.A A.D.C A.D.A Sub-System A.D.C A.D.C

A Comfort Considerations A.D.A A.B.C A.C.B A.B.C A.D.B 0 and Evaluations Determine Assembly A.D.A A.D.A A.D.A A.D.A A.D.A A.D.A Process

CAE Performance A.A.B A.A.B A.A.B A.B.A A.B.A A.B.A Evaluations

Safety System A.A.A A.A.A A.B.A A.B.A A.B.B A.B.A Development A.A.B A.A.B

Prototype Build A.D.A A.D.A A.D.A A.D.A A.D.A Evaluations As a result of the physical components of the safety belt sub-system fulfilling

multiple requirements the connectivity map reveals a coupled product

architecture. The following is an example of how to analyze the connectivity map

for a task, the elements it affects and the functional requirements that are used to

evaluate the design.

The Determine Seat Travel task is partially responsible for the detailed design

of the Track and Recliner, and the designs must satisfy the Accommodate

Seating and Comfort functional requirements.

Reviewing the process DSM, the task Determine Seat Travel is iterative because

of information requirements from the Define Seating Hardpoints task. This

implies that common physical elements, element boundaries, and/or functional

requirements are parts of these tasks. Table 6 summarizes the elements and

requirements for these tasks.

Task Physical Elements Functional Requirements 1.2.1.1 A.B.C Define Seating Hardpoints 1.2.1.2 A.D.B 1.2.2.1 1.2.1.1 A.B.C Determine Seat Travel 1.2.1.2 A.D.B

Table 6 - Tasks Physical Elements and Functional Requirements

For these tasks two of physical elements affected are common (i.e. Track and

Recliner) and need to satisfy the same functional requirements (i.e. Accommodate

Seating and Comfort). This application of the connectivity map qualified the

61 elements and requirements being shared between the tasks. Analyzing the third

task, Define Allowable Anchorage Locations, shows no iterations in the DSM.

The connectivity map has three common elements for this task with the preceding

tasks and one functional requirement. The common functional requirement is the

information being transferred from the tasks. Using the process DSM to identify

the iterative task relationships, the criteria in Table 7 can be used with the

Connectivity Map to analyze the causes and type of iteration.

Physical Components Functional Requirements Cause and Type of Iteration Common between tasks Common requirements Design refinement during

process, and/or

inconsistent evaluation for

performance attribute

Common between tasks Unique requirements Trade-off between

functions based on related

parameters of the physical

system

Unique components for Common requirements Integral architecture each task requiring coordination for

system level performance

Unique components Unique requirements Component interfaces each task interact to affect system

level attribute

Table 7 - Connectivity Map Metrics for Type and Cause of Iteration

62 The sharing of physical elements and functional requirements alone does not assure iteration; it can be a characteristic of the design's maturity and evolution during the process. The DSM identifies iteration because it accounts for the flows of information between tasks (i.e. form requirements, functional requirements and process requirements) and the Connectivity Map identifies the type and cause by relating the process to the physical system through the functional requirements.

The seat assembly fabric is the only physical element that is affected by one functional requirement (Comfort) and one task (Style and Develop Exterior of

Seat) which implies a modular engineering single attribute optimization approach.

This methodology also identified that the following tasks do not satisfy a functional requirement of the physical system:

* Specify Market Availability Program

" Determine Applicable Safety Belt Regulations

" Interpret Regulations

These tasks are strategic management process requirements that can be instituted outside of the development process and are best performed by a single organization. Understanding an element's requirements is a pre-requisite to detailed design and has an impact on the efficiency and effectiveness of the process and organizational structure.

63 An electronic catalog can contain models of the potential physical components of a system. In addition, constraints for the components and their interfaces can be defined parametrically and also captured in a catalog. The selection design approach can utilize a catalog to facilitate concurrent design, re-use, complexity reductions and dissemination of best practices. A catalog development process and its application to the safety belt case study are presented in the next chapter.

64 6. Electronic Catalog Initiative

Evaluating the safety belt design and development process using the DSM methodology revealed the original process was an inefficient generate-and- evaluate method with many iterations and information exchanges between organizations. In-depth analysis identified the evaluation tasks, who conducted them and what information was required to perform them, revealing the opportunity for an electronic catalog of parametric constraints and generic parts.

The implementation of the new process utilizes this catalog to define sub-system boundaries, allow concurrent sub-system design and support system level optimization. Capturing the information flows of each task also identified the appropriate parametrics to define the constraints and generic parts. The Seats and Restraints Catalog presented in this chapter supports the improved process captured in the DSM.

A. Catalog Concept

Information that is common between programs, shared between organizations or that can be defined generically using parametrics is suited for an electronic catalog. The underlying motivations for creating a catalog are the sharing of information, facilitating a selection process and eliminating the need for duplication or re-creation of effort. When a catalog is accessible by all of the involved design activities and they are using compatible design systems, work that is created by one organization can be used by the others. A few of the early

65 applications of electronic design catalogs at Ford include standard parts (e.g. fasteners, pushpins and plugs) and power tools (e.g. design aids for body structure development). Users of the catalogs include Ford's design and packaging departments and an array of full service suppliers. This approach for sharing and distributing information creates a broad range of users, consistent form and format of information, and a single source of ownership. Additionally, a catalog of standard and generic parts can be used for reducing complexity by restricting available items to the program teams and prohibiting the incorporation of new items. Along with insuring higher quality consistent designs, having generic part geometry and constraints available in a catalog reduces the required design and compliance verification time.

B. Catalog Hierarchy

The initial phase of creating the catalog includes developing its hierarchy based on its intended users, physical system decomposition and organizational structure. A module of the catalog hierarchy can be a child of a module above it and a parent to a module below it (e.g. Seat Belts is a child of Seats and

Restraints and a parent to Generic Parts). As the hierarchy is stepped down so is the level of abstraction for the items that comprise that module. Figure 17 presents a high level generic hierarchy for the Seats and Restraints sub-system catalog. The Seat Belt branch of the catalog contains the catalog items for the

Restraint Assembly physical elements presented as part of the physical system

66 decomposition in Figure 14 and the Compatibility functional requirements from the functional decomposition in Figure 15.

Along with the hierarchy, the searchable and definable attributes need to be determined for each type of item that will be placed in the catalog. Attributes need to be selected that have values that can be assigned to each item that will differentiate it from other items in the same category of the catalog. Proper attribute selection can be used to communicate requirements or applicable information by prompting the user for values of what determines the applicability of a requirement. For the restraints regulatory zones, the search attributes were created so that if a user puts in the level of information required to generate the compliance file names and numbers (e.g. market availability, seat type and

Seats and Restraints

I Design Front Seat Belts Sensors Side Steering Wheel Aids Airbags Airbags Components

Child Generic Generic Generic Generic Generic Seats Parts Parts Parts Parts Parts

Test Parametric _ Parametric Parametric Parametric _ Parametric Fixtures Reqmts Reqmts Reqmts Reqmts Reqmts

Group 1 - Group 1 - Group 1 Group 1 Group 1

Group 2 Group 2 Group 2 Group 2 Group 2

Group 3 Group 3 Group 3 Group 3 Group 3

Figure 17 - Generic Sub-System Catalog Hierarchy

67 anchorage type), the applicable regulatory zones would be displayed. If a user

down selects through the catalog hierarchy manually certain attribute values are

assumed. For example, if a user selected Regulatory Zone and then North

America, the value assigned to market is automatically North America. These

attributes are based on the information required to determine what regulations

apply (i.e. Market) and the appropriate interpretation (i.e. seat and anchor type).

The hierarchy must be developed with the target users in mind in order to assure that information flows in a way that is anticipated by the users. In the case of the

Seats and Restraints catalog, users were assumed to be designers, engineers and full service suppliers based on typical organization interactions with the original compliance demonstration process. During the initial development of the catalog, the needs of individuals from the analysis group were not considered because this group did not traditionally interact with the design department.

Shortly after the catalog became available, engineers requested child seat fixtures for finite element analysis. Child seat fixtures are required for finite element models that are used to evaluate structural performance. To support this need additional annotation was added to the design aids communicating test load application points. The catalog hierarchy was also modified to group design aids along functional requirements.

68 C. Catalog Item Life Cycle

Three phases characterize a catalog item's life cycle:

* Creation,

" Use and application, and

" Modification and maintenance.

Figure 18 outlines the steps in each phase of a catalog item's life cycle. Steps 1

through 4, the creation phase, are required to create the item's geometry and to

archive it so it can become a catalog item. All catalog geometry must be created

adhering to pre-defined modeling standards to insure a consistent format and

user interface. The applicable attributes for the item must be assigned to each

item individually so the search algorithm will locate the item based on a user's

specified search criteria. Steps 5 through 10 detail how to change an existing

item's geometry and return it to the catalog in the event that changes are

required. The new item can either replace the previous version or create a new

one. Steps A through G explain what potential users of a catalog item must do to

search, retrieve and manipulate an item from the catalog. These steps are

necessary for each use and application of a catalog item. Since the part

geometry contains part location information, if an application re-orients a part, it

must be saved under a new part number because it is now a unique instance of the catalog item. To assure that each individual instance is not placed in the

catalog, archiving privileges for the catalog vault are restricted to catalog authors.

69 Step #1 LCreate an I-DEAS Item Step #2 Check Item into TDM Generic Zone Creation

Step #3 Check Item into Metaphase

r Step #4 Classify Item in Catalog

* I Step #5 Step A Check out of Metaphase to Modify (Search Applicable Catalog J4-

Step B Step #6 Retrieve Applicable Item to Check Item out of TDM

Step C Bring Item to Workbench C Step #7 U) Make Required Modifications CD a) 0 Step D a. Extract Item Vu Step #8 Check Item into TIDM a) Step E P. 0 Put Catalog Item Away 0 Step #9 Check Item into Metaphase Step F 4.. LModify Instance as Needed ] Step #10 Re-Classify Step G Item in Catalog 4- Save as a Unique Item

Figure 18 - Generic Restraint Zone Life Cycle

70 D. Safety Belt Application

The safety belt catalog parts and parametric constraints, which are a part of the

Seats and Restraints catalog at Ford, utilize the C3P tool set. To assure items

have an acceptable format, as determined by the users, examples of each category of item that were to be placed in the catalog were sent to the

prospective users for review and input. Additional considerations were given for the fact that, in some cases, demonstrating compliance requires providing

hardcopy evidence. For this reason, reviews were conducted electronically and

using hard copies. Based on the prospective users' feedback, a format was

selected and a catalog geometry creation method was developed. Methods such

as this one, for design best practices and procedures, are published on the Ford

Intranet on a common web site to insure that they are available to all potential

users. When the method was published in draft form, an e-mail was sent to all

the lead users informing them that it is available. They were asked to review it

and to provide feedback. The method contains the following information:

* Purpose * Key Inputs/Assumptions * Deliverables * Exclusions * Procedure * Usability * Key Tool/Process Improvement * Definitions * Related References/Documents * Records of Revisions

71 0 Keyword Search Index.

Examples of form and format decisions that were made as a part of this process

include:

1. Consistent format and adherence to Ford's drafting standards

" Minimize required training of users

" Insure compatibility with existing model files

2. Annotation and call outs for each regulatory zone consistent with the

regulation

" Final documentation requirements will be satisfied without requiring

changes in terminology

* Variable names consistent for all requirements per market.

3. Geometry would be designed at body 0, 0, 0 with the master coordinate

system named Body CSYS

" Unique application of an item requires translation and re-orientation from

0,0, 0

" Reference point common with vehicle package information

4. Seat package parameters would be named as required by the regulation

* If regulation is dependent on seat at nominal position, parameter would be

named SgRP; if regulation is dependent on seat travel, parameter is

named H-point

5. Consistent order of steps for creating catalog geometry

* Common history tree format to facilitate user required/desired modifications

6. URL address of the applicable regulation is a hypertext link on each zone

72 In the event additional information is needed about the zones definition

and/or the applicability of the regulation

After an item is created, it must be stored where it can be accessed by the catalog's search algorithm. With the current data management systems at Ford, this is a two step process:

1. Stored in a local Team Data Manager (TDM) (Figure 19)

2. Transferred to the catalog vault in Metaphase (Figure 20).

For security reasons and data management issues, there is a unique catalog vault within Metaphase that is not a part of a vehicle program. Only catalog authors (designers with write privileges) can store items in this part of

Metaphase. After the item has been completely checked in, it can be classified.

This requires someone with classifier permissions. Classifying an item requires specifying the category of the catalog of which the item is a part of and assigning the appropriate values for the applicable attributes. The North American lower anchorage zone is placed in the NA Lower Anchorages Zones branch of the

Regulatory Zones category of the catalog. As applicable, the seat and anchorage type to which it applies is assigned. These data management security measures are needed in order to assure that a user does not have the ability to change an item or an item's attribute properties without proper knowledge and training.

73 Figure 19 - Item Check-In to TDM

Figure 20 - Item Check-In to Catalog Vault of Metaphase

74 The use and application of an item from the catalog is also a two-step process.

The first step involves searching and retrieving the appropriate item from the catalog based on the user specifying known values for the applicable attributes

(Figures 21 and 22).

Figure 21 - Seats and Restraints Catalog Hierarchy

75 Figure 22 - Catalog Search Results The next step is extracting the item to make it a unique instance for that user's

application. Creating a unique instance is required because a user cannot

manipulate a catalog item because the item is generic for multiple applications.

After the unique instance has been created, a user can make the required

changes (e.g. in the case of a restraint zone, specifying the seat package and

program information) and automatically update the entire geometry. Figure 23

depicts an example of the North American Upper Anchorage zone modified as

required by the M205 program.

76 E.AEEEPTANI.E

-AEENCEL

CCEPTABLE

- E- - - -

UPP NA ER ZN Z NZ Z

N*OEGT AEAG

SEAT LOCATION FRONT PASSENGER

Figure 23 -Upper Anchorage Zone for M205 Program

An additional method was created detailing how to use and apply items from a catalog. This procedure is available from the full service supplier and internal web sites because users of the catalog will be from both types of organizations.

Changes in a regulation, its interpretation or corrections can precipitate a need for a catalog item to be updated. To incorporate these changes, a catalog author must check the item out of Metaphase to modify it, make the necessary changes

(adhering to the established method), check the item back into the TDM and Metaphase, and finally re-classify the item in the catalog. The catalog tool does

77 not automatically reference the latest revision of a part. If the modifications to an item make the previous revision obsolete, it needs to be deleted from the catalog.

E. Parametric Constraints

For the regulatory zones, the parametric relationships are based on the applicable seat package information. A user simply revises the applicable seating reference points (i.e. h-point x, y and z coordinates and seat back angle) and a feasible location envelope is developed. Early in the process, this envelope can be used to specify acceptable locations for the affected activities.

System level performance attributes can use this envelope as an acceptable boundary, while optimizing system level performance attributes such as safety and comfort. During the process, these same files can be used to verify the impact of changes on regulatory compliance (i.e. sensitivity analysis).

F. Item Naming and Numbering Convention

One issue identified during implementation of the catalog was the numbering and naming convention used to identify catalog items. The conflict arose because the data manager software will only allow parts with names and numbers that meet the standard Ford part numbering and naming convention. The conflict arises in the Seats and Restraints catalog because the majority of the items are geometry, not parts, and it was not desirable to select a naming and number convention that conflicts with a current or potential future program. To address this concern, the standard naming convention was examined and a combination

78 of identifiers was selected that is currently not possible because the represented

organizations do not interact but the part pre-fix still satisfies the standards. The following details the generic naming and numbering convention.

Generic Cataloq Item Numbering/Naming: " Part name will be descriptive and specify timing if applicable * Generic Item Numbering: * ZU5A - 012000- Up to 8 Characters t-Suffix: Determines information type, market and identifier Base: Restraints CPSC Prefix: Generic (independent of program)

Item Suffix Decomposition: * See file coding for suffix information for program specific instances: * 7N 1 Identifier (numbered consecutively) Market identification for zones (N = North America, E = Europe, A = Australia) Z for a zone, D for design aid, G for generic part

When a program creates a unique instance of an item, it must modify the part

number so that the item can be stored and not conflict with the catalog item. The

method that details how to use a catalog item specifies the procedure of how to

change the item suffix based on that unique application.

G. Launching the Catalog

Communicating the availability and applications of the catalog is also an

important step. In parallel with developing the methods on how to create catalog

items, a method on how to use these items was developed, and multiple design

activities tested it. To help promote the catalog's use, full service suppliers were

invited to use it and to suggest what it should contain. Supervisors were

79 provided with hard copies of examples of the contents of the catalog to be shared

with their organizations. In cases where a program was being designed in

PDGS, the zones were created in I-DEAS and translated into PDGS in order to

gain experience using the catalog and to insure that as many potential users as

possible were exposed to it.

In order to insure that the catalog items are kept current, champions from each

organization (design, engineering and the safety office) have been identified.

These individuals must approve the addition of any new items to the catalog,

modifications to existing items, additional attributes and hierarchy changes.

H. Additional Potential Applications

Other applications being pursued for the catalog concept include additional design aids (ergonomic aids and customer usage items), generic parts (after

market accessories), sub-system interfaces, labels and generic section geometry. The majority of these applications will support corporate-wide complexity reductions and dissemination of best practices. The primary purpose of the generic parts and system interfaces are to promote concurrent design.

When an organization designs within a generic part envelope and system interface requirements the mating components' designs can proceed without the need for sharing data, communication or concurrence.

A limitation of the catalog approach involves the need for consistent terminology in attribute definition, and item differentiation, so that a user can retrieve desired

80 and acceptable items. To help gain acceptance the catalog hierarchy needs to be aligned with the anticipated users' needs to control the amount of specified attributes and the potential items that match the selection criteria. Catalog maintenance requires discipline to assure that only the latest and most accurate information is in the catalog and that there is an approval process for changing and adding items. Figure 24 portrays a high level overview of a generic catalog development and implementation process.

Identification of Shared and/or Common Data * Corporate wide initiatives 0 Dissemination of best practices

Develop Catalog Hierarchy * Identification, organization and responsibility of potential users * System and organization decomposition

Determine Attributes for Each Family of Catalog Items 0 Differentiation of items in user terminology L Capture knowledge of applicability of requirements

Organizational Responsibilities 0 Ownership of catalog geometry o Classifier permissions 0 Approval for modifying, deleting and adding items to the catalog

Develop Modeling Standard for Catalog Items " Compatibility with existing files " Consistent variable names and terminology

Launch Catalog 0 Communicate availability to potential users 0 Maintenance plan in place

Figure 24 - Generic Catalog Development Process

81 7. Conclusion

Problems exist with approaching all system engineering opportunities with a standardized process. All components of a system are members of multiple sub- systems and provide multiple functions, while the process often overlooks and does not signify the importance of sub-system interfaces. Ideally, de-coupling a system would permit a separation of parameters to allow detailed independent design. But realistically, system attributes and organization and communication problems exist within the process. An effective and efficient system engineering approach accounts for the product architecture type, the type of design problem, the development process, and information flows and organizational structure.

The DSM methodology is an objective approach to evaluating a process in an effort to reduce iteration by optimizing the order of tasks. In the case where tasks cannot be de-coupled, the DSM can be evaluated to determine strategic changes that would improve the process. Identification of information flows and organizational interactions that are used to evaluate the process are also a resource for assignment of roles and responsibilities, organizational structure, and infrastructure requirements. This model is also an effective communication tool that can be used as a project management aid.

Through comprehensive evaluation, a design process can be developed that couples system and sub-system design to occur concurrently based on applying

82 sub-system constraints to define boundaries for system level optimization. This is preferred over the traditional component level verification and optimization approach. An electronic catalog of parametric constraints is an example of a tool that supports this type of process. By defining the constraints with parameters that are defined early in the process, mating sub-systems can be designed concurrently. Cataloging requirements also captures knowledge and promotes single source ownership of data. Today's competitive environment requires manufacturers integrate their resources with their suppliers. A catalog selection design approach supports this and is beneficial for both parties to develop core competencies and leverage economies of scale.

To support process and product re-engineering, clear deliverables and responsibilities are required, both organizationally and functionally. The deliverables need to include what is required, when it is required and in what format. This information is required of, and for, each organization and sub- system so that an integrated development process can be executed that will result in system level optimization. A connectivity map combines these types of information; for the physical system, functional requirements and development process, for evaluation. This approach evaluates coordination and qualifies the relationships between the components. A framework for doing this is displayed in Figure 25.

83 Decompose the System Functionally and Physically: * Identify system architecture type. * Assure physical system will accommodate functional requirements. * Determine performance criteria type.

Map Functional Requirements to Components and Process: " Qualify importance and value of tasks and physical components. * Cascade system level requirements to physical components. " Identify appropriate process management practices.

Evaluate and Improve Process using the Design Structure Matrix Methodology: * Identify information flows and organizational interactions. * Re-order the process to reduce potential iterations. " Coordinate roles and responsibilities of organizations. e Identify strategic actions to reduce iteration.

Figure 25 - Process and Product Re-Engineering Framework

Applying the methods presented in this thesis to the safety belt design and development case study reduced the staffing requirements 90% and allows the system to be optimized for performance attributes directly related to customer needs. Having this holistic understanding of the components; physically, functionally and of the process also benefits the implementation of new technology and architectural changes. With the lessons learned from this project additional applications of the methodology are being pursued at Ford with similar anticipated benefits.

84 8. References

1. N. Senin, D. Wallace and N. Borland. "Mixed continuous and discrete catalog- based design modeling and optimization," NSF CIPD Conference Proceedings, 1999.

2. D. Ullman. The Mechanical Design Process, McGraw-Hill, Inc., 1992.

3. E. Rechtin and M. Maier. The Art of Systems Architecting, CRC Press LLC, 1997.

4. N. Senin, D. Wallace, N. Borland and M. Jakiela. "A framework for mixed parametric and catalog-based design problem modeling and optimization," NSF CIPD Technical Report, 1997.

5. S. Eppinger, D. Whitney, R. Smith and D. Gebala. "A Model-Based Method for Organizing Tasks in Product Development," Research in Engineering Design, 1994, pp. 1 - 13.

6. L. Thompson. The Mind and Heart of the Negotiator, Prentice-Hall, Inc., 1998.

7. D. Winter. "C3P: new acronym signals big change at Ford", Vol. 32, Ward's Auto World, 08-01-1996, p. 34.

8. K. Ulrich and S. Eppinger. Product Design and Development, McGraw-Hill, Inc., 1995.

85