Skip to main content
Release: CX-Neptune (Preview)

Conformity Assessment Criteria

General Information​

  • cxId: CX-0157
  • name: Predictive Unit Real-Time Information Service (PURIS)
  • capability: Supply Security
  • version: 1.1.0
  • release: CX-Neptune

Table of Contents​

Reading Guide​

This section is non-normative.

The criteria are organised by scenario. A scenario umbrella CX-0157-SC-NN (SC = Scenario) describes one end-to-end business process of the standard (Chapter 5) together with the data model it exchanges (Chapter 3), the APIsAPI An API is a way for two or more computer programs to communicate with each other. it uses (Chapter 4) and the provisioning rules that apply (Chapter 2). Each umbrella is the unit a Conformity Assessment Body (CAB) reperforms.

Each umbrella contains atomic sub-criteria CX-0157-SC-NN-CAC-NNN, each independently assessable. Each criterion is a MUST or a MUST NOT; MUST NOT criteria are negative / anti-test scenarios that prove a forbidden behaviour (horizontal exchange of competitively sensitive information) is prevented.

The standards referenced by PURIS (CX-0018, CX-0152, CX-0002, CX-0126) are prerequisites: they are certified separately and are not re-assessed here. The criteria below only cover the extensions PURIS adds and the specific use it mandates.

Several checks (twin provisioning and consumption, semantic-model identity, JSON-schema validation, contract policy, APIAPI An API is a way for two or more computer programs to communicate with each other. implementation, competition compliance) recur in every scenario. They are written out per scenario so each scenario is a self-contained checklist, and each repetition carries a note > Same evaluation procedure as ... linking to its equivalents in the other scenarios.

Roles follow Table 4 of the standard. Provisioning and consumption criteria name the concrete role (customerCustomer In the context of OSim, the receiver of produced goods from a supplier. / supplierSupplier In the context of OSim, the producer of goods.) explicitly; where a model is exchanged in both directions, both roles are covered.

CX-0157-SC-01 Delivery Information Exchange​

Reperformance walkthrough​

  1. Depending on the incoterm, the responsible role attaches the DeliveryInformation submodel to its part type twin (CAC-001 / CAC-003) with the correct semantic id and contract policy (CAC-005, CAC-007).
  2. The other role discovers the partner twin and ingests the submodel via connector and Digital Twin APIAPI An API is a way for two or more computer programs to communicate with each other. (CAC-002 / CAC-004, CAC-008).
  3. Departure/arrival information is provided according to the incoterm variant (CAC-010, CAC-011, CAC-012) and the payload validates against the JSON schema (CAC-006).
  4. Only partner-specific information is exchanged (CAC-009).

CX-0157-SC-01-CAC-001 — Customer provides Delivery Information​

  • type: MUST
  • topic: Digital Twin Provisioning
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-003, CX-0157-SC-02-CAC-001, CX-0157-SC-03-CAC-001, CX-0157-SC-04-CAC-001, CX-0157-SC-04-CAC-003, CX-0157-SC-05-CAC-001, CX-0157-SC-05-CAC-003.

Requirement​

2.1.2 DATA REQUIRED

The customerCustomer In the context of OSim, the receiver of produced goods from a supplier. MUST provide the DeliveryInformation submodel data by attaching it to their part type twin (incoterm variant where the customerCustomer In the context of OSim, the receiver of produced goods from a supplier. is responsible for the delivery).

Proof of Conformity​

  • Inspect the customerCustomer In the context of OSim, the receiver of produced goods from a supplier.'s part type twin: a SubmodelDescriptor for DeliveryInformation exists and its submodel is retrievable (egest) via the Digital Twin APIAPI An API is a way for two or more computer programs to communicate with each other. of CX-0002.

Additional Information​

Roles and provisioning direction follow Table 4 of the standard. Prerequisite: twins are set up following CX-0002 and CX-0126 (the supplierSupplier In the context of OSim, the producer of goods. creates the twin first to define the Catena-X ID).

CX-0157-SC-01-CAC-002 — Supplier consumes Delivery Information​

  • type: MUST
  • topic: Digital Twin Consumption
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-004, CX-0157-SC-02-CAC-002, CX-0157-SC-03-CAC-002, CX-0157-SC-04-CAC-002, CX-0157-SC-04-CAC-004, CX-0157-SC-05-CAC-002, CX-0157-SC-05-CAC-004.

Requirement​

2.1.2 DATA REQUIRED

The supplierSupplier In the context of OSim, the producer of goods. MUST consume the DeliveryInformation submodel data by reading it from the customerCustomer In the context of OSim, the receiver of produced goods from a supplier.'s part type twin (incoterm variant where the customerCustomer In the context of OSim, the receiver of produced goods from a supplier. is responsible for the delivery).

Proof of Conformity​

  • Reperform discovery of the customerCustomer In the context of OSim, the receiver of produced goods from a supplier. twin and ingest of the DeliveryInformation submodel via connector and Digital Twin APIAPI An API is a way for two or more computer programs to communicate with each other. (CX-0002).

Additional Information​

Roles follow Table 4 of the standard.

CX-0157-SC-01-CAC-003 — Supplier provides Delivery Information​

  • type: MUST
  • topic: Digital Twin Provisioning
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-001, CX-0157-SC-02-CAC-001, CX-0157-SC-03-CAC-001, CX-0157-SC-04-CAC-001, CX-0157-SC-04-CAC-003, CX-0157-SC-05-CAC-001, CX-0157-SC-05-CAC-003.

Requirement​

2.1.2 DATA REQUIRED

The supplierSupplier In the context of OSim, the producer of goods. MUST provide the DeliveryInformation submodel data by attaching it to their part type twin (incoterm variant where the supplierSupplier In the context of OSim, the producer of goods. is responsible for the delivery).

Proof of Conformity​

  • Inspect the supplierSupplier In the context of OSim, the producer of goods.'s part type twin: a SubmodelDescriptor for DeliveryInformation exists and its submodel is retrievable (egest) via the Digital Twin APIAPI An API is a way for two or more computer programs to communicate with each other. of CX-0002.

Additional Information​

Roles and provisioning direction follow Table 4 of the standard.

CX-0157-SC-01-CAC-004 — Customer consumes Delivery Information​

  • type: MUST
  • topic: Digital Twin Consumption
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-002, CX-0157-SC-02-CAC-002, CX-0157-SC-03-CAC-002, CX-0157-SC-04-CAC-002, CX-0157-SC-04-CAC-004, CX-0157-SC-05-CAC-002, CX-0157-SC-05-CAC-004.

Requirement​

2.1.2 DATA REQUIRED

The customerCustomer In the context of OSim, the receiver of produced goods from a supplier. MUST consume the DeliveryInformation submodel data by reading it from the supplierSupplier In the context of OSim, the producer of goods.'s part type twin (incoterm variant where the supplierSupplier In the context of OSim, the producer of goods. is responsible for the delivery).

Proof of Conformity​

  • Reperform discovery of the supplierSupplier In the context of OSim, the producer of goods. twin and ingest of the DeliveryInformation submodel via connector and Digital Twin APIAPI An API is a way for two or more computer programs to communicate with each other. (CX-0002).

Additional Information​

Roles follow Table 4 of the standard.

CX-0157-SC-01-CAC-005 — Semantic model identity​

  • type: MUST
  • topic: Semantics, Versioning
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-02-CAC-003, CX-0157-SC-03-CAC-003, CX-0157-SC-04-CAC-005, CX-0157-SC-05-CAC-005.

Requirement​

3.4.4 IDENTIFIER OF SEMANTIC MODEL

The identifier urn:samm:io.catenax.delivery_information:2.0.0 MUST be used to define the semantics of the DeliveryInformation data.

Proof of Conformity​

  • The semanticId urn:samm:io.catenax.delivery_information:2.0.0 MUST be set in the SubmodelDescriptor of the provider's Digital Twin in the registry (CX-0002).
  • Where CX-0002 requires per-submodel assetsAsset On the Data Provider side, an Asset describes the data set which will be shared or can be consumed by a Data Consumer., the semanticId is additionally discoverable in the dcat:Dataset following the rules of CX-0002.

Additional Information​

Provide the submodel following CX-0002. Data assetsAsset On the Data Provider side, an Asset describes the data set which will be shared or can be consumed by a Data Consumer. differing only by major version are offered in parallel.

CX-0157-SC-01-CAC-006 — JSON schema validation​

  • type: MUST
  • topic: Semantics
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-02-CAC-004, CX-0157-SC-03-CAC-004, CX-0157-SC-04-CAC-006, CX-0157-SC-05-CAC-006.

Requirement​

3.4.5.2 JSON SCHEMA

The DeliveryInformation payload MUST validate against the JSON Schema generated from the aspect modelAspect Model 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). (the Value-Only payload for the GetSubmodel operation).

Proof of Conformity​

  • Validate the provider's egest payload against the aspect-model JSON Schema. The consumer is not required to validate the schema on ingest.

Additional Information​

none

CX-0157-SC-01-CAC-007 — Contract policy​

  • type: MUST
  • topic: Policy
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-02-CAC-005, CX-0157-SC-03-CAC-005, CX-0157-SC-04-CAC-007, CX-0157-SC-05-CAC-007.

Requirement​

2.1.3 POLICY CONSTRAINTS FOR DATA EXCHANGE

The contract (usage) policy for the DeliveryInformation data offer MUST contain, combined via and, the Use Case Framework (FrameworkAgreement) and at least the use case purpose (UsagePurpose) with right operand cx.puris.base:1.

Proof of Conformity​

  • Take the Contract Policy referenced by the Contract Definition of the DeliveryInformation offer and validate it against the CX-0152 policy-schema.json; confirm FrameworkAgreement is present and UsagePurpose is at least cx.puris.base:1.

Additional Information​

Follow the policy profile of CX-0152. Additional permissions, obligations and prohibitions MAY be used; access policies MAY additionally restrict by Membership / BPNL.

CX-0157-SC-01-CAC-008 — API implementation​

  • type: MUST
  • topic: APIAPI An API is a way for two or more computer programs to communicate with each other.
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-02-CAC-006, CX-0157-SC-03-CAC-006, CX-0157-SC-04-CAC-008, CX-0157-SC-05-CAC-008.

Requirement​

4 APPLICATION PROGRAMMING INTERFACES

The [CX-0002] APIsAPI An API is a way for two or more computer programs to communicate with each other. MUST be implemented by the data provider and the data consumer for the DeliveryInformation exchange.

Proof of Conformity​

  • Provider: the Digital Twin Registry and Submodel APIAPI An API is a way for two or more computer programs to communicate with each other. expose the DeliveryInformation submodel.
  • Consumer: discovery of the twin and ingest of the submodel succeed.

Additional Information​

Refer to the CX-0002 API chapters.

CX-0157-SC-01-CAC-009 — No horizontal exchange (MUST NOT)​

  • type: MUST NOT
  • topic: Compliance
  • automisable: false
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-02-CAC-007, CX-0157-SC-03-CAC-007, CX-0157-SC-04-CAC-009, CX-0157-SC-05-CAC-009.

Requirement​

5.1.1 DELIVERY INFORMATION PROCESS

Competitively sensitive DeliveryInformation related to other customersCustomer In the context of OSim, the receiver of produced goods from a supplier. or suppliersSupplier In the context of OSim, the producer of goods. MUST NOT be shared with others; the exchange MUST be direct and partner-specific.

Proof of Conformity​

  • Self-Assessment: the provider attests that data provisioning is partner-specific and that leakage is prevented across DSP catalog offerings, Shell and Submodel Descriptors, and the actual submodel data.
  • Reperform one exchange and attempt cross-partner access; confirm the data of one partner is not accessible to another (anti-test).

Additional Information​

Companies are RECOMMENDED to consult their legal department to avoid conflicts with competition law.

CX-0157-SC-01-CAC-010 — Customer responsibility​

  • type: MUST
  • topic: Process, Delivery Information
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Requirement​

5.1.1.1.2 PROCESS PRESENTATION (customerCustomer In the context of OSim, the receiver of produced goods from a supplier. is responsible for the whole delivery)

Under the incoterm EXW, the customerCustomer In the context of OSim, the receiver of produced goods from a supplier. MUST provide the departure information and MUST provide the arrival information.

Proof of Conformity​

  • Inspect a DeliveryInformation payload provided by the customerCustomer In the context of OSim, the receiver of produced goods from a supplier. for this variant: both departure and arrival event information are present. Reperform the exchange for one delivery.

Additional Information​

This variant applies to the incoterm where the customerCustomer In the context of OSim, the receiver of produced goods from a supplier. is responsible for both departure and arrival: EXW (Table 9). The actual arrival time is optional; if there is no confirmed date and time, a default arrival estimation MAY be used (e.g. departure date + 3 days).

CX-0157-SC-01-CAC-011 — Supplier responsibility​

  • type: MUST
  • topic: Process, Delivery Information
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Requirement​

5.1.1.2.2 PROCESS REPRESENTATION (supplierSupplier In the context of OSim, the producer of goods. is responsible for the whole delivery)

Under the incoterms DAP and DDP, the supplierSupplier In the context of OSim, the producer of goods. MUST provide the estimated arrival information and MUST provide the departure information.

Proof of Conformity​

  • Inspect a DeliveryInformation payload provided by the supplierSupplier In the context of OSim, the producer of goods. for this variant: both departure and estimated arrival event information are present. Reperform the exchange for one delivery.

Additional Information​

This variant applies to the incoterms where the supplierSupplier In the context of OSim, the producer of goods. is responsible for both departure and arrival: DAP, DDP (Table 9). The actual arrival time is optional; a default arrival estimation MAY be used (e.g. departure date + 3 days). Transport information is provided to the customerCustomer In the context of OSim, the receiver of produced goods from a supplier. only.

CX-0157-SC-01-CAC-012 — Split responsibility​

  • type: MUST
  • topic: Process, Delivery Information
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Requirement​

5.1.1.3.2 PROCESS PRESENTATION (responsibility is split between supplierSupplier In the context of OSim, the producer of goods. and customerCustomer In the context of OSim, the receiver of produced goods from a supplier.)

Under the incoterms FCA, FAS, FOB, CFR, CIF, CPT, CIP and DPU, the supplierSupplier In the context of OSim, the producer of goods. MUST provide the departure information and the customerCustomer In the context of OSim, the receiver of produced goods from a supplier. MUST provide the arrival information.

Proof of Conformity​

  • Inspect that the supplierSupplier In the context of OSim, the producer of goods.'s DeliveryInformation payload carries the departure information and the customerCustomer In the context of OSim, the receiver of produced goods from a supplier.'s payload carries the arrival information. Reperform the split exchange.

Additional Information​

This variant applies to the incoterms where the supplierSupplier In the context of OSim, the producer of goods. is responsible for departure and the customerCustomer In the context of OSim, the receiver of produced goods from a supplier. for arrival: FCA, FAS, FOB, CFR, CIF, CPT, CIP, DPU (Table 9). The actual arrival time is optional; a default arrival estimation MAY be used (e.g. departure date + 3 days).

CX-0157-SC-02 Short-Term Material Demand Exchange​

Reperformance walkthrough​

  1. The customerCustomer In the context of OSim, the receiver of produced goods from a supplier. attaches the ShortTermMaterialDemand submodel to its part type twin (CAC-001) with the correct semantic id and contract policy (CAC-003, CAC-005).
  2. The supplierSupplier In the context of OSim, the producer of goods. discovers and ingests the submodel (CAC-002, CAC-006).
  3. The demand payload uses valid demand categories (CAC-008) and validates against the JSON schema (CAC-004).
  4. In multi-sourcing, only supplierSupplier In the context of OSim, the producer of goods.-specific demand is exchanged (CAC-007).

CX-0157-SC-02-CAC-001 — Customer provides Short-Term Material Demand​

  • type: MUST
  • topic: Digital Twin Provisioning
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-001, CX-0157-SC-01-CAC-003, CX-0157-SC-03-CAC-001, CX-0157-SC-04-CAC-001, CX-0157-SC-04-CAC-003, CX-0157-SC-05-CAC-001, CX-0157-SC-05-CAC-003.

Requirement​

2.1.2 DATA REQUIRED

The customerCustomer In the context of OSim, the receiver of produced goods from a supplier. MUST provide the ShortTermMaterialDemand submodel data by attaching it to their part type twin.

Proof of Conformity​

  • Inspect the customerCustomer In the context of OSim, the receiver of produced goods from a supplier.'s part type twin: a SubmodelDescriptor for ShortTermMaterialDemand exists and its submodel is retrievable (egest) via the Digital Twin APIAPI An API is a way for two or more computer programs to communicate with each other. of CX-0002.

Additional Information​

Roles follow Table 4 of the standard.

CX-0157-SC-02-CAC-002 — Supplier consumes Short-Term Material Demand​

  • type: MUST
  • topic: Digital Twin Consumption
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-002, CX-0157-SC-01-CAC-004, CX-0157-SC-03-CAC-002, CX-0157-SC-04-CAC-002, CX-0157-SC-04-CAC-004, CX-0157-SC-05-CAC-002, CX-0157-SC-05-CAC-004.

Requirement​

2.1.2 DATA REQUIRED

The supplierSupplier In the context of OSim, the producer of goods. MUST consume the ShortTermMaterialDemand submodel data by reading it from the customerCustomer In the context of OSim, the receiver of produced goods from a supplier.'s part type twin.

Proof of Conformity​

  • Reperform discovery of the customerCustomer In the context of OSim, the receiver of produced goods from a supplier. twin and ingest of the ShortTermMaterialDemand submodel via connector and Digital Twin APIAPI An API is a way for two or more computer programs to communicate with each other. (CX-0002).

Additional Information​

Roles follow Table 4 of the standard.

CX-0157-SC-02-CAC-003 — Semantic model identity​

  • type: MUST
  • topic: Semantics, Versioning
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-005, CX-0157-SC-03-CAC-003, CX-0157-SC-04-CAC-005, CX-0157-SC-05-CAC-005.

Requirement​

3.1.4 IDENTIFIER OF SEMANTIC MODEL

The identifier urn:samm:io.catenax.short_term_material_demand:1.0.0 MUST be used to define the semantics of the ShortTermMaterialDemand data.

Proof of Conformity​

  • The semanticId urn:samm:io.catenax.short_term_material_demand:1.0.0 MUST be set in the SubmodelDescriptor of the provider's Digital Twin in the registry (CX-0002).
  • Where CX-0002 requires per-submodel assetsAsset On the Data Provider side, an Asset describes the data set which will be shared or can be consumed by a Data Consumer., the semanticId is additionally discoverable in the dcat:Dataset following the rules of CX-0002.

Additional Information​

Provide the submodel following CX-0002.

CX-0157-SC-02-CAC-004 — JSON schema validation​

  • type: MUST
  • topic: Semantics
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-006, CX-0157-SC-03-CAC-004, CX-0157-SC-04-CAC-006, CX-0157-SC-05-CAC-006.

Requirement​

3.1.5.2 JSON SCHEMA

The ShortTermMaterialDemand payload MUST validate against the JSON Schema generated from the aspect modelAspect Model 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)..

Proof of Conformity​

  • Validate the customerCustomer In the context of OSim, the receiver of produced goods from a supplier.'s egest payload against the aspect-model JSON Schema. The supplierSupplier In the context of OSim, the producer of goods. (consumer) is not required to validate the schema on ingest.

Additional Information​

none

CX-0157-SC-02-CAC-005 — Contract policy​

  • type: MUST
  • topic: Policy
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-007, CX-0157-SC-03-CAC-005, CX-0157-SC-04-CAC-007, CX-0157-SC-05-CAC-007.

Requirement​

2.1.3 POLICY CONSTRAINTS FOR DATA EXCHANGE

The contract (usage) policy for the ShortTermMaterialDemand data offer MUST contain, combined via and, the Use Case Framework (FrameworkAgreement) and at least the use case purpose (UsagePurpose) with right operand cx.puris.base:1.

Proof of Conformity​

  • Take the Contract Policy referenced by the Contract Definition of the ShortTermMaterialDemand offer and validate it against the CX-0152 policy-schema.json; confirm FrameworkAgreement is present and UsagePurpose is at least cx.puris.base:1.

Additional Information​

Follow the policy profile of CX-0152.

CX-0157-SC-02-CAC-006 — API implementation​

  • type: MUST
  • topic: APIAPI An API is a way for two or more computer programs to communicate with each other.
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-008, CX-0157-SC-03-CAC-006, CX-0157-SC-04-CAC-008, CX-0157-SC-05-CAC-008.

Requirement​

4 APPLICATION PROGRAMMING INTERFACES

The [CX-0002] APIsAPI An API is a way for two or more computer programs to communicate with each other. MUST be implemented by the data provider and the data consumer for the ShortTermMaterialDemand exchange.

Proof of Conformity​

  • Provider: the Digital Twin Registry and Submodel APIAPI An API is a way for two or more computer programs to communicate with each other. expose the ShortTermMaterialDemand submodel.
  • Consumer: discovery of the twin and ingest of the submodel succeed.

Additional Information​

Refer to the CX-0002 API chapters.

CX-0157-SC-02-CAC-007 — No horizontal exchange (MUST NOT)​

  • type: MUST NOT
  • topic: Compliance
  • automisable: false
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-009, CX-0157-SC-03-CAC-007, CX-0157-SC-04-CAC-009, CX-0157-SC-05-CAC-009.

Requirement​

5.2 SHORT-TERM MATERIAL DEMAND EXCHANGE

In multi-sourcing, competitively sensitive information MUST NOT be shared horizontally; demand data provided to a supplierSupplier In the context of OSim, the producer of goods. MUST be supplierSupplier In the context of OSim, the producer of goods.-specific.

Proof of Conformity​

  • Self-Assessment: the customerCustomer In the context of OSim, the receiver of produced goods from a supplier. attests that demand data is partner-specific and prevents conclusions about other suppliersSupplier In the context of OSim, the producer of goods..
  • Reperform one exchange and attempt to derive another supplierSupplier In the context of OSim, the producer of goods.'s demand; confirm it is not possible (anti-test).

Additional Information​

Companies are RECOMMENDED to consult their legal department.

CX-0157-SC-02-CAC-008 — Demand categories​

  • type: MUST
  • topic: Semantics
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Requirement​

3.1.2.1 SHORT-TERM MATERIAL DEMAND CATEGORY HANDLING

The ShortTermMaterialDemand data MUST use the demand categories defined in Table 6.

Proof of Conformity​

  • Inspect that the demand category codes in the ShortTermMaterialDemand payload are values from Table 6 (e.g. 0001, A1S1, SR99, PI01, OS01, OI01, ED01, PO01).

Additional Information​

The table supplements the aspect modelAspect Model 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)., which alone does not convey the meaning of the categories.

CX-0157-SC-03 Planned Production Output Exchange​

Reperformance walkthrough​

  1. The supplierSupplier In the context of OSim, the producer of goods. attaches the PlannedProductionOutput submodel to its part type twin (CAC-001) with the correct semantic id and contract policy (CAC-003, CAC-005).
  2. The customerCustomer In the context of OSim, the receiver of produced goods from a supplier. discovers and ingests the submodel (CAC-002, CAC-006) and validates the schema (CAC-004).
  3. In multi-customerCustomer In the context of OSim, the receiver of produced goods from a supplier. settings the supplierSupplier In the context of OSim, the producer of goods. avoids conclusions about competitors (CAC-007).

CX-0157-SC-03-CAC-001 — Supplier provides Planned Production Output​

  • type: MUST
  • topic: Digital Twin Provisioning
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-001, CX-0157-SC-01-CAC-003, CX-0157-SC-02-CAC-001, CX-0157-SC-04-CAC-001, CX-0157-SC-04-CAC-003, CX-0157-SC-05-CAC-001, CX-0157-SC-05-CAC-003.

Requirement​

2.1.2 DATA REQUIRED

The supplierSupplier In the context of OSim, the producer of goods. MUST provide the PlannedProductionOutput submodel data by attaching it to their part type twin.

Proof of Conformity​

  • Inspect the supplierSupplier In the context of OSim, the producer of goods.'s part type twin: a SubmodelDescriptor for PlannedProductionOutput exists and its submodel is retrievable (egest) via the Digital Twin APIAPI An API is a way for two or more computer programs to communicate with each other. of CX-0002.

Additional Information​

Roles follow Table 4 of the standard.

CX-0157-SC-03-CAC-002 — Customer consumes Planned Production Output​

  • type: MUST
  • topic: Digital Twin Consumption
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-002, CX-0157-SC-01-CAC-004, CX-0157-SC-02-CAC-002, CX-0157-SC-04-CAC-002, CX-0157-SC-04-CAC-004, CX-0157-SC-05-CAC-002, CX-0157-SC-05-CAC-004.

Requirement​

2.1.2 DATA REQUIRED

The customerCustomer In the context of OSim, the receiver of produced goods from a supplier. MUST consume the PlannedProductionOutput submodel data by reading it from the supplierSupplier In the context of OSim, the producer of goods.'s part type twin.

Proof of Conformity​

  • Reperform discovery of the supplierSupplier In the context of OSim, the producer of goods. twin and ingest of the PlannedProductionOutput submodel via connector and Digital Twin APIAPI An API is a way for two or more computer programs to communicate with each other. (CX-0002).

Additional Information​

Roles follow Table 4 of the standard.

CX-0157-SC-03-CAC-003 — Semantic model identity​

  • type: MUST
  • topic: Semantics, Versioning
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-005, CX-0157-SC-02-CAC-003, CX-0157-SC-04-CAC-005, CX-0157-SC-05-CAC-005.

Requirement​

3.3.4 IDENTIFIER OF SEMANTIC MODEL

The identifier urn:samm:io.catenax.planned_production_output:2.0.0 MUST be used to define the semantics of the PlannedProductionOutput data.

Proof of Conformity​

  • The semanticId urn:samm:io.catenax.planned_production_output:2.0.0 MUST be set in the SubmodelDescriptor of the provider's Digital Twin in the registry (CX-0002).
  • Where CX-0002 requires per-submodel assetsAsset On the Data Provider side, an Asset describes the data set which will be shared or can be consumed by a Data Consumer., the semanticId is additionally discoverable in the dcat:Dataset following the rules of CX-0002.

Additional Information​

Provide the submodel following CX-0002.

CX-0157-SC-03-CAC-004 — JSON schema validation​

  • type: MUST
  • topic: Semantics
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-006, CX-0157-SC-02-CAC-004, CX-0157-SC-04-CAC-006, CX-0157-SC-05-CAC-006.

Requirement​

3.3.5.2 JSON SCHEMA

The PlannedProductionOutput payload MUST validate against the JSON Schema generated from the aspect modelAspect Model 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)..

Proof of Conformity​

  • Validate the supplierSupplier In the context of OSim, the producer of goods.'s egest payload against the aspect-model JSON Schema. The customerCustomer In the context of OSim, the receiver of produced goods from a supplier. (consumer) is not required to validate the schema on ingest.

Additional Information​

none

CX-0157-SC-03-CAC-005 — Contract policy​

  • type: MUST
  • topic: Policy
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-007, CX-0157-SC-02-CAC-005, CX-0157-SC-04-CAC-007, CX-0157-SC-05-CAC-007.

Requirement​

2.1.3 POLICY CONSTRAINTS FOR DATA EXCHANGE

The contract (usage) policy for the PlannedProductionOutput data offer MUST contain, combined via and, the Use Case Framework (FrameworkAgreement) and at least the use case purpose (UsagePurpose) with right operand cx.puris.base:1.

Proof of Conformity​

  • Take the Contract Policy referenced by the Contract Definition of the PlannedProductionOutput offer and validate it against the CX-0152 policy-schema.json; confirm FrameworkAgreement is present and UsagePurpose is at least cx.puris.base:1.

Additional Information​

Follow the policy profile of CX-0152.

CX-0157-SC-03-CAC-006 — API implementation​

  • type: MUST
  • topic: APIAPI An API is a way for two or more computer programs to communicate with each other.
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-008, CX-0157-SC-02-CAC-006, CX-0157-SC-04-CAC-008, CX-0157-SC-05-CAC-008.

Requirement​

4 APPLICATION PROGRAMMING INTERFACES

The [CX-0002] APIsAPI An API is a way for two or more computer programs to communicate with each other. MUST be implemented by the data provider and the data consumer for the PlannedProductionOutput exchange.

Proof of Conformity​

  • Provider: the Digital Twin Registry and Submodel APIAPI An API is a way for two or more computer programs to communicate with each other. expose the PlannedProductionOutput submodel.
  • Consumer: discovery of the twin and ingest of the submodel succeed.

Additional Information​

Refer to the CX-0002 API chapters.

CX-0157-SC-03-CAC-007 — No competitor conclusions (MUST NOT)​

  • type: MUST NOT
  • topic: Compliance
  • automisable: false
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-009, CX-0157-SC-02-CAC-007, CX-0157-SC-04-CAC-009, CX-0157-SC-05-CAC-009.

Requirement​

5.3 PLANNED PRODUCTION OUTPUT EXCHANGE

PlannedProductionOutput data provided to a customerCustomer In the context of OSim, the receiver of produced goods from a supplier. MUST NOT include information that allows conclusions about a competitor, and MUST NOT be shared horizontally.

Proof of Conformity​

  • Self-Assessment: the supplierSupplier In the context of OSim, the producer of goods. attests that PlannedProductionOutput allocated to a customerCustomer In the context of OSim, the receiver of produced goods from a supplier. excludes other customersCustomer In the context of OSim, the receiver of produced goods from a supplier.' information.
  • Reperform one exchange and attempt to derive another customerCustomer In the context of OSim, the receiver of produced goods from a supplier.'s output; confirm it is not possible (anti-test).

Additional Information​

Recommended allocation methods: derive from orders/call-offs, from incoming Short-Term Material Demand, or from scheduled deliveries. Consult the legal department.

CX-0157-SC-04 Item Stock Exchange​

Reperformance walkthrough​

  1. The customerCustomer In the context of OSim, the receiver of produced goods from a supplier. provides ItemStock with direction inbound and the supplierSupplier In the context of OSim, the producer of goods. provides it with direction outbound on their respective part type twins (CAC-001, CAC-003, CAC-010), each with the correct semantic id and contract policy (CAC-005, CAC-007).
  2. Each partner consumes the other's ItemStock submodel (CAC-002, CAC-004, CAC-008) and validates the schema (CAC-006).
  3. Only partner-specific stock is exchanged (CAC-009).

CX-0157-SC-04-CAC-001 — Customer provides Item Stock (inbound)​

  • type: MUST
  • topic: Digital Twin Provisioning
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-001, CX-0157-SC-01-CAC-003, CX-0157-SC-02-CAC-001, CX-0157-SC-03-CAC-001, CX-0157-SC-04-CAC-003, CX-0157-SC-05-CAC-001, CX-0157-SC-05-CAC-003.

Requirement​

2.1.2 DATA REQUIRED

The customerCustomer In the context of OSim, the receiver of produced goods from a supplier. MUST provide the ItemStock submodel data (direction inbound) by attaching it to their part type twin.

Proof of Conformity​

  • Inspect the customerCustomer In the context of OSim, the receiver of produced goods from a supplier.'s part type twin: a SubmodelDescriptor for ItemStock exists and its submodel is retrievable (egest) via the Digital Twin APIAPI An API is a way for two or more computer programs to communicate with each other. of CX-0002.

Additional Information​

Roles and direction (inbound for the customerCustomer In the context of OSim, the receiver of produced goods from a supplier.) follow Table 4 of the standard.

CX-0157-SC-04-CAC-002 — Supplier consumes Item Stock​

  • type: MUST
  • topic: Digital Twin Consumption
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-002, CX-0157-SC-01-CAC-004, CX-0157-SC-02-CAC-002, CX-0157-SC-03-CAC-002, CX-0157-SC-04-CAC-004, CX-0157-SC-05-CAC-002, CX-0157-SC-05-CAC-004.

Requirement​

2.1.2 DATA REQUIRED

The supplierSupplier In the context of OSim, the producer of goods. MUST consume the ItemStock submodel data (direction inbound) by reading it from the customerCustomer In the context of OSim, the receiver of produced goods from a supplier.'s part type twin.

Proof of Conformity​

  • Reperform discovery of the customerCustomer In the context of OSim, the receiver of produced goods from a supplier. twin and ingest of the ItemStock submodel via connector and Digital Twin APIAPI An API is a way for two or more computer programs to communicate with each other. (CX-0002).

Additional Information​

Roles follow Table 4 of the standard.

CX-0157-SC-04-CAC-003 — Supplier provides Item Stock (outbound)​

  • type: MUST
  • topic: Digital Twin Provisioning
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-001, CX-0157-SC-01-CAC-003, CX-0157-SC-02-CAC-001, CX-0157-SC-03-CAC-001, CX-0157-SC-04-CAC-001, CX-0157-SC-05-CAC-001, CX-0157-SC-05-CAC-003.

Requirement​

2.1.2 DATA REQUIRED

The supplierSupplier In the context of OSim, the producer of goods. MUST provide the ItemStock submodel data (direction outbound) by attaching it to their part type twin.

Proof of Conformity​

  • Inspect the supplierSupplier In the context of OSim, the producer of goods.'s part type twin: a SubmodelDescriptor for ItemStock exists and its submodel is retrievable (egest) via the Digital Twin APIAPI An API is a way for two or more computer programs to communicate with each other. of CX-0002.

Additional Information​

Roles and direction (outbound for the supplierSupplier In the context of OSim, the producer of goods.) follow Table 4 of the standard.

CX-0157-SC-04-CAC-004 — Customer consumes Item Stock​

  • type: MUST
  • topic: Digital Twin Consumption
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-002, CX-0157-SC-01-CAC-004, CX-0157-SC-02-CAC-002, CX-0157-SC-03-CAC-002, CX-0157-SC-04-CAC-002, CX-0157-SC-05-CAC-002, CX-0157-SC-05-CAC-004.

Requirement​

2.1.2 DATA REQUIRED

The customerCustomer In the context of OSim, the receiver of produced goods from a supplier. MUST consume the ItemStock submodel data (direction outbound) by reading it from the supplierSupplier In the context of OSim, the producer of goods.'s part type twin.

Proof of Conformity​

  • Reperform discovery of the supplierSupplier In the context of OSim, the producer of goods. twin and ingest of the ItemStock submodel via connector and Digital Twin APIAPI An API is a way for two or more computer programs to communicate with each other. (CX-0002).

Additional Information​

Roles follow Table 4 of the standard.

CX-0157-SC-04-CAC-005 — Semantic model identity​

  • type: MUST
  • topic: Semantics, Versioning
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-005, CX-0157-SC-02-CAC-003, CX-0157-SC-03-CAC-003, CX-0157-SC-05-CAC-005.

Requirement​

3.2.4 IDENTIFIER OF SEMANTIC MODEL

The identifier urn:samm:io.catenax.item_stock:2.0.0 MUST be used to define the semantics of the ItemStock data.

Proof of Conformity​

  • The semanticId urn:samm:io.catenax.item_stock:2.0.0 MUST be set in the SubmodelDescriptor of the provider's Digital Twin in the registry (CX-0002).
  • Where CX-0002 requires per-submodel assetsAsset On the Data Provider side, an Asset describes the data set which will be shared or can be consumed by a Data Consumer., the semanticId is additionally discoverable in the dcat:Dataset following the rules of CX-0002.

Additional Information​

Provide the submodel following CX-0002.

CX-0157-SC-04-CAC-006 — JSON schema validation​

  • type: MUST
  • topic: Semantics
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-006, CX-0157-SC-02-CAC-004, CX-0157-SC-03-CAC-004, CX-0157-SC-05-CAC-006.

Requirement​

3.2.5.2 JSON SCHEMA

The ItemStock payload MUST validate against the JSON Schema generated from the aspect modelAspect Model 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)..

Proof of Conformity​

  • Validate the provider's egest payload against the aspect-model JSON Schema. The consumer is not required to validate the schema on ingest.

Additional Information​

none

CX-0157-SC-04-CAC-007 — Contract policy​

  • type: MUST
  • topic: Policy
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-007, CX-0157-SC-02-CAC-005, CX-0157-SC-03-CAC-005, CX-0157-SC-05-CAC-007.

Requirement​

2.1.3 POLICY CONSTRAINTS FOR DATA EXCHANGE

The contract (usage) policy for the ItemStock data offer MUST contain, combined via and, the Use Case Framework (FrameworkAgreement) and at least the use case purpose (UsagePurpose) with right operand cx.puris.base:1.

Proof of Conformity​

  • Take the Contract Policy referenced by the Contract Definition of the ItemStock offer and validate it against the CX-0152 policy-schema.json; confirm FrameworkAgreement is present and UsagePurpose is at least cx.puris.base:1.

Additional Information​

Follow the policy profile of CX-0152.

CX-0157-SC-04-CAC-008 — API implementation​

  • type: MUST
  • topic: APIAPI An API is a way for two or more computer programs to communicate with each other.
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-008, CX-0157-SC-02-CAC-006, CX-0157-SC-03-CAC-006, CX-0157-SC-05-CAC-008.

Requirement​

4 APPLICATION PROGRAMMING INTERFACES

The [CX-0002] APIsAPI An API is a way for two or more computer programs to communicate with each other. MUST be implemented by the data provider and the data consumer for the ItemStock exchange.

Proof of Conformity​

  • Provider: the Digital Twin Registry and Submodel APIAPI An API is a way for two or more computer programs to communicate with each other. expose the ItemStock submodel.
  • Consumer: discovery of the twin and ingest of the submodel succeed.

Additional Information​

Refer to the CX-0002 API chapters.

CX-0157-SC-04-CAC-009 — No horizontal exchange (MUST NOT)​

  • type: MUST NOT
  • topic: Compliance
  • automisable: false
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-009, CX-0157-SC-02-CAC-007, CX-0157-SC-03-CAC-007, CX-0157-SC-05-CAC-009.

Requirement​

5.4 ITEM STOCK EXCHANGE

In multi-sourcing and multi-customerCustomer In the context of OSim, the receiver of produced goods from a supplier. scenarios, ItemStock information in relation to other customersCustomer In the context of OSim, the receiver of produced goods from a supplier. or suppliersSupplier In the context of OSim, the producer of goods. MUST NOT be shared horizontally.

Proof of Conformity​

  • Self-Assessment: the provider attests that stock data is partner-specific and excludes other partners' capacities, call-offs, deliveries, consumption and stock.
  • Reperform one exchange and attempt to derive another partner's stock; confirm it is not possible (anti-test).

Additional Information​

Companies are RECOMMENDED to consult their legal department.

CX-0157-SC-04-CAC-010 — Stock direction​

  • type: MUST
  • topic: Semantics, Process
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Requirement​

2.1.2 DATA REQUIRED

ItemStock MUST be provided with the direction defined in Table 4: inbound when provided by the customerCustomer In the context of OSim, the receiver of produced goods from a supplier. and outbound when provided by the supplierSupplier In the context of OSim, the producer of goods..

Proof of Conformity​

  • Inspect the direction property of the ItemStock payload for the provider role: inbound for the customerCustomer In the context of OSim, the receiver of produced goods from a supplier., outbound for the supplierSupplier In the context of OSim, the producer of goods..

Additional Information​

The same direction rule applies to DaysOfSupply (see CX-0157-SC-05-CAC-001 and CX-0157-SC-05-CAC-003).

CX-0157-SC-05 Days of Supply Exchange​

Reperformance walkthrough​

  1. The customerCustomer In the context of OSim, the receiver of produced goods from a supplier. provides DaysOfSupply with direction inbound and the supplierSupplier In the context of OSim, the producer of goods. provides it with direction outbound on their respective part type twins (CAC-001, CAC-003), each with the correct semantic id and contract policy (CAC-005, CAC-007).
  2. Each partner consumes the other's DaysOfSupply submodel (CAC-002, CAC-004, CAC-008) and validates the schema (CAC-006).
  3. In multi-sourcing and multi-customerCustomer In the context of OSim, the receiver of produced goods from a supplier. settings, allocated Days of Supply are sent to the particular partner and horizontal exchange is avoided (CAC-009, CAC-010, CAC-011).
  4. The exchanged Days of Supply values are recomputed from the projected item stock and the demand or outgoing deliveries (CAC-012, CAC-013).

CX-0157-SC-05-CAC-001 — Customer provides Days of Supply (inbound)​

  • type: MUST
  • topic: Digital Twin Provisioning
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-001, CX-0157-SC-01-CAC-003, CX-0157-SC-02-CAC-001, CX-0157-SC-03-CAC-001, CX-0157-SC-04-CAC-001, CX-0157-SC-04-CAC-003, CX-0157-SC-05-CAC-003.

Requirement​

2.1.2 DATA REQUIRED

The customerCustomer In the context of OSim, the receiver of produced goods from a supplier. MUST provide the DaysOfSupply submodel data (direction inbound) by attaching it to their part type twin.

Proof of Conformity​

  • Inspect the customerCustomer In the context of OSim, the receiver of produced goods from a supplier.'s part type twin: a SubmodelDescriptor for DaysOfSupply exists and its submodel is retrievable (egest) via the Digital Twin APIAPI An API is a way for two or more computer programs to communicate with each other. of CX-0002.

Additional Information​

Roles and direction (inbound for the customerCustomer In the context of OSim, the receiver of produced goods from a supplier.) follow Table 4 of the standard.

CX-0157-SC-05-CAC-002 — Supplier consumes Days of Supply​

  • type: MUST
  • topic: Digital Twin Consumption
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-002, CX-0157-SC-01-CAC-004, CX-0157-SC-02-CAC-002, CX-0157-SC-03-CAC-002, CX-0157-SC-04-CAC-002, CX-0157-SC-04-CAC-004, CX-0157-SC-05-CAC-004.

Requirement​

2.1.2 DATA REQUIRED

The supplierSupplier In the context of OSim, the producer of goods. MUST consume the DaysOfSupply submodel data (direction inbound) by reading it from the customerCustomer In the context of OSim, the receiver of produced goods from a supplier.'s part type twin.

Proof of Conformity​

  • Reperform discovery of the customerCustomer In the context of OSim, the receiver of produced goods from a supplier. twin and ingest of the DaysOfSupply submodel via connector and Digital Twin APIAPI An API is a way for two or more computer programs to communicate with each other. (CX-0002).

Additional Information​

Roles follow Table 4 of the standard.

CX-0157-SC-05-CAC-003 — Supplier provides Days of Supply (outbound)​

  • type: MUST
  • topic: Digital Twin Provisioning
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-001, CX-0157-SC-01-CAC-003, CX-0157-SC-02-CAC-001, CX-0157-SC-03-CAC-001, CX-0157-SC-04-CAC-001, CX-0157-SC-04-CAC-003, CX-0157-SC-05-CAC-001.

Requirement​

2.1.2 DATA REQUIRED

The supplierSupplier In the context of OSim, the producer of goods. MUST provide the DaysOfSupply submodel data (direction outbound) by attaching it to their part type twin.

Proof of Conformity​

  • Inspect the supplierSupplier In the context of OSim, the producer of goods.'s part type twin: a SubmodelDescriptor for DaysOfSupply exists and its submodel is retrievable (egest) via the Digital Twin APIAPI An API is a way for two or more computer programs to communicate with each other. of CX-0002.

Additional Information​

Roles and direction (outbound for the supplierSupplier In the context of OSim, the producer of goods.) follow Table 4 of the standard.

CX-0157-SC-05-CAC-004 — Customer consumes Days of Supply​

  • type: MUST
  • topic: Digital Twin Consumption
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-002, CX-0157-SC-01-CAC-004, CX-0157-SC-02-CAC-002, CX-0157-SC-03-CAC-002, CX-0157-SC-04-CAC-002, CX-0157-SC-04-CAC-004, CX-0157-SC-05-CAC-002.

Requirement​

2.1.2 DATA REQUIRED

The customerCustomer In the context of OSim, the receiver of produced goods from a supplier. MUST consume the DaysOfSupply submodel data (direction outbound) by reading it from the supplierSupplier In the context of OSim, the producer of goods.'s part type twin.

Proof of Conformity​

  • Reperform discovery of the supplierSupplier In the context of OSim, the producer of goods. twin and ingest of the DaysOfSupply submodel via connector and Digital Twin APIAPI An API is a way for two or more computer programs to communicate with each other. (CX-0002).

Additional Information​

Roles follow Table 4 of the standard.

CX-0157-SC-05-CAC-005 — Semantic model identity​

  • type: MUST
  • topic: Semantics, Versioning
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-005, CX-0157-SC-02-CAC-003, CX-0157-SC-03-CAC-003, CX-0157-SC-04-CAC-005.

Requirement​

3.5.4 IDENTIFIER OF SEMANTIC MODEL

The identifier urn:samm:io.catenax.days_of_supply:2.0.0 MUST be used to define the semantics of the DaysOfSupply data.

Proof of Conformity​

  • The semanticId urn:samm:io.catenax.days_of_supply:2.0.0 MUST be set in the SubmodelDescriptor of the provider's Digital Twin in the registry (CX-0002).
  • Where CX-0002 requires per-submodel assetsAsset On the Data Provider side, an Asset describes the data set which will be shared or can be consumed by a Data Consumer., the semanticId is additionally discoverable in the dcat:Dataset following the rules of CX-0002.

Additional Information​

Provide the submodel following CX-0002.

CX-0157-SC-05-CAC-006 — JSON schema validation​

  • type: MUST
  • topic: Semantics
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-006, CX-0157-SC-02-CAC-004, CX-0157-SC-03-CAC-004, CX-0157-SC-04-CAC-006.

Requirement​

3.5.5.2 JSON SCHEMA

The DaysOfSupply payload MUST validate against the JSON Schema generated from the aspect modelAspect Model 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)..

Proof of Conformity​

  • Validate the provider's egest payload against the aspect-model JSON Schema. The consumer is not required to validate the schema on ingest.

Additional Information​

none

CX-0157-SC-05-CAC-007 — Contract policy​

  • type: MUST
  • topic: Policy
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-007, CX-0157-SC-02-CAC-005, CX-0157-SC-03-CAC-005, CX-0157-SC-04-CAC-007.

Requirement​

2.1.3 POLICY CONSTRAINTS FOR DATA EXCHANGE

The contract (usage) policy for the DaysOfSupply data offer MUST contain, combined via and, the Use Case Framework (FrameworkAgreement) and at least the use case purpose (UsagePurpose) with right operand cx.puris.base:1.

Proof of Conformity​

  • Take the Contract Policy referenced by the Contract Definition of the DaysOfSupply offer and validate it against the CX-0152 policy-schema.json; confirm FrameworkAgreement is present and UsagePurpose is at least cx.puris.base:1.

Additional Information​

Follow the policy profile of CX-0152.

CX-0157-SC-05-CAC-008 — API implementation​

  • type: MUST
  • topic: APIAPI An API is a way for two or more computer programs to communicate with each other.
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-008, CX-0157-SC-02-CAC-006, CX-0157-SC-03-CAC-006, CX-0157-SC-04-CAC-008.

Requirement​

4 APPLICATION PROGRAMMING INTERFACES

The [CX-0002] APIsAPI An API is a way for two or more computer programs to communicate with each other. MUST be implemented by the data provider and the data consumer for the DaysOfSupply exchange.

Proof of Conformity​

  • Provider: the Digital Twin Registry and Submodel APIAPI An API is a way for two or more computer programs to communicate with each other. expose the DaysOfSupply submodel.
  • Consumer: discovery of the twin and ingest of the submodel succeed.

Additional Information​

Refer to the CX-0002 API chapters.

CX-0157-SC-05-CAC-009 — No horizontal exchange (MUST NOT)​

  • type: MUST NOT
  • topic: Compliance
  • automisable: false
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Same evaluation procedure as CX-0157-SC-01-CAC-009, CX-0157-SC-02-CAC-007, CX-0157-SC-03-CAC-007, CX-0157-SC-04-CAC-009.

Requirement​

5.5.1 DAYS OF SUPPLY PROCESS

DaysOfSupply information in relation to other customersCustomer In the context of OSim, the receiver of produced goods from a supplier. or suppliersSupplier In the context of OSim, the producer of goods. MUST NOT be shared horizontally.

Proof of Conformity​

  • Self-Assessment: the provider attests that Days of Supply data is partner-specific.
  • Reperform one exchange and attempt to derive another partner's Days of Supply; confirm it is not possible (anti-test).

Additional Information​

Companies are RECOMMENDED to consult their legal department.

CX-0157-SC-05-CAC-010 — Multi-sourcing allocation​

  • type: MUST
  • topic: Process, Compliance
  • automisable: false
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Requirement​

5.5.3 DAYS OF SUPPLY MANAGEMENT WITHIN MULTI-SOURCING SCENARIOS

In multi-sourcing, the customerCustomer In the context of OSim, the receiver of produced goods from a supplier. MUST make sure that allocated Days of Supply based on allocated Item Stock are sent to the particular supplierSupplier In the context of OSim, the producer of goods. and MUST avoid horizontal exchange of competitively sensitive information.

Proof of Conformity​

  • Reperform the allocation for a multi-sourcing setup: the Days of Supply provided to a supplierSupplier In the context of OSim, the producer of goods. are computed from that supplierSupplier In the context of OSim, the producer of goods.'s allocated item stock only.
  • Self-Assessment that no other supplierSupplier In the context of OSim, the producer of goods.'s information is derivable.

Additional Information​

For calculation of allocated item stock, see Annex 1 of the standard.

CX-0157-SC-05-CAC-011 — Multi-customer allocation​

  • type: MUST
  • topic: Process, Compliance
  • automisable: false
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Requirement​

5.5.4 DAYS OF SUPPLY MANAGEMENT WITHIN MULTI-CUSTOMER SCENARIO

In a multi-customerCustomer In the context of OSim, the receiver of produced goods from a supplier. scenario, the supplierSupplier In the context of OSim, the producer of goods. MUST make sure that allocated Days of Supply based on allocated Item Stock are sent to the particular customerCustomer In the context of OSim, the receiver of produced goods from a supplier. and MUST avoid horizontal exchange of competitively sensitive information.

Proof of Conformity​

  • Reperform the allocation for a multi-customerCustomer In the context of OSim, the receiver of produced goods from a supplier. setup: the Days of Supply provided to a customerCustomer In the context of OSim, the receiver of produced goods from a supplier. are computed from that customerCustomer In the context of OSim, the receiver of produced goods from a supplier.'s allocated item stock only.
  • Self-Assessment that no other customerCustomer In the context of OSim, the receiver of produced goods from a supplier.'s information is derivable.

Additional Information​

For calculation of allocated item stock, see Annex 2 of the standard.

CX-0157-SC-05-CAC-012 — Customer Days of Supply calculation​

  • type: MUST
  • topic: Days of Supply, Recalculation
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Requirement​

5.5.2.2 PROCESS REPRESENTATION and Table 35

The customerCustomer In the context of OSim, the receiver of produced goods from a supplier.'s DaysOfSupply (direction inbound) MUST be calculated from the projected item stock and the future daily demand. For a reference day with projected item stock S and future daily demand D(1), D(2), ... (where D(1) is the demand of the following day), the value is DaysOfSupply = k + (S - sum(D(1)..D(k))) / D(k+1), where k is the largest integer for which sum(D(1)..D(k)) <= S. If S <= 0, then DaysOfSupply = 0.

Proof of Conformity​

  • Recalculate the daysOfSupply value from the provided projected item stock and demand series for at least one sample date and compare it to the value the customerCustomer In the context of OSim, the receiver of produced goods from a supplier. provides (allowing for rounding).

Additional Information​

In the customerCustomer In the context of OSim, the receiver of produced goods from a supplier. view the stock decreases through internal demand and increases through incoming deliveries (see Table 35 of the standard).

CX-0157-SC-05-CAC-013 — Supplier Days of Supply calculation​

  • type: MUST
  • topic: Days of Supply, Recalculation
  • automisable: true
  • assessment:
    • Inspection
    • Observation
    • Self-Assessment
    • Inquiry
    • Confirmation
    • Recalculation
    • Reperformance
    • Analytical Procedures

Requirement​

5.5.2.2 PROCESS REPRESENTATION and Table 36

The supplierSupplier In the context of OSim, the producer of goods.'s DaysOfSupply (direction outbound) MUST be calculated from the projected item stock and the future daily outgoing deliveries. For a reference day with projected item stock S and future daily outgoing deliveries O(1), O(2), ... (where O(1) is the outgoing delivery of the following day), the value is DaysOfSupply = k + (S - sum(O(1)..O(k))) / O(k+1), where k is the largest integer for which sum(O(1)..O(k)) <= S. If S <= 0, then DaysOfSupply = 0.

Proof of Conformity​

  • Recalculate the daysOfSupply value from the provided projected item stock and outgoing delivery series for at least one sample date and compare it to the value the supplierSupplier In the context of OSim, the producer of goods. provides (allowing for rounding).

Additional Information​

In the supplierSupplier In the context of OSim, the producer of goods. view the stock decreases through outgoing deliveries and increases through internal production (see Table 36 of the standard).