An oslc-based lifecycle heterogeneous data packaging and tracing method
By introducing a custom vocabulary and resource shapes into the OSLC framework, a traceability semantic chain model is established, which solves the problems of inconsistent semantic descriptions and broken traceability chains between heterogeneous systems, and achieves data consistency and efficient traceability in complex systems.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- HANGZHOU HUAWANG SYST TECH CO LTD
- Filing Date
- 2026-03-09
- Publication Date
- 2026-06-09
AI Technical Summary
In the field of complex systems engineering, the existing OSLC standard cannot effectively achieve cross-system semantic traceability and automated integration, resulting in inconsistent semantic descriptions of heterogeneous data sources and broken traceability chains, making it difficult to achieve information consistency and process traceability throughout the entire lifecycle.
By introducing a custom vocabulary and resource shapes into the OSLC framework, and establishing an extensible semantic encapsulation mechanism and a semantic chain tracing model through RDF semantic registration and DFS tracing algorithm, unified semantic description and automated tracing are achieved between heterogeneous systems.
It achieves standardized encapsulation and consistent parsing of heterogeneous data, solves the problem of information gaps across stages, improves data reliability and traceability efficiency, and is suitable for multi-source collaborative engineering lifecycle management.
Smart Images
Figure CN122173515A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of systems engineering and lifecycle data management technology, and in particular to a method for encapsulating and tracing heterogeneous lifecycle data based on OSLC. Background Technology
[0002] In complex systems engineering fields such as aerospace, automotive electronics, and large equipment manufacturing, products typically employ software tools from different vendors for data management and model building throughout the demand, design, simulation, testing, and maintenance phases. Due to differences in data structures, semantic models, and interface protocols among these tools, numerous independent and heterogeneous data sources emerge, making it difficult to achieve information consistency and process traceability throughout the entire lifecycle. Existing integration solutions often achieve data exchange through interface adaptation or file conversion, but lack a unified semantic description standard, leading to inconsistencies in cross-system data encapsulation, semantic loss, and broken traceability chains. The OSLC (Open Services for Lifecycle Collaboration) standard provides an open resource model and interface specification for system lifecycle collaboration, achieving unified data access through a RESTful architecture. However, existing OSLC domain specifications only cover common scenarios such as requirements, quality, and changes, lacking sufficient support for data types and semantic relationships in customized domains such as system modeling and simulation verification, thus failing to achieve cross-stage semantic traceability and automated integration. Therefore, there is an urgent need for a mechanism that can expand the domain vocabulary and resource shapes on the basis of the existing OSLC framework, form a unified semantic encapsulation system, and establish a traceable semantic chain that can be parsed by machines, so as to realize the semantic interconnection and full-link traceability of data between heterogeneous systems, thereby improving the consistency and visualization management capabilities of engineering data. Summary of the Invention
[0003] One objective of this invention is to propose a lifecycle heterogeneous data encapsulation and tracing method based on OSLC. By establishing a scalable semantic encapsulation mechanism and a tracing semantic chain model, it achieves unified semantic description and automated tracing of data resources between heterogeneous systems. This invention introduces a custom vocabulary, resource shape, and cascading constraint mechanism into the original OSLC framework. Through RDF semantic registration and DFS tracing algorithm, it generates a full lifecycle integrated view, possessing the advantages of strong semantic consistency, accurate data association, and efficient tracing execution.
[0004] A method for encapsulating and tracing heterogeneous lifecycle data based on OSLC according to an embodiment of the present invention includes the following steps:
[0005] S1. Analyze the data sources of each software tool in the system engineering life cycle, determine the new domain category to which each tool belongs, and identify the types, attributes, and semantic relationships of data resources that need to be exposed;
[0006] S2. Based on the principles of coverage and minimum, the types and attributes of the data resources to be exposed are screened and limited to clarify the data scope and semantic boundaries;
[0007] S3. Construct an extensible semantic encapsulation mechanism, formulate a custom vocabulary that includes namespaces, resource classes and attribute definitions, and supplement the domain semantics not covered by the OSLC standard;
[0008] S4. Establish resource shapes corresponding to the vocabulary, and use oslc:ResourceShape to define the cardinality, value type and range of attributes to form a semantic constraint framework that can be parsed by the system, providing a structural basis for tracing the cascading constraints of semantic chains.
[0009] S5. Establish a traceability semantic chain mechanism, identify the relationship between upstream and downstream resources based on the life cycle link, define custom traceability attributes for relationships not covered by the standard and embed resource shapes to form cascade constraints, and generate a traceability semantic chain containing resource type, relationship attributes and constraint information.
[0010] S6. Register the traceability semantic chain in the system semantic library in machine-readable RDF form so that the relationship attributes and constraints between resources can be automatically identified and parsed, supporting the system to perform forward or backward traceability.
[0011] S7. Construct an OSLC adapter corresponding to the resource shape, enable resource access through RESTful API, and generate a lifecycle-wide integrated view based on the traceability semantic chain and DFS algorithm.
[0012] Optionally, the coverage principle in step S2 specifically includes: the selected resource class and attributes can support the characterization and interaction of all data resources that need to be exposed in the scenario modeled by the domain, and can clearly describe the association and traceability of data resources at the semantic level. The minimum principle in step S2 specifically includes: the selected resource class and attributes have no redundancy or duplication after completing the above support functions.
[0013] Optionally, S3 specifically includes:
[0014] S31. During the vocabulary building phase, allocate globally unique and persistent namespace URIs to new domains to ensure that semantic definitions have unique identifiers and long-term resolvability across different systems and versions; the namespace URIs adopt the Uniform Resource Identifier standard structure and are mapped to business classifications, data models and version information within the domain.
[0015] S32. Define resource classes using rdfs:Class or owl:Class to represent the type hierarchy of semantic objects, and construct inheritance relationships, attribute inheritance, and semantic constraint chains between resource classes; define resource attributes using rdf:Property to describe the key features of resources, attribute value types, and semantic relationships between resources, and limit the domain and range of attributes using rdfs:domain and rdfs:range; attributes can include identifier attributes, state attributes, and associated attributes, where associated attributes express the logical connections between cross-system data.
[0016] S33. Use oslc:ResourceShape to impose structured constraints on the attributes of resource classes, specifying the attribute cardinality, value type, value range, and data constraint rules. Implement value validity verification through oslc:valueType and oslc:range, control attribute multi-valuedness through oslc:occurs, and limit the allowed value set by combining oslc:allowedValue. The constraint mechanism ensures that the encapsulated semantic model remains consistent during machine parsing and data exchange.
[0017] S34. Combine the namespaces, resource classes, attributes, and resource shapes defined in steps S31 to S33 to form a complete semantic vocabulary and constraint file, and generate machine-readable documents in RDF or Turtle format. Publish the documents through a stable public URL so that other systems can directly access and reference them, supporting semantically consistent data encapsulation and collaborative interoperability between heterogeneous systems.
[0018] Optionally, S3 specifically includes:
[0019] When defining resource shapes, oslc:propertyDefinition is used to point to the formal definition of the attribute in the vocabulary via URI, establishing a direct link between each attribute and the semantic item in the vocabulary. This creates a one-to-one mapping between resource shapes and the vocabulary at the semantic layer.
[0020] The oslc:occurs property defines the cardinality of an attribute, specifying the number of times the attribute appears in a resource instance. When the cardinality is set to Exactly-one, the attribute is required; when it is set to Zero-or-one, the attribute is optional; and when it is set to Zero-or-many, the attribute is allowed to appear multiple times.
[0021] The `oslc:valueType` keyword specifies the data type of an attribute. When `valueType` is `Literal`, the attribute value is a literal, such as a string, boolean, or numeric type. When `valueType` is `Resource`, the attribute value is a reference to another resource, and the system establishes a cross-resource link through the reference identifier. When `valueType` is `LocalResource`, it refers to a local resource within the same namespace.
[0022] When the attribute type is Resource, use oslc:range to limit the RDF type of the referenced resource by explicitly declaring the type boundary of the referenced target; in the literal value scenario, use oslc:allowedValue to define the set of possible values and limit the attribute value to come from the preset enumeration range.
[0023] The oslc:readOnly property indicates whether a resource property is allowed to be written. When the value is true, it means that the property can only be read and cannot be modified.
[0024] Optionally, S5 specifically includes:
[0025] S51. Identify Traceability Paths: Based on the system engineering lifecycle model, semantic analysis is performed on the entire process from requirement definition, system modeling, simulation verification, test execution to defect closure. The key data resource types at each stage and the logical and semantic relationships between them are identified, and an end-to-end traceability path graph describing the mapping from upstream resources to downstream resources is constructed. The traceability path is represented by a graph structure, where each node corresponds to a resource type and each edge represents a semantic relationship. By analyzing data dependencies, input-output relationships, and business process sequences, the set of shortest traceable paths between resources is determined, forming a traceability topology within the lifecycle.
[0026] S52. Define traceability relationship attributes: For resource associations involved in the traceability path, if the OSLC standard relationship attributes cannot accurately describe the semantics, then define dedicated traceability relationship attributes in the custom vocabulary. The traceability attributes declare semantic content with rdf:Property, and specify the domain and range of the relationship through rdfs:domain and rdfs:range. Attribute annotation information, including relation semantic description, constraint rules, and visual labels, can be introduced during definition.
[0027] S53. Establish shape cascading constraints: In the shape definition of resources involving relationships, the traceability relationship attribute defined in S52 is referenced through oslc:propertyDefinition, and the shape type of the associated resource is constrained by the oslc:valueShape parameter, requiring the referenced resource to conform to the specified shape definition; when there are hierarchical dependencies between resources, a multi-level shape dependency network is established recursively to form a top-down shape cascading constraint structure.
[0028] S54. Publish Semantic Chain Specification: After the definition is completed, the tracing semantic chain will generate a semantic specification file in machine-readable RDF or Turtle format. The file contains resource types, relationship attributes, shape constraints, and URI identifiers. The semantic chain specification file is registered in the system semantic library and assigned a unique namespace address. Through the published semantic chain specification, the system can automatically identify resource types, parse relationship attributes, and load the corresponding shape constraints when performing tracing.
[0029] Optionally, the relationships not covered by the standard in step S5 specifically include: cross-stage resource association relationships within the system engineering lifecycle that are not included in existing OSLC domain specifications, including but not limited to custom traceability relationships for system model verification simulation models, simulation model verification test cases, and test case triggering defect types; the custom traceability relationship defines attribute semantics through rdf:Property, and uses rdfs:domain and rdfs:range to limit the domain and range of the relationship, then embeds the attribute into the corresponding resource shape, and constrains the type and structure of the target resource through oslc:valueShape.
[0030] Optionally, step S6 specifically includes: storing the traceability semantic chain file generated in step S5 in the system semantic library in RDF or Turtle format, and uniquely identifying each type of resource, relational attribute, and shape constraint by URI; parsing the semantic definition in the RDF document when the system is loaded, establishing an index mapping table between resources, and automatically reading and parsing the corresponding relationship when the adapter performs traceability.
[0031] Optionally, S7 specifically includes: when performing lifecycle tracing analysis, performing forward tracing or backward tracing based on the tracing semantic chain; the forward tracing refers to: starting from the upstream resource, searching for all associated downstream resources along the tracing relationship attributes; the backward tracing refers to: starting from the downstream resource, searching for all upstream source resources in reverse along the tracing relationship attributes; and using the DFS algorithm, extracting the associated entire data link resources from the resources at any node of the lifecycle as the initial node.
[0032] The beneficial effects of this invention are:
[0033] (1) This invention constructs an extensible semantic encapsulation mechanism. By extending the OSLC standard with a custom vocabulary and resource shapes, it can unify the semantic definition and structural constraints of data resources output by different software tools, and realize the standardized encapsulation and cross-system consistent parsing of heterogeneous data. (2) This invention proposes a traceability semantic chain mechanism to establish end-to-end resource association relationships between each stage of the life cycle. It semantically associates upstream requirements, system models, simulation models, test cases and defect information to form a traceability link that can be automatically identified by the system, solving the problem of cross-stage information gaps in traditional methods. (3) This invention forms cascading constraints by embedding traceability relationship attributes in resource shapes, so that the structural relationships between different resources remain consistent. When the system changes, it can realize dynamic updates and consistency verification of traceability paths, improving data reliability and link maintainability. (4) This invention adopts RDF semantic registration and DFS traversal algorithms to realize the automatic loading and execution of traceability semantic chains in the system semantic library. Users can generate a full life cycle integrated view from any node, which significantly improves the data transparency and traceability efficiency of complex systems and is suitable for multi-source collaborative engineering life cycle management scenarios. Attached Figure Description
[0034] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:
[0035] Figure 1 This is a flowchart of a method for encapsulating and tracing heterogeneous lifecycle data based on OSLC proposed in this invention.
[0036] Figure 2 This is a flowchart of an extensible semantic encapsulation mechanism for a lifecycle heterogeneous data encapsulation and tracing method based on OSLC proposed in this invention.
[0037] Figure 3 This is a flowchart of the traceability semantic chain mechanism of a lifecycle heterogeneous data encapsulation and traceability method based on OSLC proposed in this invention. Detailed Implementation
[0038] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.
[0039] refer to Figure 1-3 A method for encapsulating and tracing heterogeneous lifecycle data based on OSLC includes the following steps:
[0040] S1. Analyze the data sources of each software tool in the system engineering life cycle, determine the new domain category to which each tool belongs, and identify the data resource types, attributes, and semantic relationships that need to be exposed; the data to be exposed specifically includes the data resource types and attribute sets that can be accessed, shared, exchanged, and participate in semantic encapsulation, as determined by semantic analysis during the life cycle collaboration process of each software tool.
[0041] S2. Based on the principles of coverage and minimum, the types and attributes of the data resources to be exposed are screened and limited to clarify the data scope and semantic boundaries;
[0042] S3. Construct an extensible semantic encapsulation mechanism, formulate a custom vocabulary that includes namespaces, resource classes and attribute definitions, and supplement the domain semantics not covered by the OSLC standard;
[0043] S4. Establish resource shapes corresponding to the vocabulary, and use oslc:ResourceShape to define the cardinality, value type and range of attributes to form a semantic constraint framework that can be parsed by the system.
[0044] S5. Establish a traceability semantic chain mechanism, identify the relationship between upstream and downstream resources based on the life cycle link, define custom traceability attributes for relationships not covered by the standard and embed resource shapes to form cascade constraints, and generate a traceability semantic chain containing resource type, relationship attributes and constraint information.
[0045] S6. Register the traceability semantic chain in the system semantic library in machine-readable RDF form so that the relationship attributes and constraints between resources can be automatically identified and parsed, supporting the system to perform forward or backward traceability.
[0046] S7. Construct an OSLC adapter corresponding to the resource shape, enable resource access through RESTful API, and generate a lifecycle-wide integrated view based on the traceability semantic chain and DFS algorithm.
[0047] In this embodiment, the coverage principle in step S2 specifically includes: the selected resource class and attributes can support the characterization and interaction of all data resources that need to be exposed in the scenario modeled by the domain, and can clearly describe the association and traceability of data resources from a semantic level. The minimum principle in step S2 specifically includes: the selected resource class and attributes have no redundancy or duplication after completing the above support functions.
[0048] In this embodiment, S3 specifically includes:
[0049] S31. During the vocabulary building phase, allocate globally unique and persistent namespace URIs to new domains to ensure that semantic definitions have unique identifiers and long-term resolvability across different systems and versions; the namespace URIs adopt the Uniform Resource Identifier standard structure and are mapped to business classifications, data models and version information within the domain.
[0050] S32. Based on the RDF data description of each business object in the enterprise lifecycle management system, construct resource semantic encapsulation units in accordance with the OSLC resource modeling specification, define resource classes and attribute relationships, and form an initial semantic model.
[0051] S33. Use oslc:ResourceShape to impose structured constraints on the attributes of resource classes, clarify the attribute cardinality, value type, value range and data constraint rules, use oslc:valueType and oslc:range to implement value validity verification, use oslc:occurs to control the multi-valuedness of attributes, and combine oslc:allowedValue to limit the set of allowed values.
[0052] S34. Combine the namespaces, resource classes, attributes, and resource shapes defined in steps S31 to S33 to form a complete semantic vocabulary and constraint file, and generate machine-readable documents in RDF or Turtle format. Publish the documents through a stable public URL so that other systems can directly access and reference them, supporting semantically consistent data encapsulation and collaborative interoperability between heterogeneous systems.
[0053] In this embodiment, S3 specifically includes:
[0054] When defining resource shapes, oslc:propertyDefinition is used to point to the formal definition of the attribute in the vocabulary via URI, establishing a direct link between each attribute and the semantic item in the vocabulary, so that the resource shape and the vocabulary form a one-to-one mapping at the semantic layer.
[0055] The oslc:occurs property defines the cardinality of an attribute, specifying the number of times the attribute appears in a resource instance. When the cardinality is set to Exactly-one, the attribute is required; when it is set to Zero-or-one, the attribute is optional; and when it is set to Zero-or-many, the attribute is allowed to appear multiple times.
[0056] The `oslc:valueType` keyword specifies the data type of an attribute. When `valueType` is `Literal`, the attribute value is a literal, such as a string, boolean, or numeric type. When `valueType` is `Resource`, the attribute value is a reference to another resource, and the system establishes a cross-resource link through the reference identifier. When `valueType` is `LocalResource`, it refers to a local resource within the same namespace.
[0057] When the attribute type is Resource, use oslc:range to limit the RDF type of the referenced resource by explicitly declaring the type boundary of the referenced target; in the literal value scenario, use oslc:allowedValue to define the set of possible values and limit the attribute value to come from the preset enumeration range.
[0058] The oslc:readOnly property indicates whether a resource property is allowed to be written. When the value is true, it means that the property can only be read and cannot be modified.
[0059] In this embodiment, S5 specifically includes:
[0060] S51. Identify Traceability Paths: Based on the system engineering lifecycle model, semantic analysis is performed on the entire process from requirement definition, system modeling, simulation verification, test execution to defect closure. The key data resource types at each stage and the logical and semantic relationships between them are identified, and an end-to-end traceability path graph describing the mapping from upstream resources to downstream resources is constructed. The traceability path is represented by a graph structure, where each node corresponds to a resource type and each edge represents a semantic relationship. By analyzing data dependencies, input-output relationships, and business process sequences, the set of shortest traceable paths between resources is determined, forming a traceability topology within the lifecycle.
[0061] S52. Define traceability relationship attributes: For resource associations involved in the traceability path, if the OSLC standard relationship attributes cannot accurately describe the semantics, dedicated traceability relationship attributes are defined in a custom vocabulary. Traceability attributes declare semantic content using `rdf:Property`, and specify the domain and range of the relationship using `rdfs:domain` and `rdfs:range`. Attribute annotation information, including semantic descriptions, constraint rules, and visual labels, can be introduced during definition. The resource associations are semantic links between data resources at different lifecycle stages, used to describe dependencies, references, or verification correspondences between upstream and downstream resources. Resource associations are typically represented as attributes, such as "system model implementation requirements," "simulation model verification of the system model," and "test case verification of the simulation model," establishing semantic connections between resources through attribute references. Associations are the foundation for establishing subsequent traceability semantic chains, and the definition results determine the topology and hierarchical order of the traceability path.
[0062] S53. Establish shape cascading constraints: In the shape definitions of resources involving relationships, the traceability attribute defined in S52 is referenced through oslc:propertyDefinition, and the shape type of the associated resource is constrained by the oslc:valueShape parameter, requiring the referenced resource to conform to the specified shape definition; when there are hierarchical dependencies between associated resources, a multi-level shape dependency network is established recursively, and the shape definition of the upper-level resource can pass constraints on the shape instance of the lower-level resource; the multi-level shape dependency network specifically includes:
[0063] Dependency analysis is performed on each resource shape involved in the traceability to determine the reference relationship between upstream and downstream resource shapes. Whenever a traceability relationship attribute is defined and used in a resource shape, the system establishes a reference edge from the upper-level shape to the lower-level shape at the semantic layer when oslc:valueShape points to another resource shape.
[0064] A hierarchical directed graph structure is constructed using resource shapes as nodes and attribute references as edges. Each node in the graph contains a unique URI identifier for the shape, a set of attribute constraints, and dependency information pointing to lower-level shapes. If a shape is referenced by multiple parent shapes, a multi-input edge structure is formed in the graph, indicating that the lower-level resource is shared by multiple parent semantic domains.
[0065] After the construction is completed, a shape cascade index table is built by traversing the directed graph. The index table records the hierarchical depth, parent-child relationship and constraint propagation path of each shape node, so that the system can access the referenced shape level by level and load the constraint parameters when performing tracing or verification.
[0066] The multi-level shape dependency network consists of three parts: a node set (shape URI), attribute definitions, constraint parameters, an edge set (attribute reference relationships), and an index table (hierarchical path mapping). The establishment of the network enables the structural constraints between resources to have hierarchical propagation capabilities. When the upper-level shape structure or attributes change, they can be automatically propagated and updated along the dependency path.
[0067] S54. Publish Semantic Chain Specification: After the definition is completed, the tracing semantic chain will generate a semantic specification file in machine-readable RDF or Turtle format. The file contains resource types, relationship attributes, shape constraints, and URI identifiers. The semantic chain specification file is registered in the system semantic library and assigned a unique namespace address. Through the published semantic chain specification, the system can automatically identify resource types, parse relationship attributes, and load the corresponding shape constraints when performing tracing.
[0068] In this embodiment, the relationships not covered by the standard in step S5 specifically include: cross-stage resource association relationships within the system engineering lifecycle that are not included in the existing OSLC domain specifications, including but not limited to custom traceability relationships for system model verification simulation models, simulation model verification test cases, and test case triggering defect types; the custom traceability relationship defines attribute semantics through rdf:Property, and uses rdfs:domain and rdfs:range to limit the domain and range of the relationship, then embeds the attribute into the corresponding resource shape, and constrains the type and structure of the target resource through oslc:valueShape.
[0069] In this embodiment, S6 specifically includes: storing the traceability semantic chain file generated in step S5 in the system semantic library in RDF or Turtle format, and uniquely identifying each type of resource, relational attribute and shape constraint by URI; when the system is loaded, parsing the semantic definition in the RDF document, establishing an index mapping table between resources, and the adapter automatically reads and parses the corresponding relationship when performing traceability; the index mapping table specifically includes: (1) resource identification information: recording each resource type and its corresponding unique URI, used to identify the position of the resource in the semantic library; (2) relational attribute mapping: recording the traceability relational attribute name, attribute type and the correspondence between rdfs:domain and rdfs:range between each resource; (3) shape constraint pointer: recording the URI of each resource shape file and the corresponding oslc:ResourceShape constraint information, used to load structural constraints when tracing; (4) hierarchical path index: recording the upstream and downstream mapping paths and hierarchical depth between resources, used to determine the access order when tracing forward or backward; (5) reverse index: recording the reverse reference relationship from the target resource to the upstream resource, supporting reverse traceability query;
[0070] The adapter automatically reads and parses the following specific details during the traceback process:
[0071] During the system loading phase, the adapter calls the traceability semantic chain file registered in the semantic library. By parsing the resource types, relational attributes, and shape constraints defined in the RDF or Turtle document, it establishes a memory-level index cache. When a traceability request is received, the adapter automatically retrieves the set of relational attributes associated with the starting resource URI from the index cache based on the starting resource URI specified in the request. The adapter determines the range of accessible target resources based on the rdfs:domain and rdfs:range information corresponding to the relational attributes, and loads the corresponding target resource shape constraints according to the oslc:valueShape pointer. During the access process, the adapter traverses the relevant resource nodes sequentially according to the hierarchical path in the index mapping table, parses and matches the attribute references of each node, and generates a structured traceability path object. After parsing, the system outputs the traceability results in RDF triples or JSON-LD format.
[0072] In this embodiment, S7 specifically includes: when performing lifecycle tracing analysis, performing forward tracing or backward tracing based on the tracing semantic chain; forward tracing refers to: starting from upstream resources and searching for all associated downstream resources along the tracing relationship attributes; backward tracing refers to: starting from downstream resources and searching for all upstream source resources in reverse along the tracing relationship attributes; using the DFS algorithm, extracting the associated entire data link resources from the resources at any node of the lifecycle as the initial node.
[0073] Example 1: In this example, the development of an aerospace flight control system is used as the application background. It requires data integration of five core tools: M-require (requirements management tool), M-arch (system modeling tool), M-design (simulation management tool), HP-ALM (test management tool), and Bugzilla (defect management tool). These tools are located at different stages of the system engineering lifecycle, and the data they generate is significantly heterogeneous, requiring unified encapsulation and traceability through the OSLC standard.
[0074] S1. Analyze system engineering lifecycle data. First, analyze the data sources and business scenarios of each software tool to determine the new domain scope to which each tool belongs, and identify the types, attributes, and semantic relationships of data resources that need to be exposed. In this process, adhere to the principles of coverage and minimum. The coverage principle requires that the selected resource classes and attributes can fully describe all resources that need to be exposed in the domain; the minimum principle requires avoiding redundancy and duplication. Tool vendors need to create a domain model document, listing all resource types, attributes, and relationships, and indicating which can directly reuse OSLC standard vocabulary and which require custom extensions. The document output is a domain scope definition file, providing input for subsequent vocabulary development.
[0075] Table 1 shows some of the resource classes and attributes that need to be exposed in the M-require requirements management tool. Since the requirements management domain is covered by the OSLCRequirementsManagement2.1 specification, standard class and attribute definitions can be directly reused. For example, requirements, requirement sets, requirement refinement relationships, and requirement specification relationships can be directly defined using the oslc_rm standard, while attributes such as requirement identifiers, requirement titles, and requirement descriptions can reference DublinCore metadata terms.
[0076] Table 1
[0077] Vocabulary Name type Lexical semantics oslc_rm:Requirement Reuse OSLCRM standard classes need oslc_rm:RequirementCollection Reuse OSLCRM standard classes Demand Set dcterms:identifier Reuse OSLCCore specification, DublinCore metadata terminology, resource attributes Demand identifier dcterms:description Reuse OSLCCore specification, DublinCore metadata terminology, resource attributes Detailed requirements dcterms:title Reuse OSLCCore specification, DublinCore metadata terminology, resource attributes Requirement Title oslc_rm:elaboratedBy Reuse OSLCRM standard attributes Detailed Relationship of Requirements oslc_rm:specifiedBy Reuse OSLCRM standard attributes Requirements specification relationship
[0078] S2: Filter and limit resource types and attributes. Based on the domain model document output by S1, classify and filter heterogeneous data at different lifecycle stages, identifying domains not covered by the OSLC standard, such as the system modeling domain. For the uncovered portions, a custom vocabulary and namespace need to be established to define new resource classes and attributes. For example, the domain vocabulary namespace of the M-arch system modeling tool is: @prefixm_arch:<http: / / mbse.com / ns / architecture#>
[0079] Table 2
[0080] Vocabulary Name type Lexical semantics m_arch:ArchitectureModel Custom resource class System architecture model m_arch:Component Custom resource class Components m_arch:Interface Custom resource class interface dcterms:description Reuse OSLC Core specifications, Dublin Core metadata terminology, and resource attributes. Detailed description of the system model dcterms:title Reuse OSLC Core specifications, Dublin Core metadata terminology, and resource attributes. System Model Title m_arch:modelType Custom resource properties System Model Types m_arch:modelVersion Custom resource properties System Model Version m_arch:implementsRequirement Custom resource properties System model realizes requirement relationship
[0081] S3: Construct an extensible semantic encapsulation mechanism to create a custom vocabulary and resource shapes for domain terms not covered by OSLC. The vocabulary definition phase includes: defining namespace URIs; defining resource classes and semantic descriptions using rdfs:Class or owl:Class; defining resource attributes and value types using rdf:Property; and constraining attributes using oslc:ResourceShape, including attribute cardinality, value type, and value range.
[0082] The generated vocabulary and resource shapes are published in RDF or Turtle format under public URIs, allowing different systems to directly parse the semantic definitions. For example, the m_arch:modelType attribute is defined as a string type, allowing values to be limited to "logical" or "physical," and the enumeration range is constrained in the resource shape using oslc:allowedValue.
[0083] S4: Establish a resource shape and semantic constraint framework. Create resource shapes corresponding to the vocabulary, and use `oslc:ResourceShape` to define the cardinality, value type, and range of each attribute, forming a semantic constraint framework that can be parsed by the system. Establish a bidirectional mapping relationship between `propertyDefinition` and the vocabulary, ensuring that semantic definitions and data constraints correspond to each other, providing a structural foundation for subsequent tracing of cascading constraints in the semantic chain.
[0084] S5: Establish a traceability semantic chain mechanism, defining an end-to-end traceability semantic chain between system modeling, simulation, testing, and defect management tools. The traceability path includes: Requirements → System Model → Simulation Model → Test Case → Defect. The associated attributes of each stage are as follows:
[0085] oslc_rm:implementedBy, m_arch:validatedBy, sim:verifiedBy, cm:triggeredBy.
[0086] The system establishes a traceability semantic chain file based on these attributes, recording resource types, relationship attributes, and shape constraint information in an RDF graph structure, and registers it in the semantic library. Forward traceability starts from the requirement, while backward traceability traces back from the defect to the requirement. Both traceability methods are implemented using a depth-first search algorithm.
[0087] S6: Semantic Chain Registration and Index Mapping. The system stores the semantic chain file in RDF or Turtle format in the system's semantic library, uniquely identifying resource types, relationship attributes, and shape constraints via URIs. After parsing the RDF document, the system establishes an index mapping table, which includes: resource identification information, relationship attribute mappings, shape constraint pointers, hierarchical path indexes, and inverted indexes, used for quickly locating resource relationships and tracing paths.
[0088] S7: Constructing the OSLC adapter and trace execution. The OSLC adapter is set up as a backend service, providing RESTful interfaces (GET / POST / PUT / DELETE) for various resources to achieve standardized data exposure. The adapter automatically reads the trace semantic chain file registered in the semantic library, parses the RDF semantic definition during system load, and establishes a memory-level index cache. When a trace request is received, the adapter retrieves the corresponding relational attributes and constraint information based on the resource URI, performs a DFS traversal according to the index path, automatically parses and generates the trace chain result, and outputs it in RDF or JSON-LD format, realizing a full lifecycle integrated view.
[0089] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.
Claims
1. A method for encapsulating and tracing heterogeneous lifecycle data based on OSLC, characterized in that, Includes the following steps: S1. Analyze the data sources of each software tool in the system engineering life cycle, determine the new domain category to which each tool belongs, and identify the types, attributes, and semantic relationships of data resources that need to be exposed; S2. Based on the principles of coverage and minimum, the types and attributes of the data resources to be exposed are screened and limited to clarify the data scope and semantic boundaries; S3. Construct an extensible semantic encapsulation mechanism, formulate a custom vocabulary that includes namespaces, resource classes and attribute definitions, and supplement the domain semantics not covered by the OSLC standard; S4. Establish resource shapes corresponding to the vocabulary, and use oslc:ResourceShape to define the cardinality, value type and range of attributes to form a semantic constraint framework that can be parsed by the system. S5. Establish a traceability semantic chain mechanism, identify the relationship between upstream and downstream resources based on the life cycle link, define custom traceability attributes for relationships not covered by the standard and embed resource shapes to form cascade constraints, and generate a traceability semantic chain containing resource type, relationship attributes and constraint information. S6. Register the traceability semantic chain in the system semantic library in machine-readable RDF form so that the relationship attributes and constraints between resources can be automatically identified and parsed, supporting the system to perform forward or backward traceability. S7. Construct an OSLC adapter corresponding to the resource shape, enable resource access through RESTful API, and generate a lifecycle-wide integrated view based on the traceability semantic chain and DFS algorithm.
2. The method for encapsulating and tracing heterogeneous lifecycle data based on OSLC according to claim 1, characterized in that, The coverage principle in step S2 specifically includes: the selected resource classes and attributes should be able to support the characterization and interaction of all data resources that need to be exposed in the scenario modeled by the domain, and should be able to clearly describe the association and traceability of data resources at the semantic level. The minimum principle in step S2 specifically includes: the selected resource classes and attributes should not be redundant or duplicated after completing the above support functions.
3. The method for encapsulating and tracing heterogeneous lifecycle data based on OSLC according to claim 1, characterized in that, S3 specifically includes: S31. During the vocabulary building phase, allocate globally unique and persistent namespace URIs to new domains to ensure that semantic definitions have unique identifiers and long-term resolvability across different systems and versions; the namespace URIs adopt the Uniform Resource Identifier standard structure and are mapped to business classifications, data models and version information within the domain. S32. Based on the RDF data description of each business object in the enterprise lifecycle management system, construct resource semantic encapsulation units in accordance with the OSLC resource modeling specification, define resource classes and their attribute relationships, and form an initial semantic model. S33. Use oslc:ResourceShape to impose structured constraints on the attributes of resource classes, clarify the attribute cardinality, value type, value range and data constraint rules, implement value validity verification through oslc:valueType and oslc:range, control attribute multi-valuedness through oslc:occurs, and limit the set of allowed values in combination with oslc:allowedValue to ensure the consistency of the encapsulated semantic model in machine parsing and data exchange. S34. Combine the namespaces, resource classes, attributes, and resource shapes defined in steps S31 to S33 to form a complete semantic vocabulary and constraint file, and generate machine-readable documents in RDF or Turtle format. Publish the documents through a stable public URL so that other systems can directly access and reference them, supporting semantically consistent data encapsulation and collaborative interoperability between heterogeneous systems.
4. The OSLC-based method for encapsulating and tracing heterogeneous lifecycle data according to claim 3, characterized in that, S3 specifically includes: When defining resource shapes, oslc:propertyDefinition is used to point to the formal definition of the attribute in the vocabulary via URI, establishing a direct link between each attribute and the semantic item in the vocabulary, so that the resource shape and the vocabulary form a one-to-one mapping at the semantic layer. The oslc:occurs property defines the cardinality of an attribute, specifying the number of times the attribute appears in a resource instance. When the cardinality is set to Exactly-one, the attribute is required; when it is set to Zero-or-one, the attribute is optional; and when it is set to Zero-or-many, the attribute is allowed to appear multiple times. Use `oslc:valueType` to specify the value type of an attribute. When `valueType` is `Literal`, the attribute value is literal data, such as a string, boolean, or numeric type. When `valueType` is `Resource`, the attribute value is a reference to another resource, and the system establishes a cross-resource link through the reference identifier. When `valueType` is `LocalResource`, it refers to a local resource within the same namespace. When the attribute type is Resource, use oslc:range to limit the RDF type of the referenced resource by explicitly declaring the type boundary of the referenced target; in the literal value scenario, use oslc:allowedValue to define the set of possible values and limit the attribute value to come from the preset enumeration range. The oslc:readOnly property indicates whether a resource property is allowed to be written. When the value is true, it means that the property can only be read and cannot be modified.
5. The method for encapsulating and tracing heterogeneous lifecycle data based on OSLC according to claim 1, characterized in that, S5 specifically includes: S51. Identify Traceability Paths: Based on the system engineering lifecycle model, semantic analysis is performed on the entire process from requirement definition, system modeling, simulation verification, test execution to defect closure. The key data resource types at each stage and the logical and semantic relationships between them are identified, and an end-to-end traceability path graph describing the mapping from upstream resources to downstream resources is constructed. The traceability path is represented by a graph structure, where each node corresponds to a resource type and each edge represents a semantic relationship. By analyzing data dependencies, input-output relationships, and business process sequences, the set of shortest traceable paths between resources is determined, forming a traceability topology within the lifecycle. S52. Define traceability relationship attributes: For resource associations involved in the traceability path, if the OSLC standard relationship attributes cannot accurately describe the semantics, then define dedicated traceability relationship attributes in the custom vocabulary. The traceability attributes declare semantic content with rdf:Property, and specify the domain and range of the relationship through rdfs:domain and rdfs:range. Attribute annotation information, including relation semantic description, constraint rules, and visual labels, can be introduced during definition. S53. Establish shape cascading constraints: In the shape definition of resources involving relationships, the traceability relationship attribute defined in S52 is referenced through oslc:propertyDefinition, and the shape type of the associated resource is constrained by the oslc:valueShape parameter, requiring the referenced resource to conform to the specified shape definition; when there are hierarchical dependencies between associated resources, a multi-level shape dependency network is established recursively, and the shape definition of the upper-level resource can pass constraints on the shape instance of the lower-level resource; S54. Publish Semantic Chain Specification: After the definition is completed, the tracing semantic chain will generate a semantic specification file in machine-readable RDF or Turtle format. The file contains resource types, relationship attributes, shape constraints, and URI identifiers. The semantic chain specification file is registered in the system semantic library and assigned a unique namespace address. Through the published semantic chain specification, the system can automatically identify resource types, parse relationship attributes, and load the corresponding shape constraints when performing tracing.
6. The method for encapsulating and tracing heterogeneous lifecycle data based on OSLC according to claim 1, characterized in that, The relationships not covered by the standard in step S5 specifically include: cross-stage resource association relationships within the system engineering lifecycle that are not included in existing OSLC domain specifications, including but not limited to custom traceability relationships for system model verification simulation models, simulation model verification test cases, and test case triggering defect types; the custom traceability relationships define attribute semantics through rdf:Property, and use rdfs:domain and rdfs:range to limit the domain and range of the relationship, then embed the attributes into the corresponding resource shape, and constrain the type and structure of the target resource through oslc:valueShape.
7. The method for encapsulating and tracing heterogeneous lifecycle data based on OSLC according to claim 1, characterized in that, S6 specifically includes: storing the traceability semantic chain file generated in step S5 in the system semantic library in RDF or Turtle format, and uniquely identifying each type of resource, relational attribute, and shape constraint by URI; when the system is loaded, parsing the semantic definition in the RDF document, establishing an index mapping table between resources, and automatically reading and parsing the corresponding relationship when the adapter performs traceability.
8. The OSLC-based method for encapsulating and tracing heterogeneous lifecycle data according to claim 1, characterized in that, S7 specifically includes: when performing lifecycle tracing analysis, performing forward tracing or backward tracing based on the tracing semantic chain; forward tracing refers to: starting from upstream resources, searching for all associated downstream resources along the tracing relationship attributes; backward tracing refers to: starting from downstream resources, searching for all upstream source resources in reverse along the tracing relationship attributes; using the DFS algorithm, extracting the associated entire data link resources from the resources at any node of the lifecycle as the initial node.