Phase 1 of the design change analysis (see Figure 4-1) is to identify initial design changes. Initial design changes are found in this phase, which can be caused by many factors. For example, change of a functional requirement or a component can be caused by changes of customer requirements, government regulations, technical restrictions and environmental restrictions. Various reasons can trigger occurrence of a design change. The term ‘initial design change’ does not mean the first change of the design. It is used to differentiate propagated changes caused by this initial design change afterwards. Initial changes are normally identified by people involved in the project. There is no specific method proposed in this phase regarding how to identify them since they happen very randomly.
Phase 2 of the design change analysis is to clarify dependencies and relationships. It is critical to clarify dependencies and relationships existing in an engineering design, which makes change propagation analysis possible. Four types of relationships are considered, i.e., dependencies between functional requirements, involvement of physical components in realisations of functional requirements, behavioural relationships between physical components and spatial relationships between physical components. Modelling methods are used to clarify these dependencies and relationships. The SysML™ block definition diagram (Object Management Group, 2008) is used to model functional requirements and clarify the dependencies between them. The internal block diagram is used to model interactions (behavioural relationships) between physical components. CAD models are used to clarify the spatial relationships between physical components. A composite matrix model is used to summarise and simplify the dependencies and relationships clarified in those three models (i.e. block definition diagram, internal black diagram and CAD model). The composite matrix also represents mappings between functional requirements and physical components for the involvement of physical components in realisations of functional requirements. In this phase, designers and engineers are involved in the construction of these models since they know the product better than anyone else. System engineering modelling tool SysML™ and Computer Aided Design (CAD) tool are used.
-66-
Phase 3 of the design change analysis is to analyse design change propagation. Design propagation happens when a change of a design element (a functional requirement or a physical component) causes changes of other design elements (mainly physical components). It is difficult to evaluate the impact of a change if the change propagation has not been considered. During this phase, models in phase 2 are used, especially the composite matrix. When the changed components in the initial change have been identified, three types of physical components need to be analysed. The first type of components are those that work together to realise the same functional requirements. These components may need to be changed to compensate the influence caused by the changed components. The second type of components is those that have behavioural interactions with the changed components. Behavioural interactions can be represented by flows including energy flows, signal flows and material flows. The change of the component may change the states of these flows getting through it, which may further influence other components through which these flows pass. Influences on these components need to be analysed whether they can still work to meet their corresponding functional requirements. The third type of components is those that have spatial relationships with the changed component. The initial change may make the position of the component different, which may interfere with its neighbouring components that spatially connected. These neighbouring components also need to be analysed whether they can meet their corresponding functional requirements.
Phase 4 of the design change analysis is to identify and formalise design conflicts. Design conflicts happen when change of a design element harms or obstructs realisations of other functional requirements. A method for how to formalise a design conflict using domain ontology is proposed. The method for formalising design conflicts is further described in the next section.
Phase 5 of the design change analysis is to solve deign conflicts. A knowledge repository is constructed by generalising and formalising previous design cases with domain ontology. Formalised design conflicts in phase 4 are used to reason in the knowledge repository. The reasoning mechanism is developed by comparing similarities between formalised elements of design conflicts and generalised design
-67-
cases. General solutions are obtained during the reasoning process. Furthermore, specific reference design cases are retrieved from database to get solutions for design conflicts.
Phase 6 of the design change analysis is to evaluate design change solutions. When solutions are obtained from the design conflicts resolving phase, their impacts in terms of factors of project success need to be evaluated. In this research, four factors are chosen to represent the extent of project success, i.e., development time, development cost, development risk and functional satisfaction. Integration with other systems such as product data management (PDM) and failure mode and effect analysis (FMEA) are developed to collect reference data for evaluation. An algorithm is also developed to calculate the final impact by considering different weights of each element of an engineering design. The detailed analytical process is depicted in Figure 4-2.
-68- System modelling of engineering design Functional structure modelling Physical interaction modelling Spatial connection modelling Composite matrix model
Change propagation analysis based on the composite matrix
Knowledge-based design conflict solving
Change analysis based on physical interactions
Change analysis based on spatial connections Design conflict identification Change verification against functional requirements Synthesise Support Verify Verify Pass? No Yes Formalise design conflict
Semantic reasoning for reference solutions Ontology definition Behavioural ontology Characteristic ontology Flow ontology Component ontology Support Knowledge repository of design cases Reference solution review and selection
Making change decision
Update design models with the change decision and check further change propagation Original product design
Initial change goes to change propagation analysis
Changed product design
Change propagation ends Initial change
-69-