OsLC-based networking method for full life cycle requirement domain data

Abstract

The application discloses a full life cycle demand domain data networking method based on OSLC and belongs to the field of system engineering, and comprises the following steps: acquiring multi-source heterogeneous demand domain data from different sensors or different data suppliers; carrying out artificial analysis on the law or characteristics of the data and determining inherent attributes of the data, so as to facilitate subsequent analysis and storage; using Lyo Designer and the inherent attributes of the analyzed data, customizing an OSLC adapter of Excel, supporting the use of a unified network URL to access data of a specified structure; perfecting CRUD and query services supported by the constructed adapter, so as to realize the access to corresponding data through a corresponding uniform format URL, support POST, GET and other HTTP services with a web end, and realize cross-domain data interaction; and finally, integrating the adapter on a web platform to realize the unified processing of cross-domain heterogeneous data.

Description

Technical Field

[0001] This invention belongs to the field of systems engineering and relates to a method for achieving full lifecycle data networking using automatic networking technology. Background Technology

[0002] Digital threads refer to the creation and use of cross-domain, publicly accessible digital avatars (simulation models, test models, process models, and inspection models, etc.) that reflect the physical characteristics of complex products and support bidirectional communication of model information in both physical and digital spaces. On one hand, it ensures the continuous consistency of data, models, and information throughout the entire product lifecycle, from solution analysis, engineering manufacturing and development, production deployment to operational support, thereby enabling dynamic real-time evaluation of current and future product functions and performance. On the other hand, it feeds back information from the physical space to virtual product development, establishes a unified technical framework, supports cross-regional protocol interfaces, integrates with engineering knowledge management systems, provides an integrated perspective on complex organizations, and strengthens the quantitative analysis and confirmation of product performance boundaries and uncertainties.

[0003] OSLC-based integrated model technology is scalable, configurable, and modular. Based on this technology, an integrated view of a cross-level, cross-scale, multi-view model covering all stages of the system lifecycle and value chain can be built. This allows a unified model to drive system lifecycle activities and support decision-makers. Currently, OSLC-based integrated model technology defines various data and model specifications using unified modeling languages ​​(UML, SysML, etc.) during the user requirements phase, providing fundamental support for the subsequent integration and fusion of all data and models throughout the entire lifecycle.

[0004] Current systems engineering technologies often remain in the theoretical stage, lacking mature applications. Every product has a complex lifecycle from initial demand to service. Depending on the domain, models can be divided into stages such as demand, design, simulation, manufacturing, and service. Currently, data from different product lifecycles often comes from different suppliers, creating "data silos," meaning that cross-lifecycle product data cannot be effectively integrated and utilized. Furthermore, the design, simulation, and subsequent maintenance of large-scale complex product models still rely on expert monitoring, diagnosis, and error correction, resulting in high labor costs, high error rates, and high operational costs. Summary of the Invention

[0005] To achieve the above objectives, the technical solution adopted by this invention is: a method for networking demand domain data throughout the entire lifecycle based on OSLC, comprising the following steps:

[0006] Step 1: Prepare multi-source heterogeneous data, including demand domain data from different suppliers and different sensors.

[0007] Step two involves the standardization, analysis, and reconstruction of the data. For different data sources, the patterns or characteristics are analyzed to manually determine the inherent attributes of the data, enabling fine-grained analysis of the model data and preparing for the creation of the adapter.

[0008] Step 3: Build the framework of the OSLC adapter, that is, use Lyo Designer and the predefined inherent properties to design an adapter for a specific data source to generate a specific network URL, thereby realizing the network foundation of the data.

[0009] Step 4: Based on the generated OSLC adapter framework, improve the CRUD functionality for the corresponding data structures and the networked HTTP services, such as POST, GET, PUT, DELETE, etc. Simultaneously, it is necessary to use SPARQL technology to automate query and access functions for data and its inherent attributes through a uniformly generated network URL.

[0010] Furthermore, in step one, product data often comes from different sensors or suppliers, possessing different data structures or organizational forms. This diversification of manufacturers, heterogeneity of data formats, and blockage of data flow lead to the phenomenon of "data silos," making the processing, interaction, and analysis of product data across its entire lifecycle particularly difficult.

[0011] This technology models and parses the aforementioned data types under the OSLC service, using a unified OSLC standard to formally define and classify different data types, thereby ensuring data uniformity and flow.

[0012] Furthermore, in step two, OSLC (Open Lifecycle Collaboration Service) is introduced, reconstructing the above data partitioning method. This method mainly changes things in two aspects. First, the OSLC service spans the entire product lifecycle and is called the OSLC Core Domain. Second, OSLC has the following specifications: Change Management and Configuration Management Domain (CCM), Architecture Management (AM), Requirements Management (RM), and Quality Management (QM).

[0013] In the four OSLC core domains proposed above, dynamic partitioning is performed using product attributes as the primary dividing point, rather than static partitioning using product lifecycle as the primary dividing point. OSLC domains are first partitioned based on the attributes possessed by the product, and then each product domain becomes a subdomain of an OSLC domain. Each product lifecycle domain can exist in different OSLC domains. Once a product lifecycle exists in an OSLC domain, it means that subdomains within that OSLC domain can legally interact across domains, and identical subdomains between different OSLC domains do not have direct connections.

[0014] Furthermore, in step three, LyoDesigner is used to develop OSLC-compliant adapters for the standardized data information. The LyoDesigner project supports Java developers in developing REST-based servers and clients that need to share heterogeneous information as RDF resources. It advocates using relational data principles and the OSLC (Lifecycle Collaboration Open Services) standard to publish lifecycle data, enabling interoperability among heterogeneous products, services, and other distributed network resources.

[0015] Each adapter supports converting specific data format types into resource shape types conforming to the OSLC specification and implements HTTP service and resource query functions. The adapter setup process is as follows: create and name an OSLC server (OSLC Service) -> complete the corresponding definition domain -> establish a service provider -> check the integrity and validity of the code -> generate the OSLC server.

[0016] The advantages of this invention compared to the prior art are as follows:

[0017] This invention acquires multi-source heterogeneous demand domain data from different sensors or data providers; it conducts manual analysis based on the patterns or characteristics of the data to determine its inherent attributes, facilitating subsequent parsing and storage; using Lyo Designer and the analyzed inherent attributes of the data, it customizes an Excel OSLC adapter to support accessing data with a specified structure using a unified network URL; it improves the CRUD and query services supported by the constructed adapter, thereby enabling access to corresponding data through a unified URL format and supporting HTTP services such as POST and GET on the web, thus achieving cross-domain data interaction; finally, it integrates the adapter into a web platform to achieve unified processing of cross-domain heterogeneous data.

[0018] This invention enables data integration and management covering the entire system lifecycle, effectively automating product processing and analysis workflows, enhancing product processing reliability, and significantly reducing product maintenance and labor costs, laying the foundation for the subsequent realization of "digital leads." This invention addresses the entire lifecycle of demand domains, structuring and networking demand domain data, breaking down data silos throughout the product lifecycle, and resolving the problem of data islands. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the OSLC specification in the OSLC-based full lifecycle requirement domain data networking method of the present invention;

[0020] Figure 2 This is a flowchart of OSLC model data networking in the OSLC-based full lifecycle requirement domain data networking method of the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and effects of this invention clearer and more explicit, the following examples provide a more detailed description of the invention. It should be noted that the specific embodiments described herein are merely illustrative and not intended to limit the scope of the invention.

[0022] This invention is a method for networking data in a full lifecycle model based on OSLC. Figure 2 This demonstrates the process of networking and standardizing parsed data within the OSLC service, including the following steps:

[0023] Step one: Data preparation and formal definition. Throughout a product's entire lifecycle, data often originates from different sensors or suppliers, resulting in varying data structures and organizational forms. This diversification of vendors, heterogeneity of data formats, and blocked data flow create "data silos," making cross-lifecycle product data processing, interaction, and analysis particularly challenging.

[0024] To solve this problem, the first step is to identify the types of parameters that exist in the product lifecycle requirements domain and assess their feasibility for cross-lifecycle interaction.

[0025] The Ecore metamodel is used to describe the data organization architecture of the requirement domain tool Excel, including data hierarchy and data type information. In Excel, data hierarchy includes Workbook, Sheet, Row, and Cell, corresponding to file information, table page information, row information, and cell information, respectively. Data type information includes the data name (in String format) and the cell content (in String format).

[0026] The Ecore metamodel uses XML format file encoding as the input source for the standardized parsing and reconstruction of data in step two.

[0027] Step two involves standardized data parsing and reconstruction. In step one, the product was divided into two dimensions: attribute sets and lifecycle sets, initially demonstrating the feasibility and flow of data across different domains. This traditional data segmentation method macroscopically proves the difficulty of cross-domain heterogeneous data transfer and interaction, and cannot fundamentally bring about any substantial change. To address this challenge, a full lifecycle model data networking method based on OSLC was invented. OSLC services are used for data reconstruction and standardized parsing, unifying the data transfer format and facilitating multi-source heterogeneous data interaction.

[0028] Specifically, the data standardization and parsing part is implemented using the Java programming language, with the poi library used to extract EXCEL data and the dom library used for data standardization. Its key feature is that data parsing is performed with reference to the meta-model in step one, and the parsed and standardized data architecture is identical to the meta-model architecture in step one, stored using an XML structure.

[0029] In step two, OSLC is introduced. The data types obtained in step one are modeled and parsed under the OSLC service. A unified OSLC standard is used to formally define and classify different data types, ensuring data uniformity and flow. The unified OSLC standard restructures the data classification format in step one. The restructuring includes changes in the following two aspects, such as... Figure 1 As shown.

[0030] The data reconstruction section introduces OSLC (Open Lifecycle Collaboration Service) to restructure the above data partitioning. This method mainly changes two aspects. First, OSLC services span the entire product lifecycle, referred to as the OSLC Core Domain (e.g., Figure 1 (As shown). Second, OSLC has the following specifications: Change Management and Configuration Management Domain (CCM, Change Management), Architecture Management (AM, Configuration Management), Requirements Management (RM, Requirements Management), and Quality Management (QM, Quality Management). They have the following functions:

[0031] CCM: Parameter Management and Change Management domain. All attribute parameters and writable variables need to exist in this domain. Generally, this domain stores all variables, while some fixed parameters of the product are not stored in this domain.

[0032] AM: Structure Management Domain. This domain typically stores the product's fixed parameters, which means the product's structural composition, and may also include other descriptive information.

[0033] RM: Requirements Management Domain. Product requirements generally differ significantly from the modeling and simulation parameters of the product, therefore a separate domain is needed to manage the product requirement descriptions.

[0034] QM: Quality Management Domain. The calculation of simulation model parameters requires analysis of accuracy errors, as well as other error mitigation methods, all of which are stored in this domain.

[0035] The OSLC domains are dynamically divided based on product attributes, rather than statically based on product lifecycle. OSLC domains are first defined by the attributes of the product, and then each product domain becomes a subdomain of that OSLC domain. Each product lifecycle domain can exist in different OSLC domains. Once a product lifecycle exists in an OSLC domain, it means that subdomains within that OSLC domain can legally interact across domains. However, identical subdomains within different OSLC domains are not directly related.

[0036] In the OSLC Core Domain, the four core domains are all called Service Providers, used to provide cross-domain interaction services. The data formats storing different product lifecycle domains are collectively called Resource Shapes, which are essentially linked data, a set of RDF resource formats used for data storage and retrieval. Using linked data formats as the basic format for OSLC services has the following advantages: using URIs as names of things; using HTTP URIs so that people can look up these names; providing useful information when someone looks up a URI; using standards (RDF*, SPARQL) to include links to other URIs; so that they can discover more. URIs generated in the OSLC specification have a fixed generation format, including a unified OSLC service prefix, domain prefixes for different core domains, subdomain prefixes for the lifecycle of a particular data item, and the attribute type and number of that data.

[0037] In each core domain, the module responsible for data transmission and interaction is called the Creation Factory. It implements HTTP services for resource shapes (i.e., data) conforming to the OSLC standard, thereby enabling the interaction of network data streams. OSLC technology supports HTTP services including Create, Delete, Get, and Post, transmitting network data streams through URLs in resource shapes, thus enabling the interaction and transmission of heterogeneous data at different lifecycle stages in a unified format. Besides the OSLC Core Domain, it also has other auxiliary functions: the TRS module (Tracked Resource Set), responsible for historical tracking and backtracking of resource shapes; and the Query module, responsible for querying RDF-formatted resource shapes using SPARQL technology.

[0038] Based on the above technology, this patent parses and standardizes various attributes of Excel using OSLC, including the following four steps:

[0039] 1. WORKBOOK parsing: An Excel file needs to be parsed into a WorkBook object, including its corresponding file name, file path, and file identifier URI. These attributes will be packaged into a resource shape that conforms to the OSLC specification and encapsulated by the WORKBOOK class.

[0040] 2. SHEET parsing: Each Sheet in the WorkBook object needs to be parsed and its corresponding properties encapsulated into a SHEET class that conforms to the OSLC specification.

[0041] 3. ROW and CELL parsing: Used to parse all rows in each sheet, or directly parse all cells in each sheet. It also extracts the attributes of each row or cell and encapsulates them into ROW / CELL classes that conform to the OSLC specification.

[0042] 4. Excel2XMI: Besides parsing the basic Excel object types, it also needs to convert the various wrapper classes (WORKBOOK, SHEET, CELL, ROW) that conform to the OSLC specification into RDF resource formats for storage, i.e., storing them in XMI files. Therefore, the Excel OSLC Adapter implements an interface for the information stored in each written wrapper class, converting it into an RDF resource format. Then, the Excel adapter automatically parses these RDF resource formats, automatically generating URLs that access all their fixed attributes based on the URIs of the given namespaces in the RDF, and displaying them on the JSP front-end interface.

[0043] Step three involves developing OSLC-compliant adapters for standardized product information. The Lyo Designer project supports Java developers in creating REST-based servers and clients that need to share heterogeneous information as RDF resources. It promotes the use of relational data principles and the OSLC (Lifecycle Collaborative Open Services) standard to publish lifecycle data, enabling interoperability between heterogeneous products, services, and other distributed network resources. Lyo Designer allows for the development of adapters for pre-designed information.

[0044] Each adapter supports converting a data format type into a resource shape type conforming to the OSLC specification and implements HTTP service and resource query functions. Therefore, the entire lifecycle interaction of a product often requires the use of multiple adapters in conjunction. Below is the creation process for each OSLC adapter for Excel:

[0045] (1) Create and name an OSLC server (OSLC Service) and define its core domains. There are four core domains, as mentioned in step two. Each OSLC adapter should contain at least one core domain and at most four. The core code of each OSLC server is stored in an XML file, which can be expanded and visualized in Lyo Designer.

[0046] (2) Within the defined core domains, insert the product attributes or concepts involved in each core domain. These concepts were formally defined in step one and transformed into resource shapes conforming to the OSLC specification in step two, which can be directly written into the corresponding core domains. In this patent, the corresponding attributes of Excel (Workbook, Sheet, Row, Cell) will be loaded into the CCM domain, Excel2XMI will be loaded into the AM domain, and the Value will be loaded into the CCM and QM domains.

[0047] (3) Create a Service Provider. The Service Provider for each adapter is consistent; they are all OSLC services and are essentially indistinguishable. The Service Provider will extend into a catalog of services offered. Next, the services required by the client, such as HTTP services and CRUD services, need to be added to the extended branches of the Service Provider. In this patent, the HTTP services assigned to the Excel attribute are shown in the following table:

[0048] Excel Concept GET POST PUT DELETE QUERY WorkBook √ √ √ √ Sheet √ √ √ √ Row √ √ √ √ Cell √ √ √ √

[0049] (4) Check the integrity and legality of the code. Lyo Designer supports checking the legality of the built adapter to ensure that illegal situations (such as illegal data exchange) will not occur.

[0050] (5) Generate OSLC server. After checking the legality and completeness of the code, right-click the interface to automatically generate the corresponding OSLC server code. The code is written using a JSP framework and adopts a unified front-end and back-end approach. The generated code only has a framework that conforms to the OSLC standard; its specific functions are yet to be implemented.

[0051] At this point, the OSLC adapter can convert imported data into resource formats that conform to the OSLC standard, i.e., link data. However, how to process and parse the data still requires further improvement and supplementation.

[0052] Step four involves implementing the OSLC adapter's data interface. In step three, Lyo Designer has already implemented the initial setup of the OSLC adapter. For a specific data type, it stores the data type's decomposition pattern—that is, the divided attribute information—into a resource shape format conforming to the OSLC standard, i.e., the format for linking data. The OSLC adapter generates a corresponding URI for each attribute and data name to ensure the implementation of query and access functions. However, converting the imported data into a resource shape conforming to the OSLC standard still requires implementing the corresponding code.

[0053] In this step, this patent completes the interface implementation process of the Excel adapter. The interface conversion of Excel data types is implemented in the CCM domain:

[0054] (1) In the adapter code, add an Excel class (Class Excel) to parse the Excel data type. Since Java has implemented an Excel data parsing library, you can directly import it and call it to parse the data.

[0055] (2) Add the ExcelChangeManagement class to store the parsed Excel attribute information into resource shapes that conform to the OSLC standard. The OSLC adapter framework generated in step three provides the OSLC_Excel class, which stores resource shapes that conform to the OSLC standard for Bugzilla information. The parsed attribute information can be stored into the corresponding variables one by one.

[0056] (3) Implement the Excel_Query class. This class needs to perform queries based on the corresponding attribute information in RDF resource format. The code is written using the SPARQL framework and supports query functions such as Workbook, Row, Column, Cell, and global queries.

[0057] (4) Import the Excel file and put it into use. Import the corresponding .xls or .xlsx file into the JSP front-end file. The Excel adapter will automatically parse the corresponding file and generate a corresponding URI that can access the value for each resource directory and resource.

[0058] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements can be made without departing from the principle of the present invention, and these improvements should also be considered within the scope of protection of the present invention.

Claims

1. An OSLC based full life cycle requirements domain data web enablement method, characterized in that, The method comprises the following steps: Step one, preparing multi-source heterogeneous data in the demand domain; Step two, standardizing and reconstructing the data: analyzing the rules and characteristics of different data sources, determining the inherent attributes of the data, and performing fine-grained analysis of the model data to provide preparation for the production of Excel adapters; Step three: building the framework of the OSLC adapter for Excel: using Lyo Designer and the inherent attributes determined in step two to design an adapter for the data source to generate a specific network URL and realize the networking of the data; Step four: based on the generated OSLC adapter framework, perfect the CRUD function of the corresponding data structure and the networked HTTP service; at the same time, through the SPARQL technology, the unified generated network URL is used to realize the automatic query access function of the data and its inherent attributes; In step two, OSLC is introduced, and the data types obtained in step one are modeled and analyzed under the OSLC service. A unified OSLC standard is used to formally define and divide different data types, ensuring the uniformity and flowability of the data. The unified OSLC standard reconstructs the form of the data division in step one, which includes the following two aspects: 1) OSLC specification provides basic services across the entire product life cycle, called OSLC Core Domain, which includes resource preview, service discovery, and query basic functions; 2) OSLC specification distinguishes different product attributes and includes them in the OSLC domain specification; different domain specifications include: Change Management and Configuration Management Domain, Architecture Management, Requirements Management (RM, requirement management), and Quality Management.

2. The OSLC based full life cycle requirements domain data networked approach as claimed in claim 1, wherein, In step one, multi-source heterogeneous demand domain data is obtained from different sensors or different data suppliers, and the data has different data structures or data organization forms.

3. The OSLC based full life cycle requirements domain data networked approach as claimed in claim 1, wherein, The product attributes are used as the first division point for dynamic division, and the product attributes are used to divide the OSLC Domain, and then the domains of the product become the sub-domains of the OSLC Domain; each product life cycle domain can exist in different OSLC Domains, and once a product life cycle exists in an OSLC Domain, the sub-domains in the OSLC Domain can legally interact across domains, and the same sub-domains between each OSLC Domain have no direct connection.

4. The OSLC based full life cycle requirements domain data networked approach as claimed in claim 1, wherein, In the third step, the OSLC-compliant adapter is developed using Lyo Designer for the standardized OSLC-compliant data information; the Lyo Designer project supports Java developers to develop REST-based servers and clients that need to share heterogeneous information as RDF resources; The association data principle and the OSLC standard publishing life cycle data are used to realize the interoperability of heterogeneous products, services and other distributed network resources.

5. The OSLC based full life cycle requirements domain data web- enabled method according to claim 4, wherein, Each adapter supports the conversion of a specific data format type into an OSLC-compliant resource shape type, and realizes the HTTP service and resource query functions; The adapter building process is: creating and naming an OSLC server -> supplementing the corresponding domain definition -> establishing a service provider -> checking the integrity and legality of the code -> generating an OSLC server.

6. The OSLC based full life cycle requirements domain data web- enabled method according to claim 5, wherein, The adapter supports the CRUD and query services, realizes the access to the corresponding data through the corresponding uniform format URL, supports the POST and GET HTTP services with the Web, realizes the cross-domain data interaction, and finally integrates the adapter on the Web platform to realize the unified processing of cross-domain heterogeneous data.

Images