INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001
DESIGN COMMUNICATION USING A VARIATION OF THE DESIGN STRUCTURE MATRIX J. C. Lockledge and F. A. Salustri Keywords: concurrent engineering, automotive engineering, design information management, workflow management.
1
Introduction
As reported in earlier work[ 1], the authors have constructed a mechanism for structuring design communications at a leading American automobile maker using a variation of the Design Structure Matrix (DSM). This paper provides a formal process to create similar matrices and outlines a mechanism for keeping participants updated on the design status. The original work was carried out in collaboration with, and implemented at, a major American automobile manufacturer. The new work reported herein is a prototype which has as yet to be implemented in an industrial setting. Many major industries base their design organizations on teams of design engineers (DEs). The use of team-based engineering practices can substantially improve the effectiveness of design processes, but they also introduce new complexities in terms of communications between team members and management of tasks carried out by the teams. This is particularly true in major industries, like the automotive industry. Thus, while modern design practices have improved the nature of the products being developed, they have also increased the administrative and management burden arising from increased complexity; what is gained in one respect can be easily lost in the other. Because these complexities are not product complexities but, rather, complexities of design and designing, they were not immediately recognized as important performance issues. Recently, however, more and more interest has been shown in North America to seek a deeper understanding of the complexities of modern design as they arise largely from these issues of communications and task management. The authors are developing a means of managing the design process to ensure appropriate communication between design team members is facilitated, that task management is streamlined, and that all this can be done without placing further burdens on the designers. Different enterprises choose different strategies to achieve these goals. One leading automobile manufacturer chose the strategy of re-defining its design process. While the car manufacturer currently designs world class engines, they felt a need to reduce their time to market. As part of this overall effort, they identified their engine design process as one for examination and improvement. The authors undertook to assist the company by developing a tool to help the company's design engineers manage engine design information more efficiently and reduce the initial design time. We focused on the following stages of the process: the initial steps in identifying
a desired engine to be designed (needs analysis), coordinating the initial design (conceptual design), and the day-to-day design process (design information flow). In particular, the authors noted that information regarding design changes was propagated wholesale to all DEs. This forced DEs to spend valuable time deciding if a particular design change affected the components or systems for which they were responsible. The authors conducted interviews with many DEs involved in engine design at the auto maker. Based on analysis of these interviews and background research into the company’s practices, the authors concluded that a successful tool would have to be extremely flexible to respond to mid-program changes in design priorities and objectives. The tool also had to be very simple to use so as not to burden the DEs further with extra work. Our solution was a variation of Steward’s Design Structure Matrix (DSM)[2]. The DSM was chosen for of its simplicity of presentation and of construction. It essentially allows designers to capture the relationships between structural elements, systems, subsystems, etc. of a product in an easily understood matrix form. Once in this form, various manipulations can be performed on the matrix to discover features of the design, such a clusters of very high interaction between product components. The analogy between simple matrix operations, which all engineers understand, and design information management make the DSM quite a useful tool. The authors modified the DSM in two ways. First, we distinguished between the physical components of an automobile engine (listing them on one axis) from the functional systems and subsystems of the engine (listing them on the other axis). Identifying interactions in the modified matrix now results in identifying the functional dependencies of the structural components. By linking structure and function in this way, the matrix was used to identify the stakeholders that needed to be notified of design changes or decisions. Put another way, DEs whose tasks or designs are not affected by a design change will not be informed of the change. This means that change information is more efficiently managed. The second modification was to build a secondary matrix above the first one to cover interactions between components and manufacturing processes. In this way, interactions between components and the systems needed to manufacture them can be made explicit. This extends the chain of interactions all the way from the functional systems, through physical components, to fabrication. Any change to one can be propagated to only those stakeholders in related aspects who need to know about the change. The authors refer to the resulting matrix structure, as shown in Figure 1, as the Design Process Matrix (DPM). With these changes in place, the modified DSM now represented a tool to help manage the design process: the interactions shown by the DPM are indicative of causal relations between systems, components, and manufacturing. For each of these, stakeholders can be identified. Therefore, the DPM is a model of the interrelationships between tasks as well as a model of the required interactions between stakeholders needed to carry out the design tasks. The researched sketched above was received by the automaker and integrated into their overall technical process. However, it was empirical and derived largely from the particular characteristics of the automaker’s enterprise and corporate structure. The authors believe that a generalization of the DPM to a broader category of design enterprise could be very beneficial. In order to perform this generalization, a deeper understanding of the process of DPM construction is needed. This paper lays the foundations for such a generalization.
2
Approach to Constructing the Matrix
The purpose of this process is to create a Design Structure Matrix analogue that can be used for automating communication in a complex design environment. This environment owes its existence to the design of a product (or group of products) that will be produced by the organization. To warrant using this process, the product is expected to be complex enough to have multiple functions and several components that must be manufactured. As pointed out by Hubka and Eder 3 , the design intent (which are goals within specific constraints) is met by a series of functional systems. Each system exists by being embodied in one or more components (or more precisely organs). These components interact with each other, producing the desired effects through their functional systems. Within an organization individuals or teams (although typically a single individual) are assigned responsibility for releasing a component for production. As originally pointed out by Steward 4 , the underlying component interaction can therefore be used to model the required interaction of those responsible for designing them. This process allows an Engineering Manager to create a mechanism that takes advantage of these underlying principles to route messages to the proper individuals in a design enterprise. The process is broken into 5 steps: • Constructing a Hierarchical, Component Based DSM • Constructing a Hierarchical, System Based DSM • Constructing a Human Role to Component Mapping • Adding Process Based Communication • Constructing the Communication Matrix • These steps will be defined in detail in the following sections.
2.1 Constructing a Hierarchical, Component Based DSM The construction of a Component DSM (CDSM) has been discussed in detail by Eppinger[5]. In general, the first task is collecting the relevant component names and determining which components define others. Rules for the construction of hierarchical, component DSMs has been delineated by Sabbaghian[ 6] in his work with Boeing. He points out that in constructing a DSM that has components and sub-components, any interaction between sub-components from different components implies an interaction between the components they belong to. This is illustrated in Table 1 by the interaction between the Connecting Rod and the Piston that causes the interaction with the Piston Assembly. Interactions between sub-components both belonging to a single component do not affect the relationship of the component. This can be seen in the interaction between the Rocker Arm and the Intake and Exhaust Valves. These sub-components are all part of the valve train and therefore these relations do not influence other components. A hierarchical DSM permits a larger number of components to be addressed without overwhelming those who are indicating the relationships. A hierarchical DSM is necessary because the larger number of components (and sub-components) allows finer granularity of the relationships, and the granularity of the dependencies affects how specific the messages to users can be. It also affects the number of messages a user is likely to receive, since courser granularity implies that all of the people involved in a component will receive information on changes to any related component.
Piston Assembly
Valve Train Components
Connecting Rod
Table 1: Hierarchical Component DSM
Connecting Rod Valve Train Components
X
Exhaust Valve Intake Valve Rocker Arm
X
Piston Ring
Piston
Rocker Arm
Intake Valve
Exhaust Valve
Components
X
X
Piston Assembly Piston Piston Ring
2.2 Constructing a System Based DSM Constructing a System based DSM (SDSM) relies on first identifying the functional systems in the object being designed. The functional systems may also be modelled as being hierarchical in nature, for the same reasons given in the previous section. Table 2 shows some sample functional systems in relationship to each other. In this case, the Cooling system is shown as functionally related to both the Lubrication Delivery (in the case of an engine with an oil cooler) and Combustion Chamber systems.
Lubrication Delivery Return
X
Cooling Combustion Air Intake Exhaust Chamber
X
Chamber
Exhaust
Air Intake
Return
Delivery
Systems
Combustion
Cooling
Lubrication
Table 2: Hierarchical System DSM
2.3 Constructing a Human Role to Component/System Mapping In most design organizations, individuals are given final authority for releasing a component’s design. Since they are the only actors in the system that can affect the design, the system must interact with them, making them recipients of messages concerning design changes. For the system to do this, these roles must be identified and specified in the Role/Component Mapping (RCM) and the Role/System Mapping (RSM). Identifying these roles (and/or the individuals responsible for them) should be straight forward, as each of the sub-components must have an individual responsible for releasing it. Assigning an individual to an entire component implies that they are the responsible party for all of the sub-components. The individual assigned responsibility will then receive and need to respond to all of the messages concerning their sub-components. Individuals may also be assigned to the systems. These functional systems are not usually viewed as “released parts” so that this position takes on a monitoring role. The person assigned this role would be responsible for keeping individual DE aware of the implications to those systems of any design decisions.
2.4 Constructing the Communication Matrix. The third matrix, as illustrated in Table 3, is the DPM. This matrix ties together the functional systems and the components. It is constructed by assigning sub-components to functional systems. An assignment results from the system being embodied in the component and thus both defining it and being defined by it.
2.5 Adding Process Based Communication Not all of the individuals who are responsible for a product have design release responsibility. Some are involved in the later stages of manufacturing, distribution, marketing, and customer service. Concurrent engineering [7] discusses the need for these parties to be involved in the design process. During this step, individuals who should be aware of design changes, but who may not be central to the process, are added to the matrix. Additional roles are added to the matrix above the components, indicating their interest in those specific components. Messages will be routed to these parties as if they had release responsibility, but they are not required to respond to the changes unless they see an opportunity or problem.
3
Assisting Communication
These three matrices and two mappings are the starting point for the communication routing system. When a DE makes a change in their (sub-)component (which we’ll call M) the system will react by establishing the following sets: SM The systems of which M is part (from the DPM), CM The components that M affects (from the CDSM), SC The sys tems shared by M and components of C, and SSC The systems that interact with systems in SC (from the SDSM). Using the RCM messages can be routed to the individuals responsible for components in CM who will need to be aware of this change. The change can also be routed through the RSM to the monitors of the system in SM. The messages to DEs would contain a statement that M was
changing and which systems (SC) would likely be affected both directly and indirectly (from SSC). An example makes this somewhat complex process clearer. Suppose we had the CDSM, SDSM, and DPM shown in Table 4, Table 5, and Table 3. In this case, the components are not given hierarchically to conserve space. If a DE made a change in the Crankshaft, we would know from Table 3 that the Lubrication Delivery System and Power Conversion systems would be affected and that Manufacturing would like to be kept aware of any changes.
X
X
Valve Train
Valve Cover
X
X X
X X
X
X X
X X
Crankshaft
X
Connecting Rod
X
Head
X
Block
Manufacturing X
Process
X
Piston
Table 3: Example Design Process Matrix (DPM)
X
X
X
X
Lubrication Delivery Return Combustion Intake Exhaust Fuel Delivery Chamber Cooling Power Conversion
X
X
X X
X X
X
X
X
Turn our attention to Table 4 we can determine that the Crankshaft directly affects the Block and Connecting Rods. By going back to Table 3 we see that these components share the Lubrication Delivery System and Power Conversion systems.
X X
X
Crankshaft
X X X
X X
Connecting Rod
X X
Valve Cover
X
Valve Train
Head
Piston Block Head Valve Train Valve Cover Connecting Rod Crankshaft
Block
Component
Piston
Table 4: Example Component DSM (CDSM)
X X
X
X
X X
X
Further, by going to the SDSM (Table 5) we can find that the Lubrication Delivery system also interacts with the Lubrication Return system and that Power Conversion interacts with the Combustion Chamber.
Cooling Power Conversion Exhaust
Fuel Delivery
Intake
Return
Delivery
System
X
X
Chamber
Lubrication
Combustion
Table 5: Example System DSM (SDSM)
Lubrication Delivery Return
X X X
Combustion Intake Exhaust Fuel Delivery Chamber
X X
X X
X
X
X
Cooling Power Conversion
X
X
We can now frame messages to the individuals in charge of the Block and the Connecting Rod that would read: A change was recently made in the Crankshaft: This may impact Lubrication Delivery and Power Conversion. If so, these could cause also impact the Lubrication Return and/or the Combustion Chamber. Please verify the impact of this change on your component. Similar messages could be generated and sent to the individuals monitoring the systems. These messages are not intended to be diagnostic, rather they are to alert the DE that the design has changed and their attention may be required. Work is underway to construct a Web based tool to coordinate the communication between DE. This tool will permit users to either log into a server to be made aware of the current status of the design, or be sent daily emails that summarize the changes.
4
Conclusion
This paper is a formalisation of a system to route messages between members of a design team based on a hybrid of the DSM. The routing is accomplished by examining the underlying physical and functional requirements of the product and the interconnections between them. This routing restricts updates to interested parties to avoid overloading the participating engineers with data concerning every change being made in the program. The system does this while following the same minimalist philosophy of the DSM and thus does not require extensive data gathering or modelling. A less formally developed precursor to this system was integrated into the design approach of a major automotive manufacturer and the authors believe this formalisation allows this work to be replicated in other areas. References [1] [2]
[3]
[4] [5]
[6]
[7]
Lockledge, J.C. and Salustri, F.A., “Defining the engine design process”, Journal of Engineering Design, 10, 1999, pp. 109-124. Steward, D. (1981) System Analysis and Management: Structure, strategy and Design, 3, (New York, Perocelli). Hubka, V and Eder, E., “Engineering Design: General Procedural Model of Engineering Design”, Heurista, Zurich, Switzerland, 1992. Steward, Donald V., "The Design Structure System: A Method for Managing the Design of Complex Systems" IEEE Transactions on Engineering Management, vol. 28, pp. 71-74, 1981a. Pimmler, Thomas U. and Eppinger, Steven D., "Integration Analysis of Product Decompositions", Proceedings of the ASME Sixth International Conference on Design Theory and Methodology, Minneapolis, MN, Sept., 1994. Also, M.I.T. Sloan School of Management, Cambridge, MA, Working Paper no. 3690-94-MS, May 1994. Sabbaghian, N, Eppinger, S. and Murman, E, “Product Development Process Capture and Display Using Web-Based Technologies”, Working Paper, Center for Innovation in Product Development, MIT, URL: http://me.mit.edu/groups/cipd/projects/sabbaghian.html. Kusiak, Andrew, Engineering Design: Products, Processes, and Systems, Academic Pr, 1999.
Corresponding Author: Institution: Department: Address:
Phone: Email:
Jeffrey C. Lockledge Wayne State University Department of Industrial and Manufacturing Engineering Manufacturing Engineering Building, 4815 Fourth St., Detroit, MI 48202 313 577 3507
[email protected]
