Skip to content

REPLICATION_GUIDE.md

Latest commit

 

History

History
95 lines (72 loc) · 3.31 KB

REPLICATION_GUIDE.md

File metadata and controls

95 lines (72 loc) · 3.31 KB
Raw

Replication Guide: Cloud Continuum CPS Infrastructure

This guide provides the necessary steps to replicate the experimental results presented in the paper "A Cloud Continuum Research Infrastructure for Distributed CPS Experimentation".

1. Prerequisites

1.1 Hardware Environment

The experimental campaign compares two types of edge deployments:

  • Physical Edge (RASP): Raspberry Pi 4 Model B (4GB RAM) or equivalent ARM-based SBCs.
  • Virtualized Edge (POD): Virtualized nodes within the SLICES infrastructure (x86_64).
  • Fog/Cloud Layer: Standard Kubernetes-capable clusters (min. 4 vCPUs, 8GB RAM).

1.2 Software Requirements

  • Operating System: Ubuntu 22.04 LTS (recommended).
  • Orchestration: k3s (v1.24+) or any CNCF-compliant Kubernetes distribution.
  • Tools: kubectl, helm (v3+), python3, and bash.

2. Infrastructure Setup

Before running the experiments, you must deploy the research-infrastructure layer.

2.1 Deploy the Core Framework

Navigate to the core directory and execute the integrated setup script:

cd core/stack4things-improved
./automated_deployment.sh

This script initializes:

  • Stack4Things Conductor: The central management plane.
  • WAMP Router (Crossbar): For low-latency messaging.
  • Crossplane Provider: For Kubernetes-native resource management.

2.2 Verify Connectivity

Ensure all components are operational across the continuum:

kubectl get pods -A | grep -E "iotronic|crossplane|istio"

3. Running Experimental Campaigns

The paper evaluates the infrastructure through a systematic campaign of 40 automated runs.

3.1 Scenario A: AirWatch (Monitoring-Oriented)

This scenario evaluates anomaly detection and low-latency alerting.

  1. Configure the runner: 
    cd experiments/runner
# Edit deploy-continuum.sh to set target cluster context
  2. Launch the campaign: 
    ./campaign_runner.sh --scenario airwatch --runs 20 --edge-type [RASP|POD]

3.2 Scenario B: REC Simulation (Control-Oriented)

This scenario evaluates Digital Twin coordination and energy control.

  1. Launch the campaign: 
    cd experiments/runner
./campaign_runner.sh --scenario rec-simulation --runs 20

4. Data Collection & Metric Extraction

After completing the runs, use the research tools to extract the metrics used in the paper.

4.1 Extracting Performance Metrics

Use the extract_metrics.sh tool to pull data from Prometheus/Metrics-Server:

cd experiments/tools
./extract_metrics.sh --output results.csv

4.2 Resource Utilization Analysis

Analyze the overhead of the programmable substrate:

python3 tools/resource_sampler.py --data-dir ../results

5. Expected Results and Validation

Following this guide, you should be able to reproduce the findings reported in the paper:

  1. Placement Accuracy: Verification that workloads are correctly assigned to Edge, Fog, or Cloud layers.
  2. Latency Overhead: Bounded and attributable performance overhead even with complex Digital Twin synchronization.
  3. Observability: Full data provenance across the Edge-Fog-Cloud pattern.

For technical troubleshooting not covered in this guide, refer to the comments within the individual scenario scripts in experiments/scenarios/.