Architecture

This document explains the core concepts of DataEngine, how it interacts with template services and the Plugin, and how the four AAS-aligned APIs (AAS Registry, AAS Repository, Submodel Registry, Submodel Repository) work together.

---

High-Level Idea

DataEngine is a .NET-based API that dynamically generates complete Asset Administration Shell (AAS) submodels.

It does this by:

• Fetching submodel templates (without values) from a template AAS environment.
• Requesting values for semantic IDs from a separate Plugin API using a JSON Schema–based contract.
• Filling those values into the template and returning a fully populated, IDTA-compliant submodel to the caller.

DataEngine’s HTTP endpoints are designed to follow the IDTA / AAS specification structure:

• When a user asks for a shell descriptor, shell, submodel descriptor or submodel / submodel element, the URL structure and payloads are aligned with the AAS standard.

---

Architecture Overview

Component Roles

• AAS Viewer / UI: Visualizes AAS, shells, submodels and submodel elements for users.
• API Gateway: Single entry point (e.g. Nginx) that forwards HTTP calls to DataEngine.
• DataEngine: Core service that exposes AAS-aligned endpoints and orchestrates templates + plugin data.
• Plugin: Separate API that holds / accesses the actual values (in Plugin DB) and responds to DataEngine with data according to JSON Schema.
• Plugin DB: Database storing the real submodel/submodel-element values.
• Template Registry / Template Repo: Provide template shells/submodels and registry information that DataEngine uses as the structural basis.

---

Request Processing Flow (Submodel Example)

1. Client request

   • User (via UI or API client) calls a Submodel Repository endpoint on DataEngine, e.g. GET /submodels/{submodelId}.

2. Template retrieval

   • DataEngine resolves which template AAS / submodel must be used.
   • It calls the template AAS environment / template submodel repository to fetch the template submodel.
   • This template contains semantic IDs but no values.

3. JSON Schema request to Plugin

   • DataEngine builds a JSON Schema representing the semantic IDs and expected structure.
   • It sends a request to the Plugin API containing:
     • Which submodel / submodel elements it needs.
     • The semantic IDs and structure as JSON Schema.

4. Plugin logic + DB

   • Plugin checks its Plugin DB for values corresponding to those semantic IDs.
   • If values exist, Plugin returns them in a JSON structure that matches the agreed schema.

5. Template filling

   • DataEngine validates the Plugin response against the JSON Schema.
   • It fills the values into the previously fetched template submodel.

6. Response to client

   • DataEngine returns a fully populated AAS submodel that is ready to be consumed by UIs or other APIs.

Plugin Responsibilities

• Plugin is a separate API maintained for data.
• It:
  • Exposes an HTTP API that follows the JSON Schema contract provided by DataEngine.
  • Describes its database structures as JSON Schema (for submodels and submodel elements).
  • Stores the actual values in Plugin DB.
• TwinEngine team provides the schema and contracts for the Plugin, not the data itself.