Siemens ET200SP Time Zone Configuration in TIA Portal

Siemens ET200SP Time Zone Configuration in TIA Portal

An ET200SP CPU synchronized by Network Time Protocol (NTP) always receives the wall-clock value in UTC (Coordinated Universal Time). The CPU performs no implicit regional offset on the incoming packets — by design, NTP servers do not transmit a timezone field. The conversion from UTC to local time is therefore a CPU-side configuration task that must be performed before the value is exposed to the HMI, OPC UA client, or any process tag. This reference explains how to configure the timezone on an ET200SP CPU under TIA Portal, the program-based workaround required on the older ET200S and S7-300/400 controllers, and how to verify the result across daylight-saving transitions.

1. UTC, NTP, and Local Time — Engineering Background

NTP (RFC 5905) transmits time as the number of seconds since 1900-01-01 00:00:00 UTC. There is no timezone information embedded in the NTP packet — by design, all clients and servers speak a single, unambiguous time scale. The OS, firmware, or application on the receiving side is responsible for converting UTC to a regional local time before any value is presented to a human operator.

For the Siemens SIMATIC portfolio, the support matrix for native timezone handling varies widely across product generations. The distinction matters because a CPU's firmware lineage determines whether a timezone property exists at all in the TIA Portal device configuration.

The behavior also depends on which firmware generation is running on the CPU. Early firmware on the S7-1200 (FW < 4.2) similarly lacks the timezone property and falls back to raw UTC, identical to the S7-300 behavior. Always check the firmware version in Online & diagnostics > General before assuming the timezone dialog is present.

2. Prerequisites

Before configuring the timezone, verify that the basic time-synchronization path is operational. A correctly configured timezone on a CPU that has no NTP source still produces drift, so the upstream synchronization must be confirmed first.

• TIA Portal V15.1 or later installed on the engineering station. The reference workflow below was captured with TIA Portal V17.
• ET200SP CPU with firmware that supports timezone configuration. For the S7-1200-based 1510SP-1 PN, firmware ≥ 4.0 is required; for the S7-1500-based 1512SP-1 PN, firmware ≥ 2.0 is required.
• An ET200SP station assembled with a head module (IM155-6 PN ST or HF), the CPU, and at least one I/O module. A power module (PM) is optional but recommended for stable NTP traffic on the backplane bus.
• An NTP server reachable on the PROFINET network — either a local Stratum-1 server, a router with NTP forwarding, or a public pool (for example pool.ntp.org) if outbound traffic is permitted by the plant firewall.
• An engineering station with online access to the CPU for verification via the PROFINET interface.
• For dynamic timezone changes: a free DB or M-bit area to hold the SET_TIMEZONE request flag and the IANA timezone string.

3. Step-by-Step Configuration on the ET200SP CPU

The following procedure configures the timezone and DST rule on the ET200SP CPU so that the HMI and OPC UA clients receive local time instead of raw UTC.

1. Open the TIA Portal project and expand the device tree in the project navigator.
2. Right-click the ET200SP CPU (for example CPU_1) and choose Properties. The device configuration editor opens.
3. In the navigation tree of the editor, expand General and select Time of day.
4. Enable the checkbox Set time zone. The dialog expands to show the timezone list and the DST rule list.
5. From the timezone dropdown, choose the regional entry that matches the installation site. Common selections include:
   • (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna — Central European Time
   • (UTC-05:00) Eastern Time (US & Canada) — U.S. Eastern Standard Time
   • (UTC+09:00) Osaka, Sapporo, Tokyo — Japan Standard Time (no DST)
   • (UTC+00:00) Dublin, Edinburgh, Lisbon, London — GMT / BST (UK observes DST)
6. From the DST rule dropdown, select the regional rule. TIA Portal ships with EU, US, AU, BR, and several other regional rules pre-loaded. For regions that do not observe DST (for example Japan, China, most of Africa), leave the DST rule as "No" or "off".
7. Click OK to close the device configuration dialog.
8. Compile the project. Right-click the CPU in the project tree and select Compile > Hardware and software only. Resolve any compile errors before downloading.
9. Download the hardware configuration to the CPU. The download does not stop the CPU; the new timezone takes effect on the next read of the system clock.
10. Open Online & diagnostics > Time of day and verify that the Local time field now shows the correct value.

The CPU continues to receive UTC from the NTP server. Internally, the firmware subtracts the configured offset and applies the DST rule when populating the Local time field. The OPC UA server on the CPU exposes the same dual view: the CurrentTime node returns local time, while the UtcTime node returns raw UTC.

4. SET_TIMEZONE — Runtime Timezone Override

For machines that ship to multiple countries or that need to switch between regions — for example a mobile test bench that operates in Germany and the U.S. on alternating weeks — the timezone can be changed at runtime via the SET_TIMEZONE extended instruction.

SET_TIMEZONE belongs to the Date and time-of-day group of extended instructions and is documented in the SIMATIC S7-1200 manual collection on the TIA Portal cloud docs. See the official reference: SET_TIMEZONE — Set timezone (Siemens TIA Portal cloud docs).

The instruction accepts a timezone identifier as an IANA-style string and an optional DST flag. The string is stored in the CPU's non-volatile area and applied to all subsequent clock-read operations. Refer to the official documentation for the exact block signature and full parameter list.

Example usage in Structured Text (SCL):

// Set timezone to Central Europe with DST enabled
IF FirstRun THEN
    SET_TIMEZONE(
        REQ := TRUE,
        TZ  := 'Europe/Berlin',
        DST := TRUE,
        RET_VAL => tzStatus
    );
    FirstRun := FALSE;
END_IF;

5. ET200S (IM151-8 PN/DP) — Hardware Limitation

The ET200S IM151-8 PN/DP CPU is built on the S7-300 architecture and is configured with STEP 7 V5.x or with TIA Portal in compatibility mode. Neither tool exposes a timezone property on this CPU — only basic time synchronization (NTP or SIMATIC mode) is configurable. The CPU returns the raw UTC value, and the user program must add the regional offset before the time is shown on the operator panel.

Catalog numbers in the IM151-8 family include 6ES7 151-8AB00-0AB0, 6ES7 151-8AB01-0AB0, 6ES7 151-8FB00-0AB0, and 6ES7 151-8FB01-0AB0. The "8A" variants are standard CPUs; the "8F" variants include fail-safe functionality. All four share the same time-of-day limitation regardless of firmware version.

Because the hardware cannot apply an offset, you must compute local time in the user program. The procedure for the ET200S is identical to the procedure for the S7-300/S7-400 described in Section 6 — treat the IM151-8 PN/DP as an S7-300-class CPU for all time-of-day work.

6. Program-Based Timezone Calculation for S7-300 / 400 and ET200S

When the hardware does not provide a timezone property, the application code must compute local time from the UTC clock value returned by SFC 1 (READ_CLK). The recommended structure is a function block that runs once per second and updates a process tag visible to the HMI.

Reference SCL code (S7-300/400-compatible):

FUNCTION_BLOCK FB100 "LocalTime"
VAR
    UTC_DTL   : DTL;
    Local_DTL : DTL;
    OffsetS   : INT;        // seconds to add
    IsDST     : BOOL;
END_VAR

BEGIN
    // Step 1 — read the raw clock
    UTC_DTL := READ_CLK();

    // Step 2 — determine DST (Europe rules)
    IsDST := DST_ACTIVE_EU(UTC_DTL);

    // Step 3 — choose offset
    IF IsDST THEN
        OffsetS := 7200;   // CEST = UTC+2
    ELSE
        OffsetS := 3600;   // CET  = UTC+1
    END_IF;

    // Step 4 — apply offset and normalize
    Local_DTL := ADD_DTL_SEC(UTC_DTL, OffsetS);

    // Step 5 — expose to HMI
    "HMI_SystemTime" := Local_DTL;
END_FUNCTION_BLOCK

The DST_ACTIVE_EU helper block evaluates the European DST rule:

• Spring forward: last Sunday of March, 01:00 UTC → 02:00 local becomes 03:00 local.
• Fall back: last Sunday of October, 01:00 UTC → 03:00 local becomes 02:00 local.

For regions outside Europe, replace DST_ACTIVE_EU with the appropriate regional helper. The U.S. rule under the Energy Policy Act of 2005 is "second Sunday of March" through "first Sunday of November". Brazil, Australia, and New Zealand each follow different calendars that must be coded explicitly.

The complete DST rule for the United States can be expressed in SCL:

// FB200 — DST_ACTIVE_US
// Input:  dtl (DTL) - current UTC time
// Output: active (BOOL) - TRUE if DST is in effect
VAR_TEMP
    marchSecond : DTL;
    novFirst    : DTL;
    dow         : INT;
END_VAR
BEGIN
    // Find second Sunday of March at 02:00 local
    marchSecond := DTL_FROM_YMD(dtl.YEAR, 3, 1);  // March 1
    dow := DAY_OF_WEEK(marchSecond);
    marchSecond := ADD_DAYS(marchSecond,
                 (7 - dow + 1) MOD 7 + 7);  // second Sunday
    marchSecond.HOUR := 7;  // 07:00 UTC = 02:00 CST / 03:00 CDT

    // Find first Sunday of November at 02:00 local
    novFirst := DTL_FROM_YMD(dtl.YEAR, 11, 1);
    dow := DAY_OF_WEEK(novFirst);
    novFirst := ADD_DAYS(novFirst,
               (7 - dow + 1) MOD 7);  // first Sunday
    novFirst.HOUR := 6;  // 06:00 UTC = 01:00 EDT / 12:00 CST

    active := (dtl >= marchSecond) AND (dtl < novFirst);
END_FUNCTION_BLOCK

This same U.S. pattern can be adapted for any region by substituting the rule definition (transition dates, transition hour, and standard/daylight offsets). The key invariant is that the rule must be deterministic for the year under evaluation and must handle the year-end boundary when the DST window straddles 31 December (relevant for the southern hemisphere).

7. Daylight Saving Time Edge Cases

Three transition pitfalls commonly break DST handling in user code. They apply to both the ET200SP firmware implementation and the S7-300/400 manual implementation.

Ambiguous local hour. At fall-back, the local hour 02:00–03:00 occurs twice. S7-300/400 user code maps both occurrences to UTC+1 and the resulting local time is non-unique. A production system should log the timestamp with the DST flag set to FALSE so that an operator can disambiguate from the log. The ET200SP firmware handles this internally by stamping each local-time read with a DST_active boolean that the application can inspect.

Missing local hour. At spring-forward, the local hour 02:00–03:00 does not exist. UTC times in that interval cannot be mapped to local without violating uniqueness. The standard practice is to suppress the local mapping and continue in UTC until the transition completes. Production processes scheduled for the missing hour must either advance to the next valid local hour or be rescheduled before the transition.

Year-end rollover. Adding 3600 s or 7200 s near 23:59:59 on 31 December must roll over both the day and the year fields of the DTL structure. Implement the addition with full carry propagation through the DATE_AND_TIME fields (year, month, day, hour, minute, second). Libraries that operate only on the seconds field will produce invalid timestamps on the last day of the year.

Southern-hemisphere flip. Australia and New Zealand observe DST in the opposite half of the year from the northern hemisphere. The "spring forward" and "fall back" terminology inverts: spring forward is in October, fall back is in April. Code that hardcodes "March / October" without parameterization will be wrong in these regions.

8. Verification Procedure

After downloading the configuration, validate the result both immediately and across a DST transition window. Skipping the second verification is a common cause of post-deployment callbacks.

1. Open Online & diagnostics > Time of day on the CPU. Verify that the local time equals UTC + offset.
2. Force a manual NTP synchronization (right-click the CPU > Online & diagnostics > Time of day > Synchronize). The local time must update without a CPU stop.
3. Place a date/time field on the HMI bound to the CPU system clock tag. Walk a calibrated time source (a known-good NTP display on a laptop) and confirm the offset.
4. Disconnect the NTP server and restart the CPU. Verify that the RTC retains local time across the restart and that the time stays within the RTC drift specification (typically ±5 ppm for the ET200SP, approximately 13 seconds per month).
5. Reconnect the NTP server. Verify that the CPU gradually slews to the correct time (not a step change) per the firmware's NTP discipline algorithm.
6. Schedule a verification run one week after the next DST transition date. Confirm that the local time has shifted by ±1 h without operator intervention.
7. For SET_TIMEZONE applications, write a test routine that toggles the TZ string between two regions and verifies that the displayed local time tracks the change.
8. For multi-CPU stations, verify the RD_SYS_T / WR_SYS_T coordinated time. The slaves should track the master to within one synchronization interval (default 10 s).

9. Troubleshooting Matrix

10. Related Time-of-Day Functions in TIA Portal

The TIA Portal instruction set provides a complete family of time-handling blocks. The most relevant for this discussion are summarized below.

11. Integration with Downstream Building Automation

When an ET200SP CPU feeds time data to a non-Siemens building management system, the downstream platform typically performs the UTC → local conversion on the server side. For Schneider Electric EcoStruxure Building Operation, the configured timezone offset is added by the workstation software to the UTC time received from the field device. Refer to the official documentation: Time and Time Zone Configuration in Enterprise Server and Enterprise Central (Schneider Electric).

In this architecture, leave the ET200SP CPU on UTC (no timezone set in the device properties) and let the building server localize the value. This avoids double-offset bugs caused by the field and the server both applying the regional offset. The principle is: configure the timezone at exactly one layer of the stack.

For mixed-vendor SCADA systems that aggregate time from multiple PLCs (Siemens, Allen-Bradley, Schneider), the recommended pattern is to store UTC at the PLC and to localize at the SCADA display layer. This makes audit logs and cross-PLC event correlation unambiguous.

12. NTP Server Sourcing Best Practices

• Use a local Stratum-1 or Stratum-2 NTP source whenever possible. Public pool servers (pool.ntp.org) introduce WAN latency and dependence on internet connectivity.
• Configure at least two NTP servers on the CPU for redundancy. The firmware selects the lowest-stratum, lowest-delay source.
• Set the synchronization interval to between 10 s and 600 s. Aggressive intervals (≤ 10 s) generate unnecessary network load.
• Disable NTP on the CPU's PROFINET interface that faces the field bus. Use the corporate network interface exclusively for time sync.
• Enable NTP authentication (symmetric key) where supported by the firmware to prevent time-shift attacks from a rogue server.
• Log the time offset (delta between local and NTP) once per day to detect gradual drift caused by a failing server.

13. OPC UA Time Exposure

The ET200SP CPU embeds an OPC UA server that exposes time data on standard nodes. The relevant nodes are:

The OPC UA specification (IEC 62541) defines the DateTime data type as UTC. Therefore, the standard Server_ServerStatus_CurrentTime node is always UTC. If an OPC UA client needs local time, the application must add the regional offset, or the ET200SP CPU must expose a custom tag that has already been localized by the firmware.