The alarm threshold is a contract clause, not a setting

You have sensors installed on a route, or someone is trying to sell you some. Before you sign, could you answer four questions: at what value does the alarm trip? how many times a second — or a day — is it sampled? who decided those numbers? and when were they last reviewed? If they are not written down anywhere, you do not have a monitoring system. You have a quotation with some sensors attached.

ITU-T Recommendation L.391 (11/2025), “Monitoring systems for outside plant facilities”, second edition approved on 29 November 2025 by Study Group 15 — replacing L.391/L.81 of 2009 — starts from exactly this point, and writes it into a table that every monitoring specification should cite by name.

The threshold, not the sensor

The passage that carries this piece sits in Appendix I, on the Korean experience — not an integral part of the Recommendation, the text itself warns: “This appendix does not form an integral part of this Recommendation.” In the table on design considerations (I.1): “Monitoring system performs early warning. Real-time data gathered by WSN are analysed and an alarm is issued if the data exceed prescribed thresholds.”

Then the real problem: “If the threshold is set too low, there will be too many false warnings, and genuine warnings will not be heeded. On the contrary, if the threshold is set too high, events that may cause accidents will be missed.” Set it low, false alarms pile up, and — the consequence that matters — “genuine warnings will not be heeded”: real alarms stop being listened to, the system switches off in the mind of whoever watches it long before it fails in fact. Set it high, and the real event slips past unnoticed.

One line carries the whole piece: “This activation threshold should be set case by case for outside plant facilities.” There is no default threshold to buy off the shelf: it is a design input, and therefore a line in the specification, naming who sets it, on what basis, and under what review procedure.

Two orders of magnitude

Same table, the row on sampling rate: “The sampling rate determines how often sampling takes place. A faster sampling rate acquires more data in a given time, and therefore often forms a better representation of the original signal.” And the example that fixes the scale: “earthquake monitoring needs at least a 200-Hz data sampling rate, whereas […] some samples per day may be enough.”

Two hundred readings a second for an earthquake, a handful a day for temperature and humidity: two orders of magnitude. It is not a default menu option — it is a contractual requirement, specific to each parameter, to be written alongside the threshold.

Why the inspection round is not enough

Clause 7.1 explains why sending someone to look is not enough: “The objective of the monitoring system is to detect defects at an early stage, and to deliver warning messages to disaster managers rapidly when the defects are not tolerable.” And the limit of the human eye alone: “small defects that may cause great disasters are apt to be overlooked by only manual inspection.”

Clause 6.4 describes the manual flow — patrolling, visual inspection, a detailed investigation if defects turn up. Sensor systems “omit some of these stages and thus make it labour-saving and efficient” and “allow facility staff members to quickly find critical data”. They do not replace visual inspection — see our note on inspection frequencies under L.330, published this morning — but they cover its blind spot: the small defects the human eye, on large and scattered plant, almost never comes across.

See the service · Talk to an engineer

Seven requirements, one by one

Clause 7.2 lists seven general requirements, and each one is already a line in a specification:

designed to carry out proper response action rapidly in an emergency;
reliable and proven technology, to avoid false alarms;
operated in real time or near real time;
alerting without delay for facility staff;
interoperability with national emergency and disaster management systems, where applicable;
security measures ensuring authentication, encryption and data integrity;
evaluated and verified before application, with regular checks.

The last — “evaluated and verified before application and regularly checked” — is the acceptance-testing clause written into the standard itself: you prove the alarm trips before the system goes into service, and then periodically, rather than installing and hoping. The second-to-last is the NIS2 bridge: a system with explicit authentication, encryption and data-integrity requirements is, in effect, an information system — and for an NIS entity, a malfunction in it is an incident to be assessed, not an ordinary fault.

Push, not pull

Clause 7.3.3 distinguishes pull, which polls the sensors at fixed intervals, from push, which transmits only when an event exceeds a preset level: “proactively transmits sensed data only when an event exceeds a predetermined level”. The recommendation is unambiguous: “It is recommended that a push model be used for disaster monitoring systems. Hybrid models […] may be used to enhance system resilience.” A detail to write into the specification, not a factory default.

Wired, wireless, and the fibre that feels

Clause 7.3.1.1 brings the recommendation to exactly where we work every day: “For the application of distributed fibre optic sensing (DFOS) technique, the optical fibre itself is used as sensor.” The fibre stops merely carrying the signal and becomes the sensor itself — deformation, vibration, freeze-induced stress, per Table 3 — the same principle behind our note on vibration-based cable identification, L.316.

Table 2 compares wired and wireless. Wired is “stable and proven technology” but “expensive to install”, with cables that “can fail due to exposure to the environment” and degrade the signal over long distances. Wireless cuts costs, but “power and communication bandwidth available on the node are very limited” and each node has “limited battery life”. Clause 7.3.1 sums it up: “Wired systems generally provide higher reliability, while hybrid wired/wireless solutions may offer improved redundancy and resilience.”

Table 1 gives landslides the row that carries the image for this piece: “Duct bursts and disconnection of cables” and “Failure of earth retaining structures” — a retaining structure failing and taking with it the duct running alongside it. Measures: “Periodic inspection”, “Monitoring by measurement”, “Installation of monitoring system”. The same logic applies to collapse, with the constraint on adjacent construction — the principle behind our note on excavation coordination — and to flooding of cable tunnels, where the preventive measure is a piezometer or a water-level monitoring system.

What L.391 does not cover

Two clarifications. L.391 excludes fire: “disasters due to fire are not considered in this Recommendation because disaster management concerning fire is described in [b-ITU-T L.20], [b-ITU-T L.21], [b-ITU-T L.22] and [b-ITU-T L.23]” — compartmentation of cable penetrations sits under a different series.

And, like every ITU-T Recommendation, it is not a law: “Compliance with this Recommendation is voluntary. […] The words ‘shall’ or some other obligatory language such as ‘must’ […] are used to express requirements.” It gains force once a client names it in a specification, with threshold, sampling rate and communication model spelt out line by line.

Two threads, applied

First thread: threshold, sampling rate, push model and the seven requirements of clause 7.2 become verifiable lines in the specification — and the last requirement becomes a written, dated acceptance test: you demonstrate the alarm trips at the intended value, rather than taking it on trust.

Second thread: sensor readings and thresholds set on a route do not stay locked in the sensor supplier’s portal. With CSIDIA, the group’s other company, they become a single map of the network on which an AI runs the diagnosis and the crew closes the fault — together with the as-built record: an inclinometer alarm on a slope is worth little on its own, worth a great deal if the system already knows the duct running underneath, with those particular joints. Within the client’s perimeter: on-premise, on standalone machines with no deep integration, or a dedicated cloud with a data centre in Italy, always with shared management.

Could you say, right now, at what exact value an alarm trips on your plant — and who signed off on that number, and when? Talk to an engineer: the site visit is free of charge, and it produces the list of monitored points on the route with, for each one, the threshold, the sampling rate, who decided it and when it was last tested — including the boxes that stay blank. It stays yours whatever you decide next.