AFDX-Simulator

AFDX-Simulator is a lightweight discrete-event simulator for simplified AFDX-like (Avionics Full-Duplex Switched Ethernet) networks. It models End Systems (ES), Switches, and Networks to simulate virtual link (VL) communication, policing (MFS/BAG), routing and basic redundancy behaviors.

Architecture

The simulator follows a modular architecture with clear separation of concerns:

• Simulator core: event queue, time management and scheduling (in simulator/).
• Network model: Network objects model point-to-point propagation delays and deliver frames between ES and Switch instances (in net/).
• Nodes: EndSystem and Switch implement sending/receiving logic, VL configuration and policing (in nodes/).
• Configuration/Scenarios: YAML-based topology and scenario loaders (in config/) are used to define network topologies, links and virtual links and to schedule application events for tests.
• Tests & Scenarios: sample scenarios and unit tests under tests/ exercise routing, shapers, redundancy and timing behavior.

The code is structured into include/ and src/ folders for headers and implementation respectively.

Components

• Simulator (simulator/): discrete-event scheduler, now() time source and metrics.
• Network (net/): models propagation delay; exposes callbacks to connect ES↔Switch and methods send_to_switch and send_to_es to schedule frame arrival events.
• EndSystem (nodes/): configures VLs for transmission, enforces MFS/BAG before sending, transmits application payloads and receives frames from switches.
• Switch (nodes/): enforces VL policing (MFS and BAG), routes frames according to a routing table, and forwards frames via uplink/downlink networks.
• YamlLoader (config/): loads topology and scenario YAML files into runtime objects and builds per-switch routing tables.
• tests/: scenario YAMLs and small unit tests to validate behavior such as latency, BAG/MFS violations, redundancy and multicast routing.

VL, MFS and BAG (what they are and how to use them)

• Virtual Link (VL): a unidirectional logical flow from a source ES to one or more destination ESes. Each VL has an identifier (vlid) and parameters that shape/police traffic.
• Maximum Frame Size (MFS): the largest allowed payload (in bytes) for frames on a VL. Frames with payload larger than MFS are dropped by the sending ES or the switch.
• Bandwidth Allocation Gap (BAG): the minimum time interval (in milliseconds in this simulator) that must separate successive accepted frames of the same VL. BAG policing prevents bursts that exceed configured bandwidth.

How to use them to enable ES↔ES communication:

1. In a topology YAML (see config/*.yaml) define a virtual_links entry with vlid, mfs, bag, source (ES name), and destinations (list of ES names).
2. Configure the source ES in the topology: the loader will call configure_vl(vlid, mfs, bag) on the ES; the ES will enforce MFS/BAG when transmitting application messages.
3. Switches in the topology are configured with the VL contract so they can police forwarded traffic (also enforcing MFS/BAG). If a frame violates MFS or is sent within BAG from the last accepted frame, the frame is dropped and a message like DROP BAG violation or DROP MFS violation is logged.
4. To send traffic, create a scenario YAML defining events (time, action send, es, vlid, payload). The simulator will schedule the ES to transmit; frames travel through networks and switches to destinations according to routing configured by the loader.

Requirements and Build

Prerequisites:

• A C++ compiler supporting C++11 or newer (e.g. g++).
• make build tool.
• yaml-cpp library (development headers and linkage) for YAML parsing.

On Debian/Ubuntu, you can install dependencies with:

sudo apt-get update
sudo apt-get install build-essential libyaml-cpp-dev

Build the project:

make

Run tests:

./afdx_simulator <topology.yaml> <scenario.yaml> 

Example:

./afdx_simulator config/two_switch_star.yaml tests/scenarios/test_two_switch_routing.yaml

If your environment places libraries in non-standard locations, adapt CXXFLAGS/LDFLAGS in the Makefile accordingly.

Clean the project:

make clean

Topology files

Two example topologies are provided under config/:

• simple_star.yaml: single-switch star topology where one switch SW1 connects ES1, ES2, ES3 on the same network.
• two_switch_star.yaml: two-switch topology where SW1 and SW2 are connected by an inter-switch network, and ES nodes are attached to either switch.

Example tests and scenarios

Below are some example tests you can run by loading the scenario YAMLs in tests/scenarios/ with the corresponding topology.

1. Simple Star — Basic multicast routing

./afdx_simulator config/simple_star.yaml tests/scenarios/test_multicast_routing.yaml

• Topology: config/simple_star.yaml
• Scenario: a VL from ES1 to ES2 (and optionally ES3) — verify packets are delivered to the correct ESes and latency equals network propagation + switch processing.

2. Simple Star — MFS/BAG policing

./afdx_simulator config/simple_star.yaml tests/scenarios/test_bag_violation.yaml

• Topology: config/simple_star.yaml
• Scenario: send two frames on same VL from ES1 spaced less than BAG — expect the second frame to be dropped by the switch (or ES) with a DROP BAG violation log. Also test a frame exceeding MFS to get DROP MFS violation.

3. Two-Switch Star — Multihop routing

./afdx_simulator config/two_switch_star.yaml tests/scenarios/test_two_switch_routing.yaml

• Topology: config/two_switch_star.yaml
• Scenario: tests/scenarios/test_two_switch_routing.yaml — ES1 sends a VL destined to ES3 (via SW1→SW2); verify frames traverse both switches and reach ES3. This scenario demonstrates inter-switch forwarding and propagation delays.

4. Two-Switch Star — Redundancy / Duplicate suppression

./afdx_simulator config/two_switch_star.yaml tests/scenarios/test_redundancy.yaml

• Topology: config/two_switch_star.yaml
• Scenario: create a VL with multiple destinations or redundant paths, and verify that the simulator either forwards the expected number of copies and that BAG policing prevents accepting duplicates that violate the BAG. Use tests/scenarios/test_redundancy.yaml or construct a scenario where an ES sends duplicates; verify DROP BAG violation appears when duplicates arrive within BAG.

Additional useful test scenarios in tests/:

• tests/scenarios/test_latency_measure.yaml: measure and log latency for frames from source to destination.
• tests/scenarios/test_mfs_violation.yaml: demonstrates MFS enforcement by sending oversized payloads.
• tests/scenarios/test_multivl_load.yaml: simulates multiple VLs concurrently to observe policing and scheduling effects.

How to read test output

Take as example the scenario in tests/scenario/test_mfs_violation.yaml in the topology config/simple_star.yaml.

Topology:

• ES1 --NetA--> SW1
• ES2 --NetA--> SW1
• ES3 --NetA--> SW1
• VL=100 - source: ES1 - dest: ES2 - MFS=256 - BAG=8ms
• VL=200 - source: ES2 - dest: ES1, ES3 - MFS=128 - BAG=4ms

Test:

• At time 0, ES1 sends 3 bytes on VL=100
• At time 10, ES1 sends 320 bytes on VL=100, exceeding the MFS=256

Test output:

1 [ES ES1] TX VL=100 seq=0 time=0ms
2 [SW SW1] RX VL=100 seq=0 at t=0.5ms
3 [ES ES2] RX VL=100 seq=0 at t=1ms
4 [ES ES1] Payload too large for VL 100 (MFS=256)
5
6 === Simulation Complete ===
7 Frames sent: 1
8 Frames received: 1
9 Frames dropped: 1

• Line 1 indicates that an ES named ES1 transmitted (TX) on Virtual Link with id=100 (VL=100) a frame with id=0 (seq=0) at simulation time t=0ms
• Line 2 indicates that a switch named SW1 received (RX) on Virtual Link with id=100 (VL=100) a frame with id=0 (seq=0) at simulation time t=0.5ms (the network added 0.5ms of latency)
• Line 3 indicates that an ES named ES2 received (RX) on Virtual Link with id=100 (VL=100) a frame with id=0 (seq=0) at simulation time t=1ms (the network added 0.5ms of latency)
• Line 4 indicates that an ES named ES1 tried to send a message too large for VL=100 that has a MFS=256

Next steps and development notes

• The current routing loader builds simple per-switch port mappings (uplink/downlink) and encodes ports as 1 (uplink) and 2 (downlink). For more complex topologies, consider extending the loader to build an explicit graph and compute per-switch next-hop for each destination.
• The Network abstraction currently uses callback registration to determine the recipient type; if needed, you can extend it to support multiple recipients or explicit neighbor addresses.
• Tests are small and illustrative; adding integration tests that assert end-to-end metrics (latency, delivered frames, dropped frames) will help prevent regressions.