Source-linked AI summary
A Model-Centric DevOps Architecture for DEVS-Based Digital Twin Simulation Services
Arnis Lektauers, Gusts Linkevičs, Guntis Mosāns, Arina Fokina, Rasa Gulbe
TL;DR
The paper addresses limited lifecycle support for evolving DEVS simulation models in cloud-native environments. It proposes a model-centric DevOps architecture using declarative SMDL, formal multiPDEVS mapping, validation, versioning, and Kubernetes microservices, and validates the lifecycle with a Riga Route 22 case study reaching at least 776× real-time single-container throughput.
Problem
DEVS-based simulation models lack standardised versioning, automated validation, and CI/CD mechanisms for cloud-native lifecycle management.
Method
The architecture treats models as declarative YAML artefacts mapped to multiPDEVS and processed through CI/CD into immutable versions deployed by Kubernetes microservices.
Results
≥776× real-time single-container engine throughput was reported for the Riga Route 22 case study, which included roughly 47,870 atomic components.
Takeaways & Limitations
The case study demonstrates end-to-end configuration-only scenario evolution with structural and semantic validation before deployment.
Takeaways & Limitations
Evaluation is transport-only, while the approach is specific to multiPDEVS and assumes serialisable execution state.
Abstract
from arXiv · showhide
Digital twin simulation models are evolved and redeployed like software, yet DEVS-based engines offer a sound formal basis with little support for versioning, automated validation, or continuous delivery in cloud-native environments, leaving model lifecycle management ad hoc in most deployments. This paper proposes a model-centric DevOps architecture for deploying DEVS-based digital twin simulations as managed services. Simulation models are treated as first-class DevOps artefacts defined in a declarative YAML language with a formal mapping to multiPDEVS, supporting structural and semantic validation in a CI/CD pipeline that produces immutable versioned artefacts, so that reverting to an earlier validated version reduces to pinning its identifier. The platform is decomposed into containerised microservices on Kubernetes, with engine adaptations for state externalisation and lifecycle control. An initial case study on the Riga Route 22 public-transit corridor, the first instantiation of a planned city-wide multi-modal transport digital twin for Riga, Latvia, exercises the full lifecycle and reports single-container engine throughput for a scenario with roughly 47,870 DEVS atomic components; pipeline-level catch statistics and cluster-level concurrent multi-scenario execution are the subject of companion empirical studies.
1 Introduction
The paper addresses the gap between evolving DEVS simulation models and DevOps practices by proposing a model-centric architecture for managed digital-twin services.
- Digital twins use dynamic simulation, while DEVS provides a systems-theoretic basis for representing and predicting physical-system behaviour.
- Simulation models evolve like software but lack standardised automated validation, versioned deployment, and rollback mechanisms.
- Cloud-native deployment assumptions conflict with legacy DEVS engines that rely on persistent processes, direct file access, and manual configuration.
- The paper proposes a model-centric DevOps architecture for deploying DEVS-based digital-twin simulations as managed services.
- Its contributions include declarative SMDL and SSDL languages, cloud-native microservices, CI/CD with immutable artefacts, and an end-to-end Riga Route 22 case study.
- The work extends prior DEVS simulation-engine research by addressing operational lifecycle challenges in production cloud environments.
2 Background and Related Work
The background connects DEVS formal modelling with cloud-native simulation and identifies model lifecycle management as an unresolved DevOps concern.
- Digital twins represent physical systems through virtual counterparts, while DEVS formalises atomic and coupled models for discrete-event simulation.
- Simulation platforms increasingly use modular, containerised, orchestrated services, but many focus on deployment logistics rather than model management.
- Existing model-oriented DevOps work does not yet provide widely adopted declarative specification, structural and semantic validation, and CI/CD across cloud lifecycles.
- The related-work comparison evaluates solutions across the dimensions addressed by the proposed architecture, distinguishing full, partial, and absent support.
- The paper responds to this gap through a declarative language, cloud-native architecture, and CI/CD pipeline that bind model representation to deployment.
3 Model-Centric Representation and Lifecycle
The model-centric lifecycle represents DEVS models declaratively in YAML, maps them to multiPDEVS, validates them before runtime execution, and versions them for reproducibility.
- 3.1 YAML-Based Model Definition Language: SMDL defines DEVS models in human-readable YAML that supports version control and validation without invoking a simulation runtime.
- 3.1 YAML-Based Model Definition Language: The SMDL metamodel organises YAML documents that the processor transforms into multiPDEVS tuples, with well-formedness checks forming the first validation layer.
- 3.1 YAML-Based Model Definition Language: Scenario manifests declare data sources, parameters, iterative replanning, scoring, convergence settings, and output formats independently of engine-internal classes.
- 3.2 Mapping to DEVS: SMDL maps coupled and atomic YAML blocks to multiPDEVS tuples, while the engine processor instantiates the corresponding DEVS elements.
- 3.2 Mapping to DEVS: The mapping uses multiPDEVS with X-Machines as the component memory structure, including component references, states, events, and transition functions.
- 3.3 Validation and Versioning: Validation checks syntax, schema conformance, coupling references, closure, uniqueness, class availability, and parameter ranges before deployment.
- 3.3 Validation and Versioning: Semantic versioning distinguishes parameter patches, backward-compatible minor additions, and interface-breaking major changes, preserving reproducibility through exact version selection.
4 Cloud-Native Simulation Architecture
The cloud-native architecture separates model management, execution, data integration, and results streaming into Kubernetes microservices connected through REST and Kafka.
- The platform comprises Model Management, Simulation Execution, Data Integration, and Results and Streaming service layers.
- Model Management stores, versions, validates, and retrieves simulation model definitions, while Simulation Execution manages engine-run lifecycles.
- Each layer is implemented as containerised microservices on Kubernetes, using REST for synchronous requests and Kafka for event-driven workflows.
- Data Integration ingests IoT, API, database, and batch data, normalises events, and publishes them to Kafka for buffering, replay, and decoupling.
- The reference deployment uses a GitLab-hosted container registry and Kubernetes Secrets with namespace-level RBAC.
5 DevOps Pipeline for Simulation Models
The pipeline separates model development from simulation consumption by validating repositories, publishing immutable versioned artefacts, and assembling executable scenario jobs. Published models are bound to declarative scenarios, dispatched through messaging, and materialised as Kubernetes workloads with independent storage, result, and cleanup services.
- 5.1 Model Publishing and Registration: The model-management layer combines a registry and publishing worker, while the execution layer uses an API and orchestrator to manage projects, scenarios, experiments, and jobs.These services cooperate across the model-management and simulation-execution layers.
- 5.1 Model Publishing and Registration: Validated repositories are registered by (code, version), then published as immutable, version-scoped artefacts before entering the simulation workflow.Publication is idempotent, and earlier releases remain immutable in the catalogue and object storage.
- 5.2 Scenario Assembly and Job Dispatch: SSDL organises execution as Project → Scenario → Experiment, binding registered SMDL model versions to parameters, datasets, replications, and optional parameter sweeps.The generated document resolves the model locator and expands scenario experiments in place.
- 5.2 Scenario Assembly and Job Dispatch: For each selected scenario, the API generates and uploads a versioned SSDL document, creates a SimulationJob, and dispatches immutable references for orchestration.The dispatch message carries the job identifier plus scenario, model, and optional dataset URLs.
- 5.3 Simulation Execution: The orchestrator renders job-specific Kubernetes specifications, supports S3 or shared-volume storage, and provides a uniform engine entry point across deployment targets.Resource names are suffixed with job identifiers to support uniqueness across concurrent runs.
- 5.3 Simulation Execution: Callbacks and Kafka events return results and lifecycle information, while a cleanup worker reconciles failed Kubernetes jobs to prevent leaked resources.Result callbacks include payload metadata, larger-artefact URLs, content types, byte sizes, and SHA-256 checksums.
6 Case Study and Evaluation
The Riga Route 22 case study exercises the proposed DEVS architecture end to end, from hierarchical transport modelling and declarative scenario configuration through Kubernetes execution and evaluation. The 24-hour run preserves the empirical demand profile and completes in substantially less than real time, while performance measurements remain single-container results.
- 6.1 Application Context: The scenario is configured through YAML using 23,868 directed road segments, 4 transit line directions, 65 stops, 392 departures, and 24,314 traveler demands.Transit demand contains 12,314 synthetic travelers from e-ticket validations, while car demand contains 12,000 synthetic trips.
- 6.2 DEVS Model Architecture: The hierarchical model couples per-segment road links and intersections inside TransportNetworkModel, while TransportModel adds transit stops, traveler and vehicle sources, and sinks.Six atomic model types are used, with classic Parallel DEVS selected for the sparse FIFO road-traffic pipeline.
- 6.4 Cloud Deployment: Each selected scenario runs as an isolated Kubernetes job whose engine container retrieves model artefacts, returns results through REST, and streams progress and lifecycle events through Kafka.The execution design supports horizontal scaling of concurrent scenarios at the cluster level.
- 6.5 Simulation Results: 18,542 of 24,314 generated travelers reach their destinations within 24 hours, including 61.8% of car trips and 90.3% of transit trips.Transit OD pairs follow the same line direction, while most unserved car trips are late-evening departures that exceed the horizon.
- 6.5 Simulation Results: Arrival curves follow the empirical daily demand profile with mode-specific median-travel-time lags, preserving demand structure end to end.The run is sub-capacity: at most three links are simultaneously congested, and 92 links, or 0.39% of the network, reach the congestion threshold.
- 6.6 Engine Performance: Runtime grows approximately linearly with demand at 2.3 ms per additional traveler, with a 22 s fixed baseline for startup, loading, and construction of 47,870 atomic models.The 24,314-traveler baseline completes in 74 s at approximately 1,170× real time, while tested configurations span 51–111 s and 776–1,684× real time.
7 Discussion
The discussion links the architecture’s formal and lifecycle claims to validation, immutability, and an initial transport case study, while delimiting the evidence by application, engine, runtime, and evaluation scope.
- ≥776× real-time throughput was measured across the demand sweep in a single-container Route 22 case study.The largest tested configuration kept a 50-iteration equilibration loop within roughly one minute of wall-clock per iteration.
- SMDL conformance is decidable without runtime invocation through a tuple-level mapping to multiPDEVS and three derived well-formedness conditions.The argument supports the CI/CD design but does not claim mechanised proof.
- The architecture’s closest comparison, DEVSML 3.0, lacks CI/CD lifecycle support, versioned artefacts, and deep semantic validation.Table 1 also positions xDEVS and cloud-native digital-twin platforms as related but incomplete alternatives on these dimensions.
- Evaluation remains bounded to transport, multiPDEVS, serialisable execution state, and a single city, corridor, engine, and cloud runtime.Extending the approach to multi-formalism simulation or pointer-rich non-serialisable state requires additional abstraction.
- Pipeline catch statistics and cluster-level concurrent multi-scenario measurements are deferred to companion studies rather than reported here.Those studies target validation coverage, catch distribution, startup, concurrency, and event-stream latency under Kubernetes conditions.
8 Conclusion and Future Work
The paper concludes with a Kubernetes-based model-centric DevOps architecture and an initial Riga Route 22 validation, then identifies empirical, scaling, and methodological extensions.
- The architecture treats YAML-based SMDL models as versioned DevOps artefacts mapped formally to multiPDEVS and deployed through validated CI/CD workflows.Containerised Kubernetes microservices use immutable object-storage artefacts, environment-injected metadata, REST callbacks, and Kafka lifecycle events.
- The Route 22 case study handled roughly 47,870 atomic components with schedule-aware multi-modal routing and iterative equilibration with convergence detection.Scenario configuration changed network, transit, replanning, and scoring parameters without engine-code changes, with structural and semantic validation before deployment.
- Immediate empirical work will measure pipeline catch statistics and concurrent multi-scenario orchestration under realistic Kubernetes conditions.The planned measurements include container startup and event-stream latency.
- Future application work will scale the corridor model toward a city-wide Riga transport twin and evaluate further domains and hybrid DEVS/DESS support.Planned extensions also include live bus-location feeds and ML-based parameter calibration in the CI/CD pipeline.