This section provides an overview of some well-established research work that helps to model both product and process information, organised according to the categorisation summarised in Figure 2. The review process was organised as explained in Section 1.3. We focused on publications that explicitly consider both product and design process domains, and on key contributions – as such, our bibliography does not constitute an exhaustively complete list of such work.
Four main groupings of publications were identified as reflected in the categorisation: frameworks; abstract formalisms; partially integrated specific formalisms; and fully integrated specific formalisms. Examples from each of these categories are discussed in the next subsections. While examples from all four categories are given, greatest attention is given to specific formalisms because these arguably provide the most concrete support relating to integration of product and process information in an industry context, which was the original motivation for this article.
4.2 Examples of abstract formalisms
The only examples we found of commonly used abstract formalisms that do not stipulate a categorisation of elements are the Domain Mapping Matrix (DMM) and the Multiple Domain Matrix (MDM). These can be applied to model and analyse the structure of systems that comprise multiple domains (Danilovic & Browning 2007; Lindemann et al.
A DMM is a rectangular matrix similar in principle to a DSM. However, while DSMs can be used to represent the dependency structure between the components of a product or the tasks in a process, as explained earlier, DMMs are used to explicitly map dependencies between elements of different domains (e.g., between tasks and components, although many other mappings are possible). DSMs and DMMs can be combined in an MDM to represent a system’s structure across multiple domains. An MDM is essentially a Design Structure Matrix (DSM) that comprises detailed DSMs of single domains along its diagonal with DMMs that map domain pairs outside its diagonal. This allows direct integration of models of the product and design process domain by modelling the dependencies between the elements within and across the domains.
MDMs are often used as the basis of approaches that analyse the structure of systems with multiple domains, e.g., activities, components, requirements and design teams. For example, a number of authors use a component DSM and design process DSM, combined with a mapping matrix that shows which tasks contribute to the design of which components, as the basis of simulations to explore the impact of product changes on the design process (e.g., Gärtner et al.
2009; Ahmad, Wynn & Clarkson 2010).
4.3 Examples of specific formalisms
To recap, specific formalisms are not developed in isolation but appear in research publications alongside (or embedded within) approaches, i.e., explanations or hints towards their intended applications.
Some such publications focus on the specification of an integrated formalism that aims to allow users to represent all relevant dependencies amongst domains in a development process (e.g., Abramovici & Chasiotis 2002; Bernard et al.
2006; Gonnet et al.
2007; Robin et al.
2007; Aurisicchio & Bracewell 2013). The aforementioned formalisms are graphical in nature, defining different elements and connections that the authors propose are useful to describe product and design process information in an integrated way. Other authors concentrate on describing a support tool that exploits an integrated perspective on product and design process (e.g., Clarkson & Hamilton 2000; Ouertani & Gzara 2008; Lévárdy & Browning 2009; Ahmad et al.
2013). The latter publications do propose integrated formalisms, but those formalisms are not claimed to comprehensively capture the possible elements and links – they are each tailored to the application at hand. They demonstrate how insight can be gained by considering product and process information in an integrated way.
To illustrate the categorisation of formalisms by level of integration, selected specific formalisms were analysed in detail according to the scheme described in Section 3.2.3. The result is shown in Table 3. Overall the analysis of integrated specific formalisms highlights key commonalities about how the approaches integrate product and process information. First, links within either product or design process domains often involve hierarchical organisation of elements. Second, links in the process domain always involve information flows between activities while links from process to product domain always involve specifying the inputs and outputs of tasks. The approaches differ in terms of the particular elements they allow to be described in each domain, as well as other domains (such as rationale) that they consider.
An analysis of the same publications according to purpose of the approaches they describe was also undertaken. The result is summarised in Table 4. Key approaches and issues are discussed in the following paragraphs.
Firstly, to give some examples of approaches that show how integrated information might be exploited, Signposting (Clarkson & Hamilton 2000) guides the selection of activities at each step in the design process based on the designer’s confidence in the current state of design parameters. Signposting was enhanced in later work by Melo (2002), O’Donovan, Eckert & Clarkson (2004) and Flanagan (2006) to support design planning. In this approach the advantage of integrated modelling is to capture how the process unfolds based on the current state of the design. This is shown to be more realistic than modelling design as a predetermined sequence of activity. Other authors use integrated models to support engineering change management. For example, DEPNET (product specification DEPendencies NETwork identification and qualification) interlinks product data and design activities (Ouertani & Gzara 2008). The DEPNET database keeps track of the ongoing design process and is used to generate a dependency network of produced product data. If a product datum is changed the representation allows the dependency network to be filtered, to locate likely downstream impacts. The Information Structure Framework (ISF) developed by Ahmad et al. (2013) similarly aims to support change management through a cross-domain model, in this case integrating information about requirements, functions, components, deliverables and detail design activities. Changes can be introduced to information in any of these interlinked domains and the ISF helps a designer to assess how the change might propagate within and across them.
Secondly, in terms of models aimed at generic knowledge description, some formalisms are mainly oriented around describing a process as a flow of activities while also indicating the product elements used as input and output to those activities, alongside selected links in the product domain. For example, the well-known IDEF3 Process Description Capture Method and formalism aims to support capture of different user perspectives on precedence and causality relationships in a process (Mayer et al.
1995). IDEF3 is based on two connected diagram types: the process flow diagram and the object state transition network diagram. The former represents a process through a flow of units of behaviour (UOBs, i.e., actions), which are interlinked via precedence links and junctions (i.e., logic operators such as And, Or and Xor). The latter diagram represents an object which is transformed from one object state to another through the UOBs. The Applied Signposting Model (ASM) developed by Wynn et al. (2006) is targeted specifically at modelling engineering design processes. It represents design as structured activity networks in which tasks cannot interact directly, but are interconnected via input and output deliverables. The deliverables refer to design parameters and their status at each point in the process, and parameters can in turn be interconnected into a product information hierarchy. The ASM was developed to support several defined purposes, and following case studies it was found that the integrated nature helped to achieve a comprehensive representation by requiring users to consider the rationale behind task sequences in detail.
Thirdly, other formalisms aim to capture design and development process knowledge in a complete and contextualised way. As well as product and process elements, this involves representation of design rationale, design alternatives, and/or the history of a design as it evolves during the design process. Objectives for such modelling include capturing design knowledge to support its reuse (e.g., Abramovici & Chasiotis 2002); providing an enabler towards AI in design and intelligent CAD (e.g., Klein 2000); and coordinating work and decisions among design actors – for instance by analysing conflicts and propagating decision consequences (e.g., Arndt & Klein 2002) or by facilitating reactive control considering the changing design context (Robin et al.
2007). While some such work has an ultimate aim to support practice, other authors including Wang et al. (2013) and Grebici et al. (2009) concentrate on using integrated formalisms to model and analyse the relationship between product and design process, with the aim to derive research insights.
One representative example of a formalism in this category is FBS-PPRE (Bernard et al.
2006) which aims to capture and reuse the description of various information objects in PD, including process history and alternatives, with the intention to support managing their evolution and performance. The formalism extends the function, behaviour and structure paradigm to process, product and resource. The design process is treated as the transformation of functions to behaviours and finally to structure. Function is extended to process (temporal, spatial and hierarchical organisation of activities), product (object resulting from the process), resource (means used in a process), and external factors (contextual and environmental effects). Behaviour represents a set of laws governing the evolution or sequence of changes that takes place. Structure represents the decomposition of the system into its basic components. Pro2Kon (Abramovici & Chasiotis 2002; Chasiotis 2006) is another formalism that aims to represent multiple aspects of implicit and explicit procedural knowledge, with the objective to reuse that knowledge in support of distributed product development. Pro2Kon allows calculation methods, models, and results to be represented and interlinked by integrating four main model categories. The explicit procedural knowledge is represented using model elements concerning process knowledge and design-oriented product knowledge, while implicit knowledge is formalised in terms of elements that represent behaviour-oriented product knowledge and configuration knowledge. Similarly the CollaborativeModel (CoMoDe) formalism views design processes as a set of iterative activities from which initial design specifications evolve to a final desired product (Gonnet et al.
2007). Design activity is represented in terms of how the ‘DesignObjects’ evolve during the design process through a set of ‘Operations’ applied by ‘Actors’ given a set of ‘Requirements’, creating instances in time called ‘ModelVersions’. ‘Activities’ can be further detailed to trace the historical, contextual and rationale relationships between different ‘ModelVersions’.
To populate Table 4 considering these and other formalisms revealed by the review, purposes from Table 2 were initially assigned to each publication during a workshop with the majority of coauthors and later revalidated as described in Section 1.3, leading to improvements in the classification. The content of Table 4 distinguishes between primary and secondary purposes of each publication. The primary purpose indicates that the work was specifically developed for this purpose, at least as emphasised in the corresponding publication. Where a secondary purpose is noted, this indicates that although the original authors did not emphasise that a formalism was developed for that purpose, the workshop participants and other authors believed it could arguably be used for it (or is used for it) in practice. A clear differentiation between primary and secondary purposes might not always be possible or at least may remain a subject for debate. However, we believe that this distinction is important as it indicates not only the original objective as emphasised by a paper’s authors, but also potential capabilities of each approach. In particular, modelling formalisms are often taken up by other researchers or practitioners, who see the potential of the formalism for another purpose or only use a part of the originally included functionality. For example ASM was originally developed in the context of a planning support approach (Wynn et al.
2006), and has since been applied for process visualisation and improvement (e.g., Zhang, Hao & Thomson 2015).
Finally, although care was taken in formulating Tables 3 and 4, including several iterations among this paper’s authors to refine the content, it is important to note that approaches (and especially their intended purposes) are sometimes described in an ambiguous or incomplete way. Thus subjectivity could not be eliminated entirely from Tables 3 and 4. It should further be noted that Table 4 is not intended to imply a ranking of formalisms according to the number of purposes covered, because purposes are addressed in different ways and, arguably, to different degrees of research validation.
Table 4. Categorisation by purpose of selected integrated formalisms. Primary purposes are specifically emphasised in the indicated publication. Secondary purposes (i.e., possible applications of the formalism suggested by the authors of this article) are shown in italic. See Table 3 for a detailed description of each formalism, and Table 2 for a detailed explanation of each purpose