Framework of a representation model for modular product development

Abstract

Partitioning, development, fabrication, and management of construction blocks of modular products still heavily rely on manual labor of sophisticated designers because existing representation models seldom have automatic capability of product data processing for modular product development. To cope with this challenge, a framework for building an efficient representation model for modular product development has been developed. First, the framework redefines some very important concepts in order to make them clear and accurate. Second, the framework proposes a generic structure for modular products, which comes from the analysis and synthesis of real cases of modular product development in industry. Third, concept formalization is brought forward to facilitate manufacturers to establish responding ontology while the development process for modular product development ontology is provided as a simple reference for manufacturers to build their own modular product development ontology. Last, the analysis shows that the proposed approach is feasible, and may assist manufacturers to establish modular product development ontology for automation in modular product development.

Introduction

A representation model is an abstract description to express real modular products^1–4 in modular product development (MPD). It determines the complexity of partitioning, developing, fabricating, and managing construction blocks of modular products. There have been many studies on representation models in the past. In design and development, there are product functional structure models, ⁵ graph or network models,^6–8 and tree models. ⁹ In management, there are generic product structure models ¹⁰ and product data management models provided by various commercial Product data management/Product lifecycle management (PDM/PLM) systems.^11–13 In product configuration, there are structured net models, ¹⁴ Petri net models, ¹⁵ ontology-based models,^16,17 and so on. In knowledge management or data exchange, ontology-based models^18–20 share most scenarios.

However, the application of existing representation models in real MPD projects has encountered the following difficulties.

1. Owing to relative independence and lack of representation unitarity, most models are difficult to integrate.

2. Construction elements of most models are over generic, relative loose, and lack close relationships.

3. Attributes of product construction blocks are seldom involved in most models. It is difficult to retrieve those attributes for further needs.

4. A visitor could not access directly the information hiding in various heterogeneous documents that model elements represent.

5. Except for data exchange models, most models are not intended for computer automatic processing.

Therefore, partitioning, development, fabrication, and management of construction blocks of modular products still rely heavily on manual labors of sophisticate designers. In order to solve this dilemma, a pervasive representation model is proposed as a basis to realize computer automatic processing for MPD. The organization of the rest of this text includes four sections: presentation model for modular products; model establishment; model feasibility; and conclusion and future works.

Presentation model for modular products

The representation model for modular products is a hybrid of a hierarchy structure and ontology. The ontology, including classes and properties, deals with concepts, while all the individuals of classes and properties are attached on the hierarchy structure that expresses the organization of product components.

The establishment procedure of the model includes six steps, as shown in Figure 1. Step 1 clarifies and defines some important concepts used in MPD. Step 2 defines the generic structure for all modular products. Step 3 formalizes the defined concepts. Step 4 establishes generic structure for each model product. Step 5 establishes ontology for modular products based on the results of steps 3 and 4. Step 6 constructs the product structure with individuals of ontology classes and properties.

Figure 1.

Framework of the presentation model.

With the help of the presentation model, computers could substitute engineers to automatically deal with most activities in MPD. These activities fall mainly within the following scenarios.

1. Product modularization: the process that transforms a set of non-modular products into a family of modular products.

2. Model product development: the development of new modular product architectures based on existing modular products.

3. Design solution development: the development of new design solutions for a certain configuration item.

4. Module instance development: the development of new module instances for a certain module.

5. Fabrication schedule: the production planning of module instances for new customizations.

6. Product configuration: the procedure to configure a new variant derived from a model product.

7. Maintenance and service: services that support normal operation of modular products.

In addition, the ontology individuals could be dynamically produced according to newly developed construction blocks of modular products through a multi-agent system,^21,22 as shown in Figure 1. The multi-agent system could translate the heterogeneous documents of each node of a product structure into new individuals based on modular product ontology.

Model establishment

Concepts definition

Some significant concepts have been redefined as reference definitions to establish a pervasive model for MPD. These concepts are related directly to real practices in manufacturing industry and have no serious conflicts with existing ones.

Modular products

Definition 1: modular products are the products or systems that can perform certain functions through a combination of distinct module instances that could be developed independently.

Definition 2: MPD is a systematic and sustainable process to obtain modular products at low costs.^2–4

Product option

Definition 3: customer requirements (CR) is a regular expression of refined customer needs about products.^3,23

Definition 4: a configuration item attribute (CIA) is an attribute of the physical entity that a configuration item represents. A CIA is translated from CR.

Definition 5: a product option (PO) represents a non-empty subset of CIAs of a certain configuration item provided by a manufacturer for customers to select and customize specific product features and is on behalf of customers’ rights reflecting customer experiences on a class of products.

Definition 6: a PO value (POV) is a group of values assigned to the attributes represented by a PO and is one of the choices provided by the PO.

Definition 7: an option value carrier (OVC) is a set of physical entities that realize one POV of a certain PO.

Modular product architecture

Definition 8: a modular product architecture (MPA) is a fixed hierarchy, a three-dimensional framework being composed of interfaces and boundaries, and represents the overall abstract structure of a family of modular products.

Definition 9: a model product represents a set of variants derived from a certain MPA.

Definition 10: a product structure is the structure of a variant derived from a model product and represents a real manufactured product.

Product module

Definition 11: a module is an abstract entity that represents all the development specifications, the boundaries, the intended functions, and the interfaces satisfied by all the instantiated module instances.

Definition 12: an interface is a part of a module, the specifications of the channel through which a module instance interacts with its surroundings.

Definition 13: a module instance is a physical implementation of a module, meeting all the requirements of the module, and can be designed, developed, tested, and fabricated independently.

Currently, in academia and industry, a module instance is generally known as a ‘module’. However, this ‘module’ is difficult to differentiate from common product components. It is a semantic or conceptual confusion between a general and a special, or between an abstract and an actual. Therefore, a computer reasoning system finds it difficult to identify relationships among those ‘modules’.

Modular product configuration item

Definition 14: A configuration item (CI) is an under control construction block of modular products or systems that customers emphasize on, is the product configuration unit managed by the manufacturer, and is the basic unit of the task allocation in project management in MPD.

A CI containing other CIs, is called as a combination CI (CCI), while a CI not containing other CIs is called as a meta CI (MCI). In fact, a CI is an alias of a module controlled by customers and the manufacturer, and has all the properties of a module.

Definition 15: A design solution (DS) is the design solution to realize a modular product CI, and is composed of modules. A CI may have one or more DSs.

Definition 16: A DS instance (DSI) is a group of module instances assigned to the modules of a certain DS.

Figure 2 shows the relationships among some of the above-mentioned concepts. They interact together, and constitute the concept system of MPD.

Figure 2.

Relationships among concepts.

Generic structure definition

A generic structure for modular products has been built, as shown in Figure 3, based on the integration of common characteristics of modular products. This structure is a unified model for all modular products. Because of considering product development, manufacturing, project management, and customer cognition on products, the generic structure could be used as a standard generic structure for the representation model.

Figure 3.

Generic structure for modular products.

Since the structure of a model product is relative steady, the top structure of the generic structure is merely a CI hierarchy. That is to say that each CI of each level has only one DS, i.e. one structure. For example, in Figure 3, MP refers to a model product, being a CCI according to the definition of a CI, that has three sub-CIs, i.e. MCI₀, CCI₁, and CCI₂. Moreover, CCI₁ has three sub-CIs, i.e. CCI₁₀, MCI₁₁, and MCI₁₂. The middle structure of the generic structure is composed of all DSs of each MCI, all modules of each DS, and all module instances of each module. In addition, the middle structure will increase by adding new DSs of certain MCIs during the MPD procedure. For instance, in Figure 3, it can see that there are some DSs and a new DS, modules, and module instances in the middle structure of MP. The bottom structure of the generic structure is composed of the assembly of each module instance.

Based on this generic structure, each model product could be transformed into a similar structure so that the unified operations could be fulfilled on all the model products.

Concept formalization

Concept formalization is the procedure that uses a symbol system to express the involved concepts, and that makes the concepts more concrete. Using the formalization, concepts could be easily described by an ontology language. Manufacturers may extend these formalizations with respect to their own situations.

PO

The formalization of PO is as follows.

$$\begin{array}{c}\mathrm{PO}=(\left\{\mathrm{MPA}\right\},\left\{\mathrm{CI}\right\},\left\{A\right\},\left\{\mathrm{POV}\right\},\left\{\mathrm{OVC}\right\},\left\{m\right\})\hfill \\ \mathrm{POV}=\{<A_p,\mathrm{value}>\},A_p\in \left\{A\right\}\hfill \\ \mathrm{OVC}=\{<\mathrm{PO}{V}_i,\mathrm{MP}{A}_j,C{I}_k,\left\{m_l\right\}>\},\hfill \\ \hfill \mathrm{PO}{V}_i\in \left\{\mathrm{POV}\right\},\mathrm{MP}{A}_j\in \left\{\mathrm{MPA}\right\},\hfill \\ \hfill C{I}_k\in \left\{\mathrm{CI}\right\},m_l\in \left\{m\right\}\hfill \end{array}$$

where, PO refers to a PO; {MPA} refers to the set of MPAs that has the PO; {CI} refers to the set of CIs that has the PO; {A} refers to the set of CIAs; {POV} refers to the set of POVs; value refers to the specific value of a CIA; {OVC} refers to the set of OVCs; {m} refers to the set of module instances.

MPA

The formalization of MPA is as follows.

$${\displaystyle \begin{array}{c}\mathrm{MPA}=(\left\{\mathrm{CCI}\right\},\left\{\mathrm{MCI}\right\},\left\{\mathrm{DS}\right\},\left\{M\right\},\left\{\mathrm{DSI}\right\},\left\{m\right\},\mathrm{HR},\mathrm{SR})\hfill \\ \mathrm{CCI}=\{\left\{\mathrm{CCI}\right\},\{\mathrm{MCI}\},\mathrm{HR}\}\hfill \\ \mathrm{MCI}=\{\mathrm{CCI},\left\{\mathrm{DS}\right\}\}\hfill \\ \mathrm{DS}=\{\mathrm{MC}{I}_m,\left\{M_q\right\}\}\hfill \\ \mathrm{DSI}=\{<D{S}_i,\left\{m_j\right\}>\},D{S}_i\in \left\{\mathrm{DS}\right\},m_j\in \left\{m\right\}\hfill \\ \mathrm{HR}=\{<\mathrm{CC}{I}_i,\mathrm{CC}{I}_j>\cup <\mathrm{CC}{I}_l,\mathrm{MC}{I}_m>\cup <D{S}_p,M_q>\},\hfill \\ \hfill M_q\in \left\{M\right\},\mathrm{MC}{I}_m\in \left\{\mathrm{MCI}\right\},\mathrm{CC}{I}_i,\mathrm{CC}{I}_j,\mathrm{CC}{I}_l\in \left\{\mathrm{CCI}\right\}\hfill \\ \mathrm{SR}=\{<\mathrm{MC}{I}_i,D{S}_j>\},\mathrm{MC}{I}_i\in \left\{\mathrm{MCI}\right\},D{S}_j\in \left\{\mathrm{DS}\right\}\hfill \end{array}}$$

where, MPA refers to a MPA; {CCI} refers to the finite set of CCIs; {MCI} refers to the finite set of MCIs; {DS} refers to the finite set of DSs; {M} refers to the finite set of modules; {DSI} refers to the set of DSIs; {m} refers to the set of module instances; HR refers to the hierarchy relationship; SR refers to the selection relationship.

Product module

The formalization of a module is as follows

$$\begin{array}{c}M=(\left\{m\right\},\left\{F\right\},\left\{i\right\},\left\{B\right\},\left\{R\right\},\left\{A\right\})\hfill \\ \left\{F\right\}\subset \left\{A\right\}\hfill \\ \left\{R\right\}=\mathrm{Range}\left(\left\{A\right\}\right)\hfill \\ \left\{B\right\}\subset \left\{R\right\}\hfill \end{array}$$

where, M refers to a module; {m} refers to the finite set of module instances; {R} refers to the set of design rules; {B} refers to the set of boundaries satisfied by all the module instances; {F} refers to the set of functions; {i} refers to the set of interface; {A} refers to the set of attributes of this module; Range(.) refers to the value scope of each element of {A}.

Module instance

The formalization of a module instance is as follows

$$m=(M,\{<A,\mathrm{value}>\})$$

where, m refers to a module instance; {<A, value>} refers the set of attribute values of the module instance.

Modular product structure

The formalization of a modular product structure is as follows

$$\begin{array}{c}\mathrm{MP}=(\left\{m\right\},\mathrm{MPA},\mathrm{PCST}),\hfill \\ \hfill m_i\in M_j\in \mathrm{MPA}\hfill \\ \hfill \mathrm{PCST}=\left\{\mathrm{PO}{V}_i\right\},\mathrm{PO}{V}_i\in P{O}_j\hfill \end{array}$$

where, MP refers to a modular product structure; {m} refers to the finite set of module instances; MPA refers to the inherited MPA; PCST refers to the list of POVs.

MPD ontology development process

The establishment of MPD ontology adopts a top-down development process, as shown in Figure 4. The process includes six steps: POs, MPA, modules, module instance, product structure ontology establishment and web ontology language (OWL) programming.

Figure 4.

MPD ontology development process.

PO ontology

A PO is a direct response to CR, and represents a group of CIAs. First, collect and analyse customer needs, and translate them into product-specific specifications, i.e. CR. Second, find all the attributes that have different requirements. Third, change these attributes and requirements into POs. Fourth, create an ontology class for concepts in the domain of the PO. Last, add individuals for each ontology class.

MPA ontology

Firms should find out all the MPAs in MPD and define the class MPA and its properties with respect to the formalized representation. Each real MPA is an individual of this class. Note that the properties of a MPA are not limited to those in formalized representation. For a certain firm, the properties of class MPA must be determined according to the real developing requirements.

Product module ontology

Modules are abstracted into an ontology class and all modules become its sub-classes according to the definition of a module. Each module class or sub-class has its individuals expressing the real modules. In order to build module ontology, firms must collect and collate existing product components and identify the module instances and then create the module class, sub-classes, and their individuals.

Module instance ontology

A module instance is the actual manufactured entity and is the most complex part in the modelling process. A module instance has general information of its functions, performances, interface, assembly, and so on. Commonly, there are two types of instances: outsourcing and self-made. For an outsourcing instance, the corresponding properties are less and it just contains the information of suppliers and acquisition-related in addition to general information. For a self-made instance, it has more information, such as alternative information, subsystems, working principle, design models, analysis and calculations, test data, and so on.

Modular product structure ontology

A product structure represents a specific variant of a model product. All the product structures are defined as a top-level ontology class and each real structure is an individual of this class according to the requirements of MPD. Firms must search out all of the product structures and extract the common properties to define the product structure ontology.

OWL programming

Tools: OWL is the standard ontology language of semantic web recommended by the W3C. On 10 February 2004, W3C released the first recommended version 1.0 of OWL and version 2.0 (OWL2) was released on 27 October 2007, after application and improvement of OWL1 for years. As a kind of ontology implementation on the web, OWL expresses ontology as an XML document and can be directly processed in a computer. Therefore, OWL2 is selected as the language to express MPD ontology.

Protégé is a kind of application software developed by Stanford University for ontology edit and knowledge acquisition and has become one of the most popular ontology editors at present. Its current release has the capability to support the newest OWL2 language. So, Protégé is employed as the development environment for MPD ontology development.

Demonstration case: Since the establishment of ontology for modular products relates to real products, we exploit a high-performance notebook personal computer (NPC) family of a famous firm to demonstrate the result of MPD ontology establishment.

NPC has a few series, such as, H, M, and L, aimed at different market segments and each series has different models. Because the modelling for the whole NPC is a huge task, an H09 model is selected to demonstrate the NPC ontology. It processes the five real products as shown in Figure 5.

Figure 5.

Product configuration list of H09 model.

The NPC ontology has been developed using Protégé 4.02. Figure 6 shows the top-level classes of the NPC ontology and their sub-classes. Figure 7 shows a PO ontology graph. Figure 8 shows a query example of the NPC ontology using a ‘DL Query’ function in Protégé. The example is a query (HasModuleInstance value MI_1G1066MHz_Memory) to search all the individuals related to module instance MI_1G1066MHz_ Memory. The result includes the individuals of ProductStructure: H09-1, H09-3, H09-4, and H09-5, the individual of Memory: M_DDR3_Memory, and the individual of ProductOption: OVC_Memory_Size_3G.

Figure 6.

Top-level class diagram of NPC ontology.

Figure 7.

Product option PO_CPU_Performance ontology.

Figure 8.

Sample of an ontology query.

Model feasibility analysis

Feasibility analysis

Since a family of modular products commonly has a steady architecture, it is possible to define a generic structure for the family. The proposed generic structure is just such a structure for modular products. Compatible with the structure, the related concepts in MPD are redefined at the same time. These concepts have no serious conflicts with existing ones but they become more precise and clear. In addition, the concepts directly relate to real practices in manufacturing industry. Although it seems to be more theoretical, they satisfy the requirements of MPD. Since the ontology technology is well suited to knowledge representation, ¹⁹ the representation models are based on ontology. Moreover, OWL is exploited to implement the ontology in computers. In comparison with the existing contributions, this study focuses on the development process of modular products, not on the knowledge management. In summary, this approach is feasible in industry.

Comparison with existing models

In order to show the differences, Table 1 lists the comparisons between the proposed model and some existing ones. The comparison has six aspects, i.e. purpose, application scope, work object, technology, modelling method, and information carrier. The major difference between the proposed model and others is to support MPD rather than to express products or their knowledge using conventional product decomposition.

Table 1.

Comparison with various existing product representations.

	The proposed	Existing PDM/PLM systems11,12	Hao and Wang 24	Gao et al. 16	Nanda et al. 19
Purpose	Efficient design reuse; automatic processing	Product data management	Knowledge sharing	Automatic configuration	Information sharing
Application scope	Product data management	Product data management	Product life cycle	Product configuration	Knowledge management
Work object	MPD	General product; modular products	Product; components; process	CR; component configuration	Product family; component
Technology	Ontology	Generic BOM	Ontology	Ontology	Ontology
Modelling method	Formal model; process	Product structure decomposition	IDEF0	Multi-digraph; formal model	Formal model; process
Information carrier	OWL2.0; XML	Database	ODLBKIF; ASPECTOL;	BNF; database	OWL1.0; XML

MPD: modular product development; CR: realise customer requirements; PDM: product data management; PLM: product lifecycle management; BOM: bill of material; IDEF: Integration Definition for Function Modeling; ODLBKIF: object description language based on knowledge interchange format; ASPECTOL: Aspect-based ontology description language; BNF: Backus-Naur Form.

Potential industrial benefits

The purpose of this article is to provide a framework for a firm to develop a representation model to support or improve automatic capability of product data processing for MPD. Although the proposed model is just in the implementation process, in practice it shows some important potential benefits.

1. The semantic organization of product data facilitates designers or engineers to master various modular products.

2. MPD ontology provides an information system with the basis to identify and reason modules or module instances automatically.

3. MPD ontology facilitates the accumulation of MPD knowledge.

4. Modularization or modular design could be standardized and normalized.

5. MPD ontology could extend the collaborative depth with partners.

Conclusion and future works

MPD has been a significant paradigm of product development in computer industry, automotive industry, and aircraft industry. However, MPD could not avoid a large amount of manual labor while it has realized reuse of experiences and instances. How to exploit computers to substitute manual labor in knowledge-intensive areas becomes a new goal to MPD. As the basis to realize automation, a new representation model for MPD is carried out. Modelling is a generic way to express the abstract ideas or concepts in product development, such as idea generation for conceptual design. ²⁵ The proposed model is intended to support the development of complex modular products in manufacturing industry and forms them. The generic structure of the model has explicit print of mechanical and electrical products. In fact, this model is a core model of product data management. It determines the performance of accessing and managing product data. Its efficient representation can not only increase search speed but also realize reasoning automatically, and consequently, development time and costs would be reduced.

The proposed representation model, at present, only supports model product, DS, module instance development, and other scenarios. Nevertheless, it is difficult to apply directly in product modularization, although the purpose of this modelling is to process existing designs automatically. Therefore, how to make it meet the requirements of product modularization will be a research perspective in the future. At the same time, how to integrate this approach into the current PDM/PLM systems is another important issue that needs to be solved. Because each application scenario has its specific way of fulfilling automatic processing based on this representation model, the implementation of each automatic machine needs more attention paid to it. In addition, the produce mechanism of dynamic individuals through the multi-agent system based on this model requires further study.