1"use strict";(globalThis.webpackChunkcatenax_ev_github_io_new=globalThis.webpackChunkcatenax_ev_github_io_new||[]).push([[15873],{42959(e,n,t){t.r(n),t.d(n,{assets:()=>l,contentTitle:()=>d,default:()=>u,frontMatter:()=>a,metadata:()=>i,toc:()=>c});const i=JSON.parse('{"id":"standards/CX-0155-RequirementsEngineering/CX-0155-RequirementsEngineering","title":"CX-0155 Requirements Engineering v.1.0.1","description":"ABSTRACT","source":"@site/versioned_docs/version-Saturn/standards/CX-0155-RequirementsEngineering/CX-0155-RequirementsEngineering.md","sourceDirName":"standards/CX-0155-RequirementsEngineering","slug":"/standards/CX-0155-RequirementsEngineering/","permalink":"/docs/Saturn/standards/CX-0155-RequirementsEngineering/","draft":false,"unlisted":false,"tags":[],"version":"Saturn","frontMatter":{},"sidebar":"sidebar_standards","previous":{"title":"Changelog","permalink":"/docs/Saturn/standards/CX-0154-MasterDataManagement/Changelog"},"next":{"title":"Changelog","permalink":"/docs/Saturn/standards/CX-0155-RequirementsEngineering/Changelog"}}');var s=t(74848),r=t(28453),o=t(16877);const a={},d="CX-0155 Requirements Engineering v.1.0.1",l={},c=[{value:"ABSTRACT",id:"abstract",level:2},{value:"FOR WHOM IS THE STANDARD DESIGNED",id:"for-whom-is-the-standard-designed",level:2},{value:"1 INTRODUCTION",id:"1-introduction",level:2},{value:"1.1 AUDIENCE & SCOPE",id:"11-audience--scope",level:3},{value:"1.2 CONTEXT AND ARCHITECTURE FIT",id:"12-context-and-architecture-fit",level:3},{value:"Components",id:"components",level:4},{value:"Interactions",id:"interactions",level:4},{value:"1.3 CONFORMANCE AND PROOF OF CONFORMITY",id:"13-conformance-and-proof-of-conformity",level:3},{value:"1.4 EXAMPLES",id:"14-examples",level:3},{value:"2 RELEVANT PARTS OF THE STANDARD FOR SPECIFIC USE CASES",id:"2-relevant-parts-of-the-standard-for-specific-use-cases",level:2},{value:"2.1 DIGITAL TWINS AND SPECIFIC ASSET IDs",id:"21-digital-twins-and-specific-asset-ids",level:3},{value:"2.2 POLICY CONSTRAINTS FOR DATA EXCHANGE",id:"22-policy-constraints-for-data-exchange",level:2},{value:"3 ASPECT MODELS",id:"3-aspect-models",level:2},{value:"3.1 ASPECT MODEL "REQUIREMENT"",id:"31-aspect-model-requirement",level:3},{value:"3.1.1 Identifier OF SEMANTIC MODEL",id:"311-identifier-of-semantic-model",level:4},{value:"4 APPLICATION PROGRAMMING INTERFACES",id:"4-application-programming-interfaces",level:2},{value:"4.1 APIs ASSOCIATED WITH DIGITAL TWINS",id:"41-apis-associated-with-digital-twins",level:3},{value:"DATA ASSET STRUCTURE",id:"data-asset-structure",level:4},{value:"4.2 NOTIFICATIONS",id:"42-notifications",level:3},{value:"5 REFERENCES",id:"5-references",level:2},{value:"5.1 NORMATIVE REFERENCES",id:"51-normative-references",level:3},{value:"5.2 NON-NORMATIVE REFERENCES",id:"52-non-normative-references",level:3},{value:"5.3 REFERENCE IMPLEMENTATIONS",id:"53-reference-implementations",level:3},{value:"5.4 LICENSES",id:"54-licenses",level:3},{value:"Legal",id:"legal",level:2}];function h(e){const n={a:"a",blockquote:"blockquote",code:"code",em:"em",h1:"h1",h2:"h2",h3:"h3",h4:"h4",header:"header",li:"li",mermaid:"mermaid",p:"p",pre:"pre",strong:"strong",table:"table",tbody:"tbody",td:"td",th:"th",thead:"thead",tr:"tr",ul:"ul",...(0,r.R)(),...e.components};return(0,s.jsxs)(s.Fragment,{children:[(0,s.jsx)(n.header,{children:(0,s.jsx)(n.h1,{id:"cx-0155-requirements-engineering-v101",children:"CX-0155 Requirements Engineering v.1.0.1"})}),"\n",(0,s.jsx)(n.h2,{id:"abstract",children:"ABSTRACT"}),"\n",(0,s.jsx)(n.p,{children:"This standard focuses on the Requirement exchange use case. This includes relevant requirements for:"}),"\n",(0,s.jsxs)(n.ul,{children:["\n",(0,s.jsx)(n.li,{children:"data provider, that want to provide Requirements through Catena-X,"}),"\n",(0,s.jsx)(n.li,{children:"data consumer, that are want to consume Requirements via Catena-X and"}),"\n",(0,s.jsx)(n.li,{children:"application developer/ provider supporting the exchange of Requirements."}),"\n"]}),"\n",(0,s.jsx)(n.p,{children:"It will provide information about the used core components as well as the structure of the Digital Twin Registry entry, the data model exchanged and the EDC (Eclipse Dataspace Connector) data structure."}),"\n",(0,s.jsx)(n.h2,{id:"for-whom-is-the-standard-designed",children:"FOR WHOM IS THE STANDARD DESIGNED"}),"\n",(0,s.jsx)(n.h2,{id:"1-introduction",children:"1 INTRODUCTION"}),"\n",(0,s.jsxs)(n.p,{children:["Enabling seamless, secure, and efficie
1nt cross-company collaboration within the Catena-X ecosystem, this requirement exchange standard introduces a unified, ReqIF-inspired platform that ensures real-time, standardized, and sovereign data sharing between OEMs and ",(0,s.jsx)(o.A,{term:"Supplier",definition:"In the context of OSim, the producer of goods.",routePath:"/glossary",children:"suppliers"}),", empowering stakeholders to manage, exchange, and validate requirements transparently and collaboratively across the supply chain while maintaining full control over proprietary information, enhancing interoperability, accelerating innovation, and ensuring compliance with industry standards through a flexible, structured, and trustworthy digital environment."]}),"\n",(0,s.jsx)(n.h3,{id:"11-audience--scope",children:"1.1 AUDIENCE & SCOPE"}),"\n",(0,s.jsx)(n.p,{children:"This standard is relevant for the following audience:"}),"\n",(0,s.jsxs)(n.ul,{children:["\n",(0,s.jsx)(n.li,{children:"Data Provider / Consumer"}),"\n",(0,s.jsx)(n.li,{children:"Business Application Provider"}),"\n"]}),"\n",(0,s.jsxs)(n.p,{children:["This document focuses on Requirements in existing ",(0,s.jsx)(o.A,{term:"Supplier",definition:"In the context of OSim, the producer of goods.",routePath:"/glossary",children:"Supplier"}),"-OEM-Relationships which is exchanged before the actual physical ",(0,s.jsx)(o.A,{term:"Asset",definition:"On the Data Provider side, an Asset describes the data set which will be shared or can be consumed by a Data Consumer.",routePath:"/glossary",children:"asset"})," is created."]}),"\n",(0,s.jsx)(n.p,{children:"Out-of-scope is:"}),"\n",(0,s.jsxs)(n.ul,{children:["\n",(0,s.jsxs)(n.li,{children:["The exchange of instance specific information (see ",(0,s.jsx)(n.a,{href:"https://catenax-ev.github.io/docs/standards/CX-0127-IndustryCorePartInstance",children:"CX-0127 Industry Core PartInstance"}),")"]}),"\n",(0,s.jsxs)(n.li,{children:["The exchange of Master Data before the ",(0,s.jsx)(o.A,{term:"Supplier",definition:"In the context of OSim, the producer of goods.",routePath:"/glossary",children:"Supplier"}),"-OEM-Relationship is defined."]}),"\n"]}),"\n",(0,s.jsx)(n.h3,{id:"12-context-and-architecture-fit",children:"1.2 CONTEXT AND ARCHITECTURE FIT"}),"\n",(0,s.jsx)(n.p,{children:"The flowchart illustrates the interactions between four main components in the system:"}),"\n",(0,s.jsx)(n.h4,{id:"components",children:"Components"}),"\n",(0,s.jsxs)(n.ul,{children:["\n",(0,s.jsxs)(n.li,{children:[(0,s.jsx)(n.strong,{children:"Requirement System"}),": Core component responsible for requirement management"]}),"\n",(0,s.jsxs)(n.li,{children:[(0,s.jsx)(n.strong,{children:"Digital Twin Registry"}),": Stores and manages digital twin information"]}),"\n",(0,s.jsxs)(n.li,{children:[(0,s.jsx)(n.strong,{children:"Submodel Service"}),": Handles submodel data and operations"]}),"\n",(0,s.jsxs)(n.li,{children:[(0,s.jsx)(n.strong,{children:"Eclipse Dataspace Connector (EDC)"}),": Facilitates data exchange between partners"]}),"\n"]}),"\n",(0,s.jsx)(n.h4,{id:"interactions",children:"Interactions"}),"\n",(0,s.jsx)(n.p,{children:"The system architecture demonstrates how components interact to facilitate requirement exchange:"}),"\n",(0,s.jsxs)(n.ul,{children:["\n",(0,s.jsxs)(n.li,{children:["\n",(0,s.jsx)(n.p,{children:(0,s.jsx)(n.strong,{children:"Requirement System Operations"})}),"\n",(0,s.jsxs)(n.ul,{children:["\n",(0,s.jsx)(n.li,{children:"Registers Digital Twins and Submodel Descriptors in the Digital Twin Registry"}),"\n",(0,s.jsx)(n.li,{children:"Provides Requirement Submodels to the Submodel Service"}),"\n",(0,s.jsx)(n.li,{children:"Uses the Eclipse Dataspace Connector to request requirements and send notifications"}),"\n"]}),"\n"]}),"\n",(0,s.jsxs)(n.li,{children:["\n",(0,s.jsx)(n.p,{children:(0,s.jsx)(n.strong,{children:"Eclipse Dataspace Connector (EDC)"})}),"\n",(0,s.jsxs)(n.ul,{children:["\n",(0,s.jsx)(n.li,{children:"Handles notifications sent from partners back to the Requirement System"}),"\n",(0,s.jsx)(n.li,{children:"Acts as the communication bridge between partners"}),"\n"]}),"\n"]}),"\n",(0,s.jsxs)(n.li,{children:["\n",(0,s.jsx)(n.p,{children:(0,s.jsx)(n.strong,{children:"Digital Twin Registry"})}),"\n",(0,s.jsxs)(n.ul,{children:["\n",(0,s.jsx)(n.li,{children:"Provides Digital Twins to the Eclipse Dataspace Connector"}),"\n"]}),"\n"]}),"\n",(0,s.jsxs)(n.li,{children:["\n",(0,s.jsx)(n.p,{children:(0,s.jsx)(n.strong,{children:"Submodel Service"})}),"\n",(0,s.jsxs)(n.ul,{children:["\n",(0,s.jsx)(n.li,{children:"Provides Submodels to the Eclipse Dataspace Connector"}),"\n"]}),"\n"]}),"\n"]}),"\n",(0,s.jsx)(n.mermaid,{value:"flowchart LR\n\nreqSysC[Requirement System]\ndtrC[Digital Twin Registry]\nsubmodelC[Submodel Service]\nedcC[Eclipse Dataspace Connector]\n\nreqSysC -- Register Digital Twins and Submodel Descriptors --\x3e dtrC\nreqSysC -- Provide Requirement Submodels --\x3e submodelC\nreqSysC -- Use E
1DC to Request Requirements and send notifications --\x3e edcC\nedcC -- Handle Notifications sent from partner --\x3e reqSysC\ndtrC -- Provide Digital Twins --\x3e edcC\nsubmodelC -- Provide Submodels --\x3e edcC\n"}),"\n",(0,s.jsx)(n.h3,{id:"13-conformance-and-proof-of-conformity",children:"1.3 CONFORMANCE AND PROOF OF CONFORMITY"}),"\n",(0,s.jsxs)(n.blockquote,{children:["\n",(0,s.jsx)(n.p,{children:(0,s.jsx)(n.em,{children:"This section is non-normative"})}),"\n"]}),"\n",(0,s.jsx)(n.p,{children:"As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes\nin this specification are non-normative. Everything else in this specification is normative."}),"\n",(0,s.jsxs)(n.p,{children:["The key words ",(0,s.jsx)(n.strong,{children:"MAY"}),", ",(0,s.jsx)(n.strong,{children:"MUST"}),", ",(0,s.jsx)(n.strong,{children:"MUST NOT"}),", ",(0,s.jsx)(n.strong,{children:"OPTIONAL"}),", ",(0,s.jsx)(n.strong,{children:"RECOMMENDED"}),", ",(0,s.jsx)(n.strong,{children:"REQUIRED"}),", ",(0,s.jsx)(n.strong,{children:"SHOULD"}),"\nand ",(0,s.jsx)(n.strong,{children:"SHOULD NOT"})," in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174]\nwhen, and only when, they appear in all capitals, as shown here."]}),"\n",(0,s.jsx)(n.p,{children:"All participants and their solutions will need to prove, that they are conform with the Catena-X standards.\nTo validate that the standards are applied correctly, Catena-X employs Conformity Assessment Bodies (CABs)."}),"\n",(0,s.jsx)(n.p,{children:"To prove conformance with the standard a participant (consumer, provider or application developer) MUST show that they can consume a requirement, update the status of this requirement and send it via notification to another participant."}),"\n",(0,s.jsx)(n.h3,{id:"14-examples",children:"1.4 EXAMPLES"}),"\n",(0,s.jsxs)(n.p,{children:["The sequence diagram illustrates the requirement exchange flow between a ",(0,s.jsx)(o.A,{term:"Customer",definition:"In the context of OSim, the receiver of produced goods from a supplier.",routePath:"/glossary",children:"Customer"})," (e.g., an OEM) and a ",(0,s.jsx)(o.A,{term:"Supplier",definition:"In the context of OSim, the producer of goods.",routePath:"/glossary",children:"Supplier"}),":"]}),"\n",(0,s.jsxs)(n.p,{children:["\\1. ",(0,s.jsx)(n.strong,{children:"Initial Requirement Creation"}),":"]}),"\n",(0,s.jsxs)(n.ul,{children:["\n",(0,s.jsxs)(n.li,{children:[(0,s.jsx)(o.A,{term:"Customer",definition:"In the context of OSim, the receiver of produced goods from a supplier.",routePath:"/glossary",children:"Customer"})," creates a requirement in their requirements system and registers it in their DTR and creates a submodel."]}),"\n",(0,s.jsxs)(n.li,{children:[(0,s.jsx)(o.A,{term:"Customer",definition:"In the context of OSim, the receiver of produced goods from a supplier.",routePath:"/glossary",children:"Customer"}),"'s system sends a notification through the EDC to the ",(0,s.jsx)(o.A,{term:"Supplier",definition:"In the context of OSim, the producer of goods.",routePath:"/glossary",children:"Supplier"})]}),"\n"]}),"\n",(0,s.jsxs)(n.p,{children:["\\2. ",(0,s.jsx)(n.strong,{children:"Requirement Request"}),":"]}),"\n",(0,s.jsxs)(n.ul,{children:["\n",(0,s.jsxs)(n.li,{children:[(0,s.jsx)(o.A,{term:"Supplier",definition:"In the context of OSim, the producer of goods.",routePath:"/glossary",children:"Supplier"}),"'s system requests the requirement details through the EDC"]}),"\n",(0,s.jsxs)(n.li,{children:["The requirement is transferred from ",(0,s.jsx)(o.A,{term:"Customer",definition:"In the context of OSim, the receiver of produced goods from a supplier.",routePath:"/glossary",children:"Customer"}),"'s DTR to ",(0,s.jsx)(o.A,{term:"Supplier",definition:"In the context of OSim, the producer of goods.",routePath:"/glossary",children:"Supplier"}),"'s DTR and submodel service"]}),"\n"]}),"\n",(0,s.jsxs)(n.p,{children:["\\3. ",(0,s.jsx)(n.strong,{children:"Requirement Update"}),":"]}),"\n",(0,s.jsxs)(n.ul,{children:["\n",(0,s.jsxs)(n.li,{children:["After processing, ",(0,s.jsx)(o.A,{term:"Supplier",definition:"In the context of OSim, the producer of goods.",routePath:"/glossary",children:"Supplier"})," updates the requirement in their requirements system"]}),"\n",(0,s.jsxs)(n.li,{children:[(0,s.jsx)(o.A,{term:"Supplier",definition:"In the context of OSim, the producer of goods.",routePath:"/glossary",children:"Supplier"})," sends a notification about the update through the EDC back to the ",(0,s.jsx)(o.A,{term:"Customer",definition:"In the context of OSim, the receiver of produced goods from a supplier.",routePath:"/glossary",children:"Customer"})]}),"\n",(0,s.jsxs)(n.li,{children:[(0,s.jsx)(o.A,{term:"Customer",definition:"In the context of OSim, the receiver of produced goods from a supplier.",routePath:"/glossary",children:"Customer"})," is notified about the requirement update"]}),"\n"]}),"\n",(0,s.jsxs)(n.p,{children:["\\4. ",(0,s.jsx)(n.strong,{children:"Next interactions"}),":"]}),"\n",(0,s.jsxs)(n.ul,{children:["\n",(0,s.jsxs)(n.li,{children:["The process can be repeated for further updates or new requirements in an interactive manner between the ",(0,s.jsx)(o.A,{term:"Customer",definition:"In the context of OSim, the receiver of produced goods from a supplier.",routePath:"/glossary",children:"Customer"})," and ",(0,s.jsx)(o.A,{term:"Supplier",definition:"In the context of OSim, the producer of goods.",routePath:"/glossary",children:"Supplier"}),"."]}),"\n"]}),"\n",(0,s.jsx)(n.p,{children:"The diagram shows the core components involved in this exchange:"}),"\n",(0,s.jsxs)(n.ul,{children:["\n",(0,s.jsxs)(n.li,{children:["Requirement Systems (on both ",(0,s.jsx)(o.A,{term:"Customer",definition:"In the context of OSim, the receiver of produced goods from a supplier.",routePath:"/glossary",children:"Customer"})," and ",(0,s.jsx)(o.A,{term:"Supplier",definition:"In the context of OSim, the producer of goods.",routePath:"/glossary",children:"Supplier"})," sides)"]}),"\n",(0,s.jsx)(n.li,{children:"Digital Twin Registry (DTR) & Submodel Services"}),"\n",(0,s.jsx)(n.li,{children:"Eclipse Dataspace Connector (EDC) for secure data exchange"}),"\n",(0,s.jsx)(n.li,{children:"Solid lines indicate dataflow"}),"\n",(0,s.jsx)(n.li,{children:"Dashed lines indicate initialization of a request"}),"\n"]}),"\n",(0,s.jsx)(n.mermaid,{value:"\nsequenceDiagram\n participant oemReqSys as Requirement System Customer\n participant oemDtr as DTR & Submodel Service Customer\n participant oemEDC as EDC Customer\n\n participant supEDC as EDC Supplier\n participant supDtr as DTR & Submodel Service Supplier\n participant supReqSys as Requirement System Supplier\n\n oemReqSys->>oemDtr: Requirement (DTR + Submodel)\n oemReqSys->>oemEDC: Notification\n oemEDC->>supEDC: Notification\n supEDC->>supReqSys: Notification\n supReqSys--\x3e>supEDC: Request Requirement\n\n\n supEDC--\x3e>oemEDC: Request Requirement\n oemEDC--\x3e>oemDtr: Request Requirement\n\n oemDtr->>oemEDC: Requirement\n\n oemEDC->>supEDC: Requirement\n supEDC->>supDtr: Requirement (DTR + Submodel)\n\n supDtr->>supReqSys: Requirement\n\n supReqSys->>supDtr: Update Requirement\n supReqSys->>supEDC: Notification (updated Requirement)\n supEDC->>oemEDC: Notification (updated Requirement)\n oemEDC->>oemReqSys: Notification (updated Requirement)\n"}),"\n",(0,s.jsx)(n.h2,{id:"2-relevant-parts-of-the-standard-for-specific-use-cases",children:"2 RELEVANT PARTS OF THE STANDARD FOR SPECIFIC USE CASES"}),"\n",(0,s.jsxs)(n.blockquote,{children:["\n",(0,s.jsx)(n.p,{children:(0,s.jsx)(n.em,{children:"This section is normative"})}),"\n"]}),"\n",(0,s.jsx)(n.h3,{id:"21-digital-twins-and-specific-asset-ids",children:"2.1 DIGITAL TWINS AND SPECIFIC ASSET IDs"}),"\n",(0,s.jsxs)(n.p,{children:["The Digital Twin MUST be described either as ",(0,s.jsx)(n.code,{children:"PartRole"})," or as ",(0,s.jsx)(n.code,{children:"PartType"}),".\nIf both are are possible ",(0,s.jsx)(n.code,{children:"PartType"})," shall be used."]}),"\n",(0,s.jsxs)(n.p,{children:["Specific ",(0,s.jsx)(o.A,{term:"Asset",definition:"On the Data Provider side, an Asset describes the data set which will be shared or can be consumed by a Data Consumer.",routePath:"/glossary",children:"asset"})," ",(0,s.jsx)(o.A,{term:"IDS",definition:"The International Data Space enables 'smart services' and business processes across companies and industries while ensuring data sovereignty and self-determined control of data use.",routePath:"/glossary",children:"IDs"})," are used to identify digital twins when looking up or searching for these digital twins.\nThis is a required to connect the digital twins of the planned parts to its digital twins.\nMandatory specific ",(0,s.jsx)(o.A,{term:"Asset",definition:"On the Data Provider side, an Asset describes the data set which will be shared or can be consumed by a Data Consumer.",routePath:"/glossary",children:"asset"})," ",(0,s.jsx)(o.A,{term:"IDS",definition:"The International Data Space enables 'smart services' and business processes across companies and industries while ensuring data sovereignty and self-determined control of data use.",routePath:"/glossary",children:"IDs"})," ensure that at least this information is available for the digital twin."]}),"\n",(0,s.jsxs)(n.table,{children:[(0,s.jsx)(n.thead,{children:(0,s.jsxs)(n.tr,{children:[(0,s.jsx)(n.th,{children:"Key"}),(0,s.jsx)(n.th,{children:"Availability"}),(0,s.jsx)(n.th,{children:"Description"}),(0,s.jsx)(n.th,{children:"Type"})]})}),(0,s.jsxs)(n.tbody,{children:[(0,s.jsxs)(n.tr,{children:[(0,s.jsx)(n.td,{children:"manufacturerId"}),(0,s.jsx)(n.td,{children:"mandatory"}),(0,s.jsxs)(n.td,{children:["The Business Partner Number (",(0,s.jsx)(o.A,{term:"BPNL",definition:"The unique identifier of a legal entity of a partner within Catena-X (e.g., a company).",routePath:"/glossary",children:"BPNL"}),") of the manufacturer of the part."]}),(0,s.jsx)(n.td,{children:(0,s.jsx)(o.A,{term:"BPNL",definition:"The unique identifier of a legal entity of a partner within Catena-X (e.g., a company).",routePath:"/glossary",children:"BPNL"})})]}),(0,s.jsxs)(n.tr,{children:[(0,s.jsx)(n.td,{children:"digitalTwinType"}),(0,s.jsx)(n.td,{children:"mandatory"}),(0,s.jsxs)(n.td,{children:["The digitalTwinType has to be set to ",(0,s.jsx)(n.code,{children:'digitalTwinType="PartType"'})," or ",(0,s.jsx)(n.code,{children:'digitalTwinType="PartRole"'}),". Without this filter, a search for a particular manufacturer part ID would not only return the digital twin of the engineered part, but also all digital twins of the manufacturer that are accessible, i.e., of the corresponding serial parts."]}),(0,s.jsx)(n.td,{children:"String"})]})]})]}),"\n",(0,s.jsx)(n.h2,{id:"22-policy-constraints-for-data-exchange",children:"2.2 POLICY CONSTRAINTS FOR DATA EXCHANGE"}),"\n",(0,s.jsxs)(n.p,{children:["In alignment with our commitment to data sovereignty, a specific framework governing the utilization of data within the Catena-X use cases has been outlined. As part of this data sovereignty framework, conventions for access policies, for usage policies and for the constraints contained in the policies have been specified in standard 'CX-0152 Policy Constraints for Data Exchange'. This standard document CX-0152 ",(0,s.jsx)(n.strong,{children:"MUST"})," be followed when providing services or apps for data sharing/consuming and when sharing or consuming data in the Catena-X ecosystem. What conventions are relevant for what roles named in ",(0,s.jsx)(n.a,{href:"#11-audience--scope",children:"1.1 AUDIENCE & SCOPE"})," is specified in the CX-0152 standard document as well. CX-0152 can be found in the ",(0,s.jsx)(n.a,{href:"https://catenax-ev.github.io/docs/standards/overview",children:"standard library"}),"."]}),"\n",(0,s.jsxs)(n.p,{children:["The following usage purpose ",(0,s.jsx)(n.strong,{children:"MUST"})," be registered for data exchange in the use case:"]}),"\n",(0,s.jsxs)(n.table,{children:[(0,s.jsx)(n.thead,{children:(0,s.jsxs)(n.tr,{children:[(0,s.jsx)(n.th,{children:"Type"}),(0,s.jsx)(n.th,{children:"Subject"}),(0,s.jsx)(n.th,{children:"Description"}),(0,s.jsx)(n.th,{children:"Version"}),(0,s.jsx)(n.th,{children:"Usage Purpose"})]})}),(0,s.jsx)(n.tbody,{children:(0,s.jsxs)(n.tr,{children:[(0,s.jsxs)(n.td,{children:["cx-taxo",":Engineering"]}),(0,s.jsxs)(n.td,{children:["cx-taxo",":ReadAccessEngineering"]}),(0,s.jsxs)(n.td,{children:["Data consumer are allowed to use the data for ",(0,s.jsx)("br",{})," \u2022 Collaborative engineering of products (e.g., 3D Designs, Simulations) ",(0,s.jsx)("br",{})," \u2022 regulatory compliance use cases (e.g., material information in master data for secondar material content checks) ",(0,s.jsx)("br",{}),"\u2022 Mock-Up and integration (e.g., collision checks in 3D) ",(0,s.jsx)("br",{})," \u2022 versioning & release notifications of products (e.g., new product version that shall be used in a new product generation) ",(0,s.jsx)("br",{})," \u2022 interface alignments (e.g., between interacting systems on physical, logical and functional level) ",(0,s.jsx)("br",{})," They explicitly ",(0,s.jsx)(n.strong,{children:"MUST not"})," use the data for reverse engineering, e.g., by using material classifications for building the product themselves."]}),(0,s.jsx)(n.td,{children:"1"}),(0,s.jsx)(n.td,{children:"cx.enginnering:1"})]})})]}),"\n",(0,s.jsx)(n.h2,{id:"3-aspect-models",children:"3 ASPECT MODELS"}),"\n",(0,s.jsxs)(n.blockquote,{children:["\n",(0,s.jsx)(n.p,{children:(0,s.jsx)(n.em,{children:"This section is normative"})}),"\n"]}),"\n",(0,s.jsx)(n.h3,{id:"31-aspect-model-requirement",children:'3.1 ASPECT MODEL "REQUIREMENT"'}),"\n",(0,s.jsx)(n.p,{children:'This semantic model, developed for the Catena-X data space, defines a standardized structure for exch
1anging product and process requirements.\nIt establishes a "Requirement" aspect that includes a unique ID, detailed information, and its current status.\nThe model breaks down requirement information into specifics like name, type (e.g., functional, non-functional), version, description, and author.'}),"\n",(0,s.jsxs)(n.p,{children:["Furthermore, it captures the status of a requirement from both the ",(0,s.jsx)(o.A,{term:"Customer",definition:"In the context of OSim, the receiver of produced goods from a supplier.",routePath:"/glossary",children:"customer"})," and ",(0,s.jsx)(o.A,{term:"Supplier",definition:"In the context of OSim, the producer of goods.",routePath:"/glossary",children:"supplier"})," perspectives, including status values and timestamps.\nThe model also supports relationships between different requirements and allows for additional metadata and links to specification documents."]}),"\n",(0,s.jsx)(n.h4,{id:"311-identifier-of-semantic-model",children:"3.1.1 Identifier OF SEMANTIC MODEL"}),"\n",(0,s.jsx)(n.p,{children:"The semantic model has the unique identifier:"}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-text",children:" urn:samm:io.catenax.requirement:1.0.0#\n"})}),"\n",(0,s.jsxs)(n.blockquote,{children:["\n",(0,s.jsx)(n.p,{children:(0,s.jsx)(n.em,{children:"Note:"})}),"\n"]}),"\n",(0,s.jsxs)(n.blockquote,{children:["\n",(0,s.jsxs)(n.ul,{children:["\n",(0,s.jsxs)(n.li,{children:["The can find the corresponding Turtle file ",(0,s.jsx)(n.a,{href:"https://github.com/eclipse-tractusx/sldt-semantic-models/blob/main/io.catenax.requirement/1.0.0/requirement.ttl",children:"here"})]}),"\n",(0,s.jsxs)(n.li,{children:["You can find the corresponding files (Documentation, JSON Schema or AASX File, etc.) ",(0,s.jsx)(n.a,{href:"https://github.com/eclipse-tractusx/sldt-semantic-models/tree/main/io.catenax.requirement/1.0.0/gen",children:"here"}),"."]}),"\n"]}),"\n"]}),"\n",(0,s.jsx)(n.h2,{id:"4-application-programming-interfaces",children:"4 APPLICATION PROGRAMMING INTERFACES"}),"\n",(0,s.jsxs)(n.blockquote,{children:["\n",(0,s.jsx)(n.p,{children:(0,s.jsx)(n.em,{children:"This section is normative"})}),"\n"]}),"\n",(0,s.jsx)(n.h3,{id:"41-apis-associated-with-digital-twins",children:"4.1 APIs ASSOCIATED WITH DIGITAL TWINS"}),"\n",(0,s.jsxs)(n.p,{children:["This standard completely and solely builds upon the standard ",(0,s.jsx)(n.a,{href:"https://catenax-ev.github.io/docs/next/standards/CX-0002-DigitalTwinsInCatenaX",children:"CX-0002"})," Digital Twins in Catena-X."]}),"\n",(0,s.jsx)(n.h4,{id:"data-asset-structure",children:"DATA ASSET STRUCTURE"}),"\n",(0,s.jsxs)(n.p,{children:["The Data ",(0,s.jsx)(o.A,{term:"Asset",definition:"On the Data Provider side, an Asset describes the data set which will be shared or can be consumed by a Data Consumer.",routePath:"/glossary",children:"Assets"})," need to be registered in the EDC as follows:"]}),"\n",(0,s.jsxs)(n.blockquote,{children:["\n",(0,s.jsx)(n.p,{children:"Note: Expressions in double curly braces {{}} must be substituted with a corresponding value."}),"\n"]}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-json",children:'{\n "@context": {\n "dct": "http://purl.org/dc/terms/",\n "cx-taxo": "https://w3id.org/catenax/taxonomy#",\n "cx-common": "https://w3id.org/catenax/ontology/common#"\n },\n "@type": "Asset", \n "@id": "{{CONNECTOR_ASSET_ID}}",\n "properties": {\n "dct:type": {"@id": "cx-taxo:Engineering"},\n "cx-common:version": "1.0",\n "aas-semantics:semanticId": {"@id": " urn:samm:io.catenax.requirement:1.0.0#\nrequirement"} \n },\n "dataAddress": {\n "@type": "DataAddress",\n "type": "HttpData",\n "baseUrl": "{{ SUBMODEL_ENDPOINT }}",\n "proxyQueryParams": "false",\n "proxyBody": "false",\n "proxyPath": "true",\n "proxyMethod": "false",\n }\n}\n'})}),"\n",(0,s.jsxs)(n.p,{children:["The data ",(0,s.jsx)(o.A,{term:"Asset",definition:"On the Data Provider side, an Asset describes the data set which will be shared or can be consumed by a Data Consumer.",routePath:"/glossary",children:"asset"})," MUST contain the following properties with the corresponding values from the table above:"]}),"\n",(0,s.jsxs)(n.ul,{children:["\n",(0,s.jsxs)(n.li,{children:[(0,s.jsx)(n.code,{children:"dct:type"})," for type (as @id reference), see also CX-0018"]}),"\n",(0,s.jsxs)(n.li,{children:[(0,s.jsx)(n.code,{children:"cx-common:version"})," for version, see also CX-0018"]}),"\n"]}),"\n",(0,s.jsx)(n.h3,{id:"42-notifications",children:"4.2 NOTIFICATIONS"}),"\n",(0,s.jsxs)(n.p,{children:["This standard completely and s
1olely builds upon the standard ",(0,s.jsx)(n.a,{href:"https://catenax-ev.github.io/docs/standards/CX-0151-IndustryCoreBasics",children:"CX-0151"})," Industry Core: Basics."]}),"\n",(0,s.jsx)(n.h2,{id:"5-references",children:"5 REFERENCES"}),"\n",(0,s.jsx)(n.h3,{id:"51-normative-references",children:"5.1 NORMATIVE REFERENCES"}),"\n",(0,s.jsxs)(n.blockquote,{children:["\n",(0,s.jsx)(n.p,{children:(0,s.jsx)(n.em,{children:"This section is normative"})}),"\n"]}),"\n",(0,s.jsxs)(n.ul,{children:["\n",(0,s.jsxs)(n.li,{children:["CX-0001 EDC Discovery ",(0,s.jsx)(o.A,{term:"API",definition:"An API is a way for two or more computer programs to communicate with each other.",routePath:"/glossary",children:"API"})," v1.0.2"]}),"\n",(0,s.jsx)(n.li,{children:"CX-0002 Digital Twins in Catena-X v2.2.0"}),"\n",(0,s.jsx)(n.li,{children:"CX-0003 SAMM Aspect Meta Model v1.1.0"}),"\n",(0,s.jsx)(n.li,{children:"CX-0018 Dataspace Connectivity v3.1.0"}),"\n",(0,s.jsx)(n.li,{children:"CX-0126 Industry Core: PartType 2.1.0"}),"\n",(0,s.jsx)(n.li,{children:"CX-0151 Industry Core: Basics v1.0.0"}),"\n",(0,s.jsx)(n.li,{children:"CX-0152 Policy Constraints for Data Exchange v1.0.0"}),"\n"]}),"\n",(0,s.jsx)(n.h3,{id:"52-non-normative-references",children:"5.2 NON-NORMATIVE REFERENCES"}),"\n",(0,s.jsxs)(n.blockquote,{children:["\n",(0,s.jsx)(n.p,{children:(0,s.jsx)(n.em,{children:"This section is non-normative"})}),"\n"]}),"\n",(0,s.jsxs)(n.ul,{children:["\n",(0,s.jsx)(n.li,{children:(0,s.jsx)(n.a,{href:"https://www.omg.org/reqif/",children:"ReqIF"})}),"\n"]}),"\n",(0,s.jsx)(n.h3,{id:"53-reference-implementations",children:"5.3 REFERENCE IMPLEMENTATIONS"}),"\n",(0,s.jsxs)(n.blockquote,{children:["\n",(0,s.jsx)(n.p,{children:(0,s.jsx)(n.em,{children:"This section is non-normative"})}),"\n"]}),"\n",(0,s.jsx)(n.p,{children:"This section is empty."}),"\n",(0,s.jsx)(n.h3,{id:"54-licenses",children:"5.4 LICENSES"}),"\n",(0,s.jsxs)(n.blockquote,{children:["\n",(0,s.jsx)(n.p,{children:(0,s.jsx)(n.em,{children:"This section is non-normative"})}),"\n"]}),"\n",(0,s.jsxs)(n.p,{children:["The in Section 3 referenced ",(0,s.jsx)(o.A,{term:"Aspect Model",definition:"A formal, machine-readable semantic description (expressed with RDF/Turtle) of data accessible from an aspect. Note 1: An Aspect Model must adhere to the Semantic Aspect Meta Model (SAMM) and be compliant with its validity rules. Note 2: Aspect Models are logical data models that can be used to detail a conceptual model to describe the semantics of runtime data related to a concept; elements of an Aspect Model can/should refer to terms of a standardized Business Glossary (if existing).",routePath:"/glossary",children:"Aspect Models"})," are available under the terms of the Creative Commons Attribution 4.0 International (CC-BY-4.0) license, which is available at Creative Commons."]}),"\n",(0,s.jsx)(n.h2,{id:"legal",children:"Legal"}),"\n",(0,s.jsxs)(n.p,{children:["Copyright \xa9 2025 Catena-X Automotive Network e.V. All rights reserved. For more information, please visit ",(0,s.jsx)(n.a,{href:"/copyright",children:"here"}),"."]})]})}function u(e={}){const{wrapper:n}={...(0,r.R)(),...e.components};return n?(0,s.jsx)(n,{...e,children:(0,s.jsx)(h,{...e})}):h(e)}},28453(e,n,t){t.d(n,{R:()=>o,x:()=>a});var i=t(96540);const s={},r=i.createContext(s);function o(e){const n=i.useContext(r);return i.useMemo(function(){return"function"==typeof e?e(n):{...n,...e}},[n,e])}function a(e){let n;return n=e.disableParentContext?"function"==typeof e.components?e.components(s):e.components||s:o(e.components),i.createElement(r.Provider,{value:n},e.children)}},16877(e,n,t){t.d(n,{A:()=>m});var i=t(96540),s=t(66588);const r="glossaryTermWrapper_xqTQ",o="glossaryTerm_wdF6",a="tooltip_DUhm",d="tooltipFloating_oqgg",l="tooltipTop_L1lz",c="tooltipBottom_GPpw",h="tooltipVisible_fU0u";var u=t(74848);function m({term:e,definition:n,routePath:t="/glossary",children:m}){const[p,x]=(0,i.useState)(!1),[f,g]=(0,i.useState)(null),[j,C]=(0,i.useState)("top"),S=(0,i.useRef)(null),v=(0,i.useRef)(null),E=(0,i.useCallback)(()=>{if(!S.current||!v.current)return;const e=S.current.getBoundingClientRect(),n=v.current.getBoundingClientRect(),t=window.innerWidth,i=window.innerHeight,s=e.top>=n.height+8,r=i-e.bottom>=n.height+8,o=s||!r?"top":"bottom";let a;a="top"===o?e.top-n.height-8:e.bottom+8;let d=e.left+e.width/2-n.width/2;d=Math.max(8,Math.min(d,t-n.width-8)),C(o),g({top:Math.max(4,a),left:d})},[]);(0,i.useEffect)(()=>
1{if(!p)return;let e;const n=requestAnimationFrame(()=>{e=requestAnimationFrame(()=>{E()})}),t=()=>E(),i=()=>E();return window.addEventListener("scroll",t,!0),window.addEventListener("resize",i),()=>{cancelAnimationFrame(n),e&&cancelAnimationFrame(e),window.removeEventListener("scroll",t,!0),window.removeEventListener("resize",i)}},[p,E]);const T=(0,s.P_)("docusaurus-plugin-glossary"),y=(0,i.useMemo)(()=>{if(n&&"string"==typeof n&&n.length>0)return n;const t=(T&&T.terms||[]).find(n=>"string"==typeof n.term&&n.term.toLowerCase()===String(e).toLowerCase());return t&&t.definition?t.definition:void 0},[n,T,e]),b=(0,i.useMemo)(()=>t&&"string"==typeof t&&t.length>0?t:T&&T.routePath||"/glossary",[T,t]),A=m||e,R=e.toLowerCase().replace(/\s+/g,"-");return(0,u.jsxs)("span",{ref:S,className:r,children:[(0,u.jsx)("a",{href:`${b}#${R}`,className:o,onMouseEnter:()=>x(!0),onMouseLeave:()=>x(!1),onFocus:()=>x(!0),onBlur:()=>x(!1),"aria-describedby":`tooltip-${R}`,children:A}),y&&(0,u.jsxs)("span",{ref:v,id:`tooltip-${R}`,className:`${a} ${p?h:""} ${"top"===j?l:c} ${d}`,role:"tooltip",style:p&&f?{top:`${f.top}px`,left:`${f.left}px`}:void 0,children:[(0,u.jsx)("strong",{children:e})," ",y]})]})}}}]);
Line numbers count LF bytes from the start of the resource, as the search results do. Vendor segments are library code the classifier recognised; they are stored but not indexed. Bytes are shown as Latin1 characters, one per byte.