MOSAIC Simulation Platform Overview

• MOSAIC Simulation Platform is a modular simulation ecosystem defined by flexible integration APIs, unified scheduling, and scenario-driven configuration for diverse domains.
• It employs innovative time synchronization and discrete-event coupling methods, using lookahead scheduling and event queue management to ensure causality across hybrid simulators.
• The platform features domain-specific instantiations in hardware–software co-design, cyber-physical systems, urban mobility, and multi-agent social dynamics, enabling validated and scalable studies.

The MOSAIC Simulation Platform describes a family of advanced, modular simulation environments deployed across computer architecture, smart grids, cyber-physical systems, social agent modeling, and urban mobility research. The term "MOSAIC" appears in several prominent research platforms, most notably the MosaicSim simulator for hardware–software co-design in heterogeneous systems, the mosaik and Eclipse MOSAIC frameworks for cyber-physical co-simulation and urban applications, and the MOSAIC multi-agent simulation for social content dynamics. Each contributes distinct methodologies, architectures, and application domains, while sharing principles of modularity, extensibility, and scenario-driven composability.

1. Architectural Principles and Core Design Patterns

MOSAIC platforms generally adopt a master–orchestrator model, where a centralized scheduler or world object drives the execution and synchronization of a dynamic ensemble of component simulators or tiles. These simulators may represent hardware cores, accelerators, communication networks, agent-based models, or domain-specific subsystems. The platforms exhibit the following architectural traits:

• Modular Entities: Simulation units (tiles, agents, application modules) are encapsulated with clear data and control boundaries, enabling heterogeneous mixing (e.g., CPU, accelerator, communication link, social agent).
• Flexible Integration APIs: Component adapters must expose core routines (e.g., init, step, get_data, set_event). The architecture accommodates time-stepped, event-driven, or hybrid simulators using type annotations and trigger lists (Ofenloch et al., 2024).
• Scenario-Driven Configuration: Users assemble and parameterize simulation scenarios using high-level scripts or configuration files (YAML, JSON, or Python), specifying which components participate, how they interlink, and the global time semantics.
• Unified Scheduling Engine: A central scheduler or "Interleaver" orchestrates global time progression, event queue management, and the ordering of simulator invocations, enforcing causality and attribute-level triggers (Ofenloch et al., 2024).

This approach facilitates rapid prototyping, iterative extension, and scalable deployment, especially in domains demanding cross-layer modeling or hardware–software co-design (Matthews et al., 2020, Steinbrink et al., 2018).

2. Time Synchronization, Discrete-Event Coupling, and Causality Enforcement

A defining feature of MOSAIC (particularly in mosaik 3.0 and MosaicSim) is the unification of time-stepped and discrete-event semantics using lookahead scheduling and attribute-level triggers. The scheduler advances simulation time by dynamically determining the next "safe" time: the minimum across all simulators' next event or step deadlines.

• Formal Time Mapping: Internal integer time indices $t\in\mathbb{N}$ are mapped to real-world wall-clock time by $t_\mathrm{real} = t \cdot \Delta$, where $\Delta$ is the global resolution (Ofenloch et al., 2024).
• Max-Advance Semantics: For each simulator $i$, the maximum interval to the next synchronization is given by

$$\mathrm{max\_advance}_i(t) = \min_{j \in \mathrm{Pred}(i)} [ t_j^{\mathrm{next\_input}} - t ]$$

where $\mathrm{Pred}(i)$ are upstream data providers (Ofenloch et al., 2024).

• Event Queue Management: The scheduler maintains a queue of $(t, \mathrm{sim}, \mathrm{data})$ tuples, invoking step() methods at the minimum $t^*$ across all pending events or time steps.
• Superdense Time and Same-Time Loops: By designating feedback edges as "weak," the scheduler resolves instantaneous dependencies via bounded same-time iterations, essential for tightly-coupled control systems.

Such synchronization principles are operationalized in cosima (for OMNeT++ networking (Oest et al., 2022)) and in MosaicSim's tile-level, cycle-driven stepping (Matthews et al., 2020).

3. Domain-Specific Instantiations and Workflows

3.1 Hardware–Software Co-Design: MosaicSim

MosaicSim targets performance modeling of heterogeneous SoCs, comprising general-purpose CPU tiles, accelerators, scratchpad DMA engines, and configurable interconnection fabrics. Core workflows entail:

• LLVM-IR–Driven Modeling: Static Data Dependence Graphs (DDG) and dynamic traces (DTG) over LLVM IR basic blocks provide a flexible ISA substrate for simulating custom instructions, compiler transformations, and high-level language API calls.
• Cycle Estimates and Stall Modeling: Kernel cycle count is given by

$$T_\mathrm{sim} = \sum_{\ell} \frac{\mathrm{IssueCycles}(\ell) + \mathrm{ExecLat}(\ell)}{\min(W, \# \mathrm{ready\_instrs})} + \sum T_\mathrm{DRAM}$$

with parameters for issue width $W$, reorder buffer $R$, and memory ordering (Matthews et al., 2020).

• Plug-In Accelerators: Integration of HLS- or SystemC-driven performance models by registering new tile types with associated performance parameters and memory constraints.
• Hardware–Software Pragma Support: Compiler passes insert LLVM intrinsics, triggering custom tile/accelerator behaviors.

3.2 Cyber-Physical Co-Simulation: mosaik and Eclipse MOSAIC

These variants implement a generic scenario-driven orchestration of time-stepped (e.g., power system dynamics), discrete-event (e.g., communication protocols), and hybrid simulators. Key practices include:

• Component and Scenario APIs: Simulator adapters implement four core routines (init, create, step, get_data), while scenario scripts (Python or YAML/INI) load and interconnect models (Steinbrink et al., 2018, Ofenloch et al., 2024).
• Explicit, Non-Iterative Coupling: At each synchronization point, the scheduler advances all simulators to the next discrete time, exchanges outputs, and passes results downstream.
• cosima Extension (for OMNeT++): Implements TCP-bridged communication between the mosaik "CommunicationSimulator" and OMNeT++ "MosaikScheduler", with fine-grained event alignment and message timestamp propagation (Oest et al., 2022).

3.3 Urban Mobility: Eclipse MOSAIC for Ride-Hailing

This application leverages the extensibility of Eclipse MOSAIC and its Application Simulator API to orchestrate realistic ride-hailing scenarios:

• Application Simulator Extensions: User-level apps model logbook ingestion, ride assignment, vehicle state machines, and rebalancing strategies via modular plug-ins (Schrab et al., 2024).
• Integration with Traffic Simulation (SUMO): Application components interact via CellSim and TraCI interfaces, issuing route updates, boarding delays, and emissions tracking (via HBEFA models).
• Empirical Data Injection: Real-world driver logbooks are parsed and injected into simulation scenarios to generate temporally-accurate ride orders and vehicle itineraries.

3.4 Multi-Agent Social Network Dynamics

MOSAIC in the context of multi-agent simulations for content dissemination (distinct from the above co-simulation frameworks) orchestrates LLM-driven agents embedded in a directed social graph.

• Personas and Episodic Memories: Agents are initialized with demographic and attitudinal priors, episodic interaction histories, and reflection routines that modulate action selection.
• LLM-Powered Decision Processes: At each time step, agents compute action probabilities via a softmax over latent utility scores provided by back-end LLMs. Binary classification (e.g., flagging misinformation) adopts a logistic mapping (Liu et al., 10 Apr 2025).
• Fact-Checking and Moderation Modules: Several content moderation strategies (community-based, third-party, hybrid) are evaluated using engagement balance, precision, recall, and $F_1$ metrics.

4. Extensibility, Platform APIs, and Best Practices

The extensibility of MOSAIC-class platforms is realized via clean adapter interfaces, scenario-graph APIs, and plug-in models for new behavior types.

• Adapter Requirements: Each external simulator or module must expose standardized init and step routines, along with explicit meta-descriptions of data ports, step sizes, and triggering rules (Steinbrink et al., 2018, Ofenloch et al., 2024).
• Scenario Scripting: High-level APIs (e.g., world = mosaik.World(time_resolution=...), world.start(...), world.connect(...)) provide total control over simulation composition and execution (Ofenloch et al., 2024).
• Plug-in and Reuse Patterns: Hardware tiles, communication stacks, rebalancing heuristics, or fact-checking routines are all realized as subclasses or handler registrations, minimizing boilerplate and enabling scenario reuse across domains.
• Stateless Cycle Logic: For composability, per-tile logic is stateless across cycles; all dynamic state is maintained in per-instantiation objects (Matthews et al., 2020).

5. Performance Metrics, Validation, and Comparative Analysis

MOSAIC platforms prioritize both analytic tractability and empirical validation using error metrics, speedup factors, and survey yield rates, as relevant to each context.

• Cycle Accuracy and MAPE: For MosaicSim, geomean mean absolute percentage error (MAPE) against real hardware is ≈9.9%. Accelerator timing models achieve >97% accuracy vs. RTL or FPGA reference (Matthews et al., 2020).
• Message Latency and Convergence: In cosima-integrated smart grid scenarios, the introduction of realistic communication delays more than doubles negotiation times and raises the sensitivity of agent convergence to network failures (Oest et al., 2022).
• Survey Speed and S/N Scaling: The MOSAIC simulator for ELT science implements core equations for S/N per spectral resolution, survey speed $\propto M D^2 \eta$, and exposure-time scaling (Puech et al., 2018).
• Urban Emission Reduction: Eclipse MOSAIC studies quantify operational and environmental impacts, showing up to –24% total mileage and –25% CO₂ emission reductions for optimized ride-hailing rebalancing (Schrab et al., 2024).

6. Application Scope, Scalability, and Limitations

MOSAIC Simulation Platforms have demonstrated scalable deployments in multicore architectural exploration, distributed CPES studies with dynamic communication topologies, city-scale mobility and emissions scenarios, and emergent-pattern studies in social-influence networks. Scalability is generally bounded by the number of component simulators, the density of their interconnections, and the event density within hybrid feedback loops (Ofenloch et al., 2024). Notable limitations include:

• Hybrid Feedback Uncertainty: In mosaik 3.0, uncertainty propagation in hybrid (event/time) loops is not yet quantitatively solved; superdense time iterations require careful capping (Ofenloch et al., 2024).
• Monotonic Coupling Only: Non-iterative, statically-connected topologies are the norm; dynamic reconfiguration and rollback demand non-trivial architectural extensions (Steinbrink et al., 2018).
• Domain-Specific Limitations: In OMNeT++ co-simulations, only application-layer events are usually exposed, with lower-layer protocol details remaining internal. Real-time operation over long simulation horizons remains computationally intensive (Dede et al., 2015).

7. Representative Usage and Access

Public codebases and scenario templates are available for multiple MOSAIC incarnations:

• MosaicSim: https://github.com/princetonmosaic/mosaicsim.git (Matthews et al., 2020).
• mosaik/co-simulation: pip install mosaik, usage via Python or YAML scenario scripts (Steinbrink et al., 2018, Ofenloch et al., 2024).
• Mosaic for multi-agent social simulation: https://github.com/genglinliu/MOSAIC (Liu et al., 10 Apr 2025).
• Eclipse MOSAIC: extended for application-level simulation and emission modeling in urban mobility studies (Schrab et al., 2024).

These platforms, through modular interfaces, rigorous time/event synchronization, and validated analytic workflows, serve as reference architectures for multi-domain, cross-layer simulation in both research and applied engineering.