Abstract
Interface definitions are important in complex system design because they contribute to the definition and satisfaction of functional flows. Design structure matrix approaches have only recently focused on supporting the challenge of integrating possible interface types in conceptual design. We propose a physical interface data model to define the interface design space and thus support interface definition. This data model is integrated into the system architecture definitions and uses shared design parameters to detect risk and conflicts in collaborative design. A case study in an oil industry has been conducted to test the proposed approach and define difficulties in the implementation phase.
Introduction
Matrix-based approaches are known to be particularly suited to concept generation and evaluation in complex system design (Pimmler and Eppinger, 1994; Wyatt et al., 2008, 2012). In order to explore and evaluate possible concepts, matrix-based approaches generally use system decomposition to identify possible connections between subsystems (Pimmler and Eppinger, 1994; Wyatt et al., 2008). Only recently, some studies have focused on different types of connections in order to integrate them into design space exploration (Hamraz et al., 2013; Pimmler and Eppinger, 1994; Wyatt et al., 2012). The data used in these approaches consist mostly of quantitative evaluations of connection strength by different experts. The problem is that the design team is not able to easily identify shared design parameters that define this interface design across disciplines.
In this work, we propose to integrate the ontologies of different product component (PC) types into a design structure matrix (DSM) so as to preserve the option to computationally explore all possible configurations and to identify shared design parameters across disciplines. In combination with other types of matrices, these new data help identify risks linked to the collaboration design space and the design parameters that define it. The multiple-domain design scorecards (MDDS) (Jankovic et al., 2012) approach is proposed as a methodological support mechanism for early design concept exploration. This matrix-based methodology is based on gathering data within three matrices: a functional flow-design mapping matrix (FF-DMM), a product component-design structure matrix (PC-DSM), and a voice of design department (VoDD) matrix.
In section “Background: integrating product connections into concept generation and evaluation,” an overview of existing methods and approaches integrating different interface-related elements is presented and discussed. In sections “MDDS: integrating interface knowledge” and “Collaborative conflict detection and risk management,” we introduce MDDS and define a physical interface data model within the PC-DSM. Section “Experimental study” presents a case study conducted in an oil company; advantages and limitations in the deployment are also discussed. Finally, section “Conclusion and perspectives” concludes with our contribution to interface data integration for concept generation.
Background: integrating product connections into concept generation and evaluation
The DSM method has been known to support several operating principles for complex system design (Eppinger, 1991; Eppinger and Browning, 2012; Maurer, 2007; Sharman and Yassine, 2004; Steward, 1962, 1981; Ulrich and Eppinger, 1995; Yassine and Braha, 2003). Lindemann et al. (2009) classify matrices as follows: intra-domain, inter-domain, or multiple-domain. Intra-domain matrices or DSMs map relationships between like elements (product components, performance attributes, and engineering requirements). Several scholars (Jarrat, 2004; Pimmler and Eppinger, 1994) have provided very good overviews of different dependency types for these matrices. Inter-domain matrices (also called domain mapping matrices (DMMs)) (Danilovic and Börjesson, 2001) are matrices that consider dependencies between different domains (e.g. between functional requirements and product components). Finally, multiple-domain matrices (MDMs) represent dependencies between elements of several domains. Browning (2009) identified the following two types of matrices: static and time based. Static matrices represent elements that coexist, while time-based matrices order rows and columns to indicate flows in time.
Most approaches consider existing interfaces during conceptual design, but only some define these interconnections. Hellenbrand and Lindemann (2008) used DSM and proposed a compatibility matrix that captures possible compatibilities between two different product components and their weights. In the proposed consistency algorithm, all possible product concepts are generated when an interface is identified. Pimmler and Eppinger (1994) integrated four types of interactions in DSMs: spatial, energy, information, and material. A weighted scale is used to represent a coupling coefficient (from −2 to +2). Wyatt et al. (2008) proposed using matrix-based approaches to define the rules governing concept generation. This approach proposes a component DSM in order to compare different design concepts. In an effort to generate concepts, the authors considered different component and connection types. Concept generation rules are expressed as a mapping component and component types, and component types and connection types, as they define concept generation constraints. The authors also proposed a network-based approach (Wyatt et al., 2012) that integrates different types of connections in order to support product architecture design: structural, behavioral, assignment, and geometrical. These connection types are integrated into a network representation of the product architecture that is used for constraint-based classification and visualization of possible architectures. However, information about constraints is limited, and impact on the global architecture performance cannot be deduced and analyzed. Sharman and Yassine (2004) integrated three levels of system representation using DSM approaches: global design rules, interface rules, and intra-module design rules. The existence of product interfaces is an input for determining architecture visibility and dependency. Albers et al. (2011) proposed using the Contact and Channel Approach (C&C-A) for system architecture generation. C&C models represent the interactions between systems, subsystems, and parts through working surface pairs (WSP; geometric interfaces between artifacts or between an artifact and its environment) and channel and support structures (CSS; physical components or volumes of liquids, gases, or fields directly connecting two WSP). Information related to interfaces is not integrated into architecture-level behavior assessment. Moullec et al. (2013) developed a Bayesian network-based model for architecture generation. The possible connections between product elements are modeled as compatibility constraints that can be crisp or uncertain. Integrating uncertainties into product connection supports uncertainty estimation at the global architecture level. As in previous examples, the interfaces are characterized as nodes in Bayesian networks and do not integrate parameter definitions that are important for a particular interface. Rahmani and Thomson (2011) propose an interface model using the Model-Based System Approach. The aim of this model is to represent the interface space using Unified Modeling Language (UML) and permitting connection between different subsystems. Only recently, some studies have focused on different types of connections in order to integrate them into design space exploration (Hamraz et al., 2013; Pimmler and Eppinger, 1994; Wyatt et al., 2012).
In the majority of previously discussed approaches, different types of interfaces are proposed, but the interface design space is not defined. As interfaces also contribute to functional flows, it is necessary to characterize this design space in order to identify the impact of one interface on overall system functioning. In order to bridge this gap, the MDDS approach integrates three types of matrices and combines them with data related to the definition of physical interfaces. These data are used in identifying conflicting design parameters and managing them in an adequate collaborative failure modes, effects, and criticality analysis (C-FMECA) (IEC 60812:2006, 2006).
MDDS: integrating interface knowledge
The MDDS is an architecture generation and evaluation method (Jankovic et al., 2012) based on the semantic enrichment of three matrices related to functional flows (FF-DMM), system structures (PC-DSM), and performance evaluations (VoDD matrix). Within this method, a particular focus is made on identifying potential difficulties and conflicts between different design departments related to interfaces, and this is an object of this article. As interfaces define functional flows, the aim of this approach is to capture expert knowledge on the interface design space, specifically on design trade-offs and risk management related to the collaboration. The FF-DMM is designed to capture data generated during functional analysis (Aoussat et al., 2000). Information related to concept brainstorming, possible modules, technical solutions, and structural interfaces is captured within the PC-DSM. Finally, the technical performance brainstorming step allows experts to discuss possible performance outcomes for the modules and the ability to achieve performance goals at the system level. Based on these three steps, the MDDS method proposes six design assessment cards (DACs) (Jankovic et al., 2012). DACs are special connectivity maps (Yassine et al., 2003) used to support design process and identify possible trade-offs.
Defining the functional flows
The FF-DMM is a cross-functional flow and concept structure mapping matrix populated with data captured during the functional analysis step (Aoussat et al., 2000). It is an enriched DMM representing different functional flows as relationships between functions and technical solutions. Technical solutions in this case represent different possible design solutions for modules (i.e. product subsystems). The resulting FF-DMM is a numerical DMM where numbers (Figure 1) represent the functional flow directions of one function through technical solutions. Determining the direction of functional flows helps designers identify product interfaces.
Functional flow-design mapping matrix (FF-DMM).
For instance, the flow of the function dissipate heat starts from (1) electronics, and flows to the (2) substrate, (3) box, and (4) chassis. Technical solutions I and Delta represent technical solutions for the module chassis. Moreover, FF-DMM also integrates concurrent functional flows. Dissipate heat can be supported by two concurrent systems: (1) electronics, substrate, box, and chassis and (2) electronics, substrate, box, chassis, and collar. An FF-DMM data model showing different data types and their relationships is shown in Figure 2.
FF-DMM model ontology.
The design team is the team in charge of product design. It is identified by its project name and its project manager name. Therefore, the design team class has an aggregation relationship with the design engineer class. The design engineer class is defined by name, department, and project responsibility. Design engineers have specific areas of expertise and are members of design departments. The design department class is defined by name and design area. In general, design projects are multidisciplinary, and each design department is responsible for designing a specific module. The module class represents different subsystems. It is defined by module name and module number. For each module, in order to satisfy different technology and performance criteria, several design alternatives are examined and proposed (technical solutions). Since a design team is in charge of product design, the design team class has a composition relationship with the concept class. A concept has a concept name and a concept number. The concept class comprised several modules. Each concept is defined by a system’s objectives and function. Therefore, for each concept, there are several functions that describe the system’s mission. Function is defined by a function name and function utility describing the goal of the function. For each function, several technical solutions are required. The function class is therefore associated with technical solutions. This association is also defined by the functional flow class. The functional flow class defines the sequence of technical solutions through system architecture.
High-level architecture description as a result of design team brainstorming
The PC-DSM summarizes possible concept configurations. This matrix is a semantically enriched square matrix that integrates physical interface typology (Figure 3). Based on their typologies, these physical interfaces are linked to their corresponding data model (Figure 4). Both rows and columns list modules and their technical solutions (concept breakdowns as well as other possible technical solutions). Some of the types of physical interfaces that are identified include E for elastomer, V for screw, S for silicone, G for glue, and F for fitting. For example, the physical interface between a Pivot box and a Delta chassis can be either screws (V) or silicone (S).
Product component-design structure matrix (PC-DSM).
Physical interface data model.
A physical interface class represents possible physical interfaces between technical solutions in PC-DSM (Figure 4). It is defined by its name, milestones, and constraints. Linked to it are design parameters that are shared across physical interfaces. For each design parameter, name and value are defined. Design parameters are linked with domain-specific knowledge, which is defined by principle solution, previous experience, equation, constraints, difficulties, and comments. This class contains a designer’s (expert’s) knowledge about a given design parameter. The expert class is an aggregated class of design engineers, defined by expert name, domain expertise, and responsibility. Design parameters contribute to the achievement of technical performance, which are performance criteria defined at the system level. Therefore, the technical performance class is associated with the function class. Of course, the function class is also related to the physical interface class. One function may have several physical interfaces. For example, if glue (G) is used to connect the substrate to the box, the physical interface data show that three design parameters are shared across the interfaces: surface area, viscosity, and thickness. Moreover, previous experience and testing data can be found in guideline number 100236239 (company reference document).
Integrating performance evaluation and design department constraints
The VoDD matrix is a quality function deployment (QFD)-like matrix defined in order to capture designers’ assessments of alternate technical solutions (Figure 5). It is also used to evaluate the potential of each technical solution to meet required performance criteria.
Voice of design department (VoDD) matrix.
Columns correspond to modules and their technical solutions. Rows list the expected technical performance in order to evaluate functions as well as to differentiate each technical solution. The contribution of technical solutions to the fulfillment of technical performance criteria represents the body of the matrix in the form of scale-based evaluations.
As seen in Table 1, there are four levels in this scale: (1) performance objectives are achievable without any major problems; (2) performance objectives are known to have been achieved in previous projects; (3) performance objectives have been achieved by competitors, but not by the company; and (4) performance objectives have never been achieved by any company worldwide. The left side of the VoDD matrix defines the correlation between technical performance criteria, either positive or negative. The right side of the matrix specifies the manner of evaluating a function, based on technical performance evaluations of the associated concepts. Each technical performance is associated with one of the following:
Min indicates that the technical performance of the given concept is defined by the minimum value of the contribution to its technical solutions;
Max indicates that performance is defined by the maximum value of its contribution to technical solutions;
Avg indicates that performance is defined by the average value of its contribution to technical solutions;
Sum indicates its total contribution to technical solutions.
Maturity scale for the estimation of technical performance satisfaction.
PEC: power electric controller.
The data captured through VoDD are represented by the ontology in Figure 6. Each technical performance is related to different technical solutions. The technical solution class is defined by its name. Different evaluations are based on maturity scales and are represented by the maturity value for each technical performance. Evaluations are expert based; hence, the expert class is associated with the evaluation class. The expert class is defined by expert name, domain of expertise, and responsibility that an expert has within a company and a project.
Voice of design department matrix.
Collaborative conflict detection and risk management
The interfaces that are taken into account are physical interfaces representing mostly spatial and material interfaces, and not necessarily energy or information (Pimmler and Eppinger, 1994). A design interaction DAC, representing a particular connectivity map (Yassine et al., 2003), identifies performance targets for interfaces and identifies conflicts between different design departments that require further expert discussion. Conflicts that are often found in the design are, for example, the height of condenser that will impact the number of electronic card and therefore the manufacturing costs or the interface between chassis and box that cannot dissipate Jules per hour if a particular mechanical interface is chosen mostly for its robustness against shock capacities. PC-DSM data related to the interface design space are then used to frame discussions about potential risks and mitigation plans. All information concerning collaboration conflicts, associated risks, and mitigation plans is captured in a C-FMECA.
A design interaction objectives DAC is used to identify physical interfaces that might cause problems (Figure 7). A design interaction objectives DAC relates experts’ evaluations with regard to required performance criteria for a single concept. In the first step, physical interfaces are extracted from the PC-DSM (Figure 7) in the form of a list of possible interfaces. This list of interfaces is compared with the FF-DMM in order to identify interfaces that contribute to the overall system function. This is done in order to distinguish interfaces that impact high-level functioning of the system. This comparison yields a list of physical interfaces associated with different technical solutions and design departments.
SADT showing the overall conflict identification process.
For each physical interface, a VoDD matrix is used to extract data on related performance criteria and expert evaluations for each constituting technical solution. The target of this matrix is set using a performance evaluation function in VoDD (Figure 5). Therefore, for each physical interface, we identify related performance criteria, the ability to achieve performance predicted by experts, and targets for a given physical interface with regard to design requirements (see design interaction objectives DAC in Figure 7).
The advantage of this DAC is that it supports the identification of technical maturity conflicts between different design departments. Therefore, for the same interface, the gap between what is achievable with one technical solution in one design department and that of a technical solution proposed by another design department is identified. Moreover, the design interaction DAC identifies the limitations of different design departments. For example, for the same interface, one design department might be less technically mature and considerable effort may be required in order to reach the same performance target that can be achieved more easily by another department. The evaluation of required effort and related risks can induce the redefinition of performance targets.
The conflict list is then discussed among members of the affected design departments. Information about conflicts is complemented with interface typology data that are stored within the PC-DSM and is represented by the physical interface data model (Figure 4). This data model is designed to support the definition process of design parameters across interfaces.
This information related to physical interfaces and related design parameters then helps us to identify design parameters and domain-specific knowledge in order to better manage related risks. During collaborative risk meetings, this information is available to the design team. For the case study company, usually it takes half a day to discuss these collaborative conflicts. During such discussions, designers can estimate the degree of difficulty related to one interface, renegotiate performance targets, or set mitigation plans in order to ensure that interfaces will not decrease overall system performance.
The information resulting from this discussion is contained within C-FMECA. FMECA (IEC 60812:2006, 2006) constitutes a method describing possible system failures, their effects, and assessments of their criticality. It is a widely used reliability engineering tool in industry. In most cases, FMECA addresses global system risks and different measures to mitigate those risks. In this work, we propose C-FMECA, which addresses only collaborative risks based on data related to physical interfaces. The advantage of C-FMECA is that it essentially addresses collaborative risks. However, this would not be possible if adequate tools for identifying conflicts related to physical interfaces were not used. Moreover, the interface data model, which includes data related to physical interface typology, is indispensable for this approach because it is used as the basis for data gathering. These data embody interface characteristics as well as previous experience related to similar interface typology, hence enhancing the design team’s knowledge of the design problem.
Experimental study
The MDDS approach was used and tested in the oil industry. This case study addresses the design of a power electric controller (PEC), a regulator board that is used as a power supply for the motor control, and main controller boards. The main function of this subsystem is to generate the +3.3 and +1.9 V power supplies. The PEC system comprised a substrate, electronic components, a box, a chassis, a collar, substrate, connectors with other systems, and related wiring. The internal functional analysis (Aoussat et al., 2000) is provided in Figure 8. For confidentiality reasons, the PEC is only partially represented. There were three design departments involved in the design project: mechanics department designed the chassis, packaging department designed the box, and electronics department designed the other modules.
Internal functional analysis of PEC. (The light gray lines between components represent product component. Functional flows are represented by arrows indicating the direction of the function flow itself. The dashed light gray lines show several possible flows for the heat dissipation function.)
There were four main functions for the PEC: (1) dissipate heat with two possible functional flows; (2) resist shock; (3) withstand pressure; and (4) generate the +3.3 and +1.9 V power supplies. The directions of functional flows are represented by arrows. In this case, only the function dissipate heat, required to cool electronic components, had two possible functional flows (see the dashed lines with arrows in Figure 8); depending on the chosen solution for the chassis, heat could be dissipated through the chassis or pass through the chassis and be dissipated through the collar. In both heat dissipation functional flows, air flow against the box, chassis, or collar could facilitate the process.
MDDS is generally deployed during early conceptual design brainstorming workshops. In this case, the workshop was divided into 3 days: (1) functional analysis; (2) brainstorming about different modules (subsystems), possible technical solutions, interfaces, and system performance; and (3) expert performance evaluations for each solution, DAC computation, and system selection. In order to illustrate some of the possible concepts yielded from this discussion, the PEC reference “High Pressure High Temperature (HPHT)” concept is shown in Figure 9. The left side of Figure 9 shows an open casing with the substrate and electronic components inside; the right side of Figure 9 shows the box, wiring, and connectors integrated onto the chassis (shown in yellow). Concept 7 was chosen to illustrate interface detection and collaborative risk management.
The PEC “HPHT” concept.
After data collection in FF-DMM, PC-DSM, and VoDD matrices, design interaction objectives DAC is calculated (see Figure 10). This extract shows different system performances linked to one interface (matrix rows). The columns show the targets defined for each department (i.e. shared modules and performance targets). Here, we show only one interface, but others were generated for each cross-domain interface. For example, robustness against shocks (X) was set as a minimum (Min function in VoDD, see Figure 5). This means that the global robustness values for each concept were defined by the minimum values of their technical performance evaluations. Here, the design of the interface chassis–box could not be more than 2, the value for robustness against shocks (X). If the robustness of the interface had been 3, it would have been considered overkill for achieving the final robustness goal for the concept. The design interaction objectives DAC and physical interface data (Figure 4) are used to frame discussions on concept feasibility and related risk management during an expert review meeting. These data were then captured and shared in a form of a C-FMECA (Figure 11).
Reverse Delta-HPHT interface for concept 7: (a) an excerpt from the VoDD matrix and (b) design interaction objectives DAC.
Excerpt from C-FMECA.
Figure 11 shows an excerpt from the C-FMECA resulting from the MDDS approach. The C-FMECA is not designed as a replacement but rather as a complimentary approach. These data are integrated in the overall risk management process and FMECAs related to different phases and departments in the design. Data related to the C-FMECA come from physical interface data model and data that are considered to be standard in FMECA. Identified interfaces are then correlated to possible solutions. It shows an example of the glue physical interface between the box (packaging) and the substrate. In this example, one can see that shear and pull-off strength were critical in the design of a glue physical interface. During interface dimensioning, designers need to consider the surface area of contact between technical solutions, the viscosity coefficient, and the thickness of the glue between contacts, as defined in physical interface data model. The estimated probability is 5 because in previous experiences (guideline number 100236239) described in the physical interface model, every time a design team dimensioned a glue interface, it failed during initial testing. The impact is also considerable because the interface broke without prior reduced functionality (i.e. no forewarning). Both Likelihood and Severity are defined on a scale from 1 to 5 as it was already the case in the company. Design recommendations are summarized afterwards, and 1 week is deemed necessary to optimize design parameters with the support of a specialist. The designer in charge of dimensioning this interface had to consider that glue would have to resist shocks up to level 2 (i.e. the performance target already attained in previous designs).
In the next step, design convergence was achieved by integrating the data in the C-FMECA and analyzing whether all technical performance targets could be achieved through physical interfaces. In the glue physical interface example (see Figure 11), the design team had to decide whether glue could achieve the expected technical performance for the chassis–box interface design. In this case, the thermal dissipation performance target was set to 4. Using the previously mentioned guidelines, this target was not feasible based on the results of previous testing. This level of thermal dissipation could not be achieved with a glue physical interface. Therefore, the data implied that a glue interface, and thus the analyzed concept, was unfeasible.
This method was applied on two examples in industry. It has been applied in early stages, but following one project using this approach thought the entire system development has yet to be done. However, we have organized at the end of the workshop a group feedback on utilization and relevance of the method. As conflict identification is only a part of the methods, this is not the only point discussed during the feedback. The major advantage that has been pointed out is the possibility to capture design knowledge, both risk and interface related, using this approach and to identify collaborative conflicts early in the design. Designers have also expressed that they thought that managing collaborative conflicts and shared parameters can possibly accelerate the “convergence” in the design process. For example, in the C-FMECA, condenser height has been identified as a problem. An engineer has pointed out that this problem has been seen previously on one project and it was considered to have cost almost 1.5 years of work as it was needed to be redesigned. However, it has to be pointed out that methods for collaborative conflict management were nonexistent in the company and that a detailed field research has shown that these conflicts induced up to 1/3 of the overall project time overdue. During the workshop, it has also been observed that designers were obliged to discuss the values or interval ranges in the interface definitions. They have pointed out that this might be an interesting way to support design negotiation further in the design process. However, the degree of innovation within a system can influence the difficulty in deploying this method. This approach is based upon previous experience, and therefore, for radically new projects, where both the system architecture and the system itself are radically new, it would be hard to support it with previous knowledge. Further evaluations of the methods are needed. It is necessary to follow one project from the beginning to the end. It would be necessary to have a detailed investigation of the efficiency of the method and in-depth comparison. For example, identify how many risks have been identified early in the design process? How many risks have been known previously or are new? It would also be interesting to investigate saved design time due to this risk management. However, this is only possible if the method is deployed on several industrial cases and onto the overall project.
Conclusion and perspectives
Interfaces define and intersect functional flows and, therefore, define overall system behavior. Only recently, studies have integrated interface design into design methods in order to propagate and predict their impact. In this study, we proposed to integrate physical interface ontology into the DSM, thereby enabling experts to harness their experience related to design parameters, previous projects, constraints, and principal solutions. The proposed approach, MDDS, enables the identification of collaborative risks among different design departments.
The proposed approach was illustrated through a real case study in the oil industry. The approach enabled the identification of not only conflicting interfaces but also related risks and mitigation plans. These data were stored within a C-FMECA that addressed only collaborative conflicts. It is reasonable to expect that all companies use FMECA as an essential approach to managing risk, but it is necessary to investigate whether the data considered in physical interface data models can be used for other types of design projects.
Additional difficulties stem from a need to integrate software tools with this approach. For the time being, these data represent a mock-up. If there is a need for larger capitalization of these data, several issues must be investigated. One of the related issues is actually defining the related database, its architecture, and potential usability within the design process. It is also obvious that the existence of this database influences the deployment method. We have already seen that in order for a method to be a success, an expert in the method must participate. In this case, the question is whether additional experts are needed in the process of collaborative risk database exploitation.
Footnotes
Acknowledgements
This research work was done within the CIFRE convention and in collaboration with Schlumberger. Hereby, we would like to thank them for their support and very constructive insights during the development and testing.
Funding
This reaserch has been funded by CIFRE grant given by the ANR (French National Science Angency) and Schlumberger.