A Model-Centric DevOps Architecture for DEVS-Based Digital Twin Simulation Services Arnis Lektauers1*† , Gusts Linkevičs1† , Guntis Mosāns1 , Arina Fokina1 , Rasa Gulbe2
arXiv:2609.11122v1 [cs.SE] 10 Sep 2026
1*
Institute of Information Technology, Riga Technical University, Zunda Embankment 10, Riga, LV-1048, Latvia. 2* Dati Group Ltd., Balasta dambis 80A, Riga, LV-1048, Latvia.
*Corresponding author(s). E-mail(s): [email protected]; Contributing authors: [email protected]; [email protected]; arina.fokina [email protected]; [email protected]; † These authors contributed equally to this work. Abstract 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. Keywords: digital twin, DEVS, model-driven engineering, domain-specific modelling language, cloud-native architecture, DevOps, CI/CD, simulation model lifecycle
1
1 Introduction Digital twins are now used across engineering domains for continuous monitoring, prediction, and optimisation of physical systems through their virtual counterparts [1, 2]. Most implementations rely on dynamic simulation to let the virtual model reproduce and predict system behaviour under varying conditions. Among formal frameworks, the Discrete Event System Specification (DEVS) [3] offers a systems-theoretic basis for modelling such systems. DevOps practices, on the other hand, have reshaped software delivery through continuous integration and deployment (CI/CD) pipelines [4], yet their application to simulation model lifecycle management remains largely unexplored. Simulation models evolve iteratively like software, but lack the standardised mechanisms for automated validation, versioned deployment, and rollback that DevOps pipelines provide elsewhere. Many digital twin implementations are still built ad hoc [5], and most DEVS engines (surveyed in Section 2) were built for desktop or cluster execution with persistent processes, direct file system access, and manual configuration. These assumptions clash with cloud-native deployment, where containers are ephemeral, scaling is horizontal, and infrastructure is declared as code. This paper presents a model-centric DevOps architecture for deploying DEVSbased digital twin simulations as managed services. The contributions are: 1. A declarative YAML-based Simulation Model Definition Language (SMDL) for DEVS simulation models with a formal mapping to the multiPDEVS formalism [6], and a companion Simulation Scenario Definition Language (SSDL) for scenario parameterisation, enabling version control, automated validation, and CI/CD integration (Section 3). 2. A microservices-based cloud-native architecture with engine adaptations for state externalisation and lifecycle control, letting a classical DEVS simulator operate as a cloud-native workload while keeping model management, execution, and data integration independently deployable (Sections 4 and 5). 3. A CI/CD pipeline for simulation models with structural and semantic validation, staged deployment, and immutable versioned artefacts that support reverting by pinning an earlier validated version (Section 5). 4. An initial case study on the Riga Route 22 bus corridor, the first instantiation of a planned city-wide multi-modal transport digital twin for Riga, Latvia, that exercises the end-to-end lifecycle, quantifies single-container engine throughput, and demonstrates configuration-only evolution of a multi-modal scenario without engine-code changes (Section 6). Section 7 then maps each contribution to the evidence that supports it and to the companion studies that will extend it. The work extends our prior research on DEVSbased simulation engines for digital twins [7] by addressing the operational lifecycle challenges of running such engines in production cloud environments.
2
2 Background and Related Work This section surveys the two bodies of work on which the paper builds: the DEVS formalism and its simulation engines, and the state of cloud-native simulation and DevOps for models. Table 1 summarises where existing solutions stand on the dimensions our architecture addresses.
2.1 Digital Twins and DEVS Simulation The digital twin concept, introduced by Grieves [1], describes a virtual representation of a physical system with bidirectional data flow between the physical and digital spaces. Tao et al. [2] formalise a five-dimensional model of physical entity, virtual entity, services, data, and connections, and the survey by Fuller et al. [8] maps the enabling technologies. DEVS [3] defines atomic models with states, input/output ports, and transition functions, together with coupled models that compose atomic models via port couplings. multiPDEVS [6] extends Parallel DEVS to multicomponent systems with nonmodular decomposition and efficient handling of simultaneous events. Mature engines surveyed by Wainer and Govind [9] include ADEVS [10], CD++ [11], VLE [12], PyPDEVS [13], and xDEVS [14], complemented by graphical authoring (DEVSSuite [15]) and DEVS-based co-simulation wrappers (MECSYCO [16]). The suitability of DEVS for digital twins has been recognised in the context of digital quadruplets [5], and Vanommeslaeghe et al. [17] demonstrate co-simulation with Functional Mockup Interface (FMI). Our work builds on a multiPDEVS engine [7] that supports hierarchical composition with Parallel DEVS semantics.
2.2 Cloud-Native Simulation and DevOps for Models Simulation engines have shifted from monolithic designs toward modular [18], containerised, and orchestrated services [19]. Simulation services are increasingly exposed as microservices [20, 21] and deployed through orchestrators such as Kubernetes [22, 23], which improves scalability and manageability for digital twin and cyber-physical workloads. Current digital twin platforms adopt stateless, cloud-native, service-based architectures [24]. Such frameworks support scalable data integration and distributed execution, but they concentrate on deployment logistics rather than model management (see Table 1). Closing the gap between deployment and model management requires automated model lifecycles. In software development, process automation is now routine practice [25], yet model management still lags behind [26]. CI/CD practices in software and AI development provide versioning, staged validation, delivery, monitoring, and rollback, and DevOps and Machine Learning Operations (MLOps) tooling is gradually extending these capabilities to models [25, 27]. For simulation software, prior work on GitLab-based CI/CD for large-scale simulation software [28] and DevOps models for metadata-driven tools [29] shows that simulation code and metadata can be integrated into automated pipelines [30, 31]. Simulation models themselves, however, are not yet consistently treated as first-class DevOps artefacts and still lack
3
widely adopted approaches for declarative specification, structural and semantic validation, and CI/CD across their cloud lifecycles. Recent work on DevOps, model-driven engineering (MDE), and MLOps highlights this gap [30–32]. Complementary work on digital twin programming with semantically lifted states [33] ties runtime data to ontologies and formal specifications, reinforcing the case for treating twin models as structured, queryable artefacts rather than opaque binaries. Table 1 Comparison of related works and solutions across the dimensions addressed by the proposed architecture. full support, # G partial, # none. Solution CloudSim [20, 21] PerfSim [22] Stoja et al. [19] Modelica DT [24] xDEVS [14, 34] DEVSML 3.0 [35] KTWIN [23] Proposed (§3–5) Approach
Simulation Cloud- Model Declarative Formal Semantic Versioning/ Digital-twin support native CI/CD spec. semantics valid. rollback focus G # # G
#
# G
# # # # # # #
# G # #
#
# # # #
# # # # # # G #
# # # # # # #
# # #
# #
The rest of the paper closes this gap: Section 3 introduces the declarative language and its formal mapping, Section 4 describes the cloud-native architecture that hosts them, and Section 5 details the CI/CD pipeline that binds the two.
3 Model-Centric Representation and Lifecycle A central design principle of our architecture is treating simulation models as versioncontrolled artefacts with a well-defined lifecycle. This section describes the declarative model definition language, its mapping to the DEVS formalism, and the validation and versioning strategy.
3.1 YAML-Based Model Definition Language We introduce a Simulation Model Definition Language (SMDL) based on YAML that specifies DEVS simulation models in a human-readable, version-controllable format. The language draws on the declarative style of Microsoft’s Digital Twins Definition Language (DTDL) [36] and shares the MDE stance of DEVSML 3.0 [35]; the YAML concrete syntax is chosen because it produces line-oriented Git diffs and is validated by the same CI tooling used for container manifests, without invoking a simulation runtime. The language supports atomic models, coupled models, port specifications, couplings, and simulation parameters, and covers both fully declarative models (behaviour configured through parameters of pre-built classes) and hybrid models (behaviour implemented in code and referenced by class name). Figure 1 summarises the abstract syntax as a class diagram, with the well-formedness constraints integrated into the CI/CD pipeline in Section 3.3. 4
ports
Model 1 + name: Identifier + description: String[0..1] + version: SemVer[0..1]
Port
*
+ name: Identifier + valueType: TypeRef
* components
AtomicModel
CoupledModel
InputPort
1
OutputPort
+ state: ControlState + memory: Memory + deltaInt(), deltaExt() + deltaCon() + lambda(), ta()
Fig. 1 SMDL abstract syntax metamodel. YAML model documents conforming to this metamodel are transformed by the SMDL Processor into multiPDEVS tuples (Eqs. 1–2); its well-formedness checks form the first validation layer (Section 3.3).
Listing 1 shows the top-level structure of the manifest used in the transport case study (Section 6). The manifest declares data sources, simulation parameters, the iterative replanning loop, and the scoring function without referencing engine-internal classes, keeping scenario specification independent of engine implementation. Listing 1 Top-level structure of the Riga Route 22 scenario manifest. network : transit : demand :
{ source : geoparquet , path : .../ segments . parquet } { lines : ... , schedules : ... , stops : ... } { path : .../ demand . parquet }
simulation : horizonHours : 24.0 network : { d e f a u l t S p e e d L i m i t K p h : 50.0 , s a t u r a t i o n F l o w V e h P e r H o u r P e r L a n e : 1800.0 } transit : { d e f a u l t D w e l l T i m e S e c o n d s : 30.0 } iteration : enabled : true maxIterations : 50 co nve r g e n c e W i n d o w : 5 c o n v e r g e n c e M e a n T o l e r a n c e : 0.02 w ei gh t U p d a t e M e t h o d : MSA replanning : { route : 0.30 , mode : 0.10 , timeShift : 0.20 } scoring : m a r g i n a l U t i l i t y O f T r a v e l T i m e P e r H o u r : -6.0 modeConstants : { car : 0.0 , transit : -0.5 } output :
{ directory : results / riga - route22 , formats : [ parquet , csv ] }
3.2 Mapping to DEVS SMDL is a domain-specific modelling language whose semantic domain is the multiPDEVS formalism of Eqs. (1)–(2); the SMDL Processor realises a model-to-model transformation from the abstract syntax (Figure 1) into this domain. A YAML document conforms to the metamodel iff it passes the structural validation of Section 3.3; semantic validation then checks that the transformed multiPDEVS instance satisfies the formalism’s invariants. Separating the artefact from its semantic domain is what
5
lets the pipeline stages of Section 5 run without a simulation runtime: conformance is a structural property of the model artefact, not of an engine execution. The SMDL Processor translates a YAML model definition into the internal multiPDEVS [6] representation used by the simulation engine, following the Modelling and Simulation as a Service (MSaaS) paradigm [7]. Figure 2 shows the engine architecture: the SMDL Processor parses the model specification and constructs instantiated DEVS elements, the Simulation Manager coordinates execution with correct timing and event ordering, and an FMI adapter supports co-simulation with external Functional Mock-up Units [17, 37]. A Hierarchical Engine for Large-scale Infrastructure Co-Simulation (HELICS) broker [38] further connects the engine to multi-domain federates for scalable cyber-physical co-simulation scenarios.
..
www Digital Twin Platform
Web API
Modelling and Simulation as a Service (MSaaS) WebSocket / Kafka
REST API
Simulation Engine Federate
Simulation Server
HELICS Co-Simulation Broker
Simulation Manager
... Federate
Simulation Model / Scenario Definition Language (SMDL / SSDL) Processor
External Simulation Models Simulator
Federate Service
Functional Mock-up Interface (FMI)
Model
Model
Solver
Solver
Slave
FMI Adapter Master
...
Slave
Fig. 2 Simulation engine MSaaS architecture. The engine exposes REST, WebSocket and Kafka APIs, processes SMDL model definitions, and supports co-simulation via the FMI adapter. Adapted from [7], © 2025 IEEE.
We formalise the mapping target using the multiPDEVS formalism of [6], with XMachines [39] providing the component memory structure as adopted in the engine design of [7]. A multiPDEVS model is a tuple multiPDEVS = (X, Y, D, {Md | d ∈ D}),
(1)
where X and Y are the sets of input and output events and D is the set of component references. Each atomic component Md is defined as
Md = (Sd , Md , Id , Ed , δext,d , δint,d , δcon,d , δreac,d , λd , tad ),
6
(2)
where Sd is a finite set of control states, Md is an explicit memory structure, Id ⊆ D is the set of influencing components, and Ed ⊆ D is the set of influenced components. The time advance tad , the output function λd , and the four transition functions (internal δint,d , external δext,d , confluent δcon,d , and reaction δreac,d ) operate over the product of total states of the influencing components, where each total state has the form (s, e) with s ∈ Si and 0 ≤ e ≤ tai (s) for e the elapsed time since the last transition. Separating the control state Sd from the memory Md admits compact state-machine representations for components with few control states but rich local context, such as agents that carry attributes, history buffers, or physical variables [7]. The SMDL Processor translates each YAML block into tuples of the form of Eq. (1) and Eq. (2). Each YAML coupled block is mapped to a tuple of the form of Eq. (1), with D drawn from its components: list, X and Y drawn from its ports: section, and the couplings compiled from its couplings: specification. Each YAML component of type atomic is mapped to a tuple of the form of Eq. (2). For fully declarative components, the YAML populates the control-state part Sd together with parameterdriven transition rules; for hybrid components, a class reference supplies the memory part Md and the code that implements the transition and output functions against it. This split matches the two authoring modes supported by the language (Section 3.1). Three well-formedness checks read directly from the tuple components and form the structural layer of the validation strategy of Section 3.3: (i) every coupling reference must resolve to a port declared in the X or Y of a component in D; (ii) the couplings must satisfy closure under coupling, so that X and Y of the parent tuple correspond exactly to the external ports left after hiding internal couplings; (iii) component names within D must be unique.
3.3 Validation and Versioning Each model definition is versioned using semantic versioning (major.minor.patch): patch for parameter adjustments that do not alter model structure, minor for backward-compatible additions of new components or ports, and major for interfacebreaking structural changes. The Model Management Layer maintains a full history of deployed model versions, enabling reproducibility of past simulation results by specifying exact model versions in execution requests. Validation occurs at two levels. Structural validation checks YAML syntax and conformance against the SMDL JSON Schema, catching missing fields, type mismatches, and invalid values. Semantic validation ensures DEVS formalism compliance: port existence in coupling references, closure under coupling (no algebraic loops), component name uniqueness, model class availability, and parameter range constraints. Both validation levels are integrated into the CI/CD pipeline (Section 5).
4 Cloud-Native Simulation Architecture The platform is organised into four service layers, summarised as a C4 component view in Figure 3: 1. Model Management Layer: storage, versioning, validation, and retrieval of simulation model definitions. 7
«app» Simulation Web [React SPA] Manage projects, runs; visualize outcomes
Manages projects, start/stop runs
«app» Simulation API [FastAPI] Projects, scenarios, runs, results
Push WS/SSE real-time updates
«app» Simulation Real-time Hub [Python, Websockets] Fan-out live run events to SPA via WS/SSE
Posts control commands
Posts simulation results
Enqueues simulation (idempotent)
«app» Simulation Orchestrator [Python, Worker] Orchestrates runs; requests K8s resources
Stores run metadata and results index
Reads simulation queue
«platform» RabbitMQ Cluster [RabbitMQ]
«platform» Kafka Cluster [Kafka]
Consume sim.run.* by runId
Emits sim.run.* events
«platform» PostgreSQL [PostgreSQL]
«app» Simulation Engine [Kotlin] Executes simulation runs
Sends K8s resource request
«platform» S3 / Swift [Object storage]
Sends simulation to external tool
Uploads artifacts / downloads snapshots
«external» External Simulation Tool [AnyLogic, Simulink, ...]
Schedules/starts per-run job
«platform» Kubernetes Cluster [Kubernetes]
Fig. 3 Platform architecture (C4 component view). The four service layers (Model Management, Simulation Execution, Data Integration, and Results/Streaming) are deployed as containerised microservices on Kubernetes, communicating via REST for request–response interactions and Apache Kafka for event-driven workflows.
2. Simulation Execution Layer: lifecycle management of simulation runs, including instantiation, execution, and termination of DEVS simulation engine instances. 3. Data Integration Layer: real-time data ingestion from physical systems and external data sources, feeding live data into running simulations. 4. Results and Streaming Layer: collection of simulation outputs and streaming of results to consuming services, dashboards, and analytics pipelines. Each layer is realised as one or more containerised microservices on Kubernetes. Services communicate through synchronous REST APIs for request-response interactions and through Apache Kafka for event-driven workflows.
4.1 Data-Path Services Section 5 details the services that implement the Model Management and Simulation Execution layers. The two remaining layers carry the live data flow. The Data Integration Service ingests real-time data from Internet-of-Things (IoT) sensors over the Message Queuing Telemetry Transport (MQTT) protocol, external APIs, databases, and batch files, normalising each event into a canonical format compatible with DEVS external inputs and publishing it to Kafka for buffering, replay, and consumer decoupling. The Results Streaming Service delivers simulation outputs over WebSocket streams (dashboards), Kafka topics (analytics), InfluxDB (historical analysis), and REST (on-demand retrieval); results are tagged with run identifiers, model versions, and timestamps for traceability.
8
The reference deployment uses a GitLab-hosted container registry and Kubernetes Secret objects with per-namespace role-based access control (RBAC).1
5 DevOps Pipeline for Simulation Models Within the layered architecture of Section 4, the simulation DevOps pipeline is realised by four cooperating services that refine the Model Management and Simulation Execution layers: a Simulation Model Registry (FastAPI + PostgreSQL) and a Simulation Model Publishing worker together implement the Model Management layer by cataloguing models and ingesting model repositories, while a Simulation API manages projects, scenarios, experiments, and jobs and a Simulation Orchestrator materialises each job as a Kubernetes workload, together implementing the Simulation Execution layer. Two messaging systems decouple the stages: RabbitMQ carries point-to-point work items (publish, delete, dispatch) that must be consumed by exactly one worker, while Kafka carries progress and lifecycle events that are fanned out to multiple interested listeners such as the UI, monitoring, and result archival. An S3-compatible object store holds all binary and YAML artefacts.
5.1 Model Publishing and Registration Each simulation model is authored in a dedicated Git repository that follows a standardised layout centred on a manifest.yaml describing metadata, component sources, inputs, outputs, parameters, and runtime requirements. A repository-level CI pipeline validates the manifest against the platform schema and triggers registration via the Simulation Model Registry API, which creates a catalogue entry keyed by (code, version ) and enqueues a publish message on a dedicated RabbitMQ queue. The publishing worker consumes the message, clones the repository at the requested revision, resolves each component path reference in the manifest to a versionscoped object-store URL, and uploads the processed manifest, the model payload, and documentation under that prefix. On success, the registry record is marked published and the canonical artefact URLs are persisted; on failure, the record is marked failed and the original message is discarded rather than retried, forcing operators to correct the source and re-publish under a new version. Publication is idempotent with respect to (code, version ) identifiers: earlier releases remain immutable in both the catalogue and object storage, which underpins reproducibility of downstream experiments. Deletion propagates through a parallel RabbitMQ queue that cascades cleanup to dependent services. Figure 4 summarises this pre-runtime stage, which separates model development from consumption: researchers evolve models in isolation, and only validated, immutable versions enter the simulation workflow. 1 A more extensive supporting stack (Harbor, Istio, Prometheus/Grafana, Vault) is compatible with the architecture but is not part of the configuration evaluated here.
9
Model Developer
Git Repository
Repository CI
Simulation Model Registry API
Registry DB (PostgreSQL)
RabbitMQ publish queue
Publishing Worker
Object Store (S3)
push model + manifest.yaml (tag version) trigger pipeline validate manifest against schema POST /models (code, version, repo ref) insert entry (publish_status = processing) enqueue publish message (code, version, repo ref) 202 Accepted deliver message clone at revision rewrite manifest paths path -> s3Url (s3://bucket/{code}/{version}/...) upload manifest.processed.yaml upload model payload + README under {code}/{version}/ alt
[success]
PATCH /models/{id} (status = published, S3 URLs) update entry [failure]
PATCH /models/{id} (status = failed) update entry
Model Developer
Git Repository
Repository CI
Registry DB (PostgreSQL)
Simulation Model Registry API
RabbitMQ publish queue
Publishing Worker
Object Store (S3)
Fig. 4 Publishing flow of a simulation model: from Git push and CI validation to versioned S3 artefacts and a published registry entry.
5.2 Scenario Assembly and Job Dispatch Consumption of a published model proceeds through three entities persisted by the Simulation API: a SimulationProject groups related work, a Scenario binds a registered model version to a concrete parameterisation and an optional dataset, and an Experiment defines a parameter sweep over its parent scenario. Figure 5 summarises the resulting structure and its binding to SMDL model artefacts via ModelRef. When the user triggers execution, the API gateway accepts a selection at any granularity (full project, subset of scenarios, or individual experiments) and, for each selected scenario, performs three atomic steps. First, it generates a Simulation Scenario Definition Language (SSDL) document. SSDL is a declarative companion to SMDL: where SMDL answers what the model is and how it behaves, SSDL answers under which configurations and execution conditions the model is evaluated, organising runs into a three-level Project → Scenario → Experiment hierarchy that binds registered SMDL model versions to concrete parameterisations, datasets, and sweep definitions. The generated SSDL document inlines the project metadata, the resolved model locator from the registry, and the 10
SSDL
SMDL
Project
1..*
Model
1..*
id name modelScope
ModelRef id version alias tags
Scenario
id version tags Model Definition
1
model Parameters Replications
0..*
Experiment Parameters Replications
Fig. 5 SSDL structure. A Project groups Scenarios; each Scenario binds a SMDL Model version via a ModelRef with parameters and replications; optional Experiments refine a scenario with a parameter sweep.
scenario configuration with its experiments expanded in place. Second, it uploads the document to a version-scoped object-store path so that the engine receives a selfcontained, versioned input. Third, it creates a SimulationJob record and publishes a dispatch message on a RabbitMQ queue carrying the job identifier and the scenario, model, and optional dataset URLs, so that exactly one orchestrator worker picks up the job. This separation keeps the API responsible for what to run and the orchestrator responsible for where and how to run it, matching the C4 decomposition in the platform architecture. Because the dispatched message carries only immutable S3 references and identifiers, it is safe to redeliver, and the engine execution is fully reconstructable from the persisted SSDL document together with the referenced model version.
5.3 Engine Adaptations for Cloud Deployment The Simulation Orchestrator turns each dispatch message into a concrete Kubernetes workload by rendering a base engine manifest retrieved from object storage into a jobspecific specification: resource names are suffixed with the job identifier for uniqueness across concurrent runs, the job metadata is injected as environment variables, and the resulting Service and Pod (or Job) specifications are applied through the Kubernetes API. The engine container exposes a predictable in-cluster DNS service address that the orchestrator writes back to the SimulationJob record, providing a stable anchor for control operations and for log and metric scraping. To support heterogeneous deployment targets, the orchestrator operates in one of two storage modes: S3 mode passes object-store URLs and credentials directly to a stateless engine pod, while local mode pre-fetches artefacts to a shared persistent volume for environments where object-store egress is expensive. A uniform engine entry point abstracts over the distinction.
11
The engine reports progress and results through a pull-style callback rather than a shared database coupling. On termination it posts the result payload, an object-store URL for larger artefacts, a content type, a byte size, and a SHA-256 checksum to the Simulation API, which attaches the record to the originating experiment. Lifecycle and progress events (engine ready, iteration progress, failure, deletion) are additionally published to a Kafka topic so that independent consumers (UI, monitoring, result archival) can subscribe to the same stream in near real time. Finally, the orchestrator runs a dedicated cleanup worker that periodically reconciles the Kubernetes state with the Simulation API. Jobs that remain in the ERROR state beyond a configurable threshold have their Kubernetes resources explicitly deleted, which decouples resource reclamation from engine execution timeouts and prevents leaks when a pod crashes before its own cleanup logic runs. The manifestdriven job rendering, the dual storage modes, the callback-based result protocol, and the reconciliation worker are the adaptations required to operate a classical DEVS engine as a cloud-native workload.
6 Case Study and Evaluation The Riga Route 22 bus corridor is the first instantiation of our planned city-wide multimodal transport digital twin for Riga, Latvia; it was chosen to exercise the proposed architecture end-to-end while remaining tractable to analyse in depth. The case study extends our earlier DEVS-based geosimulation framework for public transport analysis and planning [40] to the cloud-native DevOps setting presented here and provides an empirical substrate for the declarative-specification and configuration-only evolution claims.
6.1 Application Context Bus 22 links Riga International Airport to the city centre via 17 stops, carrying both airport passengers and residents along the corridor. The digital twin supports transport planners with demand–supply equilibration, transit operations evaluation, and scenario testing for service changes. The case study exercises the architecture on a workload that combines multi-modal routing, iterative agent-based equilibration, and schedule-driven transit operations. The scenario is configured entirely through the YAML manifest shown in Listing 1. Input data is stored in GeoParquet format: a road network of 23,868 directed segments derived from OpenStreetMap [41], 4 transit line directions serving 65 stops, and 392 vehicle departures from the published General Transit Feed Specification (GTFS) feed [42]. Transit demand is generated from open e-ticket validation log [43] for the Route 22 corridor on Tuesday, 15 October 2024: 12,314 tap-in events become synthetic transit travelers, with boarding and alighting stops sampled along the corresponding line direction (the log under-counts fare-free passengers, so this is a lower bound on real loading). Car demand is synthesised as 12,000 trips with random origin–destination pairs restricted to a ≈600 m walking catchment around Route 22 stops [44], with departure times drawn from the same empirical daily profile as the transit demand. The combined scenario has 24,314 traveler demands in total. 12
TransportModel <coupled> TransportNetworkModel <coupled> per edge Zero-delay router, route-plan cursor
point-queue, RoadLinkModel A [x23,868]
TravelerSourceModel [x1]
A
per edge
IntersectionModel A [x23,868]
TravelerSinkModel A [x1]
arrived
Collects arrival times, travel times
inject
Traveler departures TransitVehicleSourceModel A [x1]
transit dispatch
Vehicle departures
wait-edge routing TransitStopModel A [x65] boarding/alighting, dwell time
Fig. 6 Hierarchical DEVS decomposition of the Riga Route 22 scenario. The inner TransportNetworkModel holds the per-edge RoadLink/Intersection FIFO cycle; the outer TransportModel adds transit-stop, source, and sink models. Arrows are port couplings labelled with the carried event type; stacked silhouettes denote instance multiplicity [×N]; the circled A marks atomic models.
6.2 DEVS Model Architecture The transport simulation is assembled as a two-level hierarchical coupled DEVS model (Figure 6). The inner coupled model, TransportNetworkModel, couples one RoadLinkModel per directed segment and one IntersectionModel per node; the outer coupled model, TransportModel, adds per-stop TransitStopModels and the traveler and transit vehicle sources and sink. Six types of atomic model appear in total. The case study uses classic Parallel DEVS atomic models rather than the engine’s multicomponent variant because the road-traffic flow is a sparse FIFO pipeline in which each component is influenced by at most one or two upstream components at a time. RoadLinkModel (one per segment) implements mesoscopic point-queue dynamics: each link maintains a vehicle queue ordered by computed exit times, with exit times derived from free-flow travel time, a minimum headway from a saturation flow of 1800 veh/h/lane, and a storage capacity from a 7.5 m jam spacing. IntersectionModel (one per node) is a zero-delay router that consults each agent’s route plan and forwards the vehicle to the next edge or to an arrived port. TransitStopModel (one per stop) handles boarding and alighting with a dwell time of tdoor + max(nb rb , na ra ) (tdoor = 5 s, rb = 3 s/pax, ra = 2 s/pax). TravelerSourceModel and TransitVehicleSourceModel inject travelers and dispatch vehicles on schedule; TravelerSinkModel records arrivals. A NetworkBuilder constructs the hierarchy automatically from the network graph and integrates transit through synthetic wait and stop edges.
6.3 Multi-Modal Routing and Iterative Equilibration Car routes are computed by time-dependent Dijkstra on the road graph using the current iteration’s edge travel time estimates. Transit routes enumerate candidate 13
(line, board stop, alight stop) triples over the published schedule, scoring each by walk access/egress, on-vehicle ride time, and accumulated dwell times against the same time-dependent edge weights, so router and simulator remain consistent. Each transit ride is materialised as a synthetic wait -edge identifier that routes the traveler to the appropriate TransitStopModel. Demand–supply equilibration follows a MATSim-style [45] co-evolutionary loop reimplemented inside the multiPDEVS engine so that network simulation, scoring, and replanning all share the same DEVS event semantics, event stream (Section 4), and SMDL versioning guarantees (Section 3). Each iteration runs the full DEVS simulation, scores plans with a Charypar–Nagel utility [46] (non-arrival penalty −1000), stochastically replans a fraction of travelers (30% route, 10% mode, 20% ±15 min departure shift), and updates edge travel times via the Method of Successive Averages. Convergence is declared when plan scores stabilise within tolerance 0.02 over five iterations. Utility coefficients used in this study are listed in the manifest of Listing 1.
6.4 Cloud Deployment The published Route 22 model is executed through the pipeline described in Section 5: a simulation project groups one or more scenarios and experiments, and triggering execution materialises one Kubernetes job per scenario as summarised in Figure 7. Each job runs an isolated engine container that fetches model artefacts from the registry, executes the scenario, and returns results via the REST callback while progress and lifecycle events stream over Kafka. This keeps scenarios isolated at the container level and lets the orchestrator scale concurrent executions horizontally with the cluster.
User
Simulation Project
Orchestrator
Model Registry
Simulation Engine (K8s Job)
Platform (REST callback)
Kafka (events)
Listeners
trigger execution (scenario / selection / all) submit scenarios create one job per scenario fetch model artefacts execute scenario (isolated) POST results (REST callback) persist & associate with experiment progress / intermediate / lifecycle events subscribe (near real-time)
User
Simulation Project
Orchestrator
Model Registry
Simulation Engine (K8s Job)
Platform (REST callback)
Kafka (events)
Listeners
Fig. 7 Execution flow of a published model: a simulation project triggers one Kubernetes job per scenario; results are returned via REST callback while progress and lifecycle events are streamed over Kafka.
14
Table 2 Scenario parameters and single-run results for Riga Route 22 with demand calibrated from e-ticket validations for 2024-10-15. Metric
Value
Network segments (DEVS link models) Intersection models Transit stops / lines / departures Total DEVS atomic models Traveler demand (car / transit) Simulation horizon
23,868 23,868 65 / 4 / 392 ≈47,870 24,314 (12,000 / 12,314) 24 h
Travelers arrived (car / transit) Median travel time (car) Median travel time (transit) P90 travel time (car) P90 travel time (transit) Transit stop visits Passengers boarded / alighted
18,542 (7,419 / 11,123) 8.8 min 8.3 min 16.0 min 17.2 min 5,236 12,193 / 11,859
6.5 Simulation Results Table 2 summarises the scenario parameters and single-run results for the Riga Route 22 simulation with a 24-hour horizon, matching the full day of the validation log. Of the 24,314 generated travelers, 18,542 reach their destination within the 24-hour horizon: 7,419 of 12,000 car trips (61.8%) and 11,123 of 12,314 transit trips (90.3%). The higher transit completion rate follows from transit OD pairs being sampled along the same line direction; unserved car trips are mostly late-evening departures whose routes do not complete within the horizon. Figure 8 compares the per-hour input demand against engine arrivals by mode. Both modes share the empirical daily profile recovered from the validation log, with morning (07:00–08:00) and afternoon (14:00–17:00) peaks. Arrival curves track their respective input curves with a short lag matching each mode’s median travel time, indicating that the engine preserves the empirical demand structure end-to-end. Central tendencies across modes are close because both demand streams draw from the same corridor envelope, not because of a mode-choice finding. Congestion is sparse: at most three links are simultaneously congested and 92 distinct links (0.39% of the network) reach the congestion threshold over the run. This confirms a sub-capacity regime whose implications for the saturated-traffic case are revisited in Section 7.
6.6 Engine Performance Iterative equilibration and interactive scenario exploration require each simulation run to complete in a small fraction of the real-time duration it represents. We ran the 24-hour Route 22 scenario with calibrated transit demand and synthetic car demand varied across six levels (0–24,000 trips, total 12, 314–36 ,314 travellers), measuring end-to-end wall-clock runtime including initialisation, input parsing, execution, and result export on an Apple M2 Max / 32 GB RAM / 4 GB JVM heap. These
15
Travelers per hour
1000 800 600 400 200 0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Simulation hour Car demand (input) Transit demand (input)
Car arrivals (n=7419) Transit arrivals (n=11123)
Fig. 8 Per-hour input demand (dashed) and engine arrivals (solid) by mode for the calibrated Route 22 run. Arrival curves track the empirical daily profile with a short lag equal to the median travel time of each mode, confirming end-to-end preservation of the demand shape.
single-container measurements set a lower bound on per-job latency; cluster-level orchestration overhead is deferred to future work (Section 7). Figure 9 reports the results. Runtime grows approximately linearly with total demand, with a least-squares slope of 2.3 ms per additional traveller and a fixed 22 s baseline that reflects engine startup, parquet loading, and DEVS network construction of the 47,870 atomic models. The calibrated baseline scenario of 24,314 travellers used in the preceding subsection is completed in 74 s, corresponding to a real-time speedup of approximately 1,170× (one simulated minute of the Riga Route 22 operating day in roughly 51 ms of wall-clock time). The lightest configuration (transit only, 12,314 travellers) completes in 51 s at 1,684× real-time, and the heaviest (36,314 travellers) completes in 111 s at 776× real-time. Across the sweep, the engine sustains a throughput of 260–320 travellers per second including all framework overhead; excluding the 22 s baseline, the marginal DEVS simulation cost is on the order of 430 travellers per second. These numbers fit the performance envelope required for iterative replanning (Section 6): each iteration of the Method of Successive Averages loop over the 24-hour horizon costs on the order of one minute of wall-clock time even at the largest configuration tested, and a 50-iteration convergence run fits within a single Kubernetes job. These single-run results provide the reference point against which the equilibration loop of Section 6 converges. Closing that feedback loop over a full DEVS re-execution is the prerequisite for transport digital twins that must evaluate service changes and infrastructure scenarios.
16
120
Linear fit: 2.33 ms/traveler + 22.2 s Measured runtime 776×
Wall-clock runtime (s)
100 962×
80 1166×
60 40
1388×
1360×
1684×
20 0 10,000
15,000
20,000
25,000
30,000
35,000
Traveler demand (transit + synthetic car) Fig. 9 Wall-clock runtime of the Route 22 24-hour simulation vs. total traveller demand. Annotations show the real-time speedup at each point. Runtime grows linearly at 2.3 ms per additional traveller over a 22 s baseline (engine startup, parquet loading, DEVS network construction).
7 Discussion Each contribution is supported by evidence aligned with its claim. The formal mapping of Eqs. (1)–(2) and the structural and semantic validation of Section 3.3 establish that SMDL conformance is decidable without invoking the runtime; this result supports the CI/CD design and follows from the metamodel construction, independent of pipeline catch statistics. The argument rests on the tuple-level SMDL-to-multiPDEVS mapping of Section 3 and the three well-formedness conditions derived from it; mechanised proof is not claimed. The Route 22 case study exercises configuration-only evolution end-to-end and quantifies single-container throughput at ≥ 776× real-time across the demand sweep, keeping a 50-iteration equilibration loop within roughly one minute of wall-clock per iteration at the largest configuration tested. Table 1 situates the approach. The closest neighbour is DEVSML 3.0 [35], which shares cloud-native DEVS deployment, declarative model specification, and formal DEVS semantics but lacks the CI/CD lifecycle, versioned artefacts, and deep semantic validation that this paper contributes. xDEVS [14, 34] offers formal DEVS semantics and a cloud-enabled distributed simulation architecture but no declarative model lifecycle; cloud-native digital twin platforms such as the Modelica DT platform of Kumar et al. [24] and KTWIN [23] target the digital twin dimension but lack formal simulation semantics or model versioning. The equilibration loop is close in spirit to MATSim [45]; grounding it in multiPDEVS is what makes automated semantic checks in the CI/CD pipeline possible. The scope of the work is bounded on three axes. SMDL and the engine adaptations are specific to multiPDEVS, and state externalisation assumes serialisable execution state; extending to multi-paradigm simulation such as DEVS/DESS or to engines built around pointer-rich non-serialisable state would require additional abstraction. Evaluation covers transport only; validation in manufacturing, energy systems, or 17
similar settings is left for future application studies. Two empirical dimensions that the registry, publishing worker, and orchestrator of Section 5 can expose are left to companion studies: pipeline-level measurements (publish latency, validation coverage, and catch distribution across the structural and semantic layers on a curated corpus of model revisions), and cluster-level evaluation of concurrent multi-scenario execution, container startup, and event-stream latency under realistic Kubernetes conditions. These companion studies will provide the pipeline and orchestration measurements that complement the architecture and formal-mapping results reported here. Several caveats attach to the reported evidence. Engine-performance measurements were obtained on a single Apple M2 Max machine with a fixed 4 GB JVM heap; variance across repeated runs, JIT warm-up, and heap-size sensitivity were not systematically controlled, and end-to-end wall-clock time conflates simulation cost with parquet parsing and network construction, though the 22 s baseline in Section 6.6 makes the decomposition transparent. The calibrated transit demand is derived from a single weekday (2024-10-15), and the synthetic demand for cars inherits the same temporal profile, which necessarily produces the close input/output shape match in Figure 8. The point-queue link model (a case-study simplification, not a platform limit) does not capture signalised intersection dynamics, so the sub-capacity regime observed in the baseline cannot be taken as evidence that the engine handles saturated traffic correctly. More broadly, the case study covers a single city, a single transit corridor, a single DEVS engine [7], and a single cloud runtime, so claims about pipeline usefulness, engine throughput, and orchestration overhead should not be extrapolated to microscopic simulation or non-Kubernetes runtimes without further study.
8 Conclusion and Future Work This paper presented a model-centric DevOps architecture for deploying DEVS-based digital twin simulations as managed services. Simulation models are treated as firstclass DevOps artefacts defined in a declarative YAML-based SMDL with a formal mapping to multiPDEVS. The platform is decomposed into containerised microservices on Kubernetes, with a CI/CD pipeline for automated validation and staged deployment, and the multiPDEVS engine is adapted for stateless containers through immutable versioned artefacts in object storage, environment-injected job metadata, and a pull-style REST result callback complemented by a Kafka lifecycle event stream. The architecture was validated with 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. The platform handled a hierarchical DEVS model with roughly 47,870 atomic components, schedule-aware multi-modal routing, and iterative equilibration with convergence detection. The YAML manifest allowed scenarios to be configured (network parameters, transit schedules, replanning strategies, scoring) without changes to engine code, and each configuration passed structural and semantic validation before deployment. Two companion empirical studies are the immediate next steps: pipeline-level catch statistics over a curated corpus of model revisions, and cluster-level evaluation of concurrent multi-scenario orchestration, container startup, and event-stream
18
latency under realistic Kubernetes conditions. The primary application direction is scaling the Route 22 case study into a full public transport digital twin for Riga, composed corridor-by-corridor from independently versioned SMDL models and federated at the city level, with live bus-location feeds from the operator supporting online route adaptation. Supporting methodological work will target multi-formalism support for hybrid DEVS / DESS models, automated ML-based parameter calibration in the CI/CD pipeline, and evaluation in further application domains (manufacturing, energy systems) to exercise the architecture beyond transport.
Acknowledgments. This research is conducted as part of the project “Development of the DigiTDevOps Digital Twin Development and Operation Platform” under the European Union’s Recovery and Resilience Mechanism Plan. It falls within Reform and Investment Direction 5.1: “Increasing Productivity Through Investment in R&D,” specifically under Sub-action 5.1.1.r (Reform): “Innovation Management and Motivation for Private R&D Investment” and Sub-action 5.1.1.2.i (Investment): “Support Instrument for Research and Internationalisation” (4th round). The project number is 5.1.1.2.i.0/4/24/A/CFLA/001.
References [1] Grieves, M., Vickers, J.: Digital Twin: Mitigating Unpredictable, Undesirable Emergent Behavior in Complex Systems. In: Transdisciplinary Perspectives on Complex Systems, pp. 85–113. Springer, Cham (2017). https://doi.org/10.1007/ 978-3-319-38756-7 4 [2] Tao, F., Zhang, H., Liu, A., Nee, A.Y.C.: Digital twin in industry: State-of-theart. IEEE Transactions on Industrial Informatics 15(4), 2405–2415 (2019) https: //doi.org/10.1109/TII.2018.2873186 [3] Zeigler, B.P., Muzy, A., Kofman, E.: Theory of Modeling and Simulation: Discrete Event and Iterative System Computational Foundations, 3rd edn. Academic Press, New York (2018). https://doi.org/10.1016/C2016-0-03987-6 [4] Bass, L., Weber, I., Zhu, L.: DevOps: A Software Architect’s Perspective. Addison-Wesley Professional, Boston, MA (2015) [5] Niyonkuru, D., Wainer, G.: A DEVS-based engine for building digital quadruplets. Simulation 97(7), 485–506 (2021) https://doi.org/10.1177/ 00375497211003130 [6] Foures, D., Franceschini, R., Bisgambiglia, P.-A., Zeigler, B.P.: multiPDEVS: A parallel multicomponent system specification formalism. Complexity 2018(1), 3751917 (2018) https://doi.org/10.1155/2018/3751917 [7] Lektauers, A.: Towards a DEVS-based simulation engine for digital twin applications. In: 2025 Winter Simulation Conference (WSC), pp. 2884–2895. IEEE, Seattle, WA, USA (2025). https://doi.org/10.1109/WSC68292.2025.11338915
19
[8] Fuller, A., Fan, Z., Day, C., Barlow, C.: Digital Twin: Enabling Technologies, Challenges and Open Research. IEEE Access 8, 108952–108971 (2020) https: //doi.org/10.1109/access.2020.2998358 [9] Wainer, G., Govind, S.: 100 volumes of SIMULATION – 20 years of DEVS research. Simulation 100(12), 1297–1318 (2024) https://doi.org/10.1177/ 00375497241291871 [10] Nutaro, J.J.: Building Software for Simulation: Theory and Algorithms, with Applications in C++. Wiley Online Library, Hoboken, NJ, USA (2011). https: //doi.org/10.1002/9780470877999 [11] Wainer, G.A.: Discrete-Event Modeling and Simulation: A Practitioner’s Approach. CRC Press, Boca Raton, FL (2009). https://doi.org/10.1201/ 9781420053371 [12] Quesnel, G., Duboz, R., Ramat, É.: The Virtual Laboratory Environment – An operational framework for multi-modelling, simulation and analysis of complex dynamical systems. Simulation Modelling Practice and Theory 17(4), 641–653 (2009) https://doi.org/10.1016/j.simpat.2008.11.003 [13] Van Tendeloo, Y., Vangheluwe, H.: PythonPDEVS: a distributed Parallel DEVS simulator. In: Proceedings of the Symposium on Theory of Modeling & Simulation: DEVS Integrative M&S Symposium. Simulation Series, vol. 47, pp. 91–98. The Society for Modeling and Simulation International (SCS), Alexandria, VA, USA (2015) [14] Risco-Martı́n, J.L., Mittal, S., Henares, K., Cardenas, R., Arroba, P.: xDEVS: A toolkit for interoperable modeling and simulation of formal discrete event systems. Software: Practice and Experience 53(3), 748–789 (2023) https://doi.org/ 10.1002/spe.3168 [15] Kim, S., Sarjoughian, H.S., Elamvazhuthi, V.: DEVS-Suite: A simulator supporting visual experimentation design and behavior monitoring. In: Spring Simulation Multi-conference (SpringSim 2009). SCS, San Diego, CA, USA (2009). ACM Digital Library ID 1639809.1655390 [16] Camus, B., Paris, T., Vaubourg, J., Presse, Y., Bourjot, C., Ciarletta, L., Chevrier, V.: Co-simulation of cyber-physical systems using a DEVS wrapping strategy in the MECSYCO middleware. Simulation 94(12), 1099–1127 (2018) https://doi.org/10.1177/0037549717749014 [17] Vanommeslaeghe, Y., Van Acker, B., Denil, J., De Meulenaere, P.: Integrating DEVS and FMI 3.0 for the simulated deployment of embedded applications. In: 2024 Annual Modeling and Simulation Conference (ANNSIM), pp. 1–13. IEEE, Washington, D.C., DC, USA (2024). https://doi.org/10.23919/ANNSIM61499. 2024.10732719
20
[18] Calheiros, R.N., Ranjan, R., Beloglazov, A., De Rose, C.A.F., Buyya, R.: CloudSim: a toolkit for modeling and simulation of cloud computing environments and evaluation of resource provisioning algorithms. Software: Practice and Experience 41(1), 23–50 (2011) https://doi.org/10.1002/spe.995 [19] Stoja, S., Capko, D., Jelacic, B., Vukmirovic, S., Nedic, N.: Simulation of cloud-native microservices-based architecture for power applications. Advances in Electrical and Computer Engineering 26(1), 23–30 (2026) https://doi.org/10. 4316/aece.2026.01003 [20] Hewage, T.B., Ilager, S., Rodriguez, M.A., Buyya, R.: CloudSim Express: A novel framework for rapid low code simulation of Cloud Computing environments. Software: Practice and Experience 54(3), 483–500 (2024) https://doi.org/10.1002/ spe.3290 [21] Andreoli, R., Zhao, J., Cucinotta, T., Buyya, R.: CloudSim 7G: An integrated toolkit for modeling and simulation of future generation Cloud Computing environments. Software: Practice and Experience 55(6), 1041–1058 (2025) https: //doi.org/10.1002/spe.3413 [22] Khan, M.G., Taheri, J., Al-Dulaimy, A., Kassler, A.: PerfSim: A Performance Simulator for Cloud Native Microservice Chains. IEEE Transactions on Cloud Computing 11(2), 1395–1413 (2023) https://doi.org/10.1109/TCC.2021.3135757 [23] Wermann, A.G., Wickboldt, J.A.: KTWIN: A serverless Kubernetes-based Digital Twin platform. Computer Networks 259, 111095 (2025) https://doi.org/10.1016/ j.comnet.2025.111095 [24] Kumar, A., Narasimhan, A., Rajendran, T., Velut, S.: Digital twin applications using a cloud native Modelica platform. In: Proceedings of the Asian Modelica Conference 2022. Linköping Electronic Conference Proceedings, vol. 193. Linköping University Electronic Press, Tokyo, Japan (2022). https://doi.org/10. 3384/ecp19375 [25] Kreuzberger, D., Kühl, N., Hirschl, S.: Machine learning operations (MLOps): Overview, definition, and architecture. IEEE Access 11, 31866–31879 (2023) https://doi.org/10.1109/ACCESS.2023.3262138 [26] Gião, H., Flores, A., Pereira, R., Cunha, J.: Chronicles of CI/CD: A Deep Dive into its Usage Over Time. https://arxiv.org/abs/2402.17588. arXiv:2402.17588 (2024) [27] Karamitsos, I., Thabit, S., Apostolopoulos, C.: Applying DevOps practices of continuous automation for machine learning. Information 11(7), 363 (2020) https: //doi.org/10.3390/info11070363 [28] Chand, S., Pfannenstiel, M., Bremer, S.: Implementation of DevOps with GitLab
21
CI/CD for the management of a large satellite simulation software. Electronic Communications of the EASST 85 (2025) https://doi.org/10.14279/eceasst.v85. 2713 [29] Capizzi, A., Distefano, S., Mazzara, M.: From DevOps to DevDataOps: Data management in DevOps processes. In: Software Engineering Aspects of Continuous Development and New Paradigms of Software Production and Deployment, pp. 52–62. Springer, Cham (2020). https://doi.org/10.1007/978-3-030-39306-9 4 . Springer [30] Reiterer, S.H., Schiffer, C., Schwaiger, M.: A graph-based meta-data model for DevOps: Extensions to SSP and SysML2 and a review on the DCP standard. In: Proceedings of the 15th International Modelica Conference. Linköping Electronic Conference Proceedings, vol. 204, pp. 159–166 (2023). https://doi.org/10.3384/ ecp204159 [31] Colantoni, A., Berardinelli, L., Wimmer, M.: DevOpsML: towards modeling DevOps processes and platforms. In: Proceedings of the 23rd ACM/IEEE International Conference on Model Driven Engineering Languages and Systems: Companion Proceedings, pp. 1–10. ACM, New York, NY, USA (2020). https: //doi.org/10.1145/3417990.3420203 [32] Subramanya, R., Sierla, S., Vyatkin, V.: From DevOps to MLOps: Overview and application to electricity market forecasting. Applied Sciences 12(19), 9851 (2022) https://doi.org/10.3390/app12199851 [33] Kamburjan, E., Klungre, V.N., Schlatte, R., Johnsen, E.B., Giese, M.: Programming and debugging with semantically lifted states. In: 18th European Semantic Web Conference (ESWC 2021). LNCS, vol. 12731, pp. 126–142. Springer, Cham (2021). https://doi.org/10.1007/978-3-030-77385-4 8 [34] Risco-Martı́n, J.L., Henares, K., Mittal, S., Almendras, L.F., Olcoz, K.: A unified cloud-enabled discrete event parallel and distributed simulation architecture. Simulation Modelling Practice and Theory 118, 102539 (2022) https://doi.org/ 10.1016/j.simpat.2022.102539 [35] Mittal, S., Risco-Martı́n, J.L.: DEVSML 3.0 stack: rapid deployment of DEVS farm in distributed cloud environment using microservices and containers. In: Proceedings of the Symposium on Theory of Modeling & Simulation. Society for Modeling and Simulation International (SCS), San Diego, CA, USA (2017). https://doi.org/10.22360/springsim.2017.tmsdevs.043 [36] Microsoft Azure: Digital Twins Definition Language (DTDL). https://github. com/Azure/opendigitaltwins-dtdl. v4, accessed April 2026 (2026) [37] Blochwitz, T., Otter, M., Akesson, J., Arnold, M., Clauss, C., Elmqvist, H., Friedrich, M., Junghanns, A., Mauss, J., Neumerkel, D., Olsson, H., Viel, A.:
22
Functional mockup interface 2.0: The standard for tool independent exchange of simulation models. In: Proceedings of the 9th International Modelica Conference, vol. 76, pp. 173–184. Linköping University Electronic Press, Munich, Germany (2012). https://doi.org/10.3384/ecp12076173 [38] Hardy, T.D., Palmintier, B., Top, P.L., Krishnamurthy, D., Fuller, J.C.: HELICS: A co-simulation framework for scalable multi-domain modeling and analysis. IEEE Access 12, 24325–24347 (2024) https://doi.org/10.1109/ACCESS.2024. 3363615 [39] Holcombe, M.: X-machines as a basis for dynamic system specification. Software Engineering Journal 3(2), 69–76 (1988) https://doi.org/10.1049/sej.1988.0009 [40] Lektauers, A., Merkuryev, Y.: DEVS-based interactive geosimulation framework for public transport analysis and planning. In: 2nd International Workshop on Simulation for Energy, Sustainable Development and Environment (SESDE 2014), pp. 50–58. Dime University of Genoa, Bordeaux, France (2014) [41] OpenStreetMap contributors: OpenStreetMap. https://www.openstreetmap.org. Planet dump; extract for Riga, Latvia (2024) [42] Rı̄gas Satiksme: Public transport route schedules for Rı̄gas Satiksme (GTFS feed). https://data.gov.lv/dati/lv/dataset/ marsrutu-saraksti-rigas-satiksme-sabiedriskajam-transportam. Latvian Open Data Portal (2024) [43] Rı̄gas Satiksme: E-ticket validation data for Rı̄gas Satiksme public transport. https://data.gov.lv/dati/lv/dataset/ e-talonu-validaciju-dati-rigas-satiksme-sabiedriskajos-transportlidzeklos. Latvian Open Data Portal; October 2024 used for this study (2024) [44] El-Geneidy, A., Grimsrud, M., Wasfi, R., Tétreault, P., Surprenant-Legault, J.: New evidence on walking distances to transit stops: Identifying redundancies and gaps using variable service areas. Transportation 41(1), 193–210 (2014) https: //doi.org/10.1007/s11116-013-9508-z [45] Horni, A., Nagel, K., Axhausen, K.W.: The Multi-agent Transport Simulation MATSim. Ubiquity Press, London (2016). https://doi.org/10.5334/baw [46] Charypar, D., Nagel, K.: Generating complete all-day activity plans with genetic algorithms. Transportation 32(4), 369–397 (2005) https://doi.org/10. 1007/s11116-004-8287-y
23