Skip to content

Feature Overview

Kevalkumar edited this page Jan 23, 2026 · 1 revision

Core features

  • Template-driven submodel generation

    DataEngine does not create submodel structures. Instead, it always starts from a standardized submodel template retrieved from the Template Repository.

    • Templates define the structure of the submodel: idShorts, semanticIds, element hierarchy, and SubmodelElement types.

    • Templates intentionally contain no realtime values.

    • DataEngine guarantees that the returned submodel always conforms to the original template structure.

  • Plugin-based value resolution

    DataEngine relies on external Plugin APIs to resolve runtime data required for AAS responses.

    • For almost every request, DataEngine invokes one or more Plugin APIs to retrieve contextual data such as shell, asset, or submodel-related information.

    • JSON Schema generation is performed only for submodel and submodel element requests.

    For submodel and submodel element requests:

    • DataEngine analyzes the template structure and generates a JSON Schema that describes which semanticIds require values.

    • This schema is sent to one or more plugins.

    • Each plugin is responsible for:

      • Exposing an API compatible with submodel and submodel element structures

      • Mapping semanticIds to its internal data model

      • Querying its own data source

      • Returning values when available

DataEngine never accesses plugin databases directly and remains fully decoupled from plugin storage implementations.

  • IDTA-aligned endpoints

    All DataEngine endpoints are structured to align with IDTA AAS specifications.

    • This allows existing AAS tools and viewers to integrate with DataEngine without custom adapters
  • Support for SubmodelElement types

    DataEngine supports a broad range of SubmodelElement types and preserves their semantics during population:

    • Property

    • File

    • Blob

    • Range

    • MultiLanguageProperty

    • SubmodelElementCollection

    • SubmodelElementList

    • ReferenceElement

    • RelationshipElement

    • Entity

    Nested structures such as collections within collections or lists of complex elements are fully supported.

    Currently not supported SubmodelElement types

    The following SubmodelElement types are not currently supported by DataEngine:

    • AnnotatedRelationshipElement

    • Capability

    • BasicEventElement

    • EventElement

    • Operation

    These element types are not commonly used in most IDTA submodel templates today and are therefore not part of the current implementation scope.

    Support for additional SubmodelElement types may be added in future releases as adoption and use cases evolve.

  • Multi-plugin orchestration

    DataEngine supports orchestration across multiple Plugin APIs to resolve runtime data.

    • Each Plugin typically represents a specific data source or domain.

    • For a given semanticId, the value is expected to be provided by only one Plugin.

    • When multiple Plugins are available, DataEngine determines which Plugin to call based on: Plugin manifest responses

    • we recommend starting with a single-plugin approach for initial implementations.

    During request processing:

    • DataEngine identifies the relevant Plugin(s) for the requested data.

    • Plugin selection is performed before value resolution to avoid ambiguous or conflicting results.

    • DataEngine aggregates Plugin responses into a single, consistent result structure.

    This approach allows DataEngine to scale across multiple data providers while maintaining deterministic behavior and avoiding semantic conflicts.

  • Hierarchical & nested models

    Templates may define deeply nested submodel structures.

    • DataEngine builds a tree structure from the template

    • Plugin requests preserve hierarchy

    • Returned values are mapped back into the correct nested position

    This ensures complex real-world asset models can be represented accurately.

  • Pluggable repository & registry access

    DataEngine integrates with external AAS infrastructure components:

    • AAS Template Registry

    • AAS Template Repository

    • AAS Registry

    These integrations are pluggable and configurable, allowing different deployments or environments without changing DataEngine logic.

  • Scope and Capabilities

    DataEngine focuses on how standardized AAS templates are transformed into live, consumable submodels rather than why this transformation is needed (which is covered on the Home page).

    This page therefore emphasizes capabilities, behaviors, and supported features instead of reiterating problem statements.

Supported standards & integrations

DataEngine is designed to integrate seamlessly with established AAS tooling and industry standards, enabling interoperability across digital twin ecosystems.

Standards support

  • Asset Administration Shell (AAS) DataEngine supports AAS version 3.0 and adheres to the structural and semantic requirements defined by the specification. The implementation is designed to be forward-compatible with newer AAS revisions where possible.

  • IDTA specifications All API endpoints, request patterns, and response structures follow IDTA specifications. This ensures that DataEngine can be consumed by standard AAS tools, viewers, and platforms without requiring custom adapters.

Platform & framework integrations

Eclipse BaSyx

DataEngine integrates with Eclipse BaSyx components for:

  • AAS Template Registry

  • Template Repository

  • AAS Registry

These components are used exclusively for template and descriptor retrieval. They are treated as external, pluggable infrastructure and can be replaced or reconfigured without impacting the core DataEngine logic.

API & communication

  • REST / HTTP

    All interactions between clients, DataEngine, BaSyx components, and Plugins are performed using RESTful HTTP APIs.

  • JSON & JSON Schema

    JSON is used as the primary data exchange format for Plugin. JSON Schema is used for semanticId-based data requests when resolving submodel and submodel element values.

Clone this wiki locally