Industrial Twin Lab

Technology Atlas

Possible implementation ecosystem — not a prescribed stack.

Architecture comes before product selection. Industrial connectivity, twin semantics, simulation, data systems, learning libraries, experiment tracking, local AI, infrastructure, and observability solve different problems and carry different operational burdens. A tool belongs only when it supports an explicit requirement and can preserve local operation, isolation, reproducibility, evidence, and maintainability.

Named technologies are candidates, not endorsements or fixed architecture decisions. They are not installed runtime capabilities of this static publication.

Candidate implementation ecosystem

  • Industrial Connectivity

    Candidate interfaces for industrial data access.

    • OPC UA
    • MQTT
    • Modbus
    • Historian connectors

  • Twin Semantics

    Candidate semantic foundations for twins.

    • Asset Administration Shell
    • Eclipse BaSyx
    • Domain ontologies

  • Simulation

    Candidate simulation and scientific-computing tools.

    • Modelica 3.7
    • OpenModelica
    • FMI 3.0
    • SSP 2.0
    • FMU
    • Python scientific computing

  • Data

    Candidate data formats, engines, and stores.

    • Parquet
    • DuckDB
    • Polars
    • TimescaleDB
    • InfluxDB
    • MinIO

  • Machine Learning

    Candidate machine-learning libraries.

    • scikit-learn
    • XGBoost
    • LightGBM
    • PyTorch

  • Experimentation

    Candidate experiment tracking and optimization tools.

    • MLflow
    • Optuna

  • Local AI

    Candidate locally operated AI capabilities.

    • Local LLM runtimes
    • RAG
    • Tool-using agents

  • Infrastructure

    Candidate runtime infrastructure.

    • Docker
    • Kubernetes
    • k3s

  • Observability

    Candidate observability tools.

    • Prometheus
    • Grafana
The map is a candidate catalogue for requirement-led evaluation. Inclusion does not endorse a product or fix an architecture decision.

For the fictional P-101 teaching asset, an OPC UA connector could provide controlled read-oriented access while an FMU represents selected pump behavior, Parquet preserves a versioned dataset, and MLflow records experiments. That is one possible composition, not a requirement and not evidence that any candidate is fit for production. Selection must consider failure modes, offline operation, attack surface, license and lifecycle risk, engineering competence, and the ability to reproduce a result after the original tool session has ended.

Modelica 3.7 (opens in a new tab)

is the language revision referenced by this publication, with clearer variability and improved unit and generated-FMU license handling.

SSP 2.0 (opens in a new tab)

addresses a different layer: packaging composite simulation architectures across FMI 3.0 and Modelica components. Their inclusion is a research prompt, not an endorsement. A package is useful here only if it preserves versions, parameters, interfaces, execution assumptions, and enough provenance to repeat the evidence across tools.

Local LLM runtimes and tool-using agents may support the AI Scientist, but language generation is not a substitute for a solver, a historian query, a validation protocol, or engineering judgment. Any multi-agent composition remains subordinate to a shared constraint hierarchy, deterministic validation, a complete audit trail, and named human authority. Kubernetes is not required merely because the architecture may one day scale. The least complex implementation that preserves the safety and evidence contracts is preferred.