Technical Manual · ICT & Network
ICT & Network — Cockpit Methodology & Formulas
Every input, count formula, ratio, threshold, and reference behind the ICT & Network cockpit. This page is primarily informational — it presents discrete device counts and simple percentage ratios, not thermodynamic or electrical physics. All formulas are documented inline and are deterministic functions of the device inventory and capacity inputs.
▶ Open the live ICT Cockpit01 Purpose & scope
The ICT & Network cockpit is a network operations monitoring view for the BKS01 conventional data centre. It answers five operational questions: how many devices are active in each network segment, is the facility still operable over its BMS/OT network, what is the uptime percentage against annual availability targets, how full are the rack cabinets, and how much bandwidth headroom remains on core uplinks.
Unlike the fire-suppression, chiller, or power calculators, the ICT cockpit does not solve physics equations. Its outputs are counts (integer device totals), ratios (percentage utilisations), and authored alarm states. The engineering basis — IT load, rack count, and PUE — is inherited from conv-engine.js to ensure a single source of truth across all BKS01 cockpit pages.
probe-accuracy-validation.mjs) that cover the power, cooling, and fire pages. Values are anchored to the conv-engine.js basis and to authored engineering constants; no Math.random is used for any displayed metric.02 Inputs
Two input groups: the device inventory (counts per device category, used to derive active-device totals and segment badge counts) and uptime / bandwidth controls (annual downtime hours and link capacity used to compute percentage ratios). Capacity values are authored engineering constants tied to the conv-engine.js IT-power basis.
| Input | Symbol | Unit | Default / source | Meaning |
|---|---|---|---|---|
Server count nServers | Nsrv | count | From asset register / SNMP | Physical and virtual-host servers in the active fleet. |
Switch count nSwitches | Nsw | count | From asset register / SNMP | Core + distribution + ToR access switches across all segments. |
Firewall count nFirewalls | Nfw | count | From asset register | Perimeter and segment firewalls (active + standby pair counted separately). |
Access-point count nAPs | Nap | count | From asset register | Wi-Fi APs in NOC, common areas, and secure wireless zones. |
Annual downtime downtime_hr | D | hr/yr | Authored per Tier target | Total unplanned + planned downtime hours per year used for uptime% calculation. |
Used rack-U used_U | Uused | U | From DCIM / physical audit | Occupied U positions across all active cabinets. |
Core link capacity cap_Gbps | C | Gbps | 40 Gbps (2 × 40G LAG) | Aggregate core-uplink capacity from which bandwidth headroom is derived. |
Core link usage usage_Gbps | Ubw | Gbps | Derived: IT_kW × 0.00768 Gbps/kW | Offered aggregate traffic on the core uplink pair, derived from the IT power basis. |
OT gateway count nGateways | G | count | 6 (authored) | BMS/OT polling gateways: EPMS, Chiller, Datahall, Fire, Fuel, Water. |
03 Calculation methodology
All formulas are simple arithmetic — sums, ratios, and ceiling divisions. There are no differential equations or thermodynamic constants. Function names below map directly to the inline JavaScript in ict.html.
Active device count
Access-switch count (derived from rack basis)
conv-engine.js (231 racks @ IT 1.85 MW). Ceiling division rounds up to the next whole switch.conv-engine.js basis · Engineering constant
Annual uptime percentage
Rack-U utilisation
Bandwidth utilisation & headroom
OT gateway reachability
Segment alarm totals (badge counts)
Link utilisation (per-link)
04 Constants & engineering basis
All authored constants have a comment-tag in the source indicating their origin. Key values:
| Constant | Value | Source / rationale |
|---|---|---|
| IT load basis | IT_kW = 1850 kW | conv-engine.js SNAP.site.it_load_kw |
| Rack count | RACKS = ceil(1850 / 8) = 232 → authored 231 | conv-engine.js SNAP.racks.at_8kw |
| ToR ratio | 1 switch per 12 racks | Engineering constant — typical spine-leaf ToR density |
| Traffic heuristic | 0.00768 Gbps/kW (~7.7 Mbps/kW) | Empirical DC heuristic for mixed north-south + east-west workload |
| Core uplink capacity | 40 Gbps (2 × 40G LAG) | Authored — SW-CORE-A/B active/active LAG |
| Standard cabinet height | 42U | EIA-310-D full-height cabinet |
| Core util warn threshold | 80 % | Standard NOC headroom rule — action before saturation |
| Stale-telemetry warn | > 60 s | SNMP polling interval threshold — authored per PRTG best practice |
| Uptime hours/year | 8760 hr | Non-leap year (365 × 24) |
| Tier 3 downtime budget | 1.57 hr/yr = 99.982% | TIA-942-B Rated-3 |
| Tier 4 downtime budget | 0.44 hr/yr = 99.995% | TIA-942-B Rated-4 |
| OT gateway count | 6 (EPMS, Chiller, Datahall, Fire, Fuel, Water) | BKS01 BMS architecture — authored |
| CCTV camera count | 96 (64 ext + 32 int) | Authored from physical security design |
| Access door count | 48 | Authored — biometric + card reader doors |
| Intrusion zones | 24 | Authored — PIR + glass-break zones |
| VMS retention target | 30 days (current: 14 d — WARN) | Physical security policy |
05 Outputs
| Output | Formula | Unit | Interpretation |
|---|---|---|---|
| Active devices | Nsrv+Nsw+Nfw+Nap | count | Total monitored devices in the fleet. |
| ToR switch count | ceil(RACKS/12) | count | Access switches required for current rack count. |
| Core aggregate offered | IT_kW × 0.00768 | Gbps | Estimated north-south + east-west traffic. |
| Core utilisation | offered/cap × 100 | % | Warn if > 80% (headroom < 20%). |
| Bandwidth headroom | (cap−offered)/cap × 100 | % | Available capacity before congestion alarm. |
| Annual uptime % | available_hr/8760 × 100 | % | Compare to Tier 3 (99.982%) or Tier 4 (99.995%) target. |
| Rack-U utilisation | used_U/42 × 100 | % | Space pressure; warn above 80%. |
| OT gateways online | Σ(online) | count / % | Facility controllability — all 6 must be online for full ops. |
| Segment alarm badges | Σ(crit+warn) per segment | count | Nav-rail badge; red = critical, amber = warning. |
| Link utilisation (per row) | traffic/cap × 100 | % | Per-link bar + percentage in the Links table. |
| Camera stream uptime | uptime_hr/24 × 100 | % | 24 h rolling availability of CCTV streams. |
| VMS retention | authored current vs target | days | WARN if retention < 30 d policy target. |
06 Worked example
BKS01 default state: IT 1.85 MW, 231 active racks @ 8 kW, 40 Gbps core LAG. Numbers reproduce the live cockpit display exactly.
- Active device inventory:
servers + switches + firewalls + APs— example:450 + 22 + 4 + 8 =484 active devices - ToR switch count:
ceil(231 / 12) =20 access switches - Core aggregate offered:
1850 kW × 0.00768 Gbps/kW =14.2 Gbps - Core utilisation:
14.2 / 40 × 100 =35.5 % → well under 80% warn threshold ✓ - Bandwidth headroom:
(40 − 14.2) / 40 × 100 =64.5 % → healthy ✓ - Annual uptime (Tier 3): downtime budget 1.57 hr/yr →
(8760 − 1.57) / 8760 × 100 =99.982 % - Rack-U utilisation example: 168 used-U across 4 racks = 4 × 42 = 168 total →
168 / 168 × 100 =100 % (all U occupied — triggered warn); single 42U cabinet at 32 used-U:32 / 42 × 100 =76.2 % → below 80% ✓ - OT gateways: all 6 online →
6 / 6 × 100 =100 % → facility controllability nominal ✓ - Alarm strip: 0 critical, 3 warning (VMS retention, tertiary DCI standby, stale sensor) → ATTENTION state
07 References & standards
- TIA-942-B — Telecommunications Infrastructure Standard for Data Centers: Tier availability targets (Rated-3: 99.982%, Rated-4: 99.995%), cabling and redundancy requirements.
- ISO/IEC 27001:2022 — Information security management systems: asset inventory requirements, access control, network segmentation, and monitoring obligations.
- Uptime Institute Tier Standard — Topology classification (Tier I–IV) and the legacy 99.9% Tier 3 / 99.99% Tier 4 uptime targets.
- ANSI/EIA-310-D — Cabinets, Racks, Panels, and Associated Equipment: 42U standard full-height cabinet definition.
- SNMP v2c/v3 (RFC 1157 / RFC 3411) — Simple Network Management Protocol: device polling, sensor freshness, and trap-based alarm sourcing used in live deployments.
- NFPA 75 — Standard for the Fire Protection of Information Technology Equipment: network and IT room requirements informing physical security and segmentation design.
- conv-engine.js — single engineering basis (IT 1.85 MW, PUE 1.45, 231 racks @ 8 kW/rack) inherited by the ICT cockpit.
- rz-line-model.js · rz-alarm-state.js · rz-inspector.js — shared BMS cockpit modules providing semantic line metadata, alarm state management, and inspector panel wiring.
08 Assumptions & limitations
The cockpit is a demonstration and engineering-education tool, not a live SNMP/SIEM feed. Device counts, alarm states, and link traffic values are authored engineering constants derived from the conv-engine.js basis. In a production deployment, these would be replaced by SNMP polling, PRTG sensor readings, and DCIM data exports. Key limitations:
- Traffic values are heuristic estimates (
IT_kW × 0.00768 Gbps/kW) — not measured counters. Actual traffic depends on workload mix. - Uptime% is a ratio of authored downtime hours to 8760 — not computed from a real event log or CMDB.
- Rack-U utilisation requires a physical audit or DCIM sync; it is not derivable from IT power alone.
- BMS/OT gateway reachability is authored (all online) in the demo; a live system would use ICMP or protocol-level heartbeats.
- CCTV camera count (96), door count (48), and intrusion zones (24) are authored from the physical security design — not dynamically polled.
- The cockpit does not compute IP addressing, VLAN design, routing tables, or PKI — those are configuration artefacts, not cockpit outputs.