▌ APPLICATION NOTE · OCTOBER 2026 · ACCIDENT BACK-TRACE After an Incident: How Logged Alarm Data Supports an Accident Back-Trace An incident on a tower crane changes the way everyone remembers the day. Accounts are collected quickly, and they are honest, but they are also shaped by what people saw, what they expected to see, and how much they can recall under pressure. The ZNAO-TG2 tower crane safety monitoring system, product code CR-SMS-TG2, logs alarms and the values around them, and that log is often what a back-trace review is built on. This application note looks at how logged alarm data supports a review after an incident: what the record can and cannot reconstruct, how a timeline should be read without jumping to conclusions, and how a finding turns into a change on site. It stays with the facts the system actually provides, sensing load weight, moment, trolley radius, hook height, slew angle, wind speed and tilt, raising overload and threshold alarms with a sounder, and logging alarms for audit, inspection and accident back-trace. 01 WHY MEMORY IS NOT ENOUGH After an incident, the first stories are usually told within minutes, and then repeated until they become the version everyone agrees on. That process is human and unavoidable, but it is also fragile. Two people can watch the same lift and remember the radius differently, and a supervisor who arrived after the event may carry more authority than the signalman who saw it. A log does not replace those accounts, but it gives the review something to check them against. The value of a record here is not that it makes people wrong. It is that it turns a disagreement about recollection into a question about data, and a question about data can be settled. Where the log and the accounts agree, the review can move on. Where they differ, the review knows exactly which moment to examine, which is far more useful than arguing about the whole shift. ▌ MEMORY DRIFTS Accounts of the same lift diverge as they are repeated, which is why a record is collected rather than recalled. ▌ DATA SETTLES POINTS Where the log and the stories agree the review moves on; where they differ it knows exactly where to look. ▌ RECORD BESIDE ACCOUNTS The log supports the people who were there and never replaces what they witnessed. ▌ A SHARED REFERENCE One record gives every participant the same numbers to discuss, which lowers the temperature of the review. 02 WHAT A LOG CAN RECONSTRUCT The system senses load weight, moment, trolley radius, hook height, slew angle, wind speed and tilt, and it raises overload and threshold alarms with a sounder. A review can therefore reconstruct the values that were live at the moment of an alarm, how close the crane was running to its limits in the period before it, and whether the same pattern appeared earlier in the shift or on previous days. The stated resolutions shape how detailed that reconstruction can be. Radius to 0.1 m, height to 0.1 m, slew to 0.1 degrees, load to 0.01 percent and wind to 0.1 m/s mean the record can distinguish a lift that was near a limit from one that was well inside it. That level of detail is what lets a review describe a lift in numbers rather than in adjectives. Zone and collision data add further context. Zone limiting of line, triangle, quadrilateral and circle obstacles, up to 8 zones, and group anti-collision with multi-crane auto-networking and pre-warning can show whether a boundary or a neighbouring crane was part of the situation, which is often exactly the question a back-trace is trying to answer. ▌ SEVEN LIVE VALUES The record holds the seven sensed quantities plus the alarm events around them, so the lift can be described in data. ▌ STATED RESOLUTION Radius and height to 0.1 m, slew to 0.1 degrees, load to 0.01 percent and wind to 0.1 m/s keep the reconstruction specific. ▌ ZONE AND COLLISION CONTEXT Up to 8 line, triangle, quadrilateral or circle zones and group anti-collision pre-warning can show whether a boundary was involved. ▌ CONDITIONS AS WELL AS LOAD Wind speed and tilt are part of the record, so a change in conditions is not left out of the picture. 03 READING A TIMELINE WITHOUT ASSUMPTIONS A timeline is easy to read badly. The temptation is to start at the alarm and work outward looking for a cause, which is a good way to find the cause you already expected. A more disciplined approach is to read the record in order, note what the values actually did, and only then ask what might explain the pattern. It also helps to separate what the log shows from what it implies. The log shows that wind rose and that the moment climbed. It does not show that the operator hesitated or that the signalman changed the plan, because those belong to the accounts. Keeping the two apart is what makes a review defensible, since it refuses to present a measurement as a motive. Repeat patterns are the strongest signal in any timeline. A single alarm at an unusual moment may be an accident of the day, while the same alarm at the same stage of the same operation, morning after morning, is a procedure that has been tolerated. A back-trace that finds a repeating pattern has found something more useful than a single cause, because a procedure can be changed. ▌ READ FORWARD Read the record in time order first, then ask what might explain it, so the cause is not chosen before the data is seen. ▌ SHOWN VERSUS IMPLIED Measurements show what happened; intent comes from the people, and the two must not be merged. ▌ REPETITION IS THE SIGNAL A pattern that recurs at the same stage of a cycle points to a procedure, not to a single unlucky moment. ▌ CONTEXT FROM THE CREW The operator and signalman explain the decisions the log cannot see, so the review should hear them before concluding. 04 FROM FINDING TO FIX A review is only finished when something changes. The finding might be a setting that was too loose, a lift plan that did not match the load, a zone that was never drawn, or simply a habit of leaving the system off. Each of those has an owner and a fix, and the value of the back-trace is that it points to the specific one instead of to a general sense that something went wrong. The record also supports the slower work of improvement. Because the system exports over RS485, USB and LAN from a Linux host, and can dock to an enterprise or regulatory cloud, the data from the incident can be kept alongside ordinary shift data. Over time that gives a site a picture of how a crane normally behaves, which is the only reliable way to recognise what was abnormal about the day in question. It is worth involving the crew in the fix rather than only in the review. The people who work the crane every day are the ones who can say whether a new setting will be followed or quietly worked around. A back-trace that ends in a rule the crew does not accept has replaced one problem with another, so the fix should be built with them. ▌ FINDING NEEDS AN OWNER Each conclusion should name the change it requires and the person responsible for making it. ▌ KEEP THE DATA RS485, USB and LAN exports from the Linux host, with optional cloud docking, let incident data sit beside everyday records. ▌ NORMAL AS A BASELINE A record of ordinary shifts is the only reliable way to judge what was unusual about one day. ▌ INVOLVE THE CREW A fix the operators helped shape is far more likely to be followed than one handed down after the review. 05 THE LIMITS OF ANY RECORD A log is evidence, and evidence has edges. It records what the sensors measured, at the resolution they measure it, while the system was powered and healthy. It does not record why a decision was made, what was said over the radio, or whether the load was rigged as the plan intended. A review that treats the log as complete will reach a confident conclusion the data does not actually support. The record also depends on maintenance and on the standards that apply in a market, such as ISO 12480-1, EN 14439, BS 7121, LOLER 1998 or OSHA 29 CFR 1926 Subpart CC. A sensor that has drifted, a display that was not checked, or a system that was powered down for part of the day all leave a gap that a later review may read as quiet rather than as missing. Knowing that is what keeps a back-trace honest. Used within those limits, logged alarm data does something no recollection can. It holds a version of events that does not change as the weeks pass. That is its real contribution to a review, and it is strongest when the site has kept the system running and treated the log as a working record rather than a document produced after the fact. ▌ EDGES OF EVIDENCE The log documents measured values; it does not document reasons, radio traffic or rigging. ▌ GAPS READ AS QUIET A system that was off or unwell leaves a gap that a later reader may mistake for an uneventful period. ▌ MAINTENANCE MATTERS A drift or a fault in the sensing chain is itself part of what a careful review must account for. ▌ A STABLE VERSION The log holds one version of events that does not shift with time, which is what no recollection can offer. PROCUREMENT IMPACT ● Ask what the system logs and how easily the log is exported, because a record that cannot be retrieved after an incident is of little use in a back-trace. ● Confirm the stated accuracy of each sensed value, since the credibility of a reconstruction rests on the resolution behind it. ● Check how sensor faults appear on the record, so that a gap is visible to a later reader instead of looking like a quiet period. ● Plan where the data will be kept, on the Linux host at the crane, an export over LAN, or a docked enterprise or regulatory cloud, and treat network provision as part of the evidence system. ● Consider zone limiting and group anti-collision at the same time as the logging, because both can supply the context a back-trace later needs. WHAT TO WATCH ● Watch whether the log is kept running across all shifts, because the commonest weakness in any back-trace is simply a system that was switched off. ● Watch the review process itself, and make sure it separates measured values from the accounts of the people who were there. ● Watch for repeating patterns across days, because a recurring alarm is the finding most likely to lead to a lasting change. ● Watch that every finding leaves with an owner and a date, since an unowned conclusion quietly disappears. ● Watch the standard that applies in your market, and keep the record in whatever form that regime requires after an incident. ABOUT ZN Industrial (Shandong Zhinuo) designs and manufactures crane safety monitoring systems, positioning systems and mechanical auxiliary handling equipment for overseas construction, industrial and steel markets. Standards and regulations vary by market — local rules still govern your site. ▌ CONTACT shandongzhinuo@outlook.com +86 176 6371 0314 · en.znaqkj.com SOURCES · ISO 12480-1 · EN 14439 · BS 7121 · LOLER 1998 · OSHA 29 CFR 1926 Subpart CC |
Articles / crane
After an Incident: How Logged Alarm Data Supports an Accident Back-Trace
An accident back-trace is built on the alarm log, not on memory alone. This note explains how logged tower crane data reconstructs a timeline after an incident, what the record can and cannot show, and how a review finding turns into a change on site.
