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. IT load and PUE from conv-engine.js are power context only; network inventory and observed traffic have independent authored authorities.
Truth boundary: the current page shows 80 Gbps installed / 40 Gbps protected usable core capacity, 20 access switches and a 14.2 Gbps authored traffic scenario. The separate four-hall study uses 500 racks per hall and derives ceil(500/12) = 42 logical access groups per hall. Physical switch count, port speed, uplink ratio and dual-ToR policy remain unavailable until an approved network architecture is supplied.
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
Three input groups are kept separate: device inventory, network capacity and observed traffic, and power context. The current network values are authored independently of IT kW; the governed study contributes rack count only and cannot manufacture port speeds or bandwidth.
| 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 project scenario | Total unplanned + planned downtime hours used for a generic availability ratio; it is not a Tier certification result. |
Used rack-U used_U | Uused | U | From DCIM / physical audit | Occupied U positions across all active cabinets. |
| Core installed / usable capacity | Cinst / Cuse | Gbps | 80 / 40 (authored) | Two 40 Gbps edge paths; protected operating capacity is 40 Gbps after reserving the alternate path. |
Observed traffic usage_Gbps | Ubw | Gbps | 14.2 (authored scenario) | Deterministic traffic telemetry independent of IT power; replace with measured counters in production. |
| Study racks / grouping policy | Rstudy / Rgroup | racks | 500 / 12 per hall | Planning input only; yields 42 logical access groups per hall, not a physical switch design. |
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
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
Study access-group count
access_groups_per_hall = ceil( study_racks_per_hall / 12 ) = ceil(500 / 12) = 42
campus_access_groups = 4 × 42 = 168
This is a logical grouping assumption for study visibility. It does not assert one physical switch per group; port count, dual-ToR policy, optics and oversubscription require an approved network brief.RZConvDesignBasis.STUDY · project grouping assumption
Annual uptime percentage
uptime_pct = available_hr / 8760 × 100 [%]
available_hr = 8760 − downtime_hr
8760 is the number of hours in a non-leap year. The ratio reports the selected project scenario only. Uptime Institute Tier is a topology and operational-sustainability certification process; this arithmetic does not establish a Tier rating or certified availability.Project scenario · Uptime Institute Tier Certification
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 = observed_Gbps / usable_Gbps × 100 [%]
bw_headroom_pct = ( usable_Gbps − observed_Gbps ) / usable_Gbps × 100 [%]
Observed traffic is the authored 14.2 Gbps scenario; usable capacity is 40 Gbps. Neither value is derived from IT kW. Warn if utilisation exceeds the declared 80% operating threshold.ict.html NETWORK_CAPACITY_BASIS · TRAFFIC_SCENARIO
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. IT, BMS/OT and security traffic values are deterministic authored telemetry scenarios, independent of the power model.ict.html SEGMENTS · authored network telemetry
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 |
| 8 kW rack-equivalent | round(1850 / 8) = 231 | Power-planning equivalence from SNAP.racks.at_8kw; not physical rack inventory |
| Current access inventory | 20 switches | Authored installed inventory; not back-solved from rack-equivalent power |
| Study grouping | max 12 racks/group | Project planning assumption; 42 logical groups/hall at 500 racks/hall |
| Observed traffic | 14.2 Gbps | Authored deterministic telemetry scenario independent of IT kW |
| Core capacity | 80 installed / 40 usable / 40 survivable Gbps | Authored protected-capacity contract |
| 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) |
| Availability objective | project input | Not a Tier certification or guaranteed uptime value |
| 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. |
| Study access groups | ceil(500/12) | groups/hall | Logical grouping only; physical switch design remains pending. |
| Core observed traffic | authored scenario | Gbps | Deterministic network telemetry independent of IT power. |
| Core utilisation | offered/cap × 100 | % | Warn if > 80% (headroom < 20%). |
| Bandwidth headroom | (cap−offered)/cap × 100 | % | Available capacity before congestion alarm. |
| Annual availability scenario | available_hr/8760 × 100 | % | Project ratio only; not a Tier certification result. |
| 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 power context, 231 rack-equivalents at 8 kW, 80 Gbps installed / 40 Gbps usable core capacity and 14.2 Gbps observed traffic. Rack-equivalent is not physical inventory.
- Active device inventory:
servers + switches + firewalls + APs— example:450 + 22 + 4 + 8 =484 active devices - Current access inventory: 20 switches (authored installed state, not calculated from IT power).
- Four-hall study grouping:
ceil(500 / 12) =42 logical access groups per hall; physical switch topology remains pending. - Observed traffic: 14.2 Gbps from the authored traffic scenario, independent of the 1.85 MW power context.
- Core utilisation:
14.2 / 40 × 100 =35.5 % → well under 80% warn threshold ✓ - Bandwidth headroom:
(40 − 14.2) / 40 × 100 =64.5 % → healthy ✓ - Availability example: a selected 1.57 hr/yr downtime scenario gives
(8760 − 1.57) / 8760 × 100 =99.982 %; this does not confer a Tier rating. - 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
Engineering reading: the ICT cockpit is healthy when core utilisation is below the declared threshold, all 6 OT gateways are online, the selected availability objective is met, and no critical alarms are active. The three current warnings require operator review even when the authored scenario labels them non-service-impacting.
07 References & standards
- TIA-942 — Telecommunications infrastructure requirements for data centres; apply the licensed edition and project conformity scope rather than copied uptime percentages.
- ISO/IEC 27001:2022 — Information security management systems: asset inventory requirements, access control, network segmentation, and monitoring obligations.
- Uptime Institute Tier Certification — independent certification of design documents, constructed facility and operational sustainability; this cockpit makes no certification claim.
- 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 — power context (IT 1.85 MW, PUE 1.45, 231 rack-equivalents at 8 kW); not the network-inventory or traffic authority.
- conv-design-basis.js — separate four-hall study authority (500 racks/hall); contributes rack grouping context only.
- 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, capacity and link traffic are authored network values; IT load is context only. In production these would be replaced by SNMP/streaming telemetry, CMDB and DCIM sources. Key limitations:
- Traffic values are authored deterministic scenarios, not measured counters and not derived from IT power. Actual traffic depends on workload mix.
- The 42 access groups per study hall do not define physical switch count, port speed, uplink oversubscription, optics or dual-ToR policy.
- 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.