Alarm thresholds in structural monitoring are set on two action levels, warning (WARNING) and alarm (ALARM), and the values come from the design, standards, a percentage of permissible values, or baseline-period statistics. A threshold on its own is not enough: it needs safeguards against false alarms, a separate NO_DATA state, and a who-what-when procedure. After the first 30 days of data, thresholds are tuned, not guessed.
In brief
- Two action levels are enough: WARNING means "verify", ALARM means "act". A third state, NO_DATA, is not the absence of a problem, but a separate problem with its own procedure.
- Threshold values come from design, standards, a percentage of permissible values, baseline-period statistics (mean ± k·σ), and experience from similar structures. Usually two sources are used at once: one says what is dangerous, the other what is unusual.
- A threshold on value is blind to rate. In the assessment, include trend (mm/day) and rate of change, and for vibration use the dynamic envelope.
- Seven safeguards against false alarms: hysteresis, minimum duration, temperature compensation, jump validation, NO_DATA instead of zero, current calibration, baseline period.
- The reaction plan is a table with names and times, signed before the first alarm, not after it. A ready-made skeleton is below.
An alarm that nobody cares about is the worst kind of alarm
Imagine a site manager who, in the first week after a deep excavation monitoring system is started, receives dozens of SMS messages. All of them come from the same inclinometer on a sunlit wall of the adjacent building, all between 13:00 and 16:00, all marked "WARNING". In the second week, he stops reading them. In the third week, he asks for notifications from that channel to be switched off. In the fourth week, the channel shows a real exceedance, and the SMS ends up in the same place as the previous ones. This is a hypothetical scenario, but anyone who has commissioned a measurement system will recognise something familiar in it.
If you are responsible for such a system, you fear two things at once: that the alarms will be false and people will stop reading them, and that the one real alarm will arrive at 3:00 to nobody. Both fears are valid, and both are treated with the same set of measures: thresholds from two sources, pre-threshold filters, and a post-threshold procedure. This text gives you a ready-to-use item, a reaction matrix to fill in with names, and a checklist for tuning after 30 days.
An early warning system in structural monitoring is a set of thresholds, rules for assessing them, and response procedures that turns a stream of measurements into a decision by a specific person at a specific time. If there is no person at the end of the chain who knows what to do with an SMS, then it is not an early warning system, but an archive.
Thresholds fail in three ways. Too tight, and they generate noise and train people to ignore alarms. Too loose, and they stay silent until the structure, not the engineer, has already made the decision. Thresholds without a procedure go nowhere. If you are just starting with the topic, begin with the complete structural monitoring guide - here I assume you know what you are measuring and are asking when the phone should ring. A reading every 15 minutes by default, or more often, gives a time advantage, which we discuss in the post about what "100x faster" really means, but a fast reading with the wrong threshold is fast information about nothing. First thresholds and procedure, then frequency.
Threshold value sources: where to get the numbers
An alarm threshold is a value of the measured quantity, or its derivative (trend, rate), whose exceedance triggers a predefined procedure. Where do you get that value from? From one of five sources, and in practice from two at once.
| Source | When it makes sense | Pros | Cons |
|---|---|---|---|
| Design / calculations (displacements and strains calculated for a given stage) | excavations, retaining systems, temporary structures, observational method per Eurocode 7 | physical meaning; responsibility for the number lies with the designer | often only a final value, with no intermediate values for phases; rate of change is rarely given |
| Standards (PN-B-02170 - vibration and buildings, SWD scales; PN-B-02171 - vibration and people in buildings) | vibration from construction, traffic, machinery | ready-made criteria; easy to defend in a dispute | narrow range of quantities; they will not tell you anything about the tilt of your specific wall |
| Percentage of permissible values (capacity, limit displacement, deflection) | a known limit value, two levels below it are needed | simple convention understandable to the site manager and designer; time reserve for response | a percentage is an agreement, not a physical law; it must be agreed and recorded |
| Baseline-period statistics (mean ± k·σ from data before influence starts) | adjacent buildings before works, existing structures, channels without a design value | detects that "something has changed", even when the value is small; captures real channel noise | tells you about unusual behaviour, not danger; requires a period without influence; sensitive to season |
| Experience from similar structures | no design and no baseline period; fast start | realistic order-of-magnitude values immediately | not transferable without justification; hard to defend when asked "why exactly this much" |
The rule I use: if there is a design or standard value, it defines ALARM. Baseline-period statistics define WARNING. The first answers the question "is this dangerous", the second "is this unusual". Both are needed, because a structure can stay within the design limits and still do something it has not done before, and that is exactly the information for which sensors are installed.
Percentage of permissible value - illustrative example
Assume, for illustration, that the designer allows a horizontal displacement of 30 mm at the top of a diaphragm wall in the final excavation stage. A convention often agreed is WARNING at 60% (18 mm), ALARM at 80% (24 mm). The remaining 20% is the reserve for the procedure, time for verification, decision and action before the structure reaches a value that the designer can no longer defend by calculation. These percentages do not come from a standard; they come from how much response time you need at a realistic rate of change. How to distribute measurement points and thresholds by work phase is described in the post on deep excavation geotechnical monitoring.
Baseline-period statistics: mean ± k·σ
The baseline period is the time after sensor installation and stabilisation, and before the start of influence (works, loading), from which the "normal" behaviour of the channel is calculated. From this period, you determine the mean (m) and standard deviation (σ) for each channel, and set the threshold as m ± k·σ. The coefficient k = 3 is a classic starting point: for a distribution close to normal, just under 0.3% of readings will fall outside ±3σ by chance.
Illustrative example. An inclinometer on the wall of a tenement house next to a planned excavation, 14 days of baseline period, reading every 15 minutes by default, or more often. After zeroing, the mean tilt is 0.00 mrad, σ = 0.04 mrad. The statistical threshold at k = 3 is ±0.12 mrad. What is that in millimetres? Displacement at height H is calculated as Δ = φ · H, where φ is given in mrad, H in metres, and the result is in mm (1 mrad over 10 m is 10 mm). For a 12 m wall, that gives 1.44 mm at the top. This is a very sensitive threshold: it will detect change, but it will not tell you whether the change is harmful. That is why beside it stands a structural threshold, agreed with the structural designer or expert for that building, which defines ALARM. How to organise this on the site manager's side is described in the post about monitoring neighbouring buildings during construction.
Two traps of the baseline period: if it includes only cloudy days, σ will be underestimated and summer afternoons will trigger alarms; if the sensor was still settling after installation, the mean and σ describe the installation, not the structure. Minimum 7 days, better 14, best 30 - with at least one weather front passage.
Two levels or three?
Two action levels are enough if each has a different procedure. A third makes sense only if it triggers a different response by different people, for example in the emergency action plan of the observational method. PN-EN 1997-1 (Eurocode 7), clause 2.7, requires that before construction starts, the limits of acceptable behaviour, a monitoring plan that reveals exceedance early enough, and an emergency action plan in case the limits are exceeded be established. Further thresholds are further, predefined actions from that plan. In the second generation of Eurocode 7 (EN 1997-1:2024), the observational method remains, but the clause numbering is different, so before citing it in documentation, check the current edition. If two levels have the same procedure, then it is one level. NO_DATA is not a third level - it is a separate axis.
What this means for you: before you enter the first number, establish which source it comes from and who is responsible for it - the designer for ALARM, you for statistical WARNING. That one decision orders everything below.
WARNING / ALARM / NO_DATA - three states, three procedures
At any moment, every channel is in one of four states: OK, WARNING, ALARM or NO_DATA. The last three require separate procedures, because they mean three different things.
WARNING is the state in which the value or trend has exceeded the warning threshold, but not the alarm threshold. It means: "something is happening, verify it". Procedure: the duty person checks whether it is the channel or the structure - looks at adjacent sensors, temperature, the communication log and what was happening on site at that time. The assessment is entered into the log. If it is the structure, alertness increases: more frequent checks, information to the works manager, possibly a manual measurement. Response time: the same day. WARNING does not stop the works; WARNING stops the assumption that everything is fine.
ALARM is the state in which the alarm threshold has been exceeded - the value agreed with the designer as the boundary above which calculations do not guarantee safety. It means: "act now". Procedure: phone, not email. Stop the works in the influence zone. Who can issue such an order must be written down in advance. Site inspection. Decision by the designer or structural engineer on further action. Response time: minutes to acknowledge receipt, first decision within one hour, also outside working hours, which is why the SMS recipient list must include substitutes.
NO_DATA is the state in which no reading has arrived from the channel within the expected time window, for example for an hour at a 15-minute cycle, i.e. after four missing readings. NO_DATA is not zero and is not OK. It is information that you are blind on that channel. The causes are usually mundane: power supply, coverage, damaged cable, frozen logger, excavator. Procedure: service checks power and transmission, determines the cause and the restoration time. If the channel is critical for the current work phase (an inclinometer in a wall you are deepening today), treat NO_DATA like WARNING: manual measurement or slowing the works until data is restored. The duration of NO_DATA is measurable and should be reported as data completeness (data SLA) - a gap in the record is a gap in evidence, as we write in the text about monitoring data as evidence in a dispute.
Return to OK is also an event. An alarm that vanished on its own, without assessment, is not a closed case, but a case that nobody opened. Closing an event should require human confirmation (who took it over, what was established), not just the value dropping below the threshold.
What this means for you: three states are three different phone calls to three different people. If today they all go to the same inbox, you have one state, and it is called "noise".
Value, trend, rate, dynamic envelope
A structure rarely fails suddenly. Usually it is moving somewhere at a certain rate, and the rate is earlier information than the level. Hence four kinds of criteria.
A value threshold (absolute) compares the current reading with a fixed number. It is the simplest and most common, and blind to direction and rate: 8 mm achieved in one year and 8 mm achieved in four days look identical to it.
A trend criterion compares the slope of a line fitted to readings from a time window, usually 24 h or 7 days, with a fixed value, for example in mm/day or mrad/day. Illustrative example: the wall has 8 mm out of 30 mm allowable - the value threshold stays silent. But the 8 mm appeared in four days, i.e. 2 mm/day. At that rate, 24 mm (conventional ALARM) is a matter of eight days. A trend criterion set at 1 mm/day would act on the second day, with a week of margin. Trend should be calculated on data cleaned of daily fluctuations (daily mean or comparison of readings from the same hour), otherwise the 24 h slope will show temperature, not the structure.
A rate-of-change criterion is the same idea over a shorter window, hours rather than days, aimed at sudden events: impact, breakthrough, sudden unloading. mm/h fits here. It makes sense for works that can damage something in a single shift: piling, demolition, dewatering.
Not every platform calculates trend and rate as a separate automatic alarm. Then the trend criterion does not disappear - it moves into the procedure: the duty person who verifies WARNING assesses the slope from the chart and statistical reports (7-day and 30-day drift, z-score against the baseline period), and the limit value in mm/day sits in the reaction matrix as the criterion for informing the designer. Worse than having no automation is only having no criterion.
The dynamic envelope applies to vibration. A vibration event lasts seconds. A single quasi-static reading at the default 15-minute interval does not replace a vibration time history; a separate dynamic acquisition path, such as event-triggered recording, is needed. A dynamic alarm compares the recorded event - peak or RMS value and the distribution of energy across bands (FFT spectrum, third-octave bands) - with a defined limit curve. For building structures, the reference is PN-B-02170:2016-12, which in the approximate method uses SWD-I and SWD-II scales and assesses the maximum values of the velocity or acceleration of the horizontal components in third-octave bands, measured at the foundation or ground level. For people in buildings, PN-B-02171:2017-06 applies, which assesses vibration in the place where people stay, in the 1-80 Hz bands, by RMS values compared with a perception threshold depending on the room use and time of day. Peak value alone is not enough, because the same amplitude at 5 Hz and at 60 Hz means something different for the structure. Hence the frequency envelope, not one number.
A typical set for a displacement or tilt channel: WARNING and ALARM on value plus a trend criterion in the procedure, or as an alarm if the platform calculates it. For vibration channels: dynamic envelope. For auxiliary channels (temperature, reference piezometer), WARNING alone is often enough, because they are used for interpretation, not for decision-making.
False alarms: 7 causes and 7 safeguards
A false alarm is a threshold exceedance that, after verification, does not correspond to a change in the structure's state. Each one costs time, system credibility, and after a few weeks, human attention. Seven most common causes and the safeguard for each:
| # | Cause | What it looks like on the chart | Safeguard |
|---|---|---|---|
| 1 | Oscillation around the threshold - channel noise jumps across the threshold in both directions | series of alarm / return / alarm every few readings | Hysteresis: the threshold for returning to OK is lower than the threshold for entering WARNING (illustratively by 5-10% of the threshold value or by 1σ) |
| 2 | A single disturbed reading - someone leaned on the sensor, a roller passed by, electrical disturbance | one bar far from its neighbours, next reading back to normal | Minimum duration: the state changes after N consecutive readings above the threshold (e.g. 2-3 15-minute cycles); a 30-45 minute delay for static phenomena is negligible |
| 3 | Daily thermal "breathing" - the structure and sensor respond to sun and night | daily sine wave, peaks at the same time | Temperature compensation / daily filter: thresholds on compensated values or on daily mean; a multi-axis tilt-temperature plot distinguishes breathing from a permanent trend |
| 4 | An order-of-magnitude jump - transmission error, wrong frame, changed unit in the logger | physically impossible value (e.g. 40 mm in 15 min on a diaphragm wall) | Jump validation: maximum physically possible change between readings; reading outside the sensor range rejected and flagged, instead of a structural alarm |
| 5 | No reading interpreted as zero - logger or software writes 0 where there is no data | sudden drop to zero and "negative displacement" alarm | NO_DATA instead of zero: missing data is a separate state with a separate procedure; zero is a value, not the absence of a measurement |
| 6 | Sensor drift / outdated calibration | slow, monotonic trend on one channel, without confirmation on adjacent ones | Calibration: keep track of calibration intervals (calibration debt), zeroing after stabilisation, comparison with a redundant channel; trend on one sensor in a group is a suspect sensor, not the structure |
| 7 | Thresholds set "from the head" on installation day | alarms from the first day, unrelated to the works | Baseline period: statistical thresholds after 7-30 days, design thresholds immediately; zeroing after installation stabilises, not on the day of tightening |
Alarm hysteresis is the difference between the threshold for entering a state and the threshold for returning from it, which prevents repeated switching of state when readings oscillate around the boundary. Minimum duration is the number of consecutive readings (or minutes) above threshold required to change state. Where the platform does not provide it, the same role is played by a procedural rule: "a single reading is verified, two consecutive readings are treated as a state". These two parameters, not the threshold value, are the first place to look when there are too many alarms. Raising the threshold "because it is noisy" is treating a fever by throwing away the thermometer.
What this means for you: before moving the threshold, go through the list from 1 to 7 and name the cause. Six out of seven false alarms can be removed without changing a single limit value.
Reaction plan: who-what-when matrix
A reaction plan is a document that assigns each state of each channel, or group of channels, specific people, actions and times. Without it, an SMS is information; with it, it is an instruction. The skeleton is filled in with names and phone numbers before the first reading. The times are illustrative, a proposal to be agreed, not a standard. The "escalation" column is an organisational rule: the notification goes to everyone on the list at the same time, and whoever sees an unacknowledged notification after the deadline calls on their own, not waiting for the system to do it.
| State | Who gets the notification (SMS + e-mail) | What they do | By when | Acknowledgement / escalation (organisational rule) |
|---|---|---|---|---|
| WARNING | duty monitoring engineer; works manager (e-mail) | verifies the channel (adjacent sensors, temperature, communication log, site diary), assesses the trend, records the assessment | acknowledgement within 1 h during working hours; assessment the same day | no acknowledgement in 2 h - substitute calls the site manager; two WARNINGs in 24 h on one channel, or trend above __________ mm/day - inform the designer |
| ALARM | duty engineer; site manager; designer / structural engineer; supervision inspector (per contract); substitutes | phone call to the site manager, stop works in the zone, inspection, designer's decision; documentation (photos, note) | acknowledgement within 15 min, also outside working hours; first decision within 1 h | unacknowledged in 15 min - substitute takes over and calls; no designer's decision in 1 h - investor |
| NO_DATA - critical channel (e.g. inclinometer in a wall during the current deepening phase) | duty engineer; service; works manager | service: power, transmission, logger; works manager: manual measurement or slowing the works until data is restored | diagnosis within 2 h; data restored the same day | no data for more than 4 h in a critical phase - treat as WARNING; more than 24 h - site manager's decision to stop works in the zone |
| NO_DATA - non-critical channel | service | determines the cause, plans repair, records the date | diagnosis on the next working day | gap longer than 72 h - information to the project manager; gap recorded in the data completeness report |
| Return to OK | duty engineer | closes the event with a description of the cause and findings; if the cause was measurement-related, sends it for tuning | at closure | an event without a cause description is not closed |
Three rules around this table. Each alarm has one owner who has "taken it over", visible to the others, so that it does not happen that nobody calls because everyone thinks someone else is calling. Silencing an alarm always has a deadline and a reason; indefinite silencing means switching off the channel without admitting it. The recipient list is made up of roles with substitutes - the duty person's leave cannot be a gap in the system.
What this means for you: copy the table into the contract document, fill in the names, numbers and trend value, and have it signed by the site manager and the designer. From that moment on, every SMS has a recipient.
Threshold tuning after 30 days of data
Thresholds set on the day of start-up are a hypothesis. After 30 days, you have data to test it: weekly cycle (works versus weekend), several weather changes, the first events. Tuning is a procedure, not a one-off decision, and it should leave a trace.
- Calculate the statistics for each channel from 30 days: mean, σ, daily amplitude, extreme values, completeness (NO_DATA).
- Review the alarm log: how many WARNING and ALARM, how many confirmed as structural change, how many measurement-related, how many thermal. Group the false ones by cause from the table above.
- First filters, then values. Thermal - temperature compensation or daily mean. Oscillatory - hysteresis. Single-event - minimum duration or the "two consecutive readings" rule. Only then consider the threshold value.
- Recalculate statistical thresholds from the new period: 30 days gives better m and σ than 14. A proposal calculated from historical percentiles (e.g. 98th percentile for WARNING) tells you what is unusual for that channel - it is a "verify" threshold, not an "act" threshold. If WARNING was design-based, leave it; its task is not to ring often, but to ring when it should.
- Do not raise a design-based ALARM threshold on your own. Tuning applies to WARNING, filters and trend criteria. Changing ALARM is the designer's decision, in writing - also when the statistics suggest another value.
- A change in work phase means a threshold review. Moving from deepening to anchoring, from test loading to service - each phase has different allowable values and different rates.
- Record who changed what, when and why. Threshold history is part of the measurement documentation: when someone asks in two years why the threshold on channel 7 was raised in week three, the answer must be in the platform, not in someone's memory.
Illustrative example: a tilt channel on the south elevation gave several WARNINGs in 30 days, all on sunny afternoons, none confirmed on adjacent channels. The conclusion is not "raise the threshold twofold", but "enable temperature compensation and calculate WARNING on the compensated value". After the change, the channel still detects a permanent trend - it just stopped ringing for the sun.
Statistical anomaly detection (z-score calculated continuously) complements this procedure: it suggests which channels behave differently from the baseline period before they exceed the threshold. It does not replace design thresholds and does not make decisions - where the boundary lies is described in the post about AI in structural monitoring.
What it looks like in Inclify
In Inclify there are three alarm types: threshold, no data (NO_DATA) and dynamic (vibration envelope). The threshold alarm is set per channel: WARNING threshold, ALARM threshold, comparison direction and hysteresis. The NO_DATA alarm has its own time window (default 60 minutes, i.e. four missing cycles with a reading every 15 minutes by default, or more often) - after that, the channel moves to NO_DATA, not zero. The state of each channel - OK, WARNING, ALARM or NO_DATA - is visible in the project panel, and every transition between states is stored in history with the value that triggered it.
Notifications are sent by email, SMS and in-app to users subscribed to the given project; each user chooses the channels and the minimum state from which they want to be awakened, and the administrator always receives ALARM. Repeats of the same alarm are limited by the calm-down time (default 60 minutes), but the transition from WARNING to ALARM and the return to OK are always sent. You acknowledge an alarm with a single action - the platform records who took it over and when, and shows it to the others - and you can silence it for a set period (from one minute to one year); indefinite silencing does not exist by design. Alarm creation, change, disabling, acknowledgement and silencing are added to the audit log, so point 7 from the tuning list happens automatically.
To be honest about what is not there: the platform does not currently calculate alarms on trend or rate of change, does not have a minimum duration parameter for exceedance, and does not automatically escalate to the next person when nobody acknowledges. You assess rate of change from a multi-axis chart (tilt against temperature), from a calibration debt report (drift as a 7-day and 30-day slope), and from a 7/30-day risk report (z-score, EWMA, CUSUM per channel); escalation and the "two consecutive readings" rule are written into the reaction matrix, which is why it is ready to copy in this text.
The alarm tuning report calculates threshold proposals for each channel from historical percentiles (WARNING from the 98th, ALARM from the 99.5th percentile) and shows how many events per week each variant would generate; you can apply the proposal with a single action or reject it. Alongside it, temperature compensation, calibration debt and data SLA reports (completeness, gaps, freshness) cover the causes 3, 5 and 6 from the false-alarm table. For vibration channels, the dynamic alarm compares RMS and MAX in 21 third-octave bands (1-100 Hz) with the reference envelope - the warning and alarm level are a fraction of the envelope, with hysteresis - and for each event you have the time history and FFT spectrum. The communication log with raw frames from devices (default 7 days) lets you verify WARNING in a few minutes; years later, the evidence is measurements in the database with UTC time and the alarm state history. Details: /platform/monitoring.
FAQ
How many alarm threshold levels should be set - two or three?
Two action levels: WARNING ("verify") and ALARM ("act"), each with its own procedure and its own recipients. A third level makes sense only if it triggers truly different actions, for example further steps in the emergency plan under the observational method. NO_DATA is not a third level, but a separate state meaning missing data, with its own service procedure. If two levels have the same procedure, merge them.
Where do I get threshold values if the design does not provide them?
Ask the designer for permissible values for the given phase and set WARNING and ALARM as an agreed percentage of them. In parallel, after the baseline period (7-30 days without influence), determine a statistical threshold as mean ± 3σ - it will catch a change in behaviour, even a small one. For vibration, use PN-B-02170 and PN-B-02171. Treat values "from experience" as a starting point, not as justification.
How does a threshold on value differ from a trend criterion?
A threshold on value compares the reading with a fixed number and does not see rate: 8 mm in one year and 8 mm in four days look the same. A trend criterion compares the slope from a window (for example mm/day from 24 h or 7 days) and responds to direction and rate of change, usually earlier. They work well together: design value, baseline trend, both calculated on data cleaned of daily temperature fluctuations. If the platform does not calculate trend as an alarm, put the limit value in mm/day into the duty procedure.
What should be done with NO_DATA?
Treat it as a separate state, never as zero and never as OK. Service checks power, transmission and the logger, and sets the restoration time. On a channel critical for the current work phase, treat NO_DATA like WARNING: manual measurement or slowing the works until the data returns. Report the duration of NO_DATA as data completeness - a gap in the record is a gap in evidence.
How often should thresholds be tuned?
The first review after 30 days of data, then whenever the work phase or loading changes, and after every event that turned out to be false for measurement reasons. First filters (hysteresis, minimum duration or the two-reading rule, temperature compensation), then threshold values. A design-based ALARM threshold is not changed without a written decision by the designer. Record every change: who, when, what, why.
Who should receive the alarm SMS?
Only people who need to act: the duty monitoring engineer, the site manager, and for ALARM also the designer or structural engineer, each with a substitute. Others (investor, supervision, management) receive email or a report, unless the contract says otherwise. The more SMS recipients you have, the faster the alarm turns into noise. This text describes engineering practice and does not constitute legal advice; the parties' obligations result from the contract, design and regulations.
Sources and further reading
- PN-EN 1997-1:2008 Eurocode 7: Geotechnical design - Part 1: General rules, clause 2.7 observational method (limits of acceptable behaviour, monitoring plan, contingency plan) - Polski Komitet Normalizacyjny, sklep.pkn.pl
- Borecka A., Stopkowicz A., Sekuła K., "Metoda obserwacyjna i monitoring geotechniczny w świetle przepisów prawa...", Przegląd Geologiczny 2017, vol. 65, no. 10/2 - full text (BazTech)
- PN-B-02170:2016-12 Assessment of the harmfulness of vibrations transmitted through the ground to buildings (SWD-I, SWD-II scales) - PKN, sklep.pkn.pl
- PN-B-02171:2017-06 Assessment of the effect of vibration on people in buildings - PKN, sklep.pkn.pl
- Stypuła K., "O zmianach w normie PN-B-02170...", Przegląd Budowlany 10/2017 - Biblioteka Nauki
- Regulation of the Minister of Transport, Construction and Maritime Economy of 25 April 2012 on determining geotechnical conditions for the foundation of building structures (§ 7, § 10 item 10 - scope of monitoring in the geotechnical design) - ISAP
- Act of 7 July 1994 - Construction Law (articles 22, 61, 62) - ISAP
- Manufacturers' documentation for loggers and sensors - sections on alarms, data validation and calibration: Campbell Scientific, Geokon
- Series entries: Structural monitoring (SHM): complete guide · Monitoring data as evidence in a dispute
What next
If you have a structure where thresholds were set once and nobody has touched them since, or you are just planning monitoring and want the first alarm to be real, the lowest entry point is a pilot on one structure or connecting sensors you already have. We will show, on a project similar to yours, what channel states, acknowledgements, time-limited silencing and tuning proposals look like, and we will walk you through the reaction matrix from this text. The Inclify team has been building and maintaining measurement systems for 15 years. These rules come from real structures, not from a handbook. The best moment is before the excavation phase or before the next review, while the baseline period can still be collected. We reply within 24 hours: let's talk. If you prefer to first read how alarms and channel states work in the platform, see /platform/monitoring.