Resolving S7-300/400 NTP Era Rollover Fault on CP343-1 CP443-1

Problem Overview

The SIMATIC S7-300 and S7-400 automation systems contain a Network Time Protocol (NTP) client implementation that fails to track the NTP era transition scheduled for 2036-02-07 06:28:15 UTC. At this moment the 32-bit seconds field of the NTP timestamp wraps from 0xFFFFFFFF to 0x00000000. The firmware on the CP 343-1 and CP 443-1 communication processors does not increment an era counter when the seconds field rolls over. Once the wall clock crosses the rollover boundary, the next NTP poll sets the internal SIMATIC clock to a date approximately 136 years in the past rather than recognizing that the current era has incremented.

The failure is silent from the controller's perspective. The CP continues to send NTP requests at the configured interval, which Siemens documents as a range of 10 seconds to one day in the official Time-of-day synchronization in NTP mode (S7-300, S7-400) functional description. The CPU accepts the time and writes it to the internal TOD clock. Diagnostic buffer entries may simply show Time set by NTP without flagging the obviously corrupt year. Operators see the HMI tag jump from 2036-02-07 06:28:14 to 1900-01-01 00:00:0X, and event logs, batch records, OPC tags, and coordinated control hand-offs all start carrying the wrong timestamp.

The defect is independent of the S7-300/400 phase-out roadmap. Siemens lists the S7-300 as supported through 2033 on the SIMATIC S7-300 product page, and the S7-400 follows the same lifecycle. The NTP era bug is a protocol implementation defect, not an obsolescence issue, and it manifests on every firmware version because no firmware update for these CPs has ever addressed era handling.

NTP Era Rollover Technical Background

The NTP protocol (RFC 5905) defines a 64-bit timestamp consisting of a 32-bit unsigned seconds field and a 32-bit fraction-of-second field. The seconds field counts from 1900-01-01 00:00:00 UTC. Because the field is unsigned 32-bit, it overflows after 2^32 = 4,294,967,296 seconds, which equals 136 years, 26 days, 17 hours, 28 minutes, and 15 seconds. The first overflow happens at 2036-02-07 06:28:15 UTC and marks the boundary between era 0 and era 1. A correctly implemented NTP v4 client maintains an era counter, increments the counter when the seconds field rolls over from 0xFFFFFFFF to 0x00000000, and computes the current date as (era * 2^32) + seconds since 1900. NTP v3 (RFC 1305) and SNTP v3/v4 (RFCs 1769, 4330) use the same 64-bit timestamp format and are subject to the identical wrap.

The SIMATIC TOD clock uses a different time base: 1990-01-01 00:00:00 UTC. The CP must convert the NTP timestamp into the SIMATIC date-and-time format by subtracting the 90-year offset (2,838,384,000 seconds) and encoding the result as 8 BCD bytes (year, month, day, hour, minute, second, milliseconds-tens/weekday, milliseconds-hundreds). If the CP simply reads the lower 32 bits of the NTP timestamp after 2036, it will compute a SIMATIC date in the year 1904 to 1906, depending on the exact offset since the last successful era-1 sync.

The timeline above shows the 32-bit seconds counter in blue, the era 0 to era 1 transition in red, and the Siemens firmware's incorrect interpretation in dashed red. After the wrap, a correctly designed client would set the SIMATIC clock to 2036-02-07 06:28:16 and continue forward. The CP 343-1 and CP 443-1 instead set the SIMATIC clock to approximately 1904-05-08 17:28:16, then continue forward from that base. Because the CP is still polling NTP every 10 s to 24 h, the corrupt time is re-applied on every poll, and the CPU's battery-backed RTC correction is overwritten on the next cycle.

SIMATIC TOD Format Reference

The internal date-and-time format used by S7-300 and S7-400 is 8 bytes BCD, defined in IEC 61131-3 and used by SFC 0 "SET_CLK" and SFC 1 "READ_CLK" on every CPU. The structure is:

The 1990 base means the SIMATIC TOD range is 1990-01-01 00:00:00 to 2089-12-31 23:59:59. The CP NTP path must therefore: (1) read the NTP 64-bit timestamp, (2) track the era counter, (3) add era * 2^32 seconds, (4) convert to UTC by subtracting 2,208,988,800 s (NTP-to-Unix), (5) convert to SIMATIC base by adding 2,838,384,000 s (Unix 1970 to SIMATIC 1990) and applying the configured time-zone offset, and (6) encode as 8-byte BCD. The Siemens CP firmware performs steps (1) and (3) incorrectly, treating the 32-bit seconds value as absolute since 1900 rather than as a relative value within the current era. Step (6) then yields a BCD year in the 04-06 range with 19xx interpretation, which the CPU's TOD register happily accepts because the SIMATIC base year is 1990 and the buggy subtraction lands in 1904-1906, which the BCD field cannot represent directly but which the CPU rolls over to the next valid 19xx interpretation.

Affected Siemens SIMATIC Hardware

The NTP client lives in the firmware of the Industrial Ethernet CP, not in the CPU firmware. Every S7-300 and S7-400 station that uses one of the following CPs in NTP mode is affected:

S7-300 CPUs with integrated PROFINET interface (such as CPU 317-2 PN/DP and CPU 319-3 PN/DP) that run NTP directly through the CPU's Ethernet port are subject to the same era bug because the underlying firmware is shared with the CP path. S7-400 CPUs (CPU 412, 414, 416, 417) paired with the integrated Ethernet interface of the CP 443-1 module exhibit identical behavior. ET 200S IM 151-8 PN/DP CPU and ET 200Pro IM 154-8 PN/DP CPU inherit the same NTP code path and share the bug.

Stations that synchronize the SIMATIC time via SIMATIC mode (a master clock on a GPS receiver feeding the CP via RS-232, or via PROFIBUS master-master clock) are not affected because they do not enter the NTP code path. Stations that synchronize from a partner CPU on MPI or PROFIBUS using the SIMATIC date-and-time format are also not affected because the time arrives in the SIMATIC base directly, not as an NTP timestamp.

Root Cause Analysis

The CP 343-1 and CP 443-1 implement an NTP client that parses the 64-bit NTP timestamp, extracts the 32-bit seconds field, applies the NTP-to-Unix and Unix-to-SIMATIC offsets, and writes the resulting 8-byte BCD date-and-time to the CPU's TOD register via OP 0x0F or SFC 0 "SET_CLK". The firmware's era handling can be summarized as follows:

1. Receive the NTP response packet (48 bytes for SNTP v4 / NTP v3 client mode, 384 bits including the 64-bit Transmit Timestamp at offset 40-47).
2. Extract the Transmit Timestamp: Tx_Ts_Seconds (upper 32 bits) and Tx_Ts_Fraction (lower 32 bits).
3. Compute simatic_seconds = Tx_Ts_Seconds - 2208988800 + 2838384000 + timezone_offset.
4. Encode simatic_seconds as 8 BCD bytes and write to CPU TOD via SFC 0 "SET_CLK".

Step 3 is where the bug sits. The firmware performs the arithmetic on the lower 32 bits of the NTP timestamp and discards the upper 32 bits. After 2036-02-07 06:28:15, the upper 32 bits of the NTP seconds field equal 1 instead of 0, and the SIMATIC base conversion produces a date in 1904-1906. The firmware never increments an era counter, never re-reads the upper 32 bits, and never validates that the resulting date falls within the 1990-2089 SIMATIC TOD range. The CPU's TOD register accepts the BCD value because the format itself is permissive, and the next diagnostic buffer entry is simply a normal Time set event with no error flag.

RFC 5905 Section 6 explicitly addresses this exact situation. The client maintains an era counter and adds era * 2^32 to the seconds field before any date conversion. A v4-compliant implementation would simply add 4,294,967,296 to Tx_Ts_Seconds after the wrap and produce the correct 2036 date. The Siemens firmware predates the v4 era handling in the Industrial Ethernet CP stack and was not updated when the bug was discovered in the wider NTP community.

Additional symptoms observed in the field include:

• CPU diagnostic buffer entry Time set with date in 1904-1906, no error code.
• CP web diagnostics page (if enabled) shows the wrong system time after each NTP poll.
• HMI tag of type DATE_AND_TIME shows year 04, 05, or 06 with 19xx prefix on PanelView or WinCC.
• OPC DA tag PLC_TIME returns a corrupt timestamp to the SCADA.
• S7 communication partner stations on the same network see the corrupted time because the CP re-broadcasts the time across MPI/PROFIBUS after the corrupt write.
• SFC 1 "READ_CLK" returns the 1904 timestamp until the next NTP poll re-applies the same corrupt value.

Field Detection and Verification Procedure

Engineers can verify the bug in a controlled environment by simulating an NTP response with a post-2036 timestamp. The procedure does not require waiting until 2036.

Prerequisites

• A reference S7-300/400 station with CP 343-1 or CP 443-1, configured for NTP mode.
• A PC running a configurable NTP server (Linux ntpd in broadcast mode, chrony with manual fudge time, or a Python script that replies to NTP requests with a crafted timestamp).
• STEP 7 V5.5+ or TIA Portal V20/V21 for reading the CPU diagnostic buffer and the CP web diagnostics page.
• Wireshark with the NTP dissector for packet capture.

Test procedure

1. Configure the test NTP server to return a current time of 2036-02-07 06:30:00 UTC (15 minutes past the era boundary). On Linux chrony, set fudge time1 4.294e9 0.05 to shift the reported time forward by 136 years. On Windows w32time, use a stratum-0 reference and a manual offset.
2. Point the CP's NTP client at the test server: HW Config > CP > Properties > Time-of-Day Synchronization > NTP Server Address.
3. Force a synchronization by restarting the CP, by toggling the NTP enable bit, or by waiting for the configured poll interval (10 s minimum).
4. Read the CPU diagnostic buffer: PLC > Diagnostic Buffer in STEP 7 or Online & Diagnostics > Diagnostic Buffer in TIA Portal.
5. Confirm the diagnostic entry Time set by NTP shows a year of 04, 05, or 06 instead of 36.
6. Read the SIMATIC TOD via SFC 1 "READ_CLK" in OB1 or via the variable table: the Date_And_Time tag should show year 1904 instead of 2036.
7. Capture the NTP traffic with Wireshark and confirm the server returns the correct 2036 timestamp in the Transmit Timestamp field at offset 40 of the response packet.

Equivalent on-plant indicator

For stations already in operation, monitor the following signals on the engineering station:

• WinCC or PanelView tag of type DATE_AND_TIME: a sudden year jump from 2036 to 1904 at the next NTP poll confirms the bug.
• SCADA event log timestamp: a 136-year backward step at the moment of the next NTP poll.
• Network capture (Wireshark) of NTP traffic on UDP 123: the server returns a correct 2036 timestamp, the CP accepts it, and the next TOD broadcast to the CPU carries 1904.
• CP web diagnostics page > Time-of-Day: shows the wrong year after each sync.

STEP 7 NTP Configuration Reference

The CP's NTP client is enabled in HW Config (STEP 7 V5.x) or in the device properties (TIA Portal V20/V21). The relevant parameters for the S7-300/400 NTP path are:

Per the official Siemens Time-of-day synchronization in NTP mode (S7-300, S7-400) documentation, the CP sends time queries at the configured interval, allowing the time to be synchronized across subnets. The documentation covers the request/response mechanism but does not address the 32-bit era transition, so the engineer must add the era handling check at the verification stage.

For S7-300, the configuration object is found by right-clicking the CP 343-1 in the rack and selecting Object Properties > Time-of-Day Synchronization. For S7-400, the same path applies on the CP 443-1. The interval entered in this dialog is the interval at which the CP sends a fresh NTP request to the configured server. Setting the interval to 10 s is the fastest test interval; production plants typically use 1 h, 6 h, or 24 h. Note that the CPU itself (not the CP) holds the time-zone and daylight-saving parameters; the CP forwards the raw UTC time to the CPU and the CPU applies the local-time offset on read-out via SFC 1 "READ_CLK" with RET_VAL for the local time conversion.

Workarounds and Mitigations

Five practical mitigations are available. Selection depends on the plant's tolerance for change, the available hardware, and the migration timeline.

1. Switch from NTP mode to SIMATIC mode

The simplest path is to disable NTP mode on the CP and switch to SIMATIC mode. In SIMATIC mode, the CP receives time from a SIMATIC master clock (typically a GPS receiver with an RS-232 output) and forwards it to the CPU in the SIMATIC date-and-time format. The NTP era bug is not exercised because the NTP code path is bypassed entirely.

Hardware required: a Siemens SICLOCK GPS receiver or a third-party GPS with RS-232 SIMATIC time output per station, or a single plant-wide master clock that distributes time via PROFIBUS master-master sync. The trade-off is the cost of GPS hardware at every station versus the NTP server infrastructure that already exists.

2. Insert an S7-1500 or ET 200SP CPU as a time gateway

Add an S7-1500 CPU or an ET 200SP CPU 1510SP / 1512SP / 1515SP between the NTP server and the S7-300/400 station. The S7-1500 acts as a properly implemented NTP client and forwards the time to the S7-300/400 station in SIMATIC mode over PROFINET or MPI. The S7-300/400 receives the time without ever entering its NTP code path, so the era bug is not triggered.

The diagram shows the recommended workaround topology. The S7-1500 (or ET 200SP CPU) holds the NTP client role, the S7-300/400 station holds the SIMATIC slave role, and the HMI/SCADA continue to read time from the S7-300/400 CPU via the existing S7 connection. No change is required on the HMI/SCADA side. The S7-1500 also serves as a natural migration stepping stone for the brownfield migration in option 4 below.

3. Run an NTP-to-SIMATIC bridge on an industrial PC

Where a spare S7-1500 is not available, a small IPC (Siemens SIMATIC IPC227, IPC277, or equivalent) can run a service that polls NTP, converts the time to the SIMATIC date-and-time format, and writes it to the S7-300/400 via S7 communication using SFC 0 "SET_CLK" over a configured S7 connection. A reference implementation in Python with snap7 is shown below.

import snap7
import ntplib
import time
from datetime import datetime, timezone

PLC_IP = "192.168.0.10"
PLC_RACK = 0
PLC_SLOT = 1
NTP_SERVER = "192.168.0.1"
POLL_SEC = 60

def utc_to_simatic_dt(utc_dt: datetime) -> bytearray:
    # SIMATIC DT: 8 bytes BCD, base 1990-01-01
    base = datetime(1990, 1, 1, tzinfo=timezone.utc)
    if utc_dt < base:
        raise ValueError("date before SIMATIC base")
    if utc_dt.year > 2089:
        raise ValueError("SIMATIC TOD range exceeded")
    bcd = bytearray(8)
    bcd[0] = ((utc_dt.year // 10) % 10) << 4 | (utc_dt.year % 10)
    bcd[1] = ((utc_dt.month // 10) % 10) << 4 | (utc_dt.month % 10)
    bcd[2] = ((utc_dt.day // 10) % 10) << 4 | (utc_dt.day % 10)
    bcd[3] = ((utc_dt.hour // 10) % 10) << 4 | (utc_dt.hour % 10)
    bcd[4] = ((utc_dt.minute // 10) % 10) << 4 | (utc_dt.minute % 10)
    bcd[5] = ((utc_dt.second // 10) % 10) << 4 | (utc_dt.second % 10)
    bcd[6] = ((utc_dt.microsecond // 100000) % 10) << 4 | ((utc_dt.weekday() + 1) & 0x07)
    bcd[7] = ((utc_dt.microsecond // 10000) % 100) & 0xFF
    return bcd

client = snap7.client.Client()
client.connect(PLC_IP, PLC_RACK, PLC_SLOT)
ntp = ntplib.NTPClient()
while True:
    try:
        resp = ntp.request(NTP_SERVER, version=4)
        dt = utc_to_simatic_dt(datetime.fromtimestamp(resp.tx_time, tz=timezone.utc))
        client.set_plc_datetime(dt)
        print(f"Set PLC time to {dt.hex()}")
    except Exception as e:
        print(f"Sync error: {e}")
    time.sleep(POLL_SEC)

The script requires python-snap7 and ntplib. Run it as a Windows service or a Linux systemd unit. Place the IPC on a UPS because loss of the IPC during a plant event leaves the PLC on its battery-backed RTC until the next NTP poll, which is acceptable for short outages. For a hardened installation, mirror the script across two IPCs and have each one watch the other's NTP response to detect a stuck clock.

4. Pre-empt the era change by setting the CPU clock forward by 136 years

Set the CPU's TOD clock to a date 136 years and a few seconds in the future using SFC 0 "SET_CLK" in OB100 or via the online panel. After the era change, the CP will set the clock back by 136 years, landing on the correct 2036 date. This is a brittle workaround and is not recommended for production plants because any other time source (HMI hand-set, partner CPU sync, master clock) will also push the clock to a future year that the SIMATIC TOD format cannot represent past 2089. The 2089 SIMATIC TOD ceiling makes this workaround unusable for any plant that must operate past 2089 anyway.

5. Replace the CP with a generation that handles the era

Some later revisions of the CP 343-1 and CP 443-1 firmware are expected to add era handling, but Siemens has not published a public statement confirming a fix as of this writing. Open a support request via Siemens Industry Online Support with the CP MLFB and current firmware version to confirm whether a fix is available. If a fix is published, apply it before 2036-02-07 06:28:15 UTC and re-validate with the test procedure above. Also confirm whether the fix covers the era 1 to era 2 wrap at 2106-02-07 06:28:15 UTC; a partial fix that handles era 1 but not era 2 will fail again in 2106.

Long-Term Migration to S7-1500 / ET 200SP

The S7-1500 CPU family and the ET 200SP CPU 1510SP / 1512SP / 1515SP have a fully v4-compliant NTP client that tracks the era counter and produces correct timestamps past 2036, 2106, and 2176. For greenfield projects started in the 2020s, the S7-1500 is the Siemens-recommended replacement. For brownfield migration, Siemens offers conversion tools (STEP 7 V5.x project migration to TIA Portal) and a documented migration path from S7-300/400 to S7-1500/ET 200SP that preserves the program logic and most of the I/O.

Migration triggers to plan for in the 2025-2030 window:

• The NTP era bug is the strongest single trigger because it has a hard cutover date that does not slip.
• The S7-300 phase-out support window per the SIMATIC S7-300 product page ends in 2033.
• Spare part availability for legacy CP 343-1 and CP 443-1 modules degrades after 2028 as the modules move to the restricted spare-parts pool.
• Windows 10 ESU and Windows 11 migration of the engineering stations removes the STEP 7 V5.6 support path and forces a move to TIA Portal V20 or V21.
• Cybersecurity directives (IEC 62443-3-3, NIS2) require firmware updates and signed firmware, which the legacy CP 343-1/443-1 firmware cannot satisfy.

Alternative Time Synchronization Architectures

Where the S7-300/400 cannot be re-timed via NTP, several alternative time architectures avoid the era bug entirely.

GPS master clock plus SIMATIC mode

A plant-wide master clock (Siemens SICLOCK TC 100, Meinberg LANTIME, or any GPS receiver with RS-232 SIMATIC time output) feeds the CP 343-1 / CP 443-1 in SIMATIC mode. The CP receives 8-byte BCD time and forwards it to the CPU without NTP involvement. Multiple stations on the same PROFIBUS or PROFINET segment can be synchronized by a single master clock using the SIMATIC master-master protocol. This is the architecture that was standard on S7-300/400 plants before NTP became common, and it remains the most reliable for any station that cannot be migrated to S7-1500.

PTP / IEEE 1588 on PROFINET

S7-300/400 stations with CP 343-1 Advanced or CP 443-1 Advanced support PTP (Precision Time Protocol) on PROFINET in slave mode, per the PROFINET specification. PTP uses a 64-bit timestamp with proper era handling, and the CP converts the PTP time to SIMATIC date-and-time on the way into the CPU. PTP is a one-way protocol that does not poll a server, so the era bug is not exercised. PTP also delivers sub-millisecond accuracy across the PROFINET segment, which is useful for synchronized motion and for IEEE 1588-based power-system applications.

PROFIBUS master-master sync

For stations that already use PROFIBUS as the field bus, a DP master with master-clock capability (CPU 416-3 DP, IM 467, or CP 443-5 Extended) can distribute time across the DP segment in SIMATIC format. This path has been used in SIMATIC plants since the 1990s and is independent of the NTP era issue. The trade-off is single-vendor lock-in and the limited accuracy (typically 1-10 ms) compared to PTP.

Verification Checklist and Acceptance Test

After applying any workaround, run the following acceptance test to confirm the SIMATIC time remains correct past the era boundary. The test must be run on a non-production CPU of the same type and firmware as the production station.

1. Configure the test NTP server to return 2036-02-07 06:30:00 UTC.
2. Force the PLC to re-sync (CP restart, SFC 0 trigger, or wait for the next poll).
3. Read the CPU TOD via SFC 1 "READ_CLK" and confirm the year is 2036, not 1904.
4. Capture the diagnostic buffer and confirm the Time set entry shows year 36.
5. Check the HMI time tag and confirm it shows 2036-02-07 06:30:00 (or local equivalent after time-zone offset).
6. Check the OPC tag on the SCADA and confirm the timestamp is in 2036.
7. Repeat the test with the test NTP server set to 2106-03-15 12:00:00 UTC to validate the next era boundary as well.
8. Document the test result and file the commissioning record with the plant's change management system.

Troubleshooting Matrix

FAQ