Fixing TIM 1531 IRC Time Sync and IEC 60870-5 Data Updates

Scope and Disambiguation

Two very different problems get filed under "update date/time" in telecontrol projects, and they have separate root causes:

1. Setting or synchronizing the PLC/RTU real-time clock so event timestamps are correct.
2. Process data not updating at the IEC 60870-5 master, which operators frequently report as "the timestamp is old" even though the clock is fine.

This reference covers both on Siemens telecontrol hardware: the TIM 1531 IRC used with S7-300/400/1500, and the CP 1243-1 IEC path on S7-1200. If your platform is different, the clock-setting mechanism is vendor-specific — a generic IEC 61131-3 runtime (for example CODESYS-based controllers) exposes its own date/time function block library, and the setting method must come from that vendor's documentation rather than being assumed.

Time-of-Day Synchronization on the TIM 1531 IRC

The TIM 1531 IRC supports time-of-day synchronization via NTP over UDP port 123 on its Industrial Ethernet interfaces, and it can retransmit the received time on each of its interfaces so downstream stations inherit a single reference. The behavioral detail that catches people out during commissioning:

So a TIM sitting in STOP still tracks NTP but stops being time-disciplined by the telecontrol path. If your clock drifts only when the station is stopped for maintenance, that is expected behavior, not a fault — configure NTP as the primary source if you need clock continuity through STOP.

Commissioning checklist for NTP

1. Verify UDP 123 is permitted end-to-end through firewalls, NAT devices, and any telecontrol router between the TIM and the NTP server. Blocked 123 is the single most common cause of a clock that never leaves its power-up value.
2. Confirm the NTP server address, update interval, and time zone / DST handling in the TIM's interface configuration. Decide once whether the plant standard is UTC on the wire with local display at the HMI — mixing conventions produces exactly one-hour or whole-hour timestamp offsets that look like a protocol bug.
3. If the TIM is configured to retransmit time on an interface, make sure no second time master is active on that same subnet. Two masters produce sawtooth timestamp behavior in the event journal.
4. Record the acceptable drift budget. If sequence-of-events resolution matters to the application, NTP must be reachable continuously, not only at startup.

Firmware handling

TIM 1531 IRC firmware images are signed and encrypted; only Siemens-created images will load. That eliminates a class of failed-update troubleshooting — if an image is rejected, it is not the correct signed file for that device, not a corrupted transfer to be retried indefinitely. Siemens advises checking regularly for firmware and security updates, and timestamp/clock handling is one of the areas where behavior has changed between revisions. Full details are in the TIM 1531 IRC Operating Instructions.

Clock Synchronization from an IEC 60870-5-104 Master

On the IEC path, the master can discipline the station clock with the clock synchronization command C_CS_NA_1. Before you assume the station is ignoring it, check that the station actually declares support for that type identification. The CP 1243-1 IEC 60870-5-104 Interoperability List V1.2 is the authoritative list for the S7-1200 IEC path and documents the supported ASDU types and cause-of-transmission codes, including:

If the master logs an unknown type identification or a negative confirmation for a clock-sync or interrogation command, compare the command the master actually emits against the interoperability list for the exact device and firmware in the field. Do not assume symmetry: a type the master supports is not necessarily a type the station accepts.

Root Causes: Data Points That Never Update at the Master

Configuring an S7-1500 as an IEC 60870-5-101/104 station is done with a TIM 1531 IRC configured as an independent device, not as a classic CP attached to the CPU. That structural difference changes where the data point list lives and how it is addressed. Work through these causes in order:

1. Value monitoring not activated. On each data point, value monitoring must be activated before the transmission type / class (spontaneous vs. interrogation) can be selected. A data point left without monitoring has no trigger, so it produces nothing spontaneously and appears frozen on the master. This is the single most common cause of "data not updating."
2. Datapoint index mismatch. Each data point receives an automatically assigned Datapoint index. That index must match the variable configuration on the IEC master. If indexes shift because data points were inserted or deleted mid-project, the master reads valid traffic against the wrong tags — values update but land on the wrong objects, or on objects nobody is watching.
3. Wrong transmission type for the signal. Spontaneous transmission is driven by threshold / value monitoring; slow-moving analogs configured with a large threshold legitimately transmit rarely. Cyclic transmission and general interrogation are separate mechanisms. A tag that only appears after a general interrogation was never configured for spontaneous transmission.
4. Manual version drift. Data point dialogs and parameter names changed between manual revisions. Verify parameter names against the TIA Portal and firmware version actually installed, using the IEC 60870-5 Configuration Manual and the later revision of that manual.
5. Station in STOP. Covered above — telecontrol-path time sync is disabled in STOP, and process data sourced from the CPU program stops changing entirely.

Verification Procedure

1. Clock: read the station time from the engineering tool and from the master's event log simultaneously. Note the delta. Repeat after 24 hours to measure drift with NTP disabled, then with NTP enabled, to prove the sync path.
2. NTP reachability: confirm the configured server responds on UDP 123 from a device on the same subnet as the TIM interface. If the TIM retransmits time, verify a downstream station picks it up.
3. Data point trigger: force one process value past its configured monitoring threshold in the CPU program and confirm a spontaneous ASDU with a CP56Time2a timestamp arrives at the master within the expected window.
4. General interrogation: issue a GI from the master. Every configured data point must respond. Points that answer GI but never report spontaneously have a transmission-type/monitoring configuration problem, not a link problem.
5. Index audit: export the data point list from the station configuration and diff it against the master's variable list by Datapoint index. Do this after every configuration change that adds or removes points.
6. Timestamp sanity: after clock changes, confirm event timestamps in the master journal are monotonic. A backward step indicates two competing clock authorities.

For an end-to-end worked example of transmitting process values from S7 stations to an IEC 60870-5-104 master — including spontaneous transmission driven by threshold/value monitoring versus cyclic and general-interrogation-driven updates, and event timestamping — see the Siemens S7-based telecontrol via IEC 60870-5 application example.

Quick Reference