A DWDM optical network planning, monitoring, and automation toolkit — built to demonstrate the software/automation side of optical network engineering (link budgeting, fiber acceptance testing, wavelength planning, remote monitoring, config generation) using the same first-order engineering models a DWDM planning tool encodes.
This was built while targeting AWS Infrastructure Services Optical Network Development Engineer roles (DWDM long-haul/metro deployment, Core Networking, DCNE, DRES). Those JDs consistently call out five things: optical planning/modeling tools, fiber quality reviews and cutsheets, DWDM network rollout/scaling, remote monitoring and device visibility, and automation scripting (Python/Bash/Shell/Perl). Each module below targets one of those directly.
What this is: working Python implementations of the standard first-pass engineering math and workflow logic an optical planning engineer uses (span-loss budgets, OSNR estimation per the textbook EDFA cascade model, ITU-T G.694.1 channel grids, greedy RWA wavelength assignment, fiber acceptance pass/fail logic) plus the automation and monitoring tooling layered on top.
What this is not: a substitute for hands-on experience operating real DWDM hardware, vendor-certified planning software (Ciena/Infinera/Nokia planning suites), or live optical telemetry. The monitoring module runs on synthetic data (see monitoring/telemetry.py for exactly what's simulated and why). Anywhere this line matters, the code comments say so explicitly rather than pretending otherwise.
| Module | What it does | Maps to |
|---|---|---|
optical/channel_grid.py |
Generates the ITU-T G.694.1 DWDM frequency grid (50/100 GHz spacing, C-band) | "optical planning and modelling tools" |
optical/link_budget.py |
Span-loss and OSNR budget calculator for a cascaded amplified DWDM link | "optical planning, modelling tools and hands-on implementation" |
optical/cutsheet.py |
Validates fiber acceptance test data against an engineering loss budget and generates a pass/fail cutsheet | "fiber quality reviews and generate cutsheets" (verbatim, AWS Optical NDE II) |
optical/topology.py |
Models a ROADM topology and does greedy RWA wavelength assignment under wavelength-continuity | "drive scaling current DWDM designs to meet demand", "design of optical solutions" |
monitoring/ |
FastAPI service exposing simulated per-channel optical telemetry with threshold alerting | "remote monitoring and device visibility" (verbatim, AWS Optical NDE II) |
automation/config_generator.py |
Jinja2-templated config generation for optical network elements from a topology + demand set | "implement changes on optical systems using... automated process via script" |
pip install -e ".[dev]"
# Link budget for a 3-span long-haul path
python -m waveops.optical.link_budget --spans-json examples/spans.json
# Fiber acceptance cutsheet from raw test data
python -m waveops.optical.cutsheet --input-csv examples/fiber_test.csv --output-csv out_cutsheet.csv
# Wavelength assignment + config generation over a 4-node topology
python -m waveops.automation.config_generator --topology-json examples/topology.json --output-dir out_configs/
# Monitoring API
uvicorn waveops.monitoring.api:app --reload
# Run the test suite
python -m pytest tests/ -v- ITU-T G.694.1 (02/2020) — DWDM frequency grid
- Standard EDFA-cascade OSNR approximation (58 dBm reference constant at 0.1nm reference bandwidth, 1550nm window) used for first-pass link engineering
- G.652/G.652.D/G.655/G.657 typical attenuation specs used as cutsheet acceptance thresholds
- OpenROADM — open-source YANG data models for ROADM/optical network elements; noted in
automation/config_generator.pyas the natural next step over the generic CLI-style templates currently used
- Swap
monitoring/telemetry.py's synthetic generator for a real SNMP/gNMI collector against lab or simulated equipment - Target NETCONF/YANG (OpenROADM) instead of generic CLI templates in
automation/config_generator.py - Add a k-shortest-paths RWA fallback instead of first-fit-only wavelength assignment
- Persist monitoring readings to a time-series store (Prometheus) instead of in-memory generation per request
MIT