Fixing S7-1500 Initiated Session Termination to WinCC V7.5 SP2

Fixing S7-1500 "System Initiated Session Termination" to WinCC V7.5 SP2

1. Problem Overview

The "Security information: System initiated session termination" diagnostic buffer entry is one of the most frequently mis-diagnosed events in the SIMATIC S7-1500 family. Engineers regularly interpret the message as evidence that the CPU has actively dropped the HMI connection, when in many cases the cause is the opposite: a client (engineering station, SCADA server, VPN concentrator, or unstable WLAN link) closed the connection in a non-graceful way, leaving the CPU with an occupied PG/HMI/OP connection resource that the operating system must reclaim under its security housekeeping routine. This article addresses the specific scenario reported on a CPU 1513-1 PN (6ES7513-1AM02-0AB0) running firmware V2.9 and later upgraded to V2.9.7, paired with a WinCC V7.5 SP2 Update 11 SCADA station. The Channel Diagnostic tool on the WinCC side returned error 0x800015210000008d and the PLC diagnostic buffer repeatedly logged:

Security information: System initiated session termination
SessionID 0-32828
Interlock system
Client IPAddr: 192.168.0.242 (WinCC PC)
Help on event: A previously established system session was terminated
due to CPU operating system security efforts.

The reported situation is a useful case study because it bundles three independent root causes that are easy to miss when addressed one at a time: (1) connection resource starvation, (2) certificate/time mismatch, and (3) the "Only allow secure PG/PC and HMI communication" protection level interacting with the password state of the PLC user. Each cause is addressed below, followed by a consolidated procedure and a verification matrix.

2. Affected Hardware, Firmware, and Software

Component	Article / Version	Notes
CPU	SIMATIC S7-1500 CPU 1513-1 PN (6ES7513-1AM02-0AB0)	Display: 6ES7591-1AA01-0AA0 (optional)
Firmware original	V2.9	Released Q1 2022 line; first V2.9.x builds have known session-termination behavior on unstable paths
Firmware updated	V2.9.7	Latest 2.9 service pack at time of writing; still requires proper resource management
Engineering	TIA Portal V18 then V19	Project upgraded during the investigation
SCADA	SIMATIC WinCC V7.5 SP2 Update 11	Tags imported via "TIA SIMATIC SCADA" export/import workflow (this is the recommended path for certificate consistency)
Channel diagnostic	ApdiagTool / S7DOS Channel Diagnosis	Returned 0x800015210000008d

The S7-1500 communication model is based on ISO/OSI transport over TCP/102 reserved for S7, with the CPU maintaining a fixed table of connection resources that are allocated each time a PG, HMI, OP, S7 route, Open User Communication, or partner connection is opened. Connection resources for the S7-1500 system are documented in the TIA Portal help under Allocation of connection resources (S7-1500).

3. Diagnostic Buffer Interpretation

The diagnostic buffer is the authoritative source. The two key entries that engineers should learn to read are:

1. Security event – System initiated session termination: the CPU's security subsystem has just torn down a session. The text is generic; it does not specify whether the client or the CPU initiated the close.
2. Connection-status event (ID 0x04 / 0x05 / 0x0B family): emitted shortly before or after the security event. Look for the Event ID and the DatID field, which contains the SessionID.

The SessionID 0-32828 reported in this case is composed of a connection type prefix (0 = PG/PC/HMI connection type) and an internal handle. When this ID is held across CPU restarts, the resource is not released until the next STOP/RUN or power cycle. On firmware V2.9, the OS keeps the slot pending even if the remote peer is no longer reachable, which is why a manual restart of the CPU was needed to recover a working link during the initial investigation.

4. Root Cause 1 – Connection Resource Starvation

S7-1500 CPUs ship with a finite number of PG/HMI/OP and S7 connection resources. For CPU 1513-1 PN (work memory 300 KB code / 1.5 MB data), the maximum number of simultaneously usable connection resources is 128 in total, of which the maximum that may be assigned to PG/HMI/OP communication is bounded by the resource table. The Allocation of connection resources (S7-1500) reference page lists the typical occupation per HMI type. Representative values for a CPU 1513-1 PN (firmware ≥ V2.6):

HMI / SCADA device	Occupied PG/HMI/OP connection resources
WinCC Runtime (single connection)	1
WinCC Runtime with redundancy	2
Comfort Panel (TP/KT)	1
WinCC Unified PC	1–2 (depends on configured tags/alarms)
WinCC Professional RT (single station)	1
TIA Portal online (per online window)	1
S7 route via NET	1 per routed target

The reported failure appeared after months of stable operation because the resource exhaustion is incremental. Every time the TIA Portal was closed directly while still online, every WLAN drop, every VPN reconnect, the CPU kept a connection resource for a configurable timeout (default 30 s, configurable up to 60 s in the CPU properties under "Connection mechanisms"). After several hours, all available PG/HMI slots were filled with stale entries, the WinCC reconnect request received "no resource available," and the security subsystem then emitted the System Initiated Session Termination event for the oldest still-pending resource.

4.1 TiaPortal housekeeping changes per firmware branch

Firmware branch	Resource-release behavior	Field comment
V2.6	Strict; 30 s timer, no graceful retry	Most affected by WLAN drops
V2.8	Improved keep-alive, faster reclaim	Recommended minimum
V2.9	Finer-grained event logging	Investigate the diagnostic buffer carefully
V2.9.7	Additional fixes for OP/HMI timeout under high tag count	Latest in 2.9 line

5. Root Cause 2 – WinCC Channel Error 0x800015210000008d

The Channel Diagnostic tool on the WinCC side returned 0x800015210000008d. Decomposing the code by Siemens convention:

• Vendor / status: 0x8000 – failure with HRESULT
• Sub-status: 0x1521 – S7DOS "password-protected resource access denied"
• Sub-detail: 0000008d – access level below that required for the requested operation (read-only / operator level insufficient)

This is a clear signal that the WinCC connection was being established but rejected at the OPC UA / S7 security layer because the password configured in the WinCC tag export did not match the CPU's user-management state, or because the CPU user level required (typically "HMI access") had a stale password entry after a project upgrade.

6. Root Cause 3 – Protection Level "Only Allow Secure PG/PC and HMI Communication"

TIA Portal offers three protection levels for CPU access under Properties > Protection > Connection mechanisms:

1. Permit access with PUT/GET (legacy, no security)
2. Only allow secure PG/PC and HMI communication (TLS-based, requires a valid certificate and matching access level)
3. Do not permit access (complete protection)

When option (2) is enabled, the CPU rejects every connection that does not present a valid X.509 certificate signed by the same project CA, and the user-management table must contain a user with the right access level and a password (an empty password is allowed for option (1) but commonly rejected by WinCC when option (2) is set). In the reported case, the moment the operator unchecked option (2), communication returned. This proves the binding was not the certificate itself but the combination of certificate, password, and access-level enforcement that option (2) activates.

7. Resolution Procedure

The fix is a sequence; performing the steps out of order re-introduces the failure. Use the order below.

7.1 Prerequisites

• TIA Portal V18 or V19 installed on the engineering station
• CPU 1513-1 PN project, compiled without errors
• WinCC V7.5 SP2 Update 11 installed on the SCADA station
• Administrator rights on both stations (TIA Portal installs a certificate store in Cert:\LocalMachine\Root\)
• Synchronized time on both stations (NTP recommended; max 5 s skew)

7.2 Step-by-Step Fix

1. Stop and power-cycle the CPU to clear orphaned resources. Power OFF, wait 10 s, power ON. This is the only reliable way to release all held PG/HMI resources on firmware V2.9.x.
2. Open the TIA Portal project in V19 and compile hardware completely (CPU + HMI tags). Use Project > Compile > Hardware and Software (rebuild all).
3. Verify the project time under Project tree > Common data > Time settings. The certificate generated during compilation is time-stamped; mismatch with the PLC causes 0x1523 errors.
4. Open the CPU protection settings: Properties > Protection > Connection mechanisms. For the first communication trial, temporarily uncheck "Only allow secure PG/PC and HMI communication" so the binding can be validated. Re-enable it after the SCADA side is verified.
5. Reset the PLC user-management: under Properties > Protection > User management, delete all users except the default "Everybody" and add a fresh user with the access level "HMI access". Assign a known, plain ASCII password (e.g. S71500Hmi!2024).
6. Download the project to the CPU (full download is recommended when protection settings change).
7. Generate a fresh tag export in TIA Portal via HMI tags > Export to SIMATIC SCADA. The export file (.xlsx) embeds the certificate fingerprint, the user name, and the password hash.
8. Import the export into WinCC on the SCADA station. This step updates the S7DOS channel configuration, the user credentials, and the certificate trust list in one atomic operation. Confirm in WinCC Explorer > Computer > Properties > Tags that the connection shows the new certificate subject.
9. Activate the WinCC project and observe the S7DOS channel state in the Channel Diagnosis tool. The error 0x800015210000008d should disappear and be replaced by a clean "Connected" state.
10. Re-enable "Only allow secure PG/PC and HMI communication" in the CPU properties and redownload the project. Verify that WinCC still connects. If the failure reappears, repeat step 5 (password reset) while the protection level is enabled – this is the failure path described in the source incident.
11. Install firmware V2.9.7 if not already applied. Use the SIMATIC Automation Tool or the Web server of the CPU (Administration > Firmware update) to perform the update. After the update, repeat the power cycle.

8. Connection Resource Management (Avoiding Recurrence)

Once the link is restored, apply the following controls to keep the resource pool healthy:

1. Always use the TIA Portal "Disconnect online connection" button (or right-click the CPU > "Go offline") before closing the project. Closing TIA Portal directly leaves one PG connection resource pinned for the full timeout.
2. Avoid WLAN or VPN for primary PG/HMI access. The implicit keep-alive timeout is 30 s; a typical WLAN roaming event exceeds that. Use wired Ethernet whenever possible. The CPU does not distinguish a graceful close from a network drop and treats both as security events.
3. Schedule a daily STOP/RUN cycle on the CPU only if the application is non-critical. This is a brute-force method to reclaim any stale resources and is acceptable on small machines but not on production lines.
4. Reduce the connection timeout under CPU Properties > Connection mechanisms > Keep-alive timeout to the minimum your network allows. Lower values reclaim resources faster but may interrupt slow scans.
5. Limit the number of online windows open simultaneously in TIA Portal. Each open online view holds a separate connection resource.

9. WinCC Channel Diagnostic Reference

The Channel Diagnostic tool (Start > Siemens Automation > Channel Diagnosis) is the first line of evidence on the SCADA side. Use the matrix below to translate common HRESULTs:

HRESULT prefix	Likely cause	Remediation
0x80001520 / 0x80001521	Password invalid or missing for the configured access level	Reset PLC user, re-import the tag export
0x80001522	Certificate not trusted / expired / wrong issuer	Re-export tags from TIA Portal, re-import in WinCC
0x80001523	Time skew between PLC and SCADA > 5 s	Synchronize clocks via NTP
0x80001530 / 0x80001531	Connection resource exhausted on the CPU	STOP/RUN CPU, reduce PG connections, re-enable secure comm.
0x80001540	CPU protection level mismatch	Match protection level between TIA project and CPU

The original incident's 0x800015210000008d lands squarely in the first row – the WinCC side had a credential set that the CPU user-management table no longer accepted after the project upgrade.

10. WinCC V7.x vs WinCC Unified Considerations

The same diagnostic buffer entry is observed on WinCC Unified (PC and Unified Comfort Panel) connections to S7-1500 CPUs. Differences engineers should know:

• Unified PC connections count as 1 PG/HMI/OP resource when using a single connection, and 2 when redundancy is configured (one primary, one standby channel).
• Unified Comfort Panels (MTP/MTP Unified) count as 1 resource per panel.
• When Unified and V7.x WinCC stations both connect to the same CPU, total resource occupation must be summed; for a 1513-1 PN the practical maximum is approximately 4–6 simultaneous HMI connections before exhaustion becomes likely.

The resolution steps above apply identically; only the import path differs. For Unified, the equivalent of step 7 is to open the Unified project in TIA Portal and use the integrated "HMI tags > Update" workflow rather than the XLSX export/import used in V7.x.

11. Firmware Update Path for S7-1500 CPUs

Firmware updates for S7-1500 CPUs and ET 200 CPUs (ET 200SP, ET 200pro) are published through the Siemens Industry Online Support portal. The recommended workflow is:

1. Download the firmware update package matching the exact MLFB (e.g. 6ES7513-1AM02-0AB0 for the 1513-1 PN).
2. Extract the package to a folder accessible from the engineering station.
3. Connect the CPU via Ethernet (direct, not via WLAN) and go online in TIA Portal.
4. Open Online > Accessible devices, select the CPU, then choose Online & diagnostics > Firmware update.
5. Browse to the extracted .upd file and start the update. The CPU performs an automatic STOP/RUN transition at the end of the update.

12. Verification Matrix

After applying the fix, use this verification matrix to confirm each layer:

Layer	Test	Expected result
Physical	Ping the CPU from the SCADA PC (ping 192.168.0.x)	Reply < 1 ms, no loss
Channel	Channel Diagnosis > S7DOS > Status	Connected (green), no 0x8000… HRESULT
Tags	WinCC tag simulator reads three distinct PLC tags	Values update on a 1 s poll
Security	Re-enable "Only allow secure PG/PC and HMI communication"	Connection remains stable
Diagnostic buffer	Trigger 10 forced STOP/RUN transitions in TIA Portal and close project cleanly	No new "System initiated session termination" events
Resource	Web server > Diagnostics > Connection resources	PG/HMI count returns to baseline within 60 s of disconnect
WinCC redundancy (if used)	Failover the SCADA pair	Standby takes over within 5 s, no 0x1521 error

13. Common Pitfalls

1. Skipping the STOP/RUN after a security change – the new protection level is in effect, but the old security event IDs remain in the buffer and obscure the new behavior.
2. Re-importing tags without regenerating the export – the certificate fingerprint in the import file is stale; WinCC will not raise an error but the secure channel will be rejected by the CPU after a few seconds.
3. Trusting the WinCC Online state alone – a green "Connected" indicator in the WinCC Channel Diagnosis can coexist with pending security events in the PLC. Always cross-check the PLC diagnostic buffer.
4. Empty password with secure comm enabled – WinCC sends a non-empty password by default in secure mode. An empty CPU password is treated as invalid; the connect fails with 0x1521.
5. Mixing the TIA V18 and V19 project files – the certificate signing chain is re-generated at compile time when the TIA version changes. Re-export tags after every TIA version change.

14. Preventive Best Practices

• Maintain a single engineering PC per project to control certificate authority consistency.
• Set the SCADA PC and CPU clocks to the same NTP source.
• Document the CPU's user-management table (user, access level, password expiry) in the project backup.
• Use the TIA Portal "Project > Security > Certificate management" view to keep an offline copy of every CPU's certificate.
• Schedule a quarterly firmware review against the Siemens Industry Online Support release notes for S7-1500.

15. FAQ