From 68e3013f5c77520317cd6e64fa92326fc8a67e9c Mon Sep 17 00:00:00 2001 From: "Marvin Manoury (Fraunhofer IPK)" Date: Fri, 22 May 2026 18:53:19 +0200 Subject: [PATCH 01/10] feat: structuring based on KIT template --- .../{ => adoption-view}/adoption-view.md | 273 ++++++- .../development-view/architecture.md | 85 +++ .../development-view/development-view.md | 676 ++++++++++++++++++ .../industry-extensions/_category_.json | 8 + .../automotive/Overview.md | 199 ++++++ .../requirements-kit/resources/img/REUSE.toml | 8 + .../requirements_customer-journey.png | Bin .../requirements_customer-journey.png.license | 0 .../software-development-view.md | 245 ------- 9 files changed, 1237 insertions(+), 257 deletions(-) rename docs-kits/kits/requirements-kit/{ => adoption-view}/adoption-view.md (70%) create mode 100644 docs-kits/kits/requirements-kit/development-view/architecture.md create mode 100644 docs-kits/kits/requirements-kit/development-view/development-view.md create mode 100644 docs-kits/kits/requirements-kit/industry-extensions/_category_.json create mode 100644 docs-kits/kits/requirements-kit/industry-extensions/automotive/Overview.md create mode 100644 docs-kits/kits/requirements-kit/resources/img/REUSE.toml rename docs-kits/kits/requirements-kit/resources/{ => img}/requirements_customer-journey.png (100%) rename docs-kits/kits/requirements-kit/resources/{ => img}/requirements_customer-journey.png.license (100%) delete mode 100644 docs-kits/kits/requirements-kit/software-development-view.md diff --git a/docs-kits/kits/requirements-kit/adoption-view.md b/docs-kits/kits/requirements-kit/adoption-view/adoption-view.md similarity index 70% rename from docs-kits/kits/requirements-kit/adoption-view.md rename to docs-kits/kits/requirements-kit/adoption-view/adoption-view.md index 98334c3f1455..4e705e5a940b 100644 --- a/docs-kits/kits/requirements-kit/adoption-view.md +++ b/docs-kits/kits/requirements-kit/adoption-view/adoption-view.md @@ -1,18 +1,54 @@ --- id: adoption-view title: Adoption View -description: 'Adoption View Requirements Kit' -sidebar_position: 2 +sidebar_position: 1 --- + + + + import Kit3DLogo from '@site/src/components/2.0/Kit3DLogo'; + + +Welcome to the **Requirements KIT Adoption View**. This view provides business value, strategic benefits, and use cases for business stakeholders and decision-makers. + +:::info Target Audience +Business Managers, Product Owners, Solution Architects, Industry Experts, and Decision Makers. +::: + +--- + ## Vision & Mission ### Vision +:::note Vision Statement +Requirements Engineering shall be a cross-company activity where different companies refine the requirements together to create an optimal specification and thus enable a fast and reliable product engineering. +::: + Our vision is to establish a seamless, secure, and efficient engineering platform within the Catena-X ecosystem. In a first step a collaborative platform for cross company requirements management that enables quick information access and multiple company collaboration via a standardized solution in the Catena-X dataspace, inspired by ReqIF (Requirements Interchange Format). By leveraging ReqIF, we aim to optimize the information flow and collaboration between OEMs and their suppliers, fostering a deep understanding and clear communication of requirements across company boundaries, while reducing time for exchanging requirements from point to point using common data exchange tools. At the heart of this commitment is the guarantee of data sovereignty any time. Each partner should be able to share their data securely while retaining full control over their own information. This enables transparent and trustworthy collaboration in product development by providing all stakeholders access to relevant requirement sets and documents without compromising proprietary or confidential information. @@ -27,11 +63,18 @@ This vision opens the way for innovative and collaborative product development b ### Mission +:::note Mission Statement +The KIT shall describe usable data models and approaches to aggregate and align Requirements in a data ecosystem. +::: + + The Requirements Kit aims to meticulously outline requirements by incorporating essential standards, aspect models and business logics. Its approach is designed to facilitate the exchange of requirements information between OEMs and Tier-N suppliers, ensuring that all relevant data is gathered and enabling authorized stakeholders to collaborate effectively. The data exchange process adheres to the Catena-X network's principles of data sovereignty, ensuring secure and compliant interactions. By following a standardized pipeline and utilizing data models within a data ecosystem, each partner is empowered to use their preferred applications, fostering a flexible and efficient collaboration environment. -## Business Value & Benefits +--- + +## Business Value -### Business Value +### Value Proposition #1: [Title] The "Requirements-KIT" provides guidelines and standards, such as semantic models and data exchange processes, which help companies create a reliable and sovereign data exchange system with their partners. @@ -39,15 +82,31 @@ This reduces cost and effort needed to integrate data-driven engineering process Since this KIT is built on the Industry Core KIT and will be closely connected to upcoming other KITSs within the Engineering Domain, investment and implementation costs to integrate requirement services are reduced. -### Todays Challenge +**Benefit**: [Primary benefit description] -As product development becomes more and more cross-company, the requirements that are necessary for the specification of the product to be developed must also be exchanged and harmonized across companies. This exchange for coordination between the customer and the development partner takes place in an iterative process that results in various documentation and changes to the specifications. +**Target Stakeholders**: [OEMs | SMEs | Solution Providers | etc.] -Nowadays, the exchange of requirements is largely file-based, with the files being provided or exchanged via company portals (B2B platforms), for example. In most cases, the requirements are first managed by the client in special requirements management software. As a starting point for collaboration in the product development process, one or more files for the product to be developed are extracted from the requirements management software with the requirements and possibly other information and made available to the development partner. In order for the development partner to view and evaluate the requirements, they must import the file into their requirements management tool (which may or may not be the same as the customer's). Once the requirements have been evaluated by the development partner, the partner exports another file from its requirements management tool and makes it available to the client. The client then imports this file back into its system and evaluates the development partner's scores, comments, etc. +**Measurable Outcomes**: [Key metrics] -This involves the circular processing of requests between partners, which can result in multiple file exports and imports to and from the respective systems. Each import/export results in a break in the data. Changes within each version of the files must be tracked and displayed by the requirements management tools. This method of working with requirements is very time consuming and requires a lot of manual effort that has nothing to do with the actual evaluation of the requirements. +### Value Proposition #2: [Title] -In addition to the challenges mentioned above, there is also the issue that the files can be designed in a variety of content forms and the formats of the files can also vary. The formats can be divided into structured and unstructured files. Unstructured files are texts, tables etc. that are not organized into individual requirements without prior processing. These increase the effort required to organize the document into individual requirements. This also makes the exchange with the partner more difficult, as the partner does not know the newly created structure. With structured files, the aforementioned circumstances no longer exist, as the requirements are already organized. In the best case, a standardized form, such as the ReqIF format, is used. However, even when using standardized formats such as ReqIF, it is still necessary to agree on a common data model for exporting and importing in advance so that data exchange via the various requirements management tools works as smoothly as possible. +**Benefit**: [Second benefit description] + +**Target Stakeholders**: [Target audience] + +**Measurable Outcomes**: [Key metrics] + +### Value Proposition #3: [Title] + +**Benefit**: [Third benefit description] + +**Target Stakeholders**: [Target audience] + +**Measurable Outcomes**: [Key metrics] + +--- + +### Summary of Business Benefits ### Benefits for OEM, SME and Solution Provider @@ -84,11 +143,88 @@ Catena-X offers solution providers a variety of strategic advantages to leverage 9. Access to data and analysis: With access to valuable industrial data, solution providers can develop and enhance their analytics and optimization solutions to boost operational efficiency and decision-making processes for customers. 10. Accelerated digital transformation: Catena-X allows solution providers to position their transformation strategies directly within the context of the automotive industry, a sector that is continually moving towards digital technologies. -## Customer Journey -![Customer Journey](resources/requirements_customer-journey.png) +| Stakeholder Type | Key Benefits | Time to Value | +|------------------|--------------|---------------| +| **OEMs** | [List 2-3 benefits for large enterprises] | [e.g., "6 months"] | +| **SMEs** | [List 2-3 benefits for small-medium enterprises] | [e.g., "3 months"] | +| **Solution Providers** | [List 2-3 benefits for tech vendors] | [e.g., "90 days"] | +| **Data Providers** | [List 2-3 benefits for data providers] | [e.g., "4 weeks"] | + +--- + +## Use Case Context + +### Industry Challenge + +As product development becomes more and more cross-company, the requirements that are necessary for the specification of the product to be developed must also be exchanged and harmonized across companies. This exchange for coordination between the customer and the development partner takes place in an iterative process that results in various documentation and changes to the specifications. + +Nowadays, the exchange of requirements is largely file-based, with the files being provided or exchanged via company portals (B2B platforms), for example. In most cases, the requirements are first managed by the client in special requirements management software. As a starting point for collaboration in the product development process, one or more files for the product to be developed are extracted from the requirements management software with the requirements and possibly other information and made available to the development partner. In order for the development partner to view and evaluate the requirements, they must import the file into their requirements management tool (which may or may not be the same as the customer's). Once the requirements have been evaluated by the development partner, the partner exports another file from its requirements management tool and makes it available to the client. The client then imports this file back into its system and evaluates the development partner's scores, comments, etc. + +This involves the circular processing of requests between partners, which can result in multiple file exports and imports to and from the respective systems. Each import/export results in a break in the data. Changes within each version of the files must be tracked and displayed by the requirements management tools. This method of working with requirements is very time consuming and requires a lot of manual effort that has nothing to do with the actual evaluation of the requirements. + +In addition to the challenges mentioned above, there is also the issue that the files can be designed in a variety of content forms and the formats of the files can also vary. The formats can be divided into structured and unstructured files. Unstructured files are texts, tables etc. that are not organized into individual requirements without prior processing. These increase the effort required to organize the document into individual requirements. This also makes the exchange with the partner more difficult, as the partner does not know the newly created structure. With structured files, the aforementioned circumstances no longer exist, as the requirements are already organized. In the best case, a standardized form, such as the ReqIF format, is used. However, even when using standardized formats such as ReqIF, it is still necessary to agree on a common data model for exporting and importing in advance so that data exchange via the various requirements management tools works as smoothly as possible. + + +**Current Challenges:** + +- **Challenge 1**: [Problem description and impact] +- **Challenge 2**: [Problem description and impact] +- **Challenge 3**: [Problem description and impact] + +### The Solution + +[Explain how this KIT addresses the challenges] + +**Solution Components:** + +1. **[Component 1]**: [Description] +2. **[Component 2]**: [Description] +3. **[Component 3]**: [Description] + +--- + +## Use Cases + +### Primary Use Case: [Use Case Name] + +**Description**: [Use case description] + +**Actors**: [Actor 1], [Actor 2], [Actor 3] + +**Process Flow**: + +1. [Step 1 description] +2. [Step 2 description] +3. [Step 3 description] -## User Journey +**Business Outcomes**: [Key outcomes] + +**Success Metrics**: [Key metrics] + +### Secondary Use Case: [Use Case Name] + +[Same structure as primary use case] + +### Additional Use Cases + +1. **[Use Case 3]**: [Brief description] +2. **[Use Case 4]**: [Brief description] + +--- + +## Business Processes + +:::tip +For industry-specific business processes, see the [Industry Extensions](https://github.com/eclipse-tractusx/eclipse-tractusx.github.io/tree/main/docs-kits/kit-template/industry-extensions) documentation. +::: + +### Core Business Process: [Process Name] + + +![Customer Journey](../resources/img/requirements_customer-journey.png) + +### Core Business Process: User Journey ```mermaid flowchart TD @@ -112,6 +248,117 @@ flowchart TD E --> G ``` +### Core Business Process: [Process Name] + +**Purpose**: [Business goal] + +**Stakeholders**: [List key stakeholders] + +**Process Steps**: + +```mermaid +sequenceDiagram + participant A as Actor A + participant B as Actor B + participant C as System/KIT + + A->>C: Action 1 + C->>B: Action 2 + B->>C: Action 3 + C->>A: Result +``` + +**Process Description**: [Brief description of key steps] + + +### Access & Usage Policies + +:::warning Industry-Specific Policies +For industry-specific policy requirements, refer to the [Industry Extensions](https://github.com/eclipse-tractusx/eclipse-tractusx.github.io/tree/main/docs-kits/kit-template/industry-extensions) section. +::: + +#### Example Access Policy + +```json +{ + "policy": { + "permission": { + "action": "use", + "constraint": { + "leftOperand": "UsagePurpose", + "operator": "isAnyOf", + "rightOperand": [ + "mx.core.digitalTwinRegistry:1" + ] + } + } + } +} +``` + +[Brief policy explanation] + +--- + +## Semantic Models + +[Brief explanation of semantic models used in this KIT] + +### Core Semantic Models + +| Model Name | Version | Purpose | Link | +|------------|---------|---------|------| +| [Model 1] | X.Y.Z | [Model purpose] | [Link] | +| [Model 2] | X.Y.Z | [Model purpose] | [Link] | + +### Model Example: [Model Name] + +**Description**: [Brief description] + +**Key Attributes**: [List key attributes] + +**Example**: + +```json +{ + "attribute1": "example-value", + "attribute2": 12345 +} +``` + +--- + +## Standards + +:::warning Industry-Specific Standards +For industry-specific standards, refer to the [Industry Extensions](https://github.com/eclipse-tractusx/eclipse-tractusx.github.io/tree/main/docs-kits/kit-template/industry-extensions) section. +::: + +### Supported Standards + +| Standard | Version | Description | Compliance Level | Link | +|----------|---------|-------------|------------------|------| +| [Standard 1] | X.Y | [Description] | Mandatory/Optional | [Link] | +| [Standard 2] | X.Y | [Description] | Mandatory/Optional | [Link] | + +--- + +## Tutorials & Resources + +### Getting Started Tutorial + +[Link to tutorial or brief description] + +### Video Resources + +| Title | Duration | Link | +|-------|----------|------| +| [Video 1] | [X min] | [Link] | + +### Whitepaper + +- *Link to Factory-X Engineering Whitepaper as soon as it is available* + ## Notice @@ -122,4 +369,6 @@ This work is licensed under the [CC-BY-4.0](https://creativecommons.org/licenses - SPDX-FileCopyrightText: 2025 Schaeffler AG - SPDX-FileCopyrightText: 2025 Mercedes Benz Group AG - SPDX-FileCopyrightText: 2025 ZF Friedrichshafen AG +- SPDX-FileCopyrightText: 2026 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. für ihre Institute IPK - SPDX-FileCopyrightText: 2025 Contributors to the Eclipse Foundation +- Source URL: https://github.com/eclipse-tractusx/eclipse-tractusx.github.io diff --git a/docs-kits/kits/requirements-kit/development-view/architecture.md b/docs-kits/kits/requirements-kit/development-view/architecture.md new file mode 100644 index 000000000000..ff751e84fc5f --- /dev/null +++ b/docs-kits/kits/requirements-kit/development-view/architecture.md @@ -0,0 +1,85 @@ +--- +id: architecture-overview +title: Architecture Overview +sidebar_position: 2 +--- + + + + + +import Kit3DLogo from '@site/src/components/2.0/Kit3DLogo'; + + + + + +## Architecture View + +## Architecture Overview + +### System Architecture + +[High-level architecture diagram and explanation] + +```mermaid +graph TB + subgraph External Systems + A[Client Application] + B[External Service] + end + + subgraph KIT Components + C[API Gateway] + D[Core Service] + E[Data Layer] + end + + subgraph Infrastructure + F[Database] + G[Message Queue] + end + + A -->|HTTPS| C + B -->|Protocol| C + C --> D + D --> E + E --> F + D --> G +``` + +### Architecture Principles + +1. **Modularity**: Loosely coupled components +2. **Scalability**: Horizontal scaling support +3. **Security**: End-to-end encryption +4. **Interoperability**: Standards-based APIs +5. **Observability**: Built-in monitoring and logging + +## NOTICE + +This work is licensed under the [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). + +- SPDX-License-Identifier: CC-BY-4.0 +- SPDX-FileCopyrightText: [YYYY] [YOUR_COMPANY] +- SPDX-FileCopyrightText: [YYYY] Contributors to the Eclipse Foundation +- Source URL: [https://github.com/eclipse-tractusx/eclipse-tractusx.github.io](https://github.com/eclipse-tractusx/eclipse-tractusx.github.io) \ No newline at end of file diff --git a/docs-kits/kits/requirements-kit/development-view/development-view.md b/docs-kits/kits/requirements-kit/development-view/development-view.md new file mode 100644 index 000000000000..e042bda1e23a --- /dev/null +++ b/docs-kits/kits/requirements-kit/development-view/development-view.md @@ -0,0 +1,676 @@ +--- +id: development-view +title: Development View +sidebar_position: 1 +--- + + + + + +import Kit3DLogo from '@site/src/components/2.0/Kit3DLogo'; + + + + + +Technical documentation for developers, architects, and implementers. + +:::info Target Audience +Software Developers, Solution Architects, Technical Leads, API Developers, Integration Engineers. +::: + +--- + +### More Guides + +- - [Architecture Overview](architecture.md) + +### Component Diagram + +The flowchart illustrates the interactions between four main components in the system: + +### Core Components + +#### Component 1: Requirement System + +**Purpose**: Core component responsible for requirement management + +**Technology Stack**: [Programming language, framework, key dependencies] + +**Interfaces**: [Input, output, protocols] + +#### Component 2: Eclipse Dataspace Connector (EDC) + +**Purpose**: Facilitates data exchange between partners + +**Technology Stack**: [Programming language, framework, key dependencies] + +**Interfaces**: [Input, output, protocols] + +#### Component 3: Requirement System + +**Purpose**: Stores and manages digital twin information + +**Technology Stack**: [Programming language, framework, key dependencies] + +**Interfaces**: [Input, output, protocols] + +#### Component 4: Requirement System + +**Purpose**: Handles submodel data and operations + +**Technology Stack**: [Programming language, framework, key dependencies] + +**Interfaces**: [Input, output, protocols] + + +--- + +## Sequence Diagrams + +### Authentication Flow + +```mermaid +sequenceDiagram + participant Client + participant APIGateway + participant AuthService + participant CoreService + + Client->>APIGateway: Request with credentials + APIGateway->>AuthService: Validate credentials + AuthService-->>APIGateway: Auth token + APIGateway-->>Client: Token response + Client->>APIGateway: API Request + Token + APIGateway->>CoreService: Forward request + CoreService-->>APIGateway: Response + APIGateway-->>Client: Final response +``` + +[Brief flow description] + +### Data Exchange Flow + +```mermaid +sequenceDiagram + participant Provider + participant Connector + participant Consumer + participant Storage + + Provider->>Connector: Offer data asset + Connector->>Connector: Register asset + Consumer->>Connector: Query available assets + Connector-->>Consumer: Asset catalog + Consumer->>Connector: Request data transfer + Connector->>Provider: Initiate transfer + Provider-->>Storage: Push data + Storage-->>Consumer: Deliver data +``` + +[Brief flow description] + +--- + +## API Specifications + +### API Overview + +[List of main APIs with purpose] + +### Base URL + +``` +https://api.example.com/v1 +``` + +### Authentication + +[Authentication method: OAuth 2.0 | API Keys | JWT] + +```http +Authorization: Bearer +``` + +### API Endpoints + +#### GET /resources + +**Description**: Retrieve resources + +**Request**: + +```http +GET /v1/resources HTTP/1.1 +Host: api.example.com +Authorization: Bearer +``` + +**Response** (200 OK): + +```json +{ + "resources": [ + { + "id": "resource-1", + "name": "Example Resource", + "type": "data-asset" + } + ] +} +``` + +#### POST /resources + +**Description**: Create a resource + +**Request**: + +```http +POST /v1/resources HTTP/1.1 +Host: api.example.com +Authorization: Bearer +Content-Type: application/json + +{ + "name": "New Resource", + "type": "data-asset" +} +``` + +**Response** (201 Created): + +```json +{ + "id": "resource-123", + "name": "New Resource", + "type": "data-asset" +} +``` + +### OpenAPI Specification + +[Link to OpenAPI specification and Swagger UI] + +--- + +## Standards Compliance + +| Standard | Version | Compliance | Description | +|----------|---------|------------|-------------| +| CX-0154 | 1.0.1 | Optional | Standard describing how to handle Master Data in Engineering. This includes parameters of | +| CX-0155 | 1.0.1 | Mandatory | Describes the required data models and API usage for the | + +### Standard Details + +#### Requirements Engineering v.1.0.1 + +**Compliance Level**: [Mandatory | Optional | Recommended] + +**Implementation**: [Brief description] + +**Reference**: [CX-0155 Requirements Engineering ](https://catenax-ev.github.io/docs/next/standards/CX-0155-RequirementsEngineering) + +#### Requirements Engineering v.1.0.1 + +**Compliance Level**: [Mandatory | Optional | Recommended] + +**Implementation**: [Brief description] + +**Reference**: [CX-0155 Requirements Engineering ](https://catenax-ev.github.io/docs/next/standards/CX-0155-RequirementsEngineering) + + +--- + +## Logic & Schema + +### Business Logic + +[Core business logic description] + +#### Logic Flow: [Process Name] + +**Input**: [Required data] + +**Processing Steps**: [Brief description of steps] + +**Output**: [Produced data] + +### Data Schema + +#### Schema: [Schema Name] + +**Purpose**: [Schema description] + +```json +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "type": "object", + "properties": { + "id": { + "type": "string", + "description": "Unique identifier" + }, + "name": { + "type": "string", + "description": "Resource name" + } + }, + "required": ["id", "name"] +} +``` + +**Example**: + +```json +{ + "id": "res-001", + "name": "Example Resource" +} +``` + +--- + +## Semantic Models + +### Model: [Model Name] + +**Version**: X.Y.Z + +**Namespace**: `urn:samm:org.eclipse.tractusx.[domain]:[version]#` + +**Description**: [Model description] + +**Key Properties**: + +| Property | Type | Required | Description | +|----------|------|----------|-------------| +| `property1` | string | Yes | [Description] | +| `property2` | integer | No | [Description] | + +**Example**: + +```json +{ + "@context": { + "@vocab": "urn:samm:org.eclipse.tractusx.[domain]:[version]#" + }, + "property1": "value1", + "property2": 42 +} +``` + +**Reference**: [Link to SAMM specification] + +--- + +## Test Cases + +### Test Strategy + +- **Unit Tests**: Component-level testing +- **Integration Tests**: API integration testing +- **End-to-End Tests**: Complete workflow testing + +### Test Case: [Test Name] + +**Objective**: [Test validation purpose] + +**Preconditions**: [Required setup] + +**Test Steps**: [Brief description] + +**Expected Outcome**: [Expected result] + +--- + +## Sample Data + +### Sample Dataset: [Dataset Name] + +**Purpose**: [Sample purpose] + +**Format**: JSON + +**Download**: [Link] + +**Example**: + +```json +{ + "sampleData": [ + { + "id": "sample-001", + "field1": "value1" + } + ] +} +``` + +--- + +## Developer Tutorials + +### Quick Start + +**Prerequisites**: [List prerequisites] + +**Steps**: + +1. Clone repository: + +```bash +git clone https://github.com/eclipse-tractusx/[repository-name].git +``` + +2. Configure `application.properties`: + +```properties +server.port=8080 +api.base-url=https://api.example.com +``` + +3. Build and run: + +```bash +mvn clean install +mvn spring-boot:run +``` + +4. Verify: + +```bash +curl http://localhost:8080/health +``` + +--- + +## Integration Examples + +### Integration with [System Name] + +**Java Example**: + +```java +public class KitIntegration { + private final KitClient client; + + public KitIntegration(String apiUrl, String apiKey) { + this.client = new KitClient(apiUrl, apiKey); + } + + public Resource getResource(String resourceId) { + return client.resources().get(resourceId); + } +} +``` + +**Python Example**: + +```python +from kit_sdk import KitClient + +client = KitClient(api_url="https://api.example.com", api_key="your-key") +resource = client.resources.get("resource-id") +``` + +--- + +## Additional Resources + +### Reference Implementations + +- [Implementation 1]: [Link] +- [Implementation 2]: [Link] + +### SDKs and Libraries + +| Language | SDK | Link | +|----------|-----|------| +| Java | [SDK Name] | [Link] | +| Python | [SDK Name] | [Link] | + +### Developer Tools + +- [Postman Collection](https://github.com/eclipse-tractusx/eclipse-tractusx.github.io/tree/main/docs-kits/kit-template/resources/postman-collection.json) +- [OpenAPI Generator](https://openapi-generator.tech/) + +--- + +#### Interactions + +The system architecture demonstrates how components interact to facilitate requirement exchange: + +- **Requirement System Operations** + - Registers Digital Twins and Submodel Descriptors in the Digital Twin Registry + - Provides Requirement Submodels to the Submodel Service + - Uses the Eclipse Dataspace Connector to request requirements and send notifications +- **Eclipse Dataspace Connector (EDC)** + - Handles notifications sent from partners back to the Requirement System + - Acts as the communication bridge between partners +- **Digital Twin Registry** + - Provides Digital Twins to the Eclipse Dataspace Connector +- **Submodel Service** + - Provides Submodels to the Eclipse Dataspace Connector + +```mermaid +flowchart LR + +reqSysC[Requirement System] +dtrC[Digital Twin Registry] +submodelC[Submodel Service] +edcC[Eclipse Dataspace Connector] + +reqSysC -- Register Digital Twins and Submodel Descriptors --> dtrC +reqSysC -- Provide Requirement Submodels --> submodelC +reqSysC -- Use EDC to Request Requirements and send notifications --> edcC +edcC -- Handle Notifications sent from partner --> reqSysC +dtrC -- Provide Digital Twins --> edcC +submodelC -- Provide Submodels --> edcC + +``` + +### Requirement Exchange Sequence + +The sequence diagram illustrates the requirement exchange flow between a Customer (e.g., an OEM) and a Supplier: + +1. **Initial Requirement Creation**: + + - Customer creates a requirement in their requirements system and registers it in their DTR and creates a submodel. + - Customer's system sends a notification through the EDC to the Supplier + +2. **Requirement Request**: + + - Supplier's system requests the requirement details through the EDC + - The requirement is transferred from Customer's DTR to Supplier's DTR and submodel service + +3. **Requirement Update**: + + - After processing, Supplier updates the requirement in their requirements system + - Supplier sends a notification about the update through the EDC back to the Customer + - Customer is notified about the requirement update + +4. **Next interactions**: + +- The process can be repeated for further updates or new requirements in an interactive manner between the Customer and Supplier. + +The diagram shows the core components involved in this exchange: + +- Requirement Systems (on both Customer and Supplier sides) +- Digital Twin Registry (DTR) & Submodel Services +- Eclipse Dataspace Connector (EDC) for secure data exchange +- Solid lines indicate dataflow +- Dashed lines indicate initialization of a request + +```mermaid + +sequenceDiagram + participant oemReqSys as Requirement System Customer + participant oemDtr as DTR & Submodel Service Customer + participant oemEDC as EDC Customer + + participant supEDC as EDC Supplier + participant supDtr as DTR & Submodel Service Supplier + participant supReqSys as Requirement System Supplier + + oemReqSys->>oemDtr: Requirement (DTR + Submodel) + oemReqSys->>oemEDC: Notification + oemEDC->>supEDC: Notification + supEDC->>supReqSys: Notification + supReqSys-->>supEDC: Request Requirement + + + supEDC-->>oemEDC: Request Requirement + oemEDC-->>oemDtr: Request Requirement + + oemDtr->>oemEDC: Requirement + + oemEDC->>supEDC: Requirement + supEDC->>supDtr: Requirement (DTR + Submodel) + + supDtr->>supReqSys: Requirement + + supReqSys->>supDtr: Update Requirement + supReqSys->>supEDC: Notification (updated Requirement) + supEDC->>oemEDC: Notification (updated Requirement) + oemEDC->>oemReqSys: Notification (updated Requirement) + + +``` + +## Requirements Aspect Model + +The following section gives an overview of the requirements aspect model. The requirements aspect model is a submodel that contains the requirements information and the status of the requirement. + +| Digital Twin Type | Aspect Model | Mandatory Version | Optional Versions | KIT | Standard | +| :-- | :-- | :-- | :-- | :-- | :-- | +| PartType | Requirements | 1.0.0 | | Requirements | CX-0155 | + +### Example of a Requirements Aspect Model + +```json +{ + "requirementRelations": [ + { + "relatedRequirementId": "urn:uuid:e6b31BC2-8102-64AF-034D-C2DC35E37cEE", + "requiremementRelationshipType": "RequirementSpecialismOfRequirement" + } + ], + "requirementId": "urn:uuid:48878d48-6f1d-47f5-8ded-a441d0d879df", + "requirementInformation": { + "foreignId": "3.1.1", + "longname": "Plastic deformation of the bogie", + "versionPredecessor": { + "versionPredecessorNumber": "1.4.5", + "versionPredecessorId": "AeEf3f22-Af51-EDF0-29D2-Ba086b386A5E" + }, + "creationdate": "2025-06-05T09:35:16.166+02:00", + "metadata": [ + { + "value": "2025-11-30T00:00:00.000+02:00", + "metadataDescription": "Timestamp of the expected finalization of the requirement", + "key": "ExpectedFinalization" + } + ], + "author": "Lisa Dräxlmaier GmbH", + "reqifType": "Functional", + "reqifName": "Plastic deformation of the bogie", + "description": "eOMtThyhVNLWUZNRcBaQKxI", + "specification": [ + "https://www.prostep.org/fileadmin/prod-pay-download-8c1d/Recommendation_ReqIF_V2.2.pdf" + ], + "version": { + "versionNumber": "2.0.0", + "versionId": "B50C5243-9590-Eaa5-dA9e-Adb383e2cFf6" + } + }, + "requirementStatus": { + "customerStatus": [ + { + "customerStatusComment": "Requirement needs to be evaluated", + "customerStatusValue": "", + "customerStatusTimestamp": "2025-06-05T09:35:16.166+02:00" + } + ], + "supplierStatus": [ + { + "supplierStatusTimestamp": "2025-06-05T09:35:16.166+02:00", + "supplierStatusValue": "", + "supplierStatusComment": "More information needed from customer" + } + ], + "statusValue": "transition status", + "statusTimestamp": "2025-06-05T09:35:16.166+02:00" + } +} + +``` + +## Notification Format + +The notification format used for the requirements exchange is based on the [Industry Core Kit's standardized notification format](../industry-core-kit/software-development-view/notifications). The following example illustrates a notification sent from a Customer to a Supplier when a new requirement is created: + +```json +{ + "header": { + "messageId": "urn:uuid:48878d48-6f1d-47f5-8ded-a441d0d879df", + "context": "Requirements-DigitalTwinEventAPI-[Create|Update|Delete]:1.0.0", + "sentDateTime": "2024-07-05T08:13:33.20733Z", + "senderBpn": "BPNL000000000AAA", + "receiverBpn": "BPNL000000000ZZZ", + "expectedResponseBy": "2024-07-08T08:13:33.20733Z", + "version": "3.0.0" + }, + "content": { + "requirementId": "UfzQhdgLLfDTDGspDb", + "description": "New requirement created for part type.", + } +} +``` + +- ```requirementId```: ```requirementId``` in requirements datamodel + + + +Base idea of notifications: Only technical information about creation/change/deletion of requirement. Descriptive information about changes and comments are stored directly within the requirement submodels. + +## EDC Setup + +In order to set up the EDC for the requirements use-case, the following steps are necessary: + +- [Setup for the DTR](../digital-twin-kit/software-development-view/) in order to provide access to the Digital Twins for the partners +- [Notifications](../industry-core-kit/software-development-view/notifications) to inform the partners about new requirements or updates. In the requirements use-case the standardized notifications from the Industry Core Kit are used. + +## Notice + +This work is licensed under the [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). + +- SPDX-License-Identifier: CC-BY-4.0 +- SPDX-FileCopyrightText: 2025 Dräxlmaier GmbH & Co. KG +- SPDX-FileCopyrightText: 2025 Schaeffler AG +- SPDX-FileCopyrightText: 2025 Mercedes Benz Group AG +- SPDX-FileCopyrightText: 2025 ZF Friedrichshafen AG +- SPDX-FileCopyrightText: 2025 Contributors to the Eclipse Foundation diff --git a/docs-kits/kits/requirements-kit/industry-extensions/_category_.json b/docs-kits/kits/requirements-kit/industry-extensions/_category_.json new file mode 100644 index 000000000000..4b2d000919e7 --- /dev/null +++ b/docs-kits/kits/requirements-kit/industry-extensions/_category_.json @@ -0,0 +1,8 @@ +{ + "label": "Industry Extensions", + "position": 7, + "link": { + "type": "generated-index", + "description": "Industry-specific extensions and standards compliance documentation for this KIT." + } +} \ No newline at end of file diff --git a/docs-kits/kits/requirements-kit/industry-extensions/automotive/Overview.md b/docs-kits/kits/requirements-kit/industry-extensions/automotive/Overview.md new file mode 100644 index 000000000000..a5b12f2acd47 --- /dev/null +++ b/docs-kits/kits/requirements-kit/industry-extensions/automotive/Overview.md @@ -0,0 +1,199 @@ +--- +id: automotive-extension +title: Automotive Industry Extension +sidebar_position: 1 +--- + + + + + +import Kit3DLogo from '@site/src/components/2.0/Kit3DLogo'; + + + + + +## Automotive Industry Extension + +This extension adapts the **[KIT_NAME] KIT** for the automotive industry with Catena-X standards compliance. + +:::info Extension Purpose +Adds: Catena-X standards, automotive semantic models, business processes, and policies. +::: + +--- + +## Catena-X Standards + +| Standard | Version | Description | Compliance | +|----------|---------|-------------|------------| +| CX-0001 | 2.0.0 | EDC Discovery API | Mandatory | +| CX-0002 | 2.0.0 | Digital Twins | Mandatory | +| CX-0018 | 3.0.0 | Dataspace Connectivity | Mandatory | + +[Link to Catena-X Standard Library](https://catena-x.net/en/standard-library) + +--- + +## Semantic Models + +### Serial Part (CX-0002) + +**Version**: 3.0.0 + +**Aspect Model**: `urn:samm:io.catenax.serial_part:3.0.0#SerialPart` + +**Key Attributes**: `catenaXId`, `localIdentifiers`, `manufacturingInformation`, `partTypeInformation` + +**Example**: + +```json +{ + "catenaXId": "urn:uuid:ed2ace5b-b25d-4e64-9b54-c2fb13c35a5c", + "localIdentifiers": [ + { + "key": "manufacturerPartId", + "value": "95657362-83" + } + ], + "manufacturingInformation": { + "date": "2023-02-04T14:48:54", + "country": "DEU" + }, + "partTypeInformation": { + "manufacturerPartId": "95657362-83", + "nameAtManufacturer": "High Voltage Battery" + } +} +``` + +[Semantic Hub](https://semantics.catena-x.net/) + +--- + +## Business Processes + +### Supply Chain Traceability + +**Purpose**: End-to-end traceability of automotive parts + +**Actors**: OEM, Tier-1/Tier-N Suppliers, Traceability Service Provider + +**Process Flow**: + +```mermaid +sequenceDiagram + participant OEM + participant Tier1 as Tier-1 Supplier + participant TraceSvc as Traceability Service + participant EDC + + OEM->>TraceSvc: Request part trace + TraceSvc->>EDC: Query digital twins + EDC->>Tier1: Request part data + Tier1-->>EDC: Provide relationships + EDC-->>TraceSvc: Return data + TraceSvc-->>OEM: Display chain +``` + +--- + +## Access & Usage Policies + +### Catena-X Framework Policy + +```json +{ + "@context": {"odrl": "http://www.w3.org/ns/odrl/2/"}, + "@type": "PolicyDefinitionRequestDto", + "@id": "cx-policy", + "policy": { + "@type": "Policy", + "odrl:permission": [{ + "odrl:action": "USE", + "odrl:constraint": { + "odrl:leftOperand": "BusinessPartnerNumber", + "odrl:operator": {"@id": "odrl:eq"}, + "odrl:rightOperand": "BPNL00000003CRHK" + } + }] + } +} +``` + +--- + +## Use Cases + +### Quality Alert Distribution + +**Description**: Rapidly distribute quality alerts across supply chain + +**Actors**: Alert Issuer, Supply Chain Partners, Catena-X Services + +**Process**: Issue detection → Alert creation → Digital twin query → Distribution → Acknowledgment + +**Benefits**: Faster response, reduced costs, improved safety + +--- + +## Compliance + +| Regulation | Region | Relevance | +|------------|--------|----------| +| GDPR | EU | Data protection | +| Battery Regulation | EU | Battery passport | +| Supply Chain Due Diligence | DE | ESG reporting | + +**Certifications**: ISO/TS 16949, VDA 6.3, TISAX + +--- + +## Getting Started + +1. Review [Core KIT Adoption View](../../adoption-view/adoption-view.md) +2. Study [Catena-X Standards](https://catena-x.net/en/standard-library) +3. Implement semantic models from [Semantic Hub](https://semantics.catena-x.net/) + +--- + +## Resources + +- [Catena-X Standard Library](https://catena-x.net/en/standard-library) +- [Tractus-X Open Source](https://eclipse-tractusx.github.io/) + +## NOTICE + +This work is licensed under the [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). + +- SPDX-License-Identifier: CC-BY-4.0 +- SPDX-FileCopyrightText: [YYYY] [YOUR_COMPANY] +- SPDX-FileCopyrightText: [YYYY] Contributors to the Eclipse Foundation +- Source URL: [https://github.com/eclipse-tractusx/eclipse-tractusx.github.io](https://github.com/eclipse-tractusx/eclipse-tractusx.github.io) diff --git a/docs-kits/kits/requirements-kit/resources/img/REUSE.toml b/docs-kits/kits/requirements-kit/resources/img/REUSE.toml new file mode 100644 index 000000000000..35d592fcfc24 --- /dev/null +++ b/docs-kits/kits/requirements-kit/resources/img/REUSE.toml @@ -0,0 +1,8 @@ +version = 1 + +[[annotations]] +path = ["*.svg", "*.jpg", "*.png"] +precedence = "closest" +SPDX-FileCopyrightText = "[XXXX] [YOUR COMPANY]" +SPDX-FileCopyrightText = "[XXXX] Contributors of the Eclipse Foundation" +SPDX-License-Identifier = "CC-BY-4.0" \ No newline at end of file diff --git a/docs-kits/kits/requirements-kit/resources/requirements_customer-journey.png b/docs-kits/kits/requirements-kit/resources/img/requirements_customer-journey.png similarity index 100% rename from docs-kits/kits/requirements-kit/resources/requirements_customer-journey.png rename to docs-kits/kits/requirements-kit/resources/img/requirements_customer-journey.png diff --git a/docs-kits/kits/requirements-kit/resources/requirements_customer-journey.png.license b/docs-kits/kits/requirements-kit/resources/img/requirements_customer-journey.png.license similarity index 100% rename from docs-kits/kits/requirements-kit/resources/requirements_customer-journey.png.license rename to docs-kits/kits/requirements-kit/resources/img/requirements_customer-journey.png.license diff --git a/docs-kits/kits/requirements-kit/software-development-view.md b/docs-kits/kits/requirements-kit/software-development-view.md deleted file mode 100644 index 8323d8866af8..000000000000 --- a/docs-kits/kits/requirements-kit/software-development-view.md +++ /dev/null @@ -1,245 +0,0 @@ ---- -id: software-development-view -title: Software Development View -description: 'Software Development View Requirements Kit' -sidebar_position: 4 ---- - -import Kit3DLogo from '@site/src/components/2.0/Kit3DLogo'; - - - -## Architecture - -### Component Diagram - -The flowchart illustrates the interactions between four main components in the system: - -#### Components - -The following components are necessary for the requirements exchange: - -- Company Specific Components: - - **Requirement System**: Core component responsible for requirement management -- Catena-X specific components: - - **Eclipse Dataspace Connector (EDC)**: Facilitates data exchange between partners - - **Digital Twin Registry**: Stores and manages digital twin information - - **Submodel Service**: Handles submodel data and operations - -#### Interactions - -The system architecture demonstrates how components interact to facilitate requirement exchange: - -- **Requirement System Operations** - - Registers Digital Twins and Submodel Descriptors in the Digital Twin Registry - - Provides Requirement Submodels to the Submodel Service - - Uses the Eclipse Dataspace Connector to request requirements and send notifications -- **Eclipse Dataspace Connector (EDC)** - - Handles notifications sent from partners back to the Requirement System - - Acts as the communication bridge between partners -- **Digital Twin Registry** - - Provides Digital Twins to the Eclipse Dataspace Connector -- **Submodel Service** - - Provides Submodels to the Eclipse Dataspace Connector - -```mermaid -flowchart LR - -reqSysC[Requirement System] -dtrC[Digital Twin Registry] -submodelC[Submodel Service] -edcC[Eclipse Dataspace Connector] - -reqSysC -- Register Digital Twins and Submodel Descriptors --> dtrC -reqSysC -- Provide Requirement Submodels --> submodelC -reqSysC -- Use EDC to Request Requirements and send notifications --> edcC -edcC -- Handle Notifications sent from partner --> reqSysC -dtrC -- Provide Digital Twins --> edcC -submodelC -- Provide Submodels --> edcC - -``` - -### Requirement Exchange Sequence - -The sequence diagram illustrates the requirement exchange flow between a Customer (e.g., an OEM) and a Supplier: - -1. **Initial Requirement Creation**: - - - Customer creates a requirement in their requirements system and registers it in their DTR and creates a submodel. - - Customer's system sends a notification through the EDC to the Supplier - -2. **Requirement Request**: - - - Supplier's system requests the requirement details through the EDC - - The requirement is transferred from Customer's DTR to Supplier's DTR and submodel service - -3. **Requirement Update**: - - - After processing, Supplier updates the requirement in their requirements system - - Supplier sends a notification about the update through the EDC back to the Customer - - Customer is notified about the requirement update - -4. **Next interactions**: - -- The process can be repeated for further updates or new requirements in an interactive manner between the Customer and Supplier. - -The diagram shows the core components involved in this exchange: - -- Requirement Systems (on both Customer and Supplier sides) -- Digital Twin Registry (DTR) & Submodel Services -- Eclipse Dataspace Connector (EDC) for secure data exchange -- Solid lines indicate dataflow -- Dashed lines indicate initialization of a request - -```mermaid - -sequenceDiagram - participant oemReqSys as Requirement System Customer - participant oemDtr as DTR & Submodel Service Customer - participant oemEDC as EDC Customer - - participant supEDC as EDC Supplier - participant supDtr as DTR & Submodel Service Supplier - participant supReqSys as Requirement System Supplier - - oemReqSys->>oemDtr: Requirement (DTR + Submodel) - oemReqSys->>oemEDC: Notification - oemEDC->>supEDC: Notification - supEDC->>supReqSys: Notification - supReqSys-->>supEDC: Request Requirement - - - supEDC-->>oemEDC: Request Requirement - oemEDC-->>oemDtr: Request Requirement - - oemDtr->>oemEDC: Requirement - - oemEDC->>supEDC: Requirement - supEDC->>supDtr: Requirement (DTR + Submodel) - - supDtr->>supReqSys: Requirement - - supReqSys->>supDtr: Update Requirement - supReqSys->>supEDC: Notification (updated Requirement) - supEDC->>oemEDC: Notification (updated Requirement) - oemEDC->>oemReqSys: Notification (updated Requirement) - - -``` - -## Requirements Aspect Model - -The following section gives an overview of the requirements aspect model. The requirements aspect model is a submodel that contains the requirements information and the status of the requirement. - -| Digital Twin Type | Aspect Model | Mandatory Version | Optional Versions | KIT | Standard | -| :-- | :-- | :-- | :-- | :-- | :-- | -| PartType | Requirements | 1.0.0 | | Requirements | CX-0155 | - -### Example of a Requirements Aspect Model - -```json -{ - "requirementRelations": [ - { - "relatedRequirementId": "urn:uuid:e6b31BC2-8102-64AF-034D-C2DC35E37cEE", - "requiremementRelationshipType": "RequirementSpecialismOfRequirement" - } - ], - "requirementId": "urn:uuid:48878d48-6f1d-47f5-8ded-a441d0d879df", - "requirementInformation": { - "foreignId": "3.1.1", - "longname": "Plastic deformation of the bogie", - "versionPredecessor": { - "versionPredecessorNumber": "1.4.5", - "versionPredecessorId": "AeEf3f22-Af51-EDF0-29D2-Ba086b386A5E" - }, - "creationdate": "2025-06-05T09:35:16.166+02:00", - "metadata": [ - { - "value": "2025-11-30T00:00:00.000+02:00", - "metadataDescription": "Timestamp of the expected finalization of the requirement", - "key": "ExpectedFinalization" - } - ], - "author": "Lisa Dräxlmaier GmbH", - "reqifType": "Functional", - "reqifName": "Plastic deformation of the bogie", - "description": "eOMtThyhVNLWUZNRcBaQKxI", - "specification": [ - "https://www.prostep.org/fileadmin/prod-pay-download-8c1d/Recommendation_ReqIF_V2.2.pdf" - ], - "version": { - "versionNumber": "2.0.0", - "versionId": "B50C5243-9590-Eaa5-dA9e-Adb383e2cFf6" - } - }, - "requirementStatus": { - "customerStatus": [ - { - "customerStatusComment": "Requirement needs to be evaluated", - "customerStatusValue": "", - "customerStatusTimestamp": "2025-06-05T09:35:16.166+02:00" - } - ], - "supplierStatus": [ - { - "supplierStatusTimestamp": "2025-06-05T09:35:16.166+02:00", - "supplierStatusValue": "", - "supplierStatusComment": "More information needed from customer" - } - ], - "statusValue": "transition status", - "statusTimestamp": "2025-06-05T09:35:16.166+02:00" - } -} - -``` - -## Notification Format - -The notification format used for the requirements exchange is based on the [Industry Core Kit's standardized notification format](../industry-core-kit/software-development-view/notifications). The following example illustrates a notification sent from a Customer to a Supplier when a new requirement is created: - -```json -{ - "header": { - "messageId": "urn:uuid:48878d48-6f1d-47f5-8ded-a441d0d879df", - "context": "Requirements-DigitalTwinEventAPI-[Create|Update|Delete]:1.0.0", - "sentDateTime": "2024-07-05T08:13:33.20733Z", - "senderBpn": "BPNL000000000AAA", - "receiverBpn": "BPNL000000000ZZZ", - "expectedResponseBy": "2024-07-08T08:13:33.20733Z", - "version": "3.0.0" - }, - "content": { - "requirementId": "UfzQhdgLLfDTDGspDb", - "description": "New requirement created for part type.", - } -} -``` - -- ```requirementId```: ```requirementId``` in requirements datamodel - - - -Base idea of notifications: Only technical information about creation/change/deletion of requirement. Descriptive information about changes and comments are stored directly within the requirement submodels. - -## EDC Setup - -In order to set up the EDC for the requirements use-case, the following steps are necessary: - -- [Setup for the DTR](../digital-twin-kit/software-development-view/) in order to provide access to the Digital Twins for the partners -- [Notifications](../industry-core-kit/software-development-view/notifications) to inform the partners about new requirements or updates. In the requirements use-case the standardized notifications from the Industry Core Kit are used. - -## Notice - -This work is licensed under the [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). - -- SPDX-License-Identifier: CC-BY-4.0 -- SPDX-FileCopyrightText: 2025 Dräxlmaier GmbH & Co. KG -- SPDX-FileCopyrightText: 2025 Schaeffler AG -- SPDX-FileCopyrightText: 2025 Mercedes Benz Group AG -- SPDX-FileCopyrightText: 2025 ZF Friedrichshafen AG -- SPDX-FileCopyrightText: 2025 Contributors to the Eclipse Foundation From 153e9fa774d5ce7dffb2d5c08957a2ca52f8e758 Mon Sep 17 00:00:00 2001 From: "Marvin Manoury (Fraunhofer IPK)" Date: Tue, 26 May 2026 16:42:03 +0200 Subject: [PATCH 02/10] fix: linting requirements KIT --- .../adoption-view/adoption-view.md | 31 +-- .../development-view/architecture.md | 2 +- .../development-view/development-view.md | 226 +----------------- 3 files changed, 7 insertions(+), 252 deletions(-) diff --git a/docs-kits/kits/requirements-kit/adoption-view/adoption-view.md b/docs-kits/kits/requirements-kit/adoption-view/adoption-view.md index 4e705e5a940b..ca6f33bea3f5 100644 --- a/docs-kits/kits/requirements-kit/adoption-view/adoption-view.md +++ b/docs-kits/kits/requirements-kit/adoption-view/adoption-view.md @@ -64,10 +64,9 @@ This vision opens the way for innovative and collaborative product development b ### Mission :::note Mission Statement -The KIT shall describe usable data models and approaches to aggregate and align Requirements in a data ecosystem. +The KIT shall describe usable data models and approaches to aggregate and align Requirements in a data ecosystem. ::: - The Requirements Kit aims to meticulously outline requirements by incorporating essential standards, aspect models and business logics. Its approach is designed to facilitate the exchange of requirements information between OEMs and Tier-N suppliers, ensuring that all relevant data is gathered and enabling authorized stakeholders to collaborate effectively. The data exchange process adheres to the Catena-X network's principles of data sovereignty, ensuring secure and compliant interactions. By following a standardized pipeline and utilizing data models within a data ecosystem, each partner is empowered to use their preferred applications, fostering a flexible and efficient collaboration environment. --- @@ -143,7 +142,6 @@ Catena-X offers solution providers a variety of strategic advantages to leverage 9. Access to data and analysis: With access to valuable industrial data, solution providers can develop and enhance their analytics and optimization solutions to boost operational efficiency and decision-making processes for customers. 10. Accelerated digital transformation: Catena-X allows solution providers to position their transformation strategies directly within the context of the automotive industry, a sector that is continually moving towards digital technologies. - | Stakeholder Type | Key Benefits | Time to Value | |------------------|--------------|---------------| | **OEMs** | [List 2-3 benefits for large enterprises] | [e.g., "6 months"] | @@ -165,7 +163,6 @@ This involves the circular processing of requests between partners, which can re In addition to the challenges mentioned above, there is also the issue that the files can be designed in a variety of content forms and the formats of the files can also vary. The formats can be divided into structured and unstructured files. Unstructured files are texts, tables etc. that are not organized into individual requirements without prior processing. These increase the effort required to organize the document into individual requirements. This also makes the exchange with the partner more difficult, as the partner does not know the newly created structure. With structured files, the aforementioned circumstances no longer exist, as the requirements are already organized. In the best case, a standardized form, such as the ReqIF format, is used. However, even when using standardized formats such as ReqIF, it is still necessary to agree on a common data model for exporting and importing in advance so that data exchange via the various requirements management tools works as smoothly as possible. - **Current Challenges:** - **Challenge 1**: [Problem description and impact] @@ -221,7 +218,6 @@ For industry-specific business processes, see the [Industry Extensions](https:// ### Core Business Process: [Process Name] - ![Customer Journey](../resources/img/requirements_customer-journey.png) ### Core Business Process: User Journey @@ -248,28 +244,6 @@ flowchart TD E --> G ``` -### Core Business Process: [Process Name] - -**Purpose**: [Business goal] - -**Stakeholders**: [List key stakeholders] - -**Process Steps**: - -```mermaid -sequenceDiagram - participant A as Actor A - participant B as Actor B - participant C as System/KIT - - A->>C: Action 1 - C->>B: Action 2 - B->>C: Action 3 - C->>A: Result -``` - -**Process Description**: [Brief description of key steps] - ### Access & Usage Policies @@ -359,7 +333,6 @@ For industry-specific standards, refer to the [Industry Extensions](https://gith - *Link to Factory-X Engineering Whitepaper as soon as it is available* - ## Notice This work is licensed under the [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). @@ -371,4 +344,4 @@ This work is licensed under the [CC-BY-4.0](https://creativecommons.org/licenses - SPDX-FileCopyrightText: 2025 ZF Friedrichshafen AG - SPDX-FileCopyrightText: 2026 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. für ihre Institute IPK - SPDX-FileCopyrightText: 2025 Contributors to the Eclipse Foundation -- Source URL: https://github.com/eclipse-tractusx/eclipse-tractusx.github.io +- Source URL: [https://github.com/eclipse-tractusx/eclipse-tractusx.github.io](https://github.com/eclipse-tractusx/eclipse-tractusx.github.io) diff --git a/docs-kits/kits/requirements-kit/development-view/architecture.md b/docs-kits/kits/requirements-kit/development-view/architecture.md index ff751e84fc5f..4efccb20c196 100644 --- a/docs-kits/kits/requirements-kit/development-view/architecture.md +++ b/docs-kits/kits/requirements-kit/development-view/architecture.md @@ -82,4 +82,4 @@ This work is licensed under the [CC-BY-4.0](https://creativecommons.org/licenses - SPDX-License-Identifier: CC-BY-4.0 - SPDX-FileCopyrightText: [YYYY] [YOUR_COMPANY] - SPDX-FileCopyrightText: [YYYY] Contributors to the Eclipse Foundation -- Source URL: [https://github.com/eclipse-tractusx/eclipse-tractusx.github.io](https://github.com/eclipse-tractusx/eclipse-tractusx.github.io) \ No newline at end of file +- Source URL: [https://github.com/eclipse-tractusx/eclipse-tractusx.github.io](https://github.com/eclipse-tractusx/eclipse-tractusx.github.io) diff --git a/docs-kits/kits/requirements-kit/development-view/development-view.md b/docs-kits/kits/requirements-kit/development-view/development-view.md index e042bda1e23a..84109a570296 100644 --- a/docs-kits/kits/requirements-kit/development-view/development-view.md +++ b/docs-kits/kits/requirements-kit/development-view/development-view.md @@ -43,7 +43,7 @@ Software Developers, Solution Architects, Technical Leads, API Developers, Integ ### More Guides -- - [Architecture Overview](architecture.md) +- [Architecture Overview](architecture.md) ### Component Diagram @@ -83,135 +83,6 @@ The flowchart illustrates the interactions between four main components in the s **Interfaces**: [Input, output, protocols] - ---- - -## Sequence Diagrams - -### Authentication Flow - -```mermaid -sequenceDiagram - participant Client - participant APIGateway - participant AuthService - participant CoreService - - Client->>APIGateway: Request with credentials - APIGateway->>AuthService: Validate credentials - AuthService-->>APIGateway: Auth token - APIGateway-->>Client: Token response - Client->>APIGateway: API Request + Token - APIGateway->>CoreService: Forward request - CoreService-->>APIGateway: Response - APIGateway-->>Client: Final response -``` - -[Brief flow description] - -### Data Exchange Flow - -```mermaid -sequenceDiagram - participant Provider - participant Connector - participant Consumer - participant Storage - - Provider->>Connector: Offer data asset - Connector->>Connector: Register asset - Consumer->>Connector: Query available assets - Connector-->>Consumer: Asset catalog - Consumer->>Connector: Request data transfer - Connector->>Provider: Initiate transfer - Provider-->>Storage: Push data - Storage-->>Consumer: Deliver data -``` - -[Brief flow description] - ---- - -## API Specifications - -### API Overview - -[List of main APIs with purpose] - -### Base URL - -``` -https://api.example.com/v1 -``` - -### Authentication - -[Authentication method: OAuth 2.0 | API Keys | JWT] - -```http -Authorization: Bearer -``` - -### API Endpoints - -#### GET /resources - -**Description**: Retrieve resources - -**Request**: - -```http -GET /v1/resources HTTP/1.1 -Host: api.example.com -Authorization: Bearer -``` - -**Response** (200 OK): - -```json -{ - "resources": [ - { - "id": "resource-1", - "name": "Example Resource", - "type": "data-asset" - } - ] -} -``` - -#### POST /resources - -**Description**: Create a resource - -**Request**: - -```http -POST /v1/resources HTTP/1.1 -Host: api.example.com -Authorization: Bearer -Content-Type: application/json - -{ - "name": "New Resource", - "type": "data-asset" -} -``` - -**Response** (201 Created): - -```json -{ - "id": "resource-123", - "name": "New Resource", - "type": "data-asset" -} -``` - -### OpenAPI Specification - -[Link to OpenAPI specification and Swagger UI] - --- ## Standards Compliance @@ -229,16 +100,15 @@ Content-Type: application/json **Implementation**: [Brief description] -**Reference**: [CX-0155 Requirements Engineering ](https://catenax-ev.github.io/docs/next/standards/CX-0155-RequirementsEngineering) +**Reference**: [CX-0155 Requirements Engineering](https://catenax-ev.github.io/docs/next/standards/CX-0155-RequirementsEngineering) -#### Requirements Engineering v.1.0.1 +#### Digital Engineering Master Data v1.0.1 **Compliance Level**: [Mandatory | Optional | Recommended] **Implementation**: [Brief description] -**Reference**: [CX-0155 Requirements Engineering ](https://catenax-ev.github.io/docs/next/standards/CX-0155-RequirementsEngineering) - +**Reference**: [CX-0154 Master Data](https://catenax-ev.github.io/docs/standards/CX-0154-MasterDataManagement) --- @@ -369,94 +239,6 @@ Content-Type: application/json --- -## Developer Tutorials - -### Quick Start - -**Prerequisites**: [List prerequisites] - -**Steps**: - -1. Clone repository: - -```bash -git clone https://github.com/eclipse-tractusx/[repository-name].git -``` - -2. Configure `application.properties`: - -```properties -server.port=8080 -api.base-url=https://api.example.com -``` - -3. Build and run: - -```bash -mvn clean install -mvn spring-boot:run -``` - -4. Verify: - -```bash -curl http://localhost:8080/health -``` - ---- - -## Integration Examples - -### Integration with [System Name] - -**Java Example**: - -```java -public class KitIntegration { - private final KitClient client; - - public KitIntegration(String apiUrl, String apiKey) { - this.client = new KitClient(apiUrl, apiKey); - } - - public Resource getResource(String resourceId) { - return client.resources().get(resourceId); - } -} -``` - -**Python Example**: - -```python -from kit_sdk import KitClient - -client = KitClient(api_url="https://api.example.com", api_key="your-key") -resource = client.resources.get("resource-id") -``` - ---- - -## Additional Resources - -### Reference Implementations - -- [Implementation 1]: [Link] -- [Implementation 2]: [Link] - -### SDKs and Libraries - -| Language | SDK | Link | -|----------|-----|------| -| Java | [SDK Name] | [Link] | -| Python | [SDK Name] | [Link] | - -### Developer Tools - -- [Postman Collection](https://github.com/eclipse-tractusx/eclipse-tractusx.github.io/tree/main/docs-kits/kit-template/resources/postman-collection.json) -- [OpenAPI Generator](https://openapi-generator.tech/) - ---- - #### Interactions The system architecture demonstrates how components interact to facilitate requirement exchange: From cb31b903eb9cdd55fae4d21c0018351588f06eb5 Mon Sep 17 00:00:00 2001 From: "Marvin Manoury (Fraunhofer IPK)" Date: Tue, 26 May 2026 22:33:31 +0200 Subject: [PATCH 03/10] fix: removed architecture and resolved broken link --- .../development-view/architecture.md | 85 --- .../development-view/development-view.md | 514 ++++++++---------- 2 files changed, 216 insertions(+), 383 deletions(-) delete mode 100644 docs-kits/kits/requirements-kit/development-view/architecture.md diff --git a/docs-kits/kits/requirements-kit/development-view/architecture.md b/docs-kits/kits/requirements-kit/development-view/architecture.md deleted file mode 100644 index 4efccb20c196..000000000000 --- a/docs-kits/kits/requirements-kit/development-view/architecture.md +++ /dev/null @@ -1,85 +0,0 @@ ---- -id: architecture-overview -title: Architecture Overview -sidebar_position: 2 ---- - - - - - -import Kit3DLogo from '@site/src/components/2.0/Kit3DLogo'; - - - - - -## Architecture View - -## Architecture Overview - -### System Architecture - -[High-level architecture diagram and explanation] - -```mermaid -graph TB - subgraph External Systems - A[Client Application] - B[External Service] - end - - subgraph KIT Components - C[API Gateway] - D[Core Service] - E[Data Layer] - end - - subgraph Infrastructure - F[Database] - G[Message Queue] - end - - A -->|HTTPS| C - B -->|Protocol| C - C --> D - D --> E - E --> F - D --> G -``` - -### Architecture Principles - -1. **Modularity**: Loosely coupled components -2. **Scalability**: Horizontal scaling support -3. **Security**: End-to-end encryption -4. **Interoperability**: Standards-based APIs -5. **Observability**: Built-in monitoring and logging - -## NOTICE - -This work is licensed under the [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). - -- SPDX-License-Identifier: CC-BY-4.0 -- SPDX-FileCopyrightText: [YYYY] [YOUR_COMPANY] -- SPDX-FileCopyrightText: [YYYY] Contributors to the Eclipse Foundation -- Source URL: [https://github.com/eclipse-tractusx/eclipse-tractusx.github.io](https://github.com/eclipse-tractusx/eclipse-tractusx.github.io) diff --git a/docs-kits/kits/requirements-kit/development-view/development-view.md b/docs-kits/kits/requirements-kit/development-view/development-view.md index 84109a570296..2ce9527c7f18 100644 --- a/docs-kits/kits/requirements-kit/development-view/development-view.md +++ b/docs-kits/kits/requirements-kit/development-view/development-view.md @@ -41,239 +41,79 @@ Software Developers, Solution Architects, Technical Leads, API Developers, Integ --- -### More Guides - -- [Architecture Overview](architecture.md) - -### Component Diagram - -The flowchart illustrates the interactions between four main components in the system: - ### Core Components #### Component 1: Requirement System -**Purpose**: Core component responsible for requirement management +**Purpose**: Core component responsible for requirement management at the data consumer or provider -**Technology Stack**: [Programming language, framework, key dependencies] +**Technology Stack**: Implementation depends on solution provider. -**Interfaces**: [Input, output, protocols] +**Interfaces**: Typically ReqIF Export #### Component 2: Eclipse Dataspace Connector (EDC) -**Purpose**: Facilitates data exchange between partners +**Purpose**: Facilitates contract negotiation and data exchange between partners in the data space -**Technology Stack**: [Programming language, framework, key dependencies] +**Technology Stack**: Java -**Interfaces**: [Input, output, protocols] +**Interfaces**: Dataspace Protocol -#### Component 3: Requirement System +#### Component 3: Digital Twin Registry **Purpose**: Stores and manages digital twin information -**Technology Stack**: [Programming language, framework, key dependencies] +**Technology Stack**: Java, Go -**Interfaces**: [Input, output, protocols] +**Interfaces**: AAS API -#### Component 4: Requirement System +#### Component 4: Submodel Server **Purpose**: Handles submodel data and operations -**Technology Stack**: [Programming language, framework, key dependencies] - -**Interfaces**: [Input, output, protocols] - ---- - -## Standards Compliance - -| Standard | Version | Compliance | Description | -|----------|---------|------------|-------------| -| CX-0154 | 1.0.1 | Optional | Standard describing how to handle Master Data in Engineering. This includes parameters of | -| CX-0155 | 1.0.1 | Mandatory | Describes the required data models and API usage for the | - -### Standard Details - -#### Requirements Engineering v.1.0.1 - -**Compliance Level**: [Mandatory | Optional | Recommended] - -**Implementation**: [Brief description] - -**Reference**: [CX-0155 Requirements Engineering](https://catenax-ev.github.io/docs/next/standards/CX-0155-RequirementsEngineering) - -#### Digital Engineering Master Data v1.0.1 - -**Compliance Level**: [Mandatory | Optional | Recommended] - -**Implementation**: [Brief description] - -**Reference**: [CX-0154 Master Data](https://catenax-ev.github.io/docs/standards/CX-0154-MasterDataManagement) - ---- - -## Logic & Schema - -### Business Logic - -[Core business logic description] - -#### Logic Flow: [Process Name] - -**Input**: [Required data] - -**Processing Steps**: [Brief description of steps] - -**Output**: [Produced data] - -### Data Schema - -#### Schema: [Schema Name] - -**Purpose**: [Schema description] - -```json -{ - "$schema": "http://json-schema.org/draft-07/schema#", - "type": "object", - "properties": { - "id": { - "type": "string", - "description": "Unique identifier" - }, - "name": { - "type": "string", - "description": "Resource name" - } - }, - "required": ["id", "name"] -} -``` - -**Example**: +**Technology Stack**: Java, Go -```json -{ - "id": "res-001", - "name": "Example Resource" -} -``` +**Interfaces**: AAS API --- -## Semantic Models - -### Model: [Model Name] - -**Version**: X.Y.Z - -**Namespace**: `urn:samm:org.eclipse.tractusx.[domain]:[version]#` - -**Description**: [Model description] - -**Key Properties**: - -| Property | Type | Required | Description | -|----------|------|----------|-------------| -| `property1` | string | Yes | [Description] | -| `property2` | integer | No | [Description] | - -**Example**: - -```json -{ - "@context": { - "@vocab": "urn:samm:org.eclipse.tractusx.[domain]:[version]#" - }, - "property1": "value1", - "property2": 42 -} -``` +## Sequence Diagrams -**Reference**: [Link to SAMM specification] +### Data Exchange Flow ---- - -## Test Cases - -### Test Strategy - -- **Unit Tests**: Component-level testing -- **Integration Tests**: API integration testing -- **End-to-End Tests**: Complete workflow testing - -### Test Case: [Test Name] - -**Objective**: [Test validation purpose] - -**Preconditions**: [Required setup] - -**Test Steps**: [Brief description] - -**Expected Outcome**: [Expected result] - ---- - -## Sample Data - -### Sample Dataset: [Dataset Name] - -**Purpose**: [Sample purpose] - -**Format**: JSON - -**Download**: [Link] - -**Example**: - -```json -{ - "sampleData": [ - { - "id": "sample-001", - "field1": "value1" - } - ] -} -``` +```mermaid +sequenceDiagram + participant oemReqSys as Requirement System Customer + participant oemDtr as DTR & Submodel Service Customer + participant oemEDC as EDC Customer ---- + participant supEDC as EDC Supplier + participant supDtr as DTR & Submodel Service Supplier + participant supReqSys as Requirement System Supplier -#### Interactions + oemReqSys->>oemDtr: Requirement (DTR + Submodel) + oemReqSys->>oemEDC: Notification + oemEDC->>supEDC: Notification + supEDC->>supReqSys: Notification + supReqSys-->>supEDC: Request Requirement -The system architecture demonstrates how components interact to facilitate requirement exchange: -- **Requirement System Operations** - - Registers Digital Twins and Submodel Descriptors in the Digital Twin Registry - - Provides Requirement Submodels to the Submodel Service - - Uses the Eclipse Dataspace Connector to request requirements and send notifications -- **Eclipse Dataspace Connector (EDC)** - - Handles notifications sent from partners back to the Requirement System - - Acts as the communication bridge between partners -- **Digital Twin Registry** - - Provides Digital Twins to the Eclipse Dataspace Connector -- **Submodel Service** - - Provides Submodels to the Eclipse Dataspace Connector + supEDC-->>oemEDC: Request Requirement + oemEDC-->>oemDtr: Request Requirement -```mermaid -flowchart LR + oemDtr->>oemEDC: Requirement -reqSysC[Requirement System] -dtrC[Digital Twin Registry] -submodelC[Submodel Service] -edcC[Eclipse Dataspace Connector] + oemEDC->>supEDC: Requirement + supEDC->>supDtr: Requirement (DTR + Submodel) -reqSysC -- Register Digital Twins and Submodel Descriptors --> dtrC -reqSysC -- Provide Requirement Submodels --> submodelC -reqSysC -- Use EDC to Request Requirements and send notifications --> edcC -edcC -- Handle Notifications sent from partner --> reqSysC -dtrC -- Provide Digital Twins --> edcC -submodelC -- Provide Submodels --> edcC + supDtr->>supReqSys: Requirement + supReqSys->>supDtr: Update Requirement + supReqSys->>supEDC: Notification (updated Requirement) + supEDC->>oemEDC: Notification (updated Requirement) + oemEDC->>oemReqSys: Notification (updated Requirement) ``` -### Requirement Exchange Sequence - The sequence diagram illustrates the requirement exchange flow between a Customer (e.g., an OEM) and a Supplier: 1. **Initial Requirement Creation**: @@ -294,123 +134,144 @@ The sequence diagram illustrates the requirement exchange flow between a Custome 4. **Next interactions**: -- The process can be repeated for further updates or new requirements in an interactive manner between the Customer and Supplier. - -The diagram shows the core components involved in this exchange: + - The process can be repeated for further updates or new requirements in an interactive manner between the Customer and Supplier. -- Requirement Systems (on both Customer and Supplier sides) -- Digital Twin Registry (DTR) & Submodel Services -- Eclipse Dataspace Connector (EDC) for secure data exchange -- Solid lines indicate dataflow -- Dashed lines indicate initialization of a request +--- -```mermaid +## Standards Compliance -sequenceDiagram - participant oemReqSys as Requirement System Customer - participant oemDtr as DTR & Submodel Service Customer - participant oemEDC as EDC Customer +| Standard | Version | Compliance | Description | +|----------|---------|------------|-------------| +| CX-0154 | 1.0.1 | Optional | Standard describing how to handle Master Data in Engineering. This includes parameters of | +| CX-0155 | 1.0.1 | Mandatory | Describes the required data models and API usage for the | - participant supEDC as EDC Supplier - participant supDtr as DTR & Submodel Service Supplier - participant supReqSys as Requirement System Supplier +### Standard Details - oemReqSys->>oemDtr: Requirement (DTR + Submodel) - oemReqSys->>oemEDC: Notification - oemEDC->>supEDC: Notification - supEDC->>supReqSys: Notification - supReqSys-->>supEDC: Request Requirement +#### Requirements Engineering v.1.0.1 +**Compliance Level**: Mandatory - supEDC-->>oemEDC: Request Requirement - oemEDC-->>oemDtr: Request Requirement +**Implementation**: The Requirements Standard describes the data model and the API to use for requirements engineering in Catena-X. The data model defined is based on ReqIF and can be used in other domains then automotive as well. - oemDtr->>oemEDC: Requirement +**Reference**: [CX-0155 Requirements Engineering](https://catenax-ev.github.io/docs/next/standards/CX-0155-RequirementsEngineering) - oemEDC->>supEDC: Requirement - supEDC->>supDtr: Requirement (DTR + Submodel) +#### Digital Engineering Master Data v1.0.1 - supDtr->>supReqSys: Requirement +**Compliance Level**: Recommended - supReqSys->>supDtr: Update Requirement - supReqSys->>supEDC: Notification (updated Requirement) - supEDC->>oemEDC: Notification (updated Requirement) - oemEDC->>oemReqSys: Notification (updated Requirement) +**Implementation**: The Digital Engineering Master Data standard describes the main artifacts required in Collaborative Engineering use cases with a focus on Catena-X. It is designed industry-agnostic and can be used in other industries as well. +**Reference**: [CX-0154 Master Data](https://catenax-ev.github.io/docs/standards/CX-0154-MasterDataManagement) -``` +--- -## Requirements Aspect Model +## Logic & Schema -The following section gives an overview of the requirements aspect model. The requirements aspect model is a submodel that contains the requirements information and the status of the requirement. +### Data Schema -| Digital Twin Type | Aspect Model | Mandatory Version | Optional Versions | KIT | Standard | -| :-- | :-- | :-- | :-- | :-- | :-- | -| PartType | Requirements | 1.0.0 | | Requirements | CX-0155 | +#### Schema: Notification Schema -### Example of a Requirements Aspect Model +**Purpose**: The notification format used for the requirements exchange is based on the [Industry Core Kit's standardized notification format](../../industry-core-kit/software-development-view/notifications.mdx). The following example illustrates a notification sent from a Customer to a Supplier when a new requirement is created: ```json { - "requirementRelations": [ - { - "relatedRequirementId": "urn:uuid:e6b31BC2-8102-64AF-034D-C2DC35E37cEE", - "requiremementRelationshipType": "RequirementSpecialismOfRequirement" - } - ], - "requirementId": "urn:uuid:48878d48-6f1d-47f5-8ded-a441d0d879df", - "requirementInformation": { - "foreignId": "3.1.1", - "longname": "Plastic deformation of the bogie", - "versionPredecessor": { - "versionPredecessorNumber": "1.4.5", - "versionPredecessorId": "AeEf3f22-Af51-EDF0-29D2-Ba086b386A5E" - }, - "creationdate": "2025-06-05T09:35:16.166+02:00", - "metadata": [ - { - "value": "2025-11-30T00:00:00.000+02:00", - "metadataDescription": "Timestamp of the expected finalization of the requirement", - "key": "ExpectedFinalization" + "$schema" : "http://json-schema.org/draft-04/schema", + "x-samm-aspect-model-urn" : "urn:samm:io.catenax.shared.message_header:3.0.0#MessageHeaderAspect", + "description" : "Aspect model describing the shared message header.", + "type" : "object", + "components" : { + "schemas" : { + "UuidV4Trait" : { + "type" : "string", + "x-samm-aspect-model-urn" : "urn:samm:io.catenax.shared.uuid:2.0.0#UuidV4Trait", + "description" : "The provided regular expression ensures that the UUID is composed of five groups of characters separated by hyphens, in the form 8-4-4-4-12 for a total of 36 characters (32 hexadecimal characters and 4 hyphens), optionally prefixed by \"urn:uuid:\" to make it an IRI.", + "pattern" : "(^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$)|(^urn:uuid:[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$)" + }, + "ContextCharacteristic" : { + "type" : "string", + "x-samm-aspect-model-urn" : "urn:samm:io.catenax.shared.message_header:3.0.0#ContextCharacteristic", + "description" : "Defining a string value for the context" + }, + "Timestamp" : { + "type" : "string", + "pattern" : "-?([1-9][0-9]{3,}|0[0-9]{3})-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])T(([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\\.[0-9]+)?|(24:00:00(\\.0+)?))(Z|(\\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))?", + "x-samm-aspect-model-urn" : "urn:samm:org.eclipse.esmf.samm:characteristic:2.2.0#Timestamp", + "description" : "Describes a Property which contains the date and time with an optional timezone." + }, + "BpnlTrait" : { + "type" : "string", + "x-samm-aspect-model-urn" : "urn:samm:io.catenax.shared.business_partner_number:2.0.0#BpnlTrait", + "description" : "The provided regular expression ensures that the BPNL is composed of prefix 'BPNL', 10 digits and two alphanumeric letters.", + "pattern" : "^BPNL[a-zA-Z0-9]{12}$" + }, + "SemanticVersioningTrait" : { + "type" : "string", + "x-samm-aspect-model-urn" : "urn:samm:io.catenax.shared.message_header:3.0.0#SemanticVersioningTrait", + "description" : "Constraint for defining a SemVer version.", + "pattern" : "^(0|[1-9][0-9]*).(0|[1-9][0-9]*).(0|[1-9][0-9]*)(-(0|[1-9A-Za-z-][0-9A-Za-z-]*)(.[0-9A-Za-z-]+)*)?([0-9A-Za-z-]+(.[0-9A-Za-z-]+)*)?$" + }, + "HeaderCharacteristic" : { + "description" : "Characteristic describing the common shared aspect Message Header", + "x-samm-aspect-model-urn" : "urn:samm:io.catenax.shared.message_header:3.0.0#HeaderCharacteristic", + "type" : "object", + "properties" : { + "messageId" : { + "description" : "Unique ID identifying the message. The purpose of the ID is to uniquely identify a single message, therefore it MUST not be reused.", + "x-samm-aspect-model-urn" : "urn:samm:io.catenax.shared.message_header:3.0.0#messageId", + "$ref" : "#/components/schemas/UuidV4Trait" + }, + "context" : { + "description" : "Information about the context the message should be considered in.\nThe value MUST consist of two parts: an identifier of the context (e.g. business domain, etc.) followed by a version number.\nBoth the identifier and the version number MUST correspond to the content of the message.\nIf the content of a message is described by an aspect model available in the Catena-X Semantic Hub, then the unique identifier of this semantic model (e.g. urn:samm:io.catenax.:1.x.x) MUST be used as a value of the context field. This is considered the default case.\nIn all other cases the value of the context field MUST follow the pattern --:<[major] version> (e.g. TRACE-QM-Alert:1.x.x).\nVersioning only refers to major versions in both default and fallback cases.\nNote: The version of the message's header is specified in the version field.", + "x-samm-aspect-model-urn" : "urn:samm:io.catenax.shared.message_header:3.0.0#context", + "$ref" : "#/components/schemas/ContextCharacteristic" + }, + "sentDateTime" : { + "description" : "Time zone aware timestamp holding the date and the time the message was sent by the sending party. The value MUST be formatted according to the ISO 8601 standard", + "x-samm-aspect-model-urn" : "urn:samm:io.catenax.shared.message_header:3.0.0#sentDateTime", + "$ref" : "#/components/schemas/Timestamp" + }, + "senderBpn" : { + "description" : "The Business Partner Number of the sending party. The value MUST be a valid BPN. BPNA and BPNS are not allowed. Applicable constraints are defined in the corresponding standard", + "x-samm-aspect-model-urn" : "urn:samm:io.catenax.shared.message_header:3.0.0#senderBpn", + "$ref" : "#/components/schemas/BpnlTrait" + }, + "receiverBpn" : { + "description" : "The Business Partner Number of the receiving party. The value MUST be a valid BPN. BPNA and BPNS are not allowed. Applicable constraints are defined in the corresponding standard.", + "x-samm-aspect-model-urn" : "urn:samm:io.catenax.shared.message_header:3.0.0#receiverBpn", + "$ref" : "#/components/schemas/BpnlTrait" + }, + "expectedResponseBy" : { + "description" : "Time zone aware timestamp holding the date and time by which the sending party expects a certain type of response from the receiving party. The meaning and interpretation of the fields's value are context-bound and MUST therefore be defined by any business domain or platform capability making use of it. The value MUST be formatted according to the ISO 8601 standard", + "x-samm-aspect-model-urn" : "urn:samm:io.catenax.shared.message_header:3.0.0#expectedResponseBy", + "$ref" : "#/components/schemas/Timestamp" + }, + "relatedMessageId" : { + "description" : "Unique ID identifying a message somehow related to the current one", + "x-samm-aspect-model-urn" : "urn:samm:io.catenax.shared.message_header:3.0.0#relatedMessageId", + "$ref" : "#/components/schemas/UuidV4Trait" + }, + "version" : { + "description" : "The unique identifier of the aspect model defining the structure and the semantics of the message's header. The version number should reflect the versioning schema of aspect models in Catena-X.", + "x-samm-aspect-model-urn" : "urn:samm:io.catenax.shared.message_header:3.0.0#version", + "$ref" : "#/components/schemas/SemanticVersioningTrait" + } + }, + "required" : [ "messageId", "context", "sentDateTime", "senderBpn", "receiverBpn", "version" ] } - ], - "author": "Lisa Dräxlmaier GmbH", - "reqifType": "Functional", - "reqifName": "Plastic deformation of the bogie", - "description": "eOMtThyhVNLWUZNRcBaQKxI", - "specification": [ - "https://www.prostep.org/fileadmin/prod-pay-download-8c1d/Recommendation_ReqIF_V2.2.pdf" - ], - "version": { - "versionNumber": "2.0.0", - "versionId": "B50C5243-9590-Eaa5-dA9e-Adb383e2cFf6" } }, - "requirementStatus": { - "customerStatus": [ - { - "customerStatusComment": "Requirement needs to be evaluated", - "customerStatusValue": "", - "customerStatusTimestamp": "2025-06-05T09:35:16.166+02:00" - } - ], - "supplierStatus": [ - { - "supplierStatusTimestamp": "2025-06-05T09:35:16.166+02:00", - "supplierStatusValue": "", - "supplierStatusComment": "More information needed from customer" - } - ], - "statusValue": "transition status", - "statusTimestamp": "2025-06-05T09:35:16.166+02:00" - } + "properties" : { + "header" : { + "description" : "Contains standardized attributes for message processing common across several use cases.", + "x-samm-aspect-model-urn" : "urn:samm:io.catenax.shared.message_header:3.0.0#header", + "$ref" : "#/components/schemas/HeaderCharacteristic" + } + }, + "required" : [ "header" ] } - ``` -## Notification Format - -The notification format used for the requirements exchange is based on the [Industry Core Kit's standardized notification format](../industry-core-kit/software-development-view/notifications). The following example illustrates a notification sent from a Customer to a Supplier when a new requirement is created: +**Example**: ```json { @@ -430,27 +291,84 @@ The notification format used for the requirements exchange is based on the [Indu } ``` -- ```requirementId```: ```requirementId``` in requirements datamodel +--- - +## Semantic Models + +### Model: Requirements + +**Version**: 1.0.0 + +**Namespace**: `urn:samm:io.catenax.requirement:1.0.0#` + +**Description**: This model describes a Requirement. It un + +**Key Properties**: + +| Property | Type | Required | Description | +|----------|------|----------|-------------| +| `requirementId` | string | Yes | UUID of the requirement | +| `requirementStatus` | string | Yes | Requirements Status based on [https://www.prostep.org/fileadmin/prod-pay-download-8c1d/Recommendation_ReqIF_V2.2.pdf](https://www.prostep.org/fileadmin/prod-pay-download-8c1d/Recommendation_ReqIF_V2.2.pdf) | -Base idea of notifications: Only technical information about creation/change/deletion of requirement. Descriptive information about changes and comments are stored directly within the requirement submodels. +**Example**: -## EDC Setup +```json +{ + "requirementRelations" : [ { + "requirementRelationshipType" : "RequirementSpecialismOfRequirement", + "relatedRequirementId" : "urn:uuid:e6b31BC2-8102-64AF-034D-C2DC35E37cEE" + } ], + "requirementId" : "urn:uuid:48878d48-6f1d-47f5-8ded-a441d0d879df", + "requirementInformation" : { + "foreignId" : "3.1.1", + "longname" : "Plastic deformation of the bogie", + "versionPredecessor" : { + "versionPredecessorNumber" : "1.4.5", + "versionPredecessorId" : "DaCfB4BD-15e7-edf0-77B6-Eb30De54aFbE" + }, + "reqIfName" : "Plastic deformation of the bogie", + "reqIfType" : "Functional", + "metadata" : [ { + "value" : "2025-11-30T00:00:00.000+02:00", + "metadataDescription" : "Timestamp of the expected finalization of the requirement", + "key" : "ExpectedFinalization" + } ], + "author" : "Lisa Dräxlmaier GmbH", + "description" : "eOMtThyhVNLWUZNRcBaQKxI", + "specification" : [ "https://www.prostep.org/fileadmin/prod-pay-download-8c1d/Recommendation_ReqIF_V2.2.pdf" ], + "creationDate" : "2026-01-26T15:01:53.446Z", + "version" : { + "versionNumber" : "2.0.0", + "versionId" : "fA8Df9A9-3399-89AB-32eB-e7e61Bce8cFF" + } + }, + "requirementStatus" : { + "customerStatus" : [ { + "customerStatusComment" : "Requirement needs to be evaluated", + "customerStatusValue" : "", + "customerStatusTimestamp" : "2026-01-26T15:01:53.449Z" + } ], + "supplierStatus" : [ { + "supplierStatusTimestamp" : "2026-01-26T15:01:53.449Z", + "supplierStatusValue" : "", + "supplierStatusComment" : "More information needed from customer" + } ], + "statusValue" : "transition status", + "statusTimestamp" : "2026-01-26T15:01:53.448Z" + } +} +``` -In order to set up the EDC for the requirements use-case, the following steps are necessary: +**Reference**: [https://github.com/eclipse-tractusx/sldt-semantic-models/tree/main/io.catenax.requirement/1.0.0](https://github.com/eclipse-tractusx/sldt-semantic-models/tree/main/io.catenax.requirement/1.0.0) -- [Setup for the DTR](../digital-twin-kit/software-development-view/) in order to provide access to the Digital Twins for the partners -- [Notifications](../industry-core-kit/software-development-view/notifications) to inform the partners about new requirements or updates. In the requirements use-case the standardized notifications from the Industry Core Kit are used. +--- ## Notice This work is licensed under the [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). - SPDX-License-Identifier: CC-BY-4.0 +- SPDX-FileCopyrightText: 2026 Fraunhofer-Gesellschaft zur Foerderung der angewandten Forschung e.V. (represented by Fraunhofer IPK) - SPDX-FileCopyrightText: 2025 Dräxlmaier GmbH & Co. KG - SPDX-FileCopyrightText: 2025 Schaeffler AG - SPDX-FileCopyrightText: 2025 Mercedes Benz Group AG From 5b00edd7e7ff53ee2a5c83e253f3eaa9d4ceb46e Mon Sep 17 00:00:00 2001 From: "Marvin Manoury (Fraunhofer IPK)" Date: Tue, 26 May 2026 22:35:32 +0200 Subject: [PATCH 04/10] chore: added license footer correctly --- .../kits/requirements-kit/adoption-view/adoption-view.md | 4 ++-- .../requirements-kit/development-view/development-view.md | 1 + .../industry-extensions/automotive/Overview.md | 7 +++++-- 3 files changed, 8 insertions(+), 4 deletions(-) diff --git a/docs-kits/kits/requirements-kit/adoption-view/adoption-view.md b/docs-kits/kits/requirements-kit/adoption-view/adoption-view.md index ca6f33bea3f5..af42dda44287 100644 --- a/docs-kits/kits/requirements-kit/adoption-view/adoption-view.md +++ b/docs-kits/kits/requirements-kit/adoption-view/adoption-view.md @@ -213,7 +213,7 @@ In addition to the challenges mentioned above, there is also the issue that the ## Business Processes :::tip -For industry-specific business processes, see the [Industry Extensions](https://github.com/eclipse-tractusx/eclipse-tractusx.github.io/tree/main/docs-kits/kit-template/industry-extensions) documentation. +For industry-specific business processes, see the [Industry Extensions](../industry-extensions) documentation. ::: ### Core Business Process: [Process Name] @@ -338,10 +338,10 @@ For industry-specific standards, refer to the [Industry Extensions](https://gith This work is licensed under the [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). - SPDX-License-Identifier: CC-BY-4.0 +- SPDX-FileCopyrightText: 2026 Fraunhofer-Gesellschaft zur Foerderung der angewandten Forschung e.V. (represented by Fraunhofer IPK) - SPDX-FileCopyrightText: 2025 Dräxlmaier GmbH & Co. KG - SPDX-FileCopyrightText: 2025 Schaeffler AG - SPDX-FileCopyrightText: 2025 Mercedes Benz Group AG - SPDX-FileCopyrightText: 2025 ZF Friedrichshafen AG -- SPDX-FileCopyrightText: 2026 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. für ihre Institute IPK - SPDX-FileCopyrightText: 2025 Contributors to the Eclipse Foundation - Source URL: [https://github.com/eclipse-tractusx/eclipse-tractusx.github.io](https://github.com/eclipse-tractusx/eclipse-tractusx.github.io) diff --git a/docs-kits/kits/requirements-kit/development-view/development-view.md b/docs-kits/kits/requirements-kit/development-view/development-view.md index 2ce9527c7f18..3246d091f659 100644 --- a/docs-kits/kits/requirements-kit/development-view/development-view.md +++ b/docs-kits/kits/requirements-kit/development-view/development-view.md @@ -374,3 +374,4 @@ This work is licensed under the [CC-BY-4.0](https://creativecommons.org/licenses - SPDX-FileCopyrightText: 2025 Mercedes Benz Group AG - SPDX-FileCopyrightText: 2025 ZF Friedrichshafen AG - SPDX-FileCopyrightText: 2025 Contributors to the Eclipse Foundation +- Source URL: [https://github.com/eclipse-tractusx/eclipse-tractusx.github.io](https://github.com/eclipse-tractusx/eclipse-tractusx.github.io) diff --git a/docs-kits/kits/requirements-kit/industry-extensions/automotive/Overview.md b/docs-kits/kits/requirements-kit/industry-extensions/automotive/Overview.md index a5b12f2acd47..ed764e523a04 100644 --- a/docs-kits/kits/requirements-kit/industry-extensions/automotive/Overview.md +++ b/docs-kits/kits/requirements-kit/industry-extensions/automotive/Overview.md @@ -194,6 +194,9 @@ sequenceDiagram This work is licensed under the [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). - SPDX-License-Identifier: CC-BY-4.0 -- SPDX-FileCopyrightText: [YYYY] [YOUR_COMPANY] -- SPDX-FileCopyrightText: [YYYY] Contributors to the Eclipse Foundation +- SPDX-FileCopyrightText: 2026 Fraunhofer-Gesellschaft zur Foerderung der angewandten Forschung e.V. (represented by Fraunhofer IPK) +- SPDX-FileCopyrightText: 2025 Dräxlmaier GmbH & Co. KG +- SPDX-FileCopyrightText: 2025 Schaeffler AG +- SPDX-FileCopyrightText: 2025 Mercedes Benz Group AG +- SPDX-FileCopyrightText: 2025 ZF Friedrichshafen AG - Source URL: [https://github.com/eclipse-tractusx/eclipse-tractusx.github.io](https://github.com/eclipse-tractusx/eclipse-tractusx.github.io) From 640d4e4468368ffd7adb3a49559be4390cfae0e7 Mon Sep 17 00:00:00 2001 From: "Marvin Manoury (Fraunhofer IPK)" Date: Tue, 26 May 2026 22:40:02 +0200 Subject: [PATCH 05/10] chore: linting requirements KIT --- .../requirements-kit/development-view/development-view.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs-kits/kits/requirements-kit/development-view/development-view.md b/docs-kits/kits/requirements-kit/development-view/development-view.md index 3246d091f659..90caaf8d13b6 100644 --- a/docs-kits/kits/requirements-kit/development-view/development-view.md +++ b/docs-kits/kits/requirements-kit/development-view/development-view.md @@ -59,13 +59,13 @@ Software Developers, Solution Architects, Technical Leads, API Developers, Integ **Interfaces**: Dataspace Protocol -#### Component 3: Digital Twin Registry +#### Component 3: Digital Twin Registry **Purpose**: Stores and manages digital twin information **Technology Stack**: Java, Go -**Interfaces**: AAS API +**Interfaces**: AAS API #### Component 4: Submodel Server @@ -151,7 +151,7 @@ The sequence diagram illustrates the requirement exchange flow between a Custome **Compliance Level**: Mandatory -**Implementation**: The Requirements Standard describes the data model and the API to use for requirements engineering in Catena-X. The data model defined is based on ReqIF and can be used in other domains then automotive as well. +**Implementation**: The Requirements Standard describes the data model and the API to use for requirements engineering in Catena-X. The data model defined is based on ReqIF and can be used in other domains then automotive as well. **Reference**: [CX-0155 Requirements Engineering](https://catenax-ev.github.io/docs/next/standards/CX-0155-RequirementsEngineering) @@ -159,7 +159,7 @@ The sequence diagram illustrates the requirement exchange flow between a Custome **Compliance Level**: Recommended -**Implementation**: The Digital Engineering Master Data standard describes the main artifacts required in Collaborative Engineering use cases with a focus on Catena-X. It is designed industry-agnostic and can be used in other industries as well. +**Implementation**: The Digital Engineering Master Data standard describes the main artifacts required in Collaborative Engineering use cases with a focus on Catena-X. It is designed industry-agnostic and can be used in other industries as well. **Reference**: [CX-0154 Master Data](https://catenax-ev.github.io/docs/standards/CX-0154-MasterDataManagement) From 91ceabbcc3d679c38d543418e622bebc0d1bb8f0 Mon Sep 17 00:00:00 2001 From: "Marvin Manoury (Fraunhofer IPK)" Date: Thu, 28 May 2026 12:31:46 +0200 Subject: [PATCH 06/10] feat: added access policy and removed broken links --- .../adoption-view/adoption-view.md | 127 +++++------------- 1 file changed, 33 insertions(+), 94 deletions(-) diff --git a/docs-kits/kits/requirements-kit/adoption-view/adoption-view.md b/docs-kits/kits/requirements-kit/adoption-view/adoption-view.md index af42dda44287..df410b6f99c1 100644 --- a/docs-kits/kits/requirements-kit/adoption-view/adoption-view.md +++ b/docs-kits/kits/requirements-kit/adoption-view/adoption-view.md @@ -73,7 +73,7 @@ The Requirements Kit aims to meticulously outline requirements by incorporating ## Business Value -### Value Proposition #1: [Title] +### Value Proposition #1: Reliable and sovereign requirements data exchange system The "Requirements-KIT" provides guidelines and standards, such as semantic models and data exchange processes, which help companies create a reliable and sovereign data exchange system with their partners. @@ -81,28 +81,6 @@ This reduces cost and effort needed to integrate data-driven engineering process Since this KIT is built on the Industry Core KIT and will be closely connected to upcoming other KITSs within the Engineering Domain, investment and implementation costs to integrate requirement services are reduced. -**Benefit**: [Primary benefit description] - -**Target Stakeholders**: [OEMs | SMEs | Solution Providers | etc.] - -**Measurable Outcomes**: [Key metrics] - -### Value Proposition #2: [Title] - -**Benefit**: [Second benefit description] - -**Target Stakeholders**: [Target audience] - -**Measurable Outcomes**: [Key metrics] - -### Value Proposition #3: [Title] - -**Benefit**: [Third benefit description] - -**Target Stakeholders**: [Target audience] - -**Measurable Outcomes**: [Key metrics] - --- ### Summary of Business Benefits @@ -142,13 +120,6 @@ Catena-X offers solution providers a variety of strategic advantages to leverage 9. Access to data and analysis: With access to valuable industrial data, solution providers can develop and enhance their analytics and optimization solutions to boost operational efficiency and decision-making processes for customers. 10. Accelerated digital transformation: Catena-X allows solution providers to position their transformation strategies directly within the context of the automotive industry, a sector that is continually moving towards digital technologies. -| Stakeholder Type | Key Benefits | Time to Value | -|------------------|--------------|---------------| -| **OEMs** | [List 2-3 benefits for large enterprises] | [e.g., "6 months"] | -| **SMEs** | [List 2-3 benefits for small-medium enterprises] | [e.g., "3 months"] | -| **Solution Providers** | [List 2-3 benefits for tech vendors] | [e.g., "90 days"] | -| **Data Providers** | [List 2-3 benefits for data providers] | [e.g., "4 weeks"] | - --- ## Use Case Context @@ -163,63 +134,14 @@ This involves the circular processing of requests between partners, which can re In addition to the challenges mentioned above, there is also the issue that the files can be designed in a variety of content forms and the formats of the files can also vary. The formats can be divided into structured and unstructured files. Unstructured files are texts, tables etc. that are not organized into individual requirements without prior processing. These increase the effort required to organize the document into individual requirements. This also makes the exchange with the partner more difficult, as the partner does not know the newly created structure. With structured files, the aforementioned circumstances no longer exist, as the requirements are already organized. In the best case, a standardized form, such as the ReqIF format, is used. However, even when using standardized formats such as ReqIF, it is still necessary to agree on a common data model for exporting and importing in advance so that data exchange via the various requirements management tools works as smoothly as possible. -**Current Challenges:** - -- **Challenge 1**: [Problem description and impact] -- **Challenge 2**: [Problem description and impact] -- **Challenge 3**: [Problem description and impact] - -### The Solution - -[Explain how this KIT addresses the challenges] - -**Solution Components:** - -1. **[Component 1]**: [Description] -2. **[Component 2]**: [Description] -3. **[Component 3]**: [Description] - ---- - -## Use Cases - -### Primary Use Case: [Use Case Name] - -**Description**: [Use case description] - -**Actors**: [Actor 1], [Actor 2], [Actor 3] - -**Process Flow**: - -1. [Step 1 description] -2. [Step 2 description] -3. [Step 3 description] - -**Business Outcomes**: [Key outcomes] - -**Success Metrics**: [Key metrics] - -### Secondary Use Case: [Use Case Name] - -[Same structure as primary use case] - -### Additional Use Cases - -1. **[Use Case 3]**: [Brief description] -2. **[Use Case 4]**: [Brief description] - --- ## Business Processes :::tip -For industry-specific business processes, see the [Industry Extensions](../industry-extensions) documentation. +For industry-specific business processes, see the [Industry Extensions](../industry-extensions/automotive/Overview.md) documentation. ::: -### Core Business Process: [Process Name] - -![Customer Journey](../resources/img/requirements_customer-journey.png) - ### Core Business Process: User Journey ```mermaid @@ -248,29 +170,46 @@ flowchart TD ### Access & Usage Policies :::warning Industry-Specific Policies -For industry-specific policy requirements, refer to the [Industry Extensions](https://github.com/eclipse-tractusx/eclipse-tractusx.github.io/tree/main/docs-kits/kit-template/industry-extensions) section. +For industry-specific policy requirements, refer to the [Industry Extensions](../industry-extensions/automotive/Overview.md) section. ::: #### Example Access Policy ```json { - "policy": { - "permission": { - "action": "use", - "constraint": { - "leftOperand": "UsagePurpose", - "operator": "isAnyOf", - "rightOperand": [ - "mx.core.digitalTwinRegistry:1" - ] - } + "@context": [ + "https://w3id.org/catenax/2025/9/policy/odrl.jsonld", + "https://w3id.org/catenax/2025/9/policy/context.jsonld" + ], + "@type": "Set", + "@id": "some-id", + "permission": [ + { + "action": "access", + "constraint": [ + { + "and": [ + { + "leftOperand": "Membership", + "operator": "eq", + "rightOperand": "active" + }, + { + "leftOperand": "BusinessPartnerNumber", + "operator": "isAnyOf", + "rightOperand": [ + "BPNL012345678910" + ] + } + ] + } + ] } - } + ] } ``` -[Brief policy explanation] +In the Engineering Context most data exchange is done bilateral, therefore the access policy focuses on specific partners (here with a ``BPNL`` for automotive data ecosystems.) --- @@ -305,7 +244,7 @@ For industry-specific policy requirements, refer to the [Industry Extensions](ht ## Standards :::warning Industry-Specific Standards -For industry-specific standards, refer to the [Industry Extensions](https://github.com/eclipse-tractusx/eclipse-tractusx.github.io/tree/main/docs-kits/kit-template/industry-extensions) section. +For industry-specific standards, refer to the [Industry Extensions](../industry-extensions/automotive/Overview.md) section. ::: ### Supported Standards From 6535bbfb27f81d1cc1c0214b95c71ff6f6b82b5b Mon Sep 17 00:00:00 2001 From: "Marvin Manoury (Fraunhofer IPK)" Date: Thu, 28 May 2026 13:24:00 +0200 Subject: [PATCH 07/10] feat: adapted Automotive view and removed placeholders --- .../adoption-view/adoption-view.md | 80 +++++++++++----- .../development-view/development-view.md | 4 +- .../automotive/Overview.md | 93 ++----------------- 3 files changed, 71 insertions(+), 106 deletions(-) diff --git a/docs-kits/kits/requirements-kit/adoption-view/adoption-view.md b/docs-kits/kits/requirements-kit/adoption-view/adoption-view.md index df410b6f99c1..8b13df46a7ee 100644 --- a/docs-kits/kits/requirements-kit/adoption-view/adoption-view.md +++ b/docs-kits/kits/requirements-kit/adoption-view/adoption-view.md @@ -215,27 +215,73 @@ In the Engineering Context most data exchange is done bilateral, therefore the a ## Semantic Models -[Brief explanation of semantic models used in this KIT] +The core semantic model within the Requirements Engineering is the Requirements Model. +It is used to describe a single Requirement. + +:::info Upcoming versions +It is currently planned to refactor the Requirements Model such that it is easier to maintain the relationships between different requirements and make them better accessible and easier to register in a Digital Twin Registry. +::: ### Core Semantic Models | Model Name | Version | Purpose | Link | |------------|---------|---------|------| -| [Model 1] | X.Y.Z | [Model purpose] | [Link] | -| [Model 2] | X.Y.Z | [Model purpose] | [Link] | +| Requirement | 1.0.0 | Describe a single Requirement in the Requirement Engineering process | [Link][1] | -### Model Example: [Model Name] +[1]: https://github.com/eclipse-tractusx/sldt-semantic-models/tree/main/io.catenax.requirement/1.0.0 -**Description**: [Brief description] +### Model Example: Requirement -**Key Attributes**: [List key attributes] +**Description**: This model describes a Requirement. It is based on ReqIF and thus uses some parameters in a common format. + +**Key Attributes**: `requirementId`, `requirementStatus` (customer and supplier), `requirementInformation` (actual requirement content), `requirementRelations` **Example**: ```json { - "attribute1": "example-value", - "attribute2": 12345 + "requirementRelations" : [ { + "requirementRelationshipType" : "RequirementSpecialismOfRequirement", + "relatedRequirementId" : "urn:uuid:e6b31BC2-8102-64AF-034D-C2DC35E37cEE" + } ], + "requirementId" : "urn:uuid:48878d48-6f1d-47f5-8ded-a441d0d879df", + "requirementInformation" : { + "foreignId" : "3.1.1", + "longname" : "Plastic deformation of the bogie", + "versionPredecessor" : { + "versionPredecessorNumber" : "1.4.5", + "versionPredecessorId" : "DaCfB4BD-15e7-edf0-77B6-Eb30De54aFbE" + }, + "reqIfName" : "Plastic deformation of the bogie", + "reqIfType" : "Functional", + "metadata" : [ { + "value" : "2025-11-30T00:00:00.000+02:00", + "metadataDescription" : "Timestamp of the expected finalization of the requirement", + "key" : "ExpectedFinalization" + } ], + "author" : "Lisa Dräxlmaier GmbH", + "description" : "eOMtThyhVNLWUZNRcBaQKxI", + "specification" : [ "https://www.prostep.org/fileadmin/prod-pay-download-8c1d/Recommendation_ReqIF_V2.2.pdf" ], + "creationDate" : "2026-01-26T15:01:53.446Z", + "version" : { + "versionNumber" : "2.0.0", + "versionId" : "fA8Df9A9-3399-89AB-32eB-e7e61Bce8cFF" + } + }, + "requirementStatus" : { + "customerStatus" : [ { + "customerStatusComment" : "Requirement needs to be evaluated", + "customerStatusValue" : "", + "customerStatusTimestamp" : "2026-01-26T15:01:53.449Z" + } ], + "supplierStatus" : [ { + "supplierStatusTimestamp" : "2026-01-26T15:01:53.449Z", + "supplierStatusValue" : "", + "supplierStatusComment" : "More information needed from customer" + } ], + "statusValue" : "transition status", + "statusTimestamp" : "2026-01-26T15:01:53.448Z" + } } ``` @@ -251,26 +297,18 @@ For industry-specific standards, refer to the [Industry Extensions](../industry- | Standard | Version | Description | Compliance Level | Link | |----------|---------|-------------|------------------|------| -| [Standard 1] | X.Y | [Description] | Mandatory/Optional | [Link] | -| [Standard 2] | X.Y | [Description] | Mandatory/Optional | [Link] | +| CX-0154 | 1.0.1 | Standard describing how to handle Master Data in Engineering. This includes parameters of | Optional | [Link][CX-0154] | +| CX-0155 | 1.0.1 | Describes the required data models and API usage for the Requirements Engineering Use Case | Mandatory | [Link][CX-0155] | +[CX-0154]: https://catenax-ev.github.io/docs/standards/CX-0154-MasterDataManagement +[CX-0155]: https://catenax-ev.github.io/docs/standards/CX-0155-RequirementsEngineering --- ## Tutorials & Resources -### Getting Started Tutorial - -[Link to tutorial or brief description] - -### Video Resources - -| Title | Duration | Link | -|-------|----------|------| -| [Video 1] | [X min] | [Link] | - ### Whitepaper -- *Link to Factory-X Engineering Whitepaper as soon as it is available* +A Whitepaper was developed tother with the Manufacturing-X Topic Group Engineering, which should soon be available at: [https://mx-guidanceboard.org/downloads/](https://mx-guidanceboard.org/downloads/). ## Notice diff --git a/docs-kits/kits/requirements-kit/development-view/development-view.md b/docs-kits/kits/requirements-kit/development-view/development-view.md index 90caaf8d13b6..59c7c1714e15 100644 --- a/docs-kits/kits/requirements-kit/development-view/development-view.md +++ b/docs-kits/kits/requirements-kit/development-view/development-view.md @@ -301,7 +301,7 @@ The sequence diagram illustrates the requirement exchange flow between a Custome **Namespace**: `urn:samm:io.catenax.requirement:1.0.0#` -**Description**: This model describes a Requirement. It un +**Description**: This model describes a Requirement. It is based on ReqIF. **Key Properties**: @@ -309,6 +309,8 @@ The sequence diagram illustrates the requirement exchange flow between a Custome |----------|------|----------|-------------| | `requirementId` | string | Yes | UUID of the requirement | | `requirementStatus` | string | Yes | Requirements Status based on [https://www.prostep.org/fileadmin/prod-pay-download-8c1d/Recommendation_ReqIF_V2.2.pdf](https://www.prostep.org/fileadmin/prod-pay-download-8c1d/Recommendation_ReqIF_V2.2.pdf) | +| `requirementInformation` | RequirementInformationEntity | Yes | Actual Requirement information with text, type meta data, author etc. | +| `requirementRelations` | RequirementRelationSet (List of RequirementIds and relationship type) | No | relationship of the requirement to other requirements | **Example**: diff --git a/docs-kits/kits/requirements-kit/industry-extensions/automotive/Overview.md b/docs-kits/kits/requirements-kit/industry-extensions/automotive/Overview.md index ed764e523a04..1741a4347e2a 100644 --- a/docs-kits/kits/requirements-kit/industry-extensions/automotive/Overview.md +++ b/docs-kits/kits/requirements-kit/industry-extensions/automotive/Overview.md @@ -42,7 +42,7 @@ KIT LOGO END ## Automotive Industry Extension -This extension adapts the **[KIT_NAME] KIT** for the automotive industry with Catena-X standards compliance. +This extension adapts the **Requirements KIT** for the automotive industry with Catena-X standards compliance. :::info Extension Purpose Adds: Catena-X standards, automotive semantic models, business processes, and policies. @@ -57,8 +57,11 @@ Adds: Catena-X standards, automotive semantic models, business processes, and po | CX-0001 | 2.0.0 | EDC Discovery API | Mandatory | | CX-0002 | 2.0.0 | Digital Twins | Mandatory | | CX-0018 | 3.0.0 | Dataspace Connectivity | Mandatory | +| CX-0126 | 3.0.0 | Industry Core: PartType 2.1.0 | Mandatory | +| CX-0151 | 3.0.0 | Industry Core: Basics v1.0.0 | Mandatory | +| CX-0152 | 3.0.0 | Policy Constraints for Data Exchange v1.0.0 | Mandatory | -[Link to Catena-X Standard Library](https://catena-x.net/en/standard-library) +[Link to Catena-X Standard Library](https://catenax-ev.github.io/docs/standards/overview) --- @@ -94,99 +97,21 @@ Adds: Catena-X standards, automotive semantic models, business processes, and po } ``` -[Semantic Hub](https://semantics.catena-x.net/) - ---- - -## Business Processes - -### Supply Chain Traceability - -**Purpose**: End-to-end traceability of automotive parts - -**Actors**: OEM, Tier-1/Tier-N Suppliers, Traceability Service Provider - -**Process Flow**: - -```mermaid -sequenceDiagram - participant OEM - participant Tier1 as Tier-1 Supplier - participant TraceSvc as Traceability Service - participant EDC - - OEM->>TraceSvc: Request part trace - TraceSvc->>EDC: Query digital twins - EDC->>Tier1: Request part data - Tier1-->>EDC: Provide relationships - EDC-->>TraceSvc: Return data - TraceSvc-->>OEM: Display chain -``` - ---- - -## Access & Usage Policies - -### Catena-X Framework Policy - -```json -{ - "@context": {"odrl": "http://www.w3.org/ns/odrl/2/"}, - "@type": "PolicyDefinitionRequestDto", - "@id": "cx-policy", - "policy": { - "@type": "Policy", - "odrl:permission": [{ - "odrl:action": "USE", - "odrl:constraint": { - "odrl:leftOperand": "BusinessPartnerNumber", - "odrl:operator": {"@id": "odrl:eq"}, - "odrl:rightOperand": "BPNL00000003CRHK" - } - }] - } -} -``` - ---- - -## Use Cases - -### Quality Alert Distribution - -**Description**: Rapidly distribute quality alerts across supply chain - -**Actors**: Alert Issuer, Supply Chain Partners, Catena-X Services - -**Process**: Issue detection → Alert creation → Digital twin query → Distribution → Acknowledgment - -**Benefits**: Faster response, reduced costs, improved safety - ---- - -## Compliance - -| Regulation | Region | Relevance | -|------------|--------|----------| -| GDPR | EU | Data protection | -| Battery Regulation | EU | Battery passport | -| Supply Chain Due Diligence | DE | ESG reporting | - -**Certifications**: ISO/TS 16949, VDA 6.3, TISAX +[Semantic Hub](https://github.com/eclipse-tractusx/sldt-semantic-models) --- ## Getting Started 1. Review [Core KIT Adoption View](../../adoption-view/adoption-view.md) -2. Study [Catena-X Standards](https://catena-x.net/en/standard-library) -3. Implement semantic models from [Semantic Hub](https://semantics.catena-x.net/) +2. Study [Catena-X Standards](https://catenax-ev.github.io/docs/standards/overview) +3. Implement semantic models from [Semantic Hub](https://github.com/eclipse-tractusx/sldt-semantic-models) --- ## Resources -- [Catena-X Standard Library](https://catena-x.net/en/standard-library) +- [Catena-X Standard Library](https://catenax-ev.github.io/docs/standards/overview) - [Tractus-X Open Source](https://eclipse-tractusx.github.io/) ## NOTICE From 046189f60bff93482c0e0bddfa9151044374a9bb Mon Sep 17 00:00:00 2001 From: "Marvin Manoury (Fraunhofer IPK)" Date: Thu, 28 May 2026 13:33:42 +0200 Subject: [PATCH 08/10] chore: linting --- .../adoption-view/adoption-view.md | 12 ++++++------ .../development-view/development-view.md | 16 ++++++++-------- .../industry-extensions/automotive/Overview.md | 2 +- 3 files changed, 15 insertions(+), 15 deletions(-) diff --git a/docs-kits/kits/requirements-kit/adoption-view/adoption-view.md b/docs-kits/kits/requirements-kit/adoption-view/adoption-view.md index 8b13df46a7ee..6328c35512ac 100644 --- a/docs-kits/kits/requirements-kit/adoption-view/adoption-view.md +++ b/docs-kits/kits/requirements-kit/adoption-view/adoption-view.md @@ -225,14 +225,14 @@ It is currently planned to refactor the Requirements Model such that it is easie ### Core Semantic Models | Model Name | Version | Purpose | Link | -|------------|---------|---------|------| -| Requirement | 1.0.0 | Describe a single Requirement in the Requirement Engineering process | [Link][1] | +| ------------ | --------- | --------- | ------ | +| Requirement | 1.0.0 | Describe a single Requirement in the Requirement Engineering process | [Semantic Model][1] | [1]: https://github.com/eclipse-tractusx/sldt-semantic-models/tree/main/io.catenax.requirement/1.0.0 ### Model Example: Requirement -**Description**: This model describes a Requirement. It is based on ReqIF and thus uses some parameters in a common format. +**Description**: This model describes a Requirement. It is based on ReqIF and thus uses some parameters in a common format. **Key Attributes**: `requirementId`, `requirementStatus` (customer and supplier), `requirementInformation` (actual requirement content), `requirementRelations` @@ -296,9 +296,9 @@ For industry-specific standards, refer to the [Industry Extensions](../industry- ### Supported Standards | Standard | Version | Description | Compliance Level | Link | -|----------|---------|-------------|------------------|------| -| CX-0154 | 1.0.1 | Standard describing how to handle Master Data in Engineering. This includes parameters of | Optional | [Link][CX-0154] | -| CX-0155 | 1.0.1 | Describes the required data models and API usage for the Requirements Engineering Use Case | Mandatory | [Link][CX-0155] | +| ---------- | --------- | ------------- | ------------------ | ------ | +| CX-0154 | 1.0.1 | Standard describing how to handle Master Data in Engineering. This includes parameters of | Optional | [CX-0154][CX-0154] | +| CX-0155 | 1.0.1 | Describes the required data models and API usage for the Requirements Engineering Use Case | Mandatory | [CX-0155][CX-0155] | [CX-0154]: https://catenax-ev.github.io/docs/standards/CX-0154-MasterDataManagement [CX-0155]: https://catenax-ev.github.io/docs/standards/CX-0155-RequirementsEngineering diff --git a/docs-kits/kits/requirements-kit/development-view/development-view.md b/docs-kits/kits/requirements-kit/development-view/development-view.md index 59c7c1714e15..f8880dea6d9c 100644 --- a/docs-kits/kits/requirements-kit/development-view/development-view.md +++ b/docs-kits/kits/requirements-kit/development-view/development-view.md @@ -41,9 +41,9 @@ Software Developers, Solution Architects, Technical Leads, API Developers, Integ --- -### Core Components +## Core Components -#### Component 1: Requirement System +### Component 1: Requirement System **Purpose**: Core component responsible for requirement management at the data consumer or provider @@ -51,7 +51,7 @@ Software Developers, Solution Architects, Technical Leads, API Developers, Integ **Interfaces**: Typically ReqIF Export -#### Component 2: Eclipse Dataspace Connector (EDC) +### Component 2: Eclipse Dataspace Connector (EDC) **Purpose**: Facilitates contract negotiation and data exchange between partners in the data space @@ -59,7 +59,7 @@ Software Developers, Solution Architects, Technical Leads, API Developers, Integ **Interfaces**: Dataspace Protocol -#### Component 3: Digital Twin Registry +### Component 3: Digital Twin Registry **Purpose**: Stores and manages digital twin information @@ -141,9 +141,9 @@ The sequence diagram illustrates the requirement exchange flow between a Custome ## Standards Compliance | Standard | Version | Compliance | Description | -|----------|---------|------------|-------------| -| CX-0154 | 1.0.1 | Optional | Standard describing how to handle Master Data in Engineering. This includes parameters of | -| CX-0155 | 1.0.1 | Mandatory | Describes the required data models and API usage for the | +| ---------- | --------- | ------------ | ------------- | +| CX-0154 | 1.0.1 | Optional | Standard describing how to handle Master Data in Engineering. This includes parameters that are fulfilling requirements but also versions of model | +| CX-0155 | 1.0.1 | Mandatory | Describes the required data models and API usage for the requirement use case | ### Standard Details @@ -306,7 +306,7 @@ The sequence diagram illustrates the requirement exchange flow between a Custome **Key Properties**: | Property | Type | Required | Description | -|----------|------|----------|-------------| +| ---------- | ------ | ---------- | ------------- | | `requirementId` | string | Yes | UUID of the requirement | | `requirementStatus` | string | Yes | Requirements Status based on [https://www.prostep.org/fileadmin/prod-pay-download-8c1d/Recommendation_ReqIF_V2.2.pdf](https://www.prostep.org/fileadmin/prod-pay-download-8c1d/Recommendation_ReqIF_V2.2.pdf) | | `requirementInformation` | RequirementInformationEntity | Yes | Actual Requirement information with text, type meta data, author etc. | diff --git a/docs-kits/kits/requirements-kit/industry-extensions/automotive/Overview.md b/docs-kits/kits/requirements-kit/industry-extensions/automotive/Overview.md index 1741a4347e2a..09c65223f285 100644 --- a/docs-kits/kits/requirements-kit/industry-extensions/automotive/Overview.md +++ b/docs-kits/kits/requirements-kit/industry-extensions/automotive/Overview.md @@ -53,7 +53,7 @@ Adds: Catena-X standards, automotive semantic models, business processes, and po ## Catena-X Standards | Standard | Version | Description | Compliance | -|----------|---------|-------------|------------| +| ---------- | --------- | ------------- | ------------ | | CX-0001 | 2.0.0 | EDC Discovery API | Mandatory | | CX-0002 | 2.0.0 | Digital Twins | Mandatory | | CX-0018 | 3.0.0 | Dataspace Connectivity | Mandatory | From 1ef6ea0554161ee738b3d7944ec57db655fc8d9d Mon Sep 17 00:00:00 2001 From: "Marvin Manoury (FhG IPK)" <101739262+manourym@users.noreply.github.com> Date: Thu, 28 May 2026 13:46:50 +0200 Subject: [PATCH 09/10] Update docusaurus.config.js for local deployment --- docusaurus.config.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docusaurus.config.js b/docusaurus.config.js index 3cfb64fdc7fd..c5dff309bf41 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -10,7 +10,7 @@ const config = { title: 'Eclipse Tractus-X', tagline: '', url: 'https://eclipse-tractusx.github.io', - baseUrl: '/', + baseUrl: '/CX-KIT-development/', onBrokenLinks: 'throw', onBrokenAnchors: 'throw', favicon: 'img/logo_tractus-x-min.ico', From a9bf2b6c645feaed5b60dd0ef2f3e8a68db0605c Mon Sep 17 00:00:00 2001 From: "Marvin Manoury (Fraunhofer IPK)" Date: Thu, 28 May 2026 13:49:46 +0200 Subject: [PATCH 10/10] Revert "Update docusaurus.config.js for local deployment" This reverts commit 1ef6ea0554161ee738b3d7944ec57db655fc8d9d. --- docusaurus.config.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docusaurus.config.js b/docusaurus.config.js index c5dff309bf41..3cfb64fdc7fd 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -10,7 +10,7 @@ const config = { title: 'Eclipse Tractus-X', tagline: '', url: 'https://eclipse-tractusx.github.io', - baseUrl: '/CX-KIT-development/', + baseUrl: '/', onBrokenLinks: 'throw', onBrokenAnchors: 'throw', favicon: 'img/logo_tractus-x-min.ico',