---
title: MOSAIC Simulation Platform Overview
url: https://www.emergentmind.com/topics/mosaic-simulation-platform
type: topic
---

# MOSAIC Simulation Platform Overview

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 [2410.16937].
- **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 [2410.16937].

This approach facilitates rapid prototyping, iterative extension, and scalable deployment, especially in domains demanding cross-layer modeling or hardware–software co-design [2004.07415][1811.06877].

## 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 [2410.16937].
- **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 [2410.16937].
- **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 [2209.12550]) and in MosaicSim's tile-level, cycle-driven stepping [2004.07415].

## 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 [2004.07415].
- **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 [1811.06877][2410.16937].
- **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 [2209.12550].

### 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 [2404.07547].
- **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 [2504.07830].
- **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 [1811.06877][2410.16937].
- **Scenario Scripting:** High-level APIs (e.g., `world = mosaik.World(time_resolution=...)`, `world.start(...)`, `world.connect(...)`) provide total control over simulation composition and execution [2410.16937].
- **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 [2004.07415].

## 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 [2004.07415].
- **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 [2209.12550].
- **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 [1806.03296].
- **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 [2404.07547].

## 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 [2410.16937]. 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 [2410.16937].
- **Monotonic Coupling Only:** Non-iterative, statically-connected topologies are the norm; dynamic reconfiguration and rollback demand non-trivial architectural extensions [1811.06877].
- **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 [1509.03067].

## 7. Representative Usage and Access

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

- MosaicSim: https://github.com/princetonmosaic/mosaicsim.git [2004.07415].
- mosaik/co-simulation: pip install mosaik, usage via Python or YAML scenario scripts [1811.06877][2410.16937].
- Mosaic for multi-agent social simulation: https://github.com/genglinliu/MOSAIC [2504.07830].
- Eclipse MOSAIC: extended for application-level simulation and emission modeling in urban mobility studies [2404.07547].

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.

Source: https://www.emergentmind.com/topics/mosaic-simulation-platform