A novel collaboration-oriented requirement model mapping and classification method based on domain knowledge for complex mechatronic products

: Complex mechatronic products include inter-disciplinary, inter-field, and inter-departmental requirement information. Aiming at the low digitization rate of existing product requirement information, a structured and digital product requirement model (RM) is defined. Besides, a collaboration-oriented requirement model mapping and classification method for complex mechatronic products is proposed, which realizes the automatic generation of the domain requirement models and the mapping between the requirement models and knowledge graph, thus improving the digitization rate of the product in the requirement phase. A simulated military plane horizontal tail control system is used as a case study to prove the effectiveness and feasibility of this method. Based on Hoteam PLM8.0 platform, a management architecture and the display path of product requirement model are given, which can provide a reference for the research and development of product lifecycle model management (PLMM) system.


Introduction
In recent years, the complexity of product research and development is increasing. Therefore, digitalized and networked collaborative manufacturing has become an inevitable trend of enterprise transformation and upgrading [1]. However, for complex mechatronic products, the information in some phases of product lifecycle is still stored and distributed in the form of electronic documents, so it is difficult to realize the efficient management of this information. It is mainly manifested in two aspects: (1) The information of electronic documents is unstructured. And the digitization rate of this information needs to be improved.
(2) The allocation of inter-disciplinary and interdepartmental product information is mainly done manually. Therefore, product developers spend a lot of time on document sorting and can't focus on creative research and development work.
Product model is equivalent to a small database, which can efficiently query, change and manage [2]. Due to the poor consistency and low communication efficiency of unstructured information in documents, model-based systems engineering (MBSE) has emerged as the times require. Systems Modeling Language (SysML) was widely used by systems engineers [3] and some scholars studied product modeling based on SysML [4][5][6]. Xu Zihe [7] defined itemized requirement information in Word document and realized the transformation between itemized requirement and SysML requirement diagram. However, SysML is difficult to parse its contents in programming languages. With the development of knowledge engineering and semantic web technology, ontology-based methods [8,9] are also widely used in requirement modeling and analysis. Yaman et al. [10] proposed an ontology framework to represent information and knowledge of engineering product requirements. Based on the framework, they also proposed an ontology model of product design requirement, which provided rich requirement semantic information for requirement storage and analysis. Bakhshandeh et al. [11] proposed a requirement extraction method based on ontology, and they took enterprise ontology and domain ontology as the basic information of requirement extraction. Sheng et al. [12] studied customer requirement modeling and mapping for configuration design, and established a four-tier customer requirement model.
Requirements are the main basis for product research and development, so it must have good traceability. Traceability describes the traceability relationship between system requirement and user requirement [13], which requires that product requirement information must be efficiently retrieved, managed and pushed. As a large-scale knowledge base composed of entities and their relationships, knowledge graph (KG) can provide support for efficient search and push of information. The concept of KG was first proposed by Google in 2012. At present, KG is widely used in natural language processing, intelligent question answering system and intelligent recommendation system, etc. [14,15]. Research on KG of RM can provide the basis for efficient retrieval, management and push of RM.
At present, many manufacturing enterprises use product lifecycle management (PLM) system to manage the product information. However, PLM is still a management method based on documents and data. There are two challenges for PLM to improve management efficiency and transform into PLMM. One is how to integrate product models, the other is how to effectively manage the product models [16][17][18]. Bruno et al. [19] proposed a reference ontology that supported PLM. This reference ontology can be used in different fields and can manage a specific product lifecycle by adding new entities, sub-entities and relationships to its structure. Cui et al. [20] put forward a requirement information management model oriented to PLM to realize customer-requirement-centered information management in PLM system. Chabot et al. [21] proposed an approach to realize the knowledge referential by using a generic approach as well as modular and reusable components. Applying this approach on PLM can improve the management efficiency.
The remaining of this paper is arranged as follows. A structured and digital definition of RM is given in section 2. Section 3 proposes a RM mapping and classification method based on domain knowledge to automatically generate the domain requirement models of the product. In section 4, a case study of simulated military aircraft horizontal tail control system is given to verifies the effectivity and feasibility of the proposed RM mapping and classification method. Section 5 puts forward a management architecture and the display path of product requirement model. Finally, conclusions are drawn in section 6.

Structured and digital definition of RM
The technical agreement documents of the product are generated when the customer signs the contract with the product manufacturer, which cover the product requirement information such as technical data, the uses and function of the system, order information and detailed technical requirements. Currently, technical agreement documents are mostly stored in electronic documents, and most of the information in these documents is unstructured, which is not conducive to store, retrieve and release. In this paper, we obtain the structured and digital product RM by extracting the requirement information in the technical agreement documents and defining it in a structured and digital manner.
Product requirement information contains at least the following types: product name, type description, function requirements, performance requirements, dimensions, weight requirements, price requirement and delivery time. Definition 1 Attribute the product name, type description, price requirement, and delivery time as attributes of the product requirement model, since they usually contain only a fixed value. Then RM is denoted as _ , , , _ RM product name type price d time product_name, type, price and d_time represent product name, type description, price requirement and delivery time, respectively. Definition 2 Consider function requirements, performance requirements, dimensions, and weight requirements as subsets of RM, since they all contain multiple information.

Classification of complex mechatronic product RM
In the design process of complex mechatronic products, each design department needs to design the subsystems according to the corresponding requirement information.
Currently, most enterprises allocate the requirements by the general department. In this way, the general department spends a lot of time on document sorting, thus extending the time of overall product research and development. To shorten the product development cycle from the requirement phase, a mapping and classification method of RM based on domain knowledge is proposed, which can automatically generate and push the domain requirement models through computer-aided analysis. The architecture of the method is shown in Figure 1. The main steps of the method are as follows.
Step 1 According to the structured and digital definition, the product requirement model _ , , , _ RM product name type price d time is obtained.
Step 2 Establishing the domain knowledge bases. When establishing the domain knowledge bases, we should determine the professional category involved in the product and divide a knowledge scope that can clearly express the phenomenon and terms of each domain. Definition 4 Remember DB as a set of domain knowledge base for all domains involved in the complex mechatronic product,  (7) The set of domain matching degrees is DMr, and the maximum value of its element is denoted as Max(DMr), then DMr str s (8) Step 4 According to the calculation results of DMr, the classification result of the requirement information is obtained through certain classification rules.
A single piece of requirement information str may match multiple domains. Denote S as a set of domains that may match the requirement information str, then ( , ) , For the second case, str will be classified into multiple domains. For the third case, str cannot be classified into any domain. In both cases, str will be merged into MH. The requirement information in MH will be output to the product developer. The product developer will further classify the requirement information according to his own professional knowledge and improve the corresponding domain knowledge base.

Mapping method between RM and KG
The product model contains the information of the product. Efficient retrieval, management and reuse of this information is conducive to improving the efficiency of product research and development. In order to support the retrieval, management and reuse of the product model, it is necessary to further condense the information in the product model to form the product knowledge model.
KG contains triples composed of entities, relationships, and attributes, such as entity-relationship-entity, entityattribute-attribute value. KG can clearly describe the relationship between product requirement information, domain requirement model and product requirement model, and provide a basis for the design department of each domain to obtain the corresponding requirement information efficiently. After the automatic generation of domain requirement models, KG corresponding to RM (RMKG) is generated through certain mapping rules. Definition 7 Remember that a piece of requirement information in the product requirement knowledge model is a requirement knowledge block, which contains two features: generalized variable description and generalized variable range.
Generalized variable description contains the description of the requirement information, while generalized variable range contains the relevant requirements indicator values for the product. Definition 8 RMKG = (E, R). E represents entities. R(E1,E2)represents the relation between E1 and E2. E1 is relation subject, while E2 is relation object. Also, under the relationship R, E1 is the parent entity of E2. Definition 9 E = (T, P, V), where T represents entity type, P and V represent entity attribute and attribute value respectively.
When generating RMKG, two types of entities are generated: (1) The entities mapped from the set elements, that is, the product requirement information, are called the terminal entity (ET).
(2) The entities mapped from sets, that is, the product requirement model set and product requirement information subsets, are called non-terminal entities (ENT).
Define the following mapping rules to generate entities, attributes, attribute values and relationships in RMKG.

A case study of mapping and classification of a simulated military aircraft horizontal tail control system requirement model
This chapter takes a certain model of simulated military aircraft horizontal tail control system as an example. Based on the spreadsheet, some important product requirement information is mapped and classified through Python, and finally the graph database Neo4j is used to display RMKG. Neo4j is one of the most widely used graph databases at present. It stores structured data in the form of native graphs. Referring to the internal data "Model Theory System of Product Life Cycle"[13], we obtain Input-Process-Output (IPO) diagram, as shown in Figure 2. Step 1 Using the structured and digital definition, RM is obtained from the technical agreement documents, and RMKG is shown in Figure 3. Step 2 Military aircraft horizontal tail control system involves professional knowledge of four domains: machinery, automatic control, fluid transmission, electrical and electronic. Based on the professional terms of the four domains, we established the domain knowledge bases and generated the knowledge graph of the domain knowledge bases. Figure 4 shows the knowledge base of the control domain. The knowledge of different domains is distinguished by different colors. There may be coupling between knowledge of different domains, such as the "sensitivity" in the figure, which belongs to both machinery and automatic control domains.

Figure 4 Domain knowledge base of the automatic control domain
Step 3 Taking RM as the input of the Python program. First, we added common requirement information such as product name, type description, price requirements and delivery time to the requirement model of each domain. Then we used jieba module to preprocess the remaining product requirement information. And then we calculated Mr between each word segmentation and each professional term by Eq. (5). After that, we used Eq. (6) to calculate the domain matching degree DMr between the requirement information and the domain knowledge base. Finally, according to the classification rules, the classification results of the requirement information are obtained. The main procedural steps of the classification rules are shown in Table 1.
Output the requirement form of each domain and the knowledge graph corresponding to the domain requirement models. The results are as follows, Table 2, Table 3, Table 4 and Table 5 are the tables of automatic control domain, the electrical and electronic domain, machinery domain and fluid transmission domain, respectively. Figure 5 shows the knowledge graph corresponding to the domain requirement models.     Figure 5 knowledge graph of the domain requirement models It can be seen from the mapping results that different entity types are distinguished by different colors. If the requirement information is confused, that is, the requirement information exists in multiple domain requirement models at the same time, when mapping it to the terminal ontology, the type is "product requirement information".
(1) Both the control requirement model and the electrical and electronic requirement model include Control current and Control current accuracy.
(2) Both the mechanical requirement model and the fluid transmission requirement model include Actuator stroke.
(3) The control requirement model, the mechanical requirement model and the fluid transmission requirement model all contain Actuator stroke control accuracy.
The confusing requirement information is finally output to the product developer. This information may be further divided, or it may be determined by the product developer whether this information needs to be output to multiple departments at the same time. For the latter, it means that the completion of these indicators requires the interdisciplinary collaboration of designers from multiple departments.
For the requirement information that is not confusing, when it is mapped to the terminal ontology, the type inherits the type of its parent entity.

Product requirement model management based on Hoteam PLM8.0 platform
In the current PLM project management, project-related information stored in the project folder is still based on unstructured documents. Translating this information into models through relevant model definition methods and using the model as the smallest unit of system management are the keys to upgrading PLM to PLMM. Based on the Hoteam PLM8.0 platform, we provided a preliminary model-based efficient management framework for the product requirement model. It can provide a basis for product model collaboration and PLMM research and development. The specific management architecture and display path are respectively shown in Figure 6 and Figure  7. Requirements are the important bases for production. According to the important requirement information, the product manufacturer will strictly approve it and make feasibility demonstration. However, most manufacturing enterprises need to meet for discussion currently. This collaborative mode of centralized meeting cannot meet the needs of operation in different places, that is, when different departments are in different places, they cannot carry out collaborative approval work in a timely manner. To improve the agility of collaboration among departments, based on the efficient management of the model, the process approval function of PLMM can be used to realize cross-regional collaboration among departments.

Conclusions
The main contributions are summarized as follows.
(1) Aiming at the existing unstructured product requirement information, the structured and digital definition is used to transform it into a product requirement model. (2) A requirement model mapping and classification method based on domain knowledge for mechatronic products is proposed. Taking a simulated military aircraft horizontal tail control system as an example, this paper realized the automatic generation of requirement models of various domains, and displayed the relationship between each requirement information and requirement model through knowledge graph. (3) Based on PLM8.0 platform, a development framework to realize efficient management of product requirement model is presented. (4) This paper provides a basis for the research and development of model collaboration technology and PLMM system, and provides technical support for the improvement of product digitization rate and collaborative agility.