ÍNDICE ALFABÉTICO

Figure 6-1 shows the homepage of the engineering design change management system developed in this project. In the homepage, there are recent engineering design change cases listed. Each record of change cases shows the case number, the subsystem where the change request occurs, the component that a change is applied to, the engineer who is assigned to this change case, the current status of the change case, and a list of actions that users want to take on this change case. A user can choose to take actions such as process the change case, reassign it to someone else, or close the case. There are also hyperlinks on case numbers. By clicking them, users can review the basic information of change cases. Similarly, users can also get information regarding the engineers who are assigned with the change case and the history of the status of each change case.

-125-

Figure 6-1 Homepage of the developed system

Figure 6-2 shows the status history of the first change case in the list. From the pop-up window which contains the status history, users can see the engineer who worked on each stage of the engineering change analysis of this case.

-126-

Figure 6-3 shows the interface where a new change order is created. The change order contains information such as change request number, subsystem, component, function, change request details, and change solution details. When the information is filled, the change order can be created and closed, which will be processed later. Users can choose, instead, to work straight on it and go to the next stage. In the screenshot of figure 6-3 below, a change order for changing the filtering mat of the cooling system has been created.

Figure 6-3 Design change case creation

Once a change order has been created, the engineer assigned with this task is to build the system models of the subsystem where the change happens. Figure 6-4 shows the interactional model of the cooling system, which is built in Topcases SysML™ modelling tool. The components and flows moving between them have been clarified.

-127-

Figure 6-4 SysML interactional modelling in Topcased

Figure 6-5 shows the definitions of the flow types which are used in the interactional model.

-128-

Figure 6-6 shows the spatial connection model which presents the spatial connections between each component. The spatial connection model is manually converted from a CAD model which can clearly show the spatial relationships between components.

Figure 6-6 Spatial connection modelling

When the system models are built in Topcased, the user needs to go back to the change management system and select a change case which has been created before. Then the user needs to select and upload the functional requirement model file and the physical structure model file (as shown in Figure 6-7). These two files are then automatically converted into a matrix, which is shown in Figure 6-8.

-129-

-130- F ig ure 6 -8 T he ma trix f o r cha ng e pro pa g a ti o n a na ly sis

-131-

The matrix is in the form of a very long table due to the presentation technology. As depicted in Figure 6-8, the grey column on the far left is a list of components of the subsystem where a design change occurs. The second row of the green zone represents the functional requirements of the subsystem. A marked cell in the matrix section of the green zone represents a component that is involved in the realisation of a functional requirement. The second row of the blue zone represents the flows that connect those components. A marked cell in the rest of the blue zone means that flow goes through the corresponding component. The second row of the grey zone on the right side represents the component. A marked cell in the rest of the grey zone means there are two components spatially connected. The composite matrix at this point has nothing to do with any design change cases, which is just automatically converted from system models.

When the matrix is ready, the component which a change case is associated with is selected for change propagation analysis. Based on the pre-defined relationships in the composite matrix, a popup window is opened, within which the basic information of the change order is shown and also flows that go through the component are listed for analysis. Following the flows, other components that these flows go through are listed as well. Following the components are the functional requirements that the components serve. If the flows going through the original component change because of the change to the original component, the knock-on effects need to be analysed by following this route: the original component → connected flows → connected components → related functional requirements. If there are functional requirement that cannot be satisfied because of the change, it is identified that there is a design conflict that happens to the component in that route right before the functional requirement.

After the analysis of the component-flow-component-functional requirement route, it is also necessary to analyse the component-component-functional requirement route, which means the change to the original component may also cause change to the spatially connected components. If the changes to those components lead to dissatisfactions of their related functional requirements, it is identified that there are design conflicts between the two components.

-132-

Figure 6-9 shows the interface of the system for design conflict formalisation with pre-defined ontology. The design conflict is decomposed into function, input flow, output flow and component. The characteristics of the component and the flows that are considered as important factors are also formalised with predefined ontology. For example, in the above interface, the function of this component is ‘heat exchanging’. Clicking the textbox in the knowledge metadata column, a popup window appears which presents the ontology definition. Engineers can choose the appropriate definition to tag (see Figure 6-10).

After selecting concepts for each part of the decomposed design conflict, the form needs to be submitted for knowledge reasoning. The knowledge system will then retrieve the most semantically similar design cases as reference solutions and the engineer can choose from the prioritised list of reference solutions.

-133-

-134-

Figure 6-10 Knowledge metadata tagging