Skip to content
Hardi Shah edited this page Jan 28, 2026 · 36 revisions

AAS TwinEngine Logo

DataEngine

Made by M&M Software Apache License

Welcome to the DataEngine Community!

DataEngine is a .NET-based service that dynamically generates complete Asset Administration Shell (AAS) structure by combining standardized templates with real-time data. It acts as an orchestration layer that transforms static AAS templates (from a template repository/template registry) into live, populated shells ready for visualization or API consumption.

  • DataEngine is compatible with AAS version 3.0.

What Is DataEngine For?

DataEngine is designed to act as the core orchestration layer in an AAS ecosystem. It serves UI applications and API consumers that need ready-to-use AAS shells, submodels, or submodel elements without manually assembling data from multiple sources. By abstracting template handling and data retrieval, DataEngine simplifies the consumption of AAS (Asset Administration Shell).

What Problem Does DataEngine Solve?

In a typical AAS setup:

  • Submodels are standardized but often contain static values embedded in AASX files or other exports.
  • Those static payloads cannot be changed dynamically at runtime, which makes them unsuitable for live scenarios.

DataEngine solves this by:

  • Automatically fetching submodel templates from repositories/registry.
  • Identifying required semanticIds/shells data.
  • Querying Plugin APIs for semanticId values, shells, assets.
  • Merging returned values into the template structure.

This removes the need for manual data mapping, reduces coupling between systems, and ensures consistent submodel generation.

Architecture Diagram

dataengine-home.png

What Design Principles Underlie DataEngine?

DataEngine is built on the following key principles:

  • Separation of concerns: Templates, data storage, and orchestration are clearly separated. DataEngine does not own data; Plugins do.
  • Standard alignment: All APIs and data structures align with IDTA and AAS specifications to ensure interoperability.
  • Template-first approach: The structure of submodels is always driven by standardized templates, not by data sources.
  • Extensibility: New Plugins, submodel types, or registries can be added without changing core logic.
  • Stateless processing: Each request is processed independently, enabling scalability and cloud-native deployments.
  • Multi-plugin readiness: Designed to support querying multiple Plugins and handling conflict resolution or fallback strategies. However, we recommend starting with a single-plugin approach for initial implementations.

Clone this wiki locally