Home / DC Solutions / Technical Manuals / ICT Cockpit

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.

Engine conv-engine.js (basis) Basis TIA-942 · ISO/IEC 27001 Inputs Device inventory + uptime/bandwidth controls Outputs Counts & ratios
▶ Open the live ICT Cockpit

01 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.

Accuracy scope: ICT is informational and is NOT under the physics-accuracy gates (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.

InputSymbolUnitDefault / sourceMeaning
Server count nServersNsrvcountFrom asset register / SNMPPhysical and virtual-host servers in the active fleet.
Switch count nSwitchesNswcountFrom asset register / SNMPCore + distribution + ToR access switches across all segments.
Firewall count nFirewallsNfwcountFrom asset registerPerimeter and segment firewalls (active + standby pair counted separately).
Access-point count nAPsNapcountFrom asset registerWi-Fi APs in NOC, common areas, and secure wireless zones.
Annual downtime downtime_hrDhr/yrAuthored per Tier targetTotal unplanned + planned downtime hours per year used for uptime% calculation.
Used rack-U used_UUusedUFrom DCIM / physical auditOccupied U positions across all active cabinets.
Core link capacity cap_GbpsCGbps40 Gbps (2 × 40G LAG)Aggregate core-uplink capacity from which bandwidth headroom is derived.
Core link usage usage_GbpsUbwGbpsDerived: IT_kW × 0.00768 Gbps/kWOffered aggregate traffic on the core uplink pair, derived from the IT power basis.
OT gateway count nGatewaysGcount6 (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

activeDevices = Nsrv + Nsw + Nfw + Nap Integer sum of all device categories from the asset register. Drives the segment navigation badge counts. No physics — pure inventory arithmetic.Asset register · SNMP

Access-switch count (derived from rack basis)

TOR_count = ceil( RACKS / 12 ) [switches] One Top-of-Rack switch per 12 active racks. RACKS = ceil(IT_kW / 8) from 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

uptime_pct = available_hr / 8760 × 100 [%] available_hr = 8760 − downtime_hr 8760 = hours in a non-leap year. downtime_hr is the sum of all unplanned + planned outage hours. Tier 3 (TIA-942): 99.982% = 1.57 hr/yr. Tier 4: 99.995% = 0.44 hr/yr. Legacy "Tier 3 = 99.9% = 8.76 hr/yr" is the older Uptime Institute classification; TIA-942-B uses 99.982%.TIA-942-B · Uptime Institute

Rack-U utilisation

rackU_util_pct = used_U / 42 × 100 [%] 42U is the standard full-height cabinet. Warn threshold defaults to 80%. Values above 80% indicate insufficient free-U for new deployments or cable management. Used_U is sourced from DCIM or a physical audit; it is not derived from IT power.EIA-310-D · ANSI/EIA-310-D standard cabinet height

Bandwidth utilisation & headroom

core_util_pct = usage_Gbps / cap_Gbps × 100 [%] bw_headroom_pct = ( cap_Gbps − usage_Gbps ) / cap_Gbps × 100 [%] usage_Gbps = IT_kW × 0.00768 (empirical DC heuristic: ~7.7 Mbps/kW mixed workload) Core uplink capacity is 40 Gbps (2 × 40G LAG, authored). Usage is a deterministic function of IT power — not polled live. Warn if core_util_pct > 80% (headroom < 20%).conv-engine.js basis · Engineering constant 0.00768 Gbps/kW

OT gateway reachability

gateways_online = Σ( gatewayi = online ) [count] gateways_pct = gateways_online / nGateways × 100 [%] Authored gateway count is 6 (EPMS, Chiller, Datahall, Fire, Fuel, Water). Online state is authored in the cockpit data model — not polled in the demo build. In a live deployment this would be SNMP or ICMP reachability.BMS/OT segment · SNMP polling

Segment alarm totals (badge counts)

seg_alarm_total = Σ( alarms[seg].sev === 'crit' ) + Σ( alarms[seg].sev === 'warn' ) global_crit = Σ all segments critical count global_warn = Σ all segments warning count Alarm badge on each nav-rail item = crit + warn for that segment. Top alarm strip state = CRITICAL if global_crit > 0, ATTENTION if global_warn > 0, else NORMAL. Alarm entries are authored engineering states (not random) representing realistic NOC scenarios.Authored alarm model · NOC ops practice

Link utilisation (per-link)

link_util_pct = ( traffic_Gbps / cap_Gbps ) × 100 if link status = 'up' link_util_pct = 0 if status = 'stby' or 'down' Per-row calculation for the Links table. Traffic values for the IT segment scale from IT_kW × 0.00768; BMS/OT and security links use authored fixed values reflecting Modbus/BACnet and H.265 CCTV traffic profiles.conv-engine.js basis · Per-link authored constants

04 Constants & engineering basis

All authored constants have a comment-tag in the source indicating their origin. Key values:

ConstantValueSource / rationale
IT load basisIT_kW = 1850 kWconv-engine.js SNAP.site.it_load_kw
Rack countRACKS = ceil(1850 / 8) = 232 → authored 231conv-engine.js SNAP.racks.at_8kw
ToR ratio1 switch per 12 racksEngineering constant — typical spine-leaf ToR density
Traffic heuristic0.00768 Gbps/kW (~7.7 Mbps/kW)Empirical DC heuristic for mixed north-south + east-west workload
Core uplink capacity40 Gbps (2 × 40G LAG)Authored — SW-CORE-A/B active/active LAG
Standard cabinet height42UEIA-310-D full-height cabinet
Core util warn threshold80 %Standard NOC headroom rule — action before saturation
Stale-telemetry warn> 60 sSNMP polling interval threshold — authored per PRTG best practice
Uptime hours/year8760 hrNon-leap year (365 × 24)
Tier 3 downtime budget1.57 hr/yr = 99.982%TIA-942-B Rated-3
Tier 4 downtime budget0.44 hr/yr = 99.995%TIA-942-B Rated-4
OT gateway count6 (EPMS, Chiller, Datahall, Fire, Fuel, Water)BKS01 BMS architecture — authored
CCTV camera count96 (64 ext + 32 int)Authored from physical security design
Access door count48Authored — biometric + card reader doors
Intrusion zones24Authored — PIR + glass-break zones
VMS retention target30 days (current: 14 d — WARN)Physical security policy

05 Outputs

OutputFormulaUnitInterpretation
Active devicesNsrv+Nsw+Nfw+NapcountTotal monitored devices in the fleet.
ToR switch countceil(RACKS/12)countAccess switches required for current rack count.
Core aggregate offeredIT_kW × 0.00768GbpsEstimated north-south + east-west traffic.
Core utilisationoffered/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 utilisationused_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 segmentcountNav-rail badge; red = critical, amber = warning.
Link utilisation (per row)traffic/cap × 100%Per-link bar + percentage in the Links table.
Camera stream uptimeuptime_hr/24 × 100%24 h rolling availability of CCTV streams.
VMS retentionauthored current vs targetdaysWARN 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.

  1. Active device inventory: servers + switches + firewalls + APs — example: 450 + 22 + 4 + 8 = 484 active devices
  2. ToR switch count: ceil(231 / 12) = 20 access switches
  3. Core aggregate offered: 1850 kW × 0.00768 Gbps/kW = 14.2 Gbps
  4. Core utilisation: 14.2 / 40 × 100 = 35.5 % → well under 80% warn threshold ✓
  5. Bandwidth headroom: (40 − 14.2) / 40 × 100 = 64.5 % → healthy ✓
  6. Annual uptime (Tier 3): downtime budget 1.57 hr/yr → (8760 − 1.57) / 8760 × 100 = 99.982 %
  7. 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% ✓
  8. OT gateways: all 6 online → 6 / 6 × 100 = 100 % → facility controllability nominal ✓
  9. Alarm strip: 0 critical, 3 warning (VMS retention, tertiary DCI standby, stale sensor) → ATTENTION state
Engineering reading: the ICT cockpit is healthy when core utilisation is below 80%, all 6 OT gateways are online, uptime% meets the Tier target, and no critical alarms are active. The three current warnings (VMS retention shortfall, tertiary WAN redundancy, 1 stale sensor) are non-impacting to facility operations.

07 References & standards

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:

▶ Open the live ICT & Network Cockpit