Communication Availability Analyser
Turn a communication status log (IED, RTU and control-centre links going down and up) into availability per link, MTBF, MTTR, the outage list, flapping links and common-cause outages — against your availability target.
Status log
Result
Open a status log or load the sample.
What this tool is, how it works and how far to trust it
An analyser that computes availability, MTBF and MTTR of telecontrol and station links from the SCADA communication status log, and finds outages with a common cause.
Read this before relying on a result. Every method, formula, assumption and limit is stated here, so you can check the answer yourself instead of accepting it blindly.
What it can do
- Read a status log CSV (time, device or link, state such as OK / FAIL, up / down, 1 / 0, comm fail / normal).
- Per link: outages, total downtime, availability, MTBF, MTTR, longest outage and short flaps under 10 s.
- Flag links still down at the end of the log, find common-cause outages (three or more links down within 5 s) and compare with the availability target.
Why you need it
- Contracts and grid codes set availability targets for telecontrol, and operations need to know which links fail, how often and for how long.
- Outages that hit several devices at once point to a shared component — a switch, a power supply, a telecom circuit — rather than to each device.
Understand this first
- Availability = 1 − downtime / period. 99.9 % allows about 43 minutes of outage a month; 99.99 % about 4 minutes.
- MTBF = uptime / number of failures; MTTR = downtime / number of failures. Many short outages and one long outage can give the same availability but need different fixes.
- Flaps (failures shorter than about 10 s) usually mean a marginal link — fibre budget, duplex mismatch, overloaded switch — rather than a device failure.
What you need before you start
- The communication status events from the SCADA event or alarm journal (CSV), covering the reporting period.
- A current browser (Chrome, Edge, Firefox or Safari). Nothing is installed and your data is never uploaded; it is processed on your own computer.
How to use it
- Open the log (or load the sample) and set the availability target.
- Read the table per link, then the common-cause outages and the links still down.
- For each weak link, check what it shares with others and whether the outages are long (repair) or short (link quality).
What you get
- Per link: availability, outages, downtime, MTBF, MTTR, longest outage, flaps; findings against the target.
- A list of common-cause outages with the links involved and their duration.
How to read the results
- Low availability from one long outage: a repair-time problem (spares, access, response).
- Low availability from many short outages: a quality problem in the link — check the network and the supervision timers.
- Common-cause outage: look for what the links share at that moment (switch, router, UPS, telecom provider).
Technical basis
- IEC 60050-192 and IEC 61907 dependability definitions; IEC 62439-1 network availability.
- Outage = time from a fail state to the next OK state of the same link; a link still failed at the end counts to the end of the log.
Limits: when not to rely on it
- The SCADA can only see a link from its own side: an outage of the SCADA server or its network looks like an outage of every link.
- Results depend on the supervision timers that generate the events (e.g. IEC 104 t1, t3).
Sample files for this tool
Download, open and compare with what the guide says you should see.
- S13_comm_status_log.csv — Communication status log — 30 days
For preliminary engineering use. Results must be checked by a qualified engineer against the project's standards. How results are checked · Terms & disclaimer · Privacy · Build 7cfcbe2 · 2026-11-14