GB/T 44063-2024Automation systems and integration - Integration model of discrete manufacturing enterprise data space (English PDF)

3 Terms, definitions and abbreviations

A data space is defined as a set of data with the features of multiple data subjects, multiple sources of generation, multiple heterogeneous types, multiple physical distributions and multiple ownership relations, forming a logical data body with internal correlation and dynamic evolution that serves the application needs of enterprises, data consumers and other users. A manufacturing enterprise data space is the data space formed by the data produced in the main business areas of a manufacturing enterprise, such as product research and design, production and manufacturing, operations management and operation and maintenance service.

Data integration is defined as bringing together, logically or physically, data of different origin, format, character and nature so as to provide the enterprise with data sharing. A model is a representation or description of an entity or a system that describes only those aspects held relevant to its purpose. An information model is the organizational form and framework that defines, describes and relates the information resources of a given manufacturing enterprise, and an information object is one information body of a business domain of the manufacturing enterprise; a note adds that an information object describes an entity, general, real or abstract, that can be conceptualized as a whole.

A data entity model is the formal description of the concrete instances of a class of data objects. An attribute is data describing the nature and features of an entity, an attribute element is a basic element composing an attribute and is its basic unit, and an attribute set is a set of one or more attributes that can exist alone as a node and forms the structured element of the attribute description of the enterprise data space information model.

Further terms taken over from other standards are product, defined as the output expected by the enterprise or a by-product of a process, with a note that it may be an intermediate, final or finished product; production, the function or action that converts raw material or semi-finished goods into finished goods; procedure, work or a task containing one or more operating units and normally to be completed at one location; plan, the controlled analysis and design of process sequence, resource requirements and process management needed to reach a given operation; product data, information about a product expressed in a formalized way suitable for communication, interpretation or processing by people or computers; and manufacturing resources, any equipment, tool or means used by the enterprise to make products or provide services.

A trusted data circulation system is defined as distributed key data infrastructure built on the existing information network for data sharing, circulation and application, which through systematic technical arrangements ensures the confirmation, performance and maintenance of digital contracts in cross-domain data circulation and resolves the security and trust problems between data providers, data users and other subjects. The related term for the contract itself is printed in the document as digital contact, defined as a machine-readable and machine-executable electronic contract reached between the data provider and the data user before circulation, which provides the ability to set circulation conditions and configure control policies and which governs the data during use according to those policies.

The abbreviations listed are BOM for bill of material, CAD for computer aided design, CAE for computer aided engineering, HDFS for Hadoop distributed file system, HTML for hypertext markup language, ID for identity, JSON for JavaScript object notation, WBS for work breakdown structure and XML for extensible markup language.

4 Data space model of the discrete manufacturing enterprise

4.1 The data space of the discrete manufacturing enterprise describes the composition and relations of the space from several dimensions, namely the business domain, the modality domain, the user domain and the data life cycle domain, shown in Figure 1. The four dimensions describe the model respectively from the angle of the enterprise business activities that generate the data, of the functions and operations applied to the data over its whole life cycle, of the classification of data by modality, and of the roles of the several kinds of user.

4.2 The business domain is composed of the main business activities of the manufacturing enterprise and the data they generate, chiefly the data produced in the four stages of product research and design, production and manufacturing, operations management, and operation and maintenance service. The research and design domain covers the product design data models generated by the design activities; the production and manufacturing domain covers the data models relating to people, machines, materials, methods and environment in production, machining and assembly; the operations management domain covers the data models of the management and decision activities of production, supply, sales, personnel, finance and materials; and the service domain covers the data models of customer service, operation and maintenance activities on the products of the enterprise.

4.3 The modality domain describes the classification by modality of the data involved in those business activities, in three classes: structured data, semi-structured data and unstructured data. Structured data is represented and stored chiefly by the relational data model, in the form of two-dimensional structured tables. Semi-structured data is represented and stored chiefly by the key-value mapping model, its format not being fixed, the formats used being XML and JSON. Unstructured data has no fixed data structure model and includes office documents of every format, text, pictures, HTML, reports of all kinds, images and audio or video information; it is represented and stored chiefly by a distributed file model such as HDFS.

4.4 The user domain is composed of the user subjects that interact with the data in those business activities, including designers, process engineers, engineers, production line workers, dispatchers, quality inspectors, production supervisors, supply chain supervisors, sales supervisors, customer service staff and operation and maintenance supervisors. These roles are both the producers of the data of their own business domain and the users of the data in the related business applications.

4.5 In cross-domain circulation the full life cycle of the data generated in the business domains comprises eight stages: data generation, data processing, data publication, data exchange, data transmission, data storage, data use and data destruction. A trusted data circulation system should be set up to safeguard trusted cross-domain circulation through those eight stages. To keep the data and the systems trustworthy, the generation stage should ensure the trustworthiness of the source of the data, including equipment, people and processes; the processing stage should use trustworthy algorithms and programs so that integrity and accuracy are not damaged; the publication stage should ensure authenticity and integrity and avoid the release of erroneous or misleading information; the exchange stage should use secure and trusted exchange methods and protocols; the transmission stage should use reliable transmission methods and protocols; the storage stage should use trustworthy storage methods and devices; the use stage should ensure that only authorized users can access and use the data; and the destruction stage should follow the established procedure so that the data cannot be maliciously exploited.

5 Cross-domain integration model of the research and design business domain

5.1.1 The core businesses of the research and design domain that bear on cross-domain integration are requirement analysis management, product and process design management, and simulation and verification management, shown in Figure 2. Requirement analysis management manages the design requirements of the design activity and serves as the basis of product and process design, covering among others the product requirement specification, the product function specification, the functional breakdown, the performance index specification, the requirement bill of material and specialist design knowledge, and involving requirement survey and requirement analysis staff. Product and process design management manages the design process, covering among others conceptual design, product structure CAD design, the internal and external structure design of components, the work breakdown structure of the product, variant design, standard part design, product library design and the generation of the process, design and manufacturing bills of material, and involving product designers and process designers. Simulation and verification management manages the quality checking of the design models, covering among others CAE simulation, operating condition simulation, process simulation, multidisciplinary physical simulation, production line simulation and the generation of the digital mock-up, and involving product designers, process designers, simulation engineers and data analysts.

5.1.2 to 5.1.4 The clause then lists, for each of the three core businesses, the content of the corresponding data entity model. The requirement analysis model covers the product requirement specification data, the product function specification data, the product performance index specification data, the requirement bill of material and specialist design knowledge, and its modality is chiefly structured and unstructured data. The product and process design model covers conceptual design data, structure CAD design data, component interface data, work breakdown data, variant design data, standard part data, product library data and the process, design and manufacturing bills of material, its modality being chiefly unstructured and structured data. The simulation and verification model covers CAE simulation data, operating condition simulation data, process simulation data, multidisciplinary physical simulation data, production line simulation data and digital mock-up simulation data, its modality being chiefly unstructured and structured data. Each item is broken down into its constituent fields in the text, the lists being introduced as including but not limited to those fields.

5.2 The cross-domain integration models then state, for each pair of domains, which data the research and design domain should integrate from the other domain and for what purpose. Toward the production and manufacturing domain, product and process design management should integrate manufacturing capability data and collaboration data so that design deliverables can be handed over to manufacturing and structural design can be driven by manufacturing capability, and so that frequent engineering changes between manufacturing and design can be handled; simulation and verification management should integrate the same data so that changes of product structure and manufacturing process can be answered quickly and their performance verified. Toward the operations management domain, requirement analysis management should integrate market requirement data, individualized production data and sales data; product and process design management should integrate supply chain data, product performance data and functional conformity data, to support overall design under supply chain health assessment and cost constraints; simulation and verification management should integrate sales data and result feedback. Toward the operation and maintenance service domain, product and process design management should integrate after-sales service data, product upgrade requirement data and customer feedback data, to support design optimization from real operating feedback and to drive changes of the design bill of material and product upgrades; simulation and verification management should integrate maintainability data, quality data, maintenance data and usage log data, to support real-time simulation of product health and the construction of a digital twin system of product operation.

6 Cross-domain integration model of the production and manufacturing business domain

6.1.1 The core businesses of the production and manufacturing domain that bear on cross-domain integration are production planning management, production execution management, production quality management and production equipment management, shown in Figure 9. Production planning management draws up the production plan that the workshop then works to, covering among others the master production schedule, the material requirement plan, the detailed operation plan, production operation documents, scheduling management, the collection of production factors and plan tracking, and involving production and planning staff. Production execution management manages workshop execution in real time, covering among others plan reception, task dispatching, task execution, process tracking, material traceability, outsourcing management, process enquiry, exception management and execution statistics, and involving workshop management and operating staff. Production quality management manages the inspection process, covering among others reception of the inspection plan, material inspection, in-process inspection, product quality management, non-conforming product management, quality exception traceability, quality statistics and inspection procedure management, and involving quality management and inspection staff. Production equipment management covers among others fixture management, mould management, the equipment ledger, operation monitoring, energy consumption management, maintenance management, equipment life analysis and predictive maintenance, and involving equipment management, workshop operating and maintenance staff.

6.1.2 to 6.1.5 The data entity models of the four core businesses are then listed field by field. The production planning model covers master production schedule data, material requirement plan data and production scheduling data, its modality being chiefly structured data. The production execution model covers production task data, task execution data, production logistics data, machining process data and outsourced task data, its modality being chiefly structured, semi-structured and unstructured data. The production quality model covers material quality data, in-process inspection data, product quality data, non-conforming product data, quality exception data, quality statistics data and inspection procedure data, its modality being chiefly structured and unstructured data. The production equipment model covers fixture data, mould data, equipment ledger data, maintenance data, operation data, energy consumption data and equipment life analysis data, its modality being chiefly structured and unstructured data.

6.2 The cross-domain integration models state which data the production domain should integrate from the other three domains. From the research and design domain, production planning management should integrate the material and process bills of material to support the material requirement calculation and the setting of plan milestones; production execution management should integrate process drawings and documents, machining technical requirements and standard time data to guide the execution of every machining step; production quality management should integrate process drawings and documents and machining technical requirements so that inspection procedures can be set on a sound basis. The clause continues in the same form for the integration with the operations management domain and with the operation and maintenance service domain.

9 Requirements for trusted data circulation across business domains

9.1 Trusted cross-domain data circulation is the data sharing behaviour, between the research and design, production and manufacturing, operations management and service domains, in which the right to hold the data resource is separated from the right to use it: the providing subject holds the data resource and the using subject holds the right of use. In the integration of the enterprise data space, trusted data circulation should be treated as the infrastructure that safeguards trusted circulation, providing to every domain of the data space a whole-life-cycle management of the circulation process across different users, data modalities, processing behaviours and businesses. All activities involving data in the business domain, the data life cycle domain, the modality domain and the user domain should rest on the trusted data circulation system.

9.2 After business domain data is collected and labelled it enters the trusted data circulation system, which should ensure that the data is turned into a managed asset. The behaviours and results of the generation process should be recorded as log evidence by the system and used as clearing and audit evidence after circulation ends; the system should record at the same time the source information of the data it generates.

9.3 Business domain data should undergo pre-processing such as desensitization and encryption inside the trusted data circulation system before entering formal circulation. The behaviours and results of processing should be recorded as log evidence for later clearing and audit, and the encryption and desensitization operations should themselves be strictly monitored and audited.

9.4 The trusted data circulation system should organize the existing data assets of each business domain into a catalogue of circulating data and publish it. The behaviours and results of publication should be recorded as log evidence for later clearing and audit.

9.5 The system should let business domains browse each other's data catalogues, settle their intention to circulate data, negotiate the boundaries of use during sharing and reach a digital contract. The behaviours and results of exchange should be recorded as log evidence for later clearing and audit. In reaching the contract the boundaries of use of the data and the attribution of ownership should be clearly defined, so that the exchange is fair and transparent.

9.6 The system should support the transmission of business domain data between several organizations or individuals in the user domain. After the parties have negotiated the digital contract, the data should be encrypted, desensitized and otherwise pre-processed; the using party may then pull or receive the data assets of the providing party. The behaviours and results should be recorded as log evidence for later clearing and audit.

9.7 After receiving the data assets the using party should apply trustworthy encryption technology so that the data is secure while stored. According to the structured, semi-structured or unstructured type in the modality domain, the data should be placed in trusted environments of different levels as the contract requires, and the behaviours and results should be recorded as log evidence for later clearing and audit.

9.8 For every kind of data operation, the using party should process the data inside its own trusted environment in accordance with the digital contract, and the system should ensure that the data is processed and used only within the scope the contract lays down; a suitable access control policy should be applied so that only authorized users can reach and use the data. The behaviours and results should be recorded as log evidence for later clearing and audit.

9.9 When all operations on the data are finished the data should be destroyed, by means including but not limited to key invalidation, file deletion and physical erasure, and the behaviours and results should be recorded as log evidence. After the sharing ends the trusted data circulation system should carry out clearing and audit on the basis of the logs of the circulation process.