Siemens S7 ISO vs TCP Communication: TSAP, RFC1006 Reference

Overview of Siemens S7 Communication Models

Siemens S7 controllers support several transport mechanisms for exchanging user data between PLCs, between PLCs and HMIs/SCADA, and between PLCs and PCs. In STEP 7 (classic) and TIA Portal, the two transport services an integrator selects when configuring an S7 connection are ISO transport (sometimes labeled "ISO on Industrial Ethernet") and TCP. A third option that often appears alongside them is ISO-on-TCP, which combines the ISO Transport semantics used inside the S7 protocol stack with the routable TCP/IP transport from the Internet suite. Understanding when each option is appropriate, how addressing differs, and what an FB/SFB-based program actually sees at the API level is essential for stable commissioning and predictable SCADA behavior.

The S7 user program does not see the wire-level format. Whether the underlying transport is pure ISO 8073 over Ethernet Type 0x88A2 frames, plain TCP over a stream socket, or ISO Transport encapsulated over a TCP socket per RFC 1006, the application calls the same SEND/RECEIVE or BSEND/BRECV blocks once the connection has been configured in the hardware/net editor. The differences sit below that abstraction in addressing, hardware support, and the path the data takes through the CP, CPU PN interface, and the network.

OSI Layer Mapping

Both ISO and TCP variants of the S7 protocol occupy similar positions in the OSI model but map to different layers and frame formats:

Key practical consequence: ISO Transport frames cannot leave the local Layer 2 broadcast domain intact. They are not routable because they carry no IP header and no TTL field. TCP and ISO-on-TCP, by contrast, ride over IP and can traverse routers, NATs (with care), VPNs, and cellular backhauls. This single observation drives most connection-type decisions.

ISO Transport (ISO 8073) on Industrial Ethernet

ISO Transport, defined in ISO/IEC 8073, is the OSI Transport Class 4 protocol that Siemens originally adopted for the Industrial Ethernet (formerly SINEC H1) environment. In Siemens hardware it is carried directly over Ethernet using EtherType 0x88A2, which identifies an "ISO connectionless or ISO connection-oriented" frame as defined in ISO/IEC 8802-2 / IEEE 802.2.

Connection identifiers used by ISO Transport

An ISO Transport connection is identified to the S7 communication interface by exactly two parameters:

• The MAC address of the partner (CPU or CP) interface.
• A TSAP (Transport Service Access Point) on each end — one local, one remote.

No IP, no port, no subnet, no router. A S7 connection configured as ISO therefore does not care whether the partner has a routable IP address; it cares only that the MAC address is reachable on the local Ethernet segment via the configured CP or PN port.

Hardware support for ISO Transport

Not every Siemens PN interface supports ISO Transport. As a rule of thumb:

• Older CP 343-1 / CP 443-1 modules (firmware classes that supported the SIMATIC NET "ISO" connection type) support ISO and ISO-on-TCP.
• Modern S7-1200 / S7-1500 PN interfaces and the newer CP 1543-1 / CP 1545-1 support ISO-on-TCP and TCP natively; pure ISO is typically disabled or not offered on current-generation PN stacks.
• Check the firmware functional description in Siemens Industry Online Support for each CP before committing to an ISO design.

TCP and RFC 1006 (ISO-on-TCP)

TCP, defined in RFC 793, is the standard Internet stream protocol. Two entities establish a session by a three-way handshake and exchange an unstructured byte stream. Siemens uses TCP two ways on the S7 platform:

1. Direct TCP — the S7 Communication layer drives the TSAP-like semantics over a raw TCP socket using port 102 (decimal), the well-known ISO-TSAP/COTP port. This is the most common transport you will see in STEP 7 net dialogs labeled simply "TCP" against an S7-1200 or S7-1500 with security disabled.
2. ISO-on-TCP — the same ISO Transport class 4 PDUs are placed inside TCP segments exactly as if ISO were running directly over the wire, but the underlying service is RFC 1006 ("ISO Transport on top of TCP"). RFC 1006 defines the framing rules that allow a stream-oriented protocol like TCP to carry the TPDUs of an OSI transport. Implementations negotiate this mode by default on Siemens CP modules.

Connection identifiers used by TCP / ISO-on-TCP

A TCP-based connection is identified to the S7 communication interface by:

• The remote IPv4 address (and optionally the local interface selector when binding explicitly).
• A port number (default 102).
• A TSAP on each end (same concept as ISO — a logical sub-address beneath the socket).

The TSAP is preserved in TCP variant connections because the S7 protocol stack treats it as the S7 connection-level identifier. Even on a raw TCP session to port 102, the user typically still enters two TSAPs in the net configuration so that the S7 layer on each side can address the right application endpoint.

RFC 1006 Framing in Practice

RFC 1006 is a thin shim placed between an ISO-Transport stack and TCP. The bits on the wire look approximately like this:

+----------------------------------------------+
| IP header                                    |
+----------------------------------------------+
| TCP header (src port, dst port, seq, ack...) |
+----------------------------------------------+
| 0x03  TPDU length byte (always 0x03 on wire) |
+----------------------------------------------+
| TPDU length (1 byte)                         |
+----------------------------------------------+
| ISO 8073 TPDU (DT, CR, CC, AK, DR, DC...)    |
+----------------------------------------------+

The leading 0x03 0xXX 0xYY triple is the RFC 1006 framing header. The first byte (0x03) is the ISO Transport Protocol Identifier; the next two bytes encode the TPDU length. Everything that follows is a normal ISO Transport TPDU with its embedded TPKT inside — exactly as it would have appeared on an ISO Ethernet frame. This is what allows the same S7 user blocks (SEND, RECEIVE, PUT, GET) to run unchanged when the designer switches the underlying transport from Ethernet-direct ISO to ISO-on-TCP.

TSAP Structure and Addressing

TSAP stands for Transport Service Access Point. In the Siemens S7 environment a TSAP is a two-byte ASCII string that uniquely names an S7 application endpoint below the TCP/ISO socket. Format:

TSAP byte 0 = ASCII character (printable, e.g. '0'..'9', 'A'..'Z')
TSAP byte 1 = ASCII character (printable)
TSAP value  = two-character string, e.g. "01", "0A", "10", "FE"

The TSAP is set on each side of the connection. The two TSAPs do not have to match — they identify the local and remote application endpoints. As long as the partner's TSAP is configured consistently in both stations' net objects, the S7 layer matches the connection.

Standard TSAP conventions

Siemens uses a documented convention for the high byte of the TSAP on many CPU types:

The second byte is commonly the connection number or a user-selected site identifier. Examples you will see in many Siemens project templates:

• Local CPU, connection 1: TSAP 01.00 or 01.01 on the CPU side.
• Partner CP 343-1 in slot 4 of a remote rack: TSAP 04.01 on the partner side.
• HMI station with TSAP 10.00 for an S7-1500 that uses the "HMI" preset.

Connection Types in STEP 7 and TIA Portal

When you add an S7 connection in either the classic NetPro editor or the TIA Portal "Devices & Networks" editor, you choose one of the following transport options from the drop-down:

In TIA Portal, the dropdown is typically labelled simply "S7 connection", and the underlying transport is fixed to ISO-on-TCP unless you manually choose another type. The classic STEP 7 NetPro UI exposed all three options explicitly. Mis-selecting ISO when both partners are S7-1500 will at minimum require a CP upgrade and at worst fail with a non-specific connection-status error.

SEND/RECEIVE Programming Interface

The S7 user program interacts with these connections through standard blocks. The transport mechanism is opaque inside the FC/FB, but the block ID handle differs per family.

Example: S7-300/400 SEND/RECEIVE call (SCL)

// Local: SEND on connection ID 1, completed immediate
CALL FB 12 "BSEND" , %DB10
   REQ    := TRUE;            // Trigger send
   ID     := W#16#1;          // Connection ID from NetPro
   R_ID   := DW#16#1;         // R_ID for BSEND pairing
   DONE   := DB10.DBX0.0;     // Send done
   ERROR  := DB10.DBX0.1;     // Send error
   STATUS := DB10.DBW2;       // Block status
   SD_i1  := P#DB11.DBX0.0 BYTE 200;  // Send DB
   LEN    := 200;

Example: TIA Portal TSEND/TRCV (SCL, S7-1500)

// Establish an ISO-on-TCP connection to partner 192.168.0.12, port 102
// Local TSAP: "10.00"; remote TSAP: "03.01"
#Conn := TC_CONNECT(REQ := TRUE,
                    CONNECT := "TCON_IP_v4",
                    InterfaceId := "PN-IF-1",
                    ID := 1,
                    ConnectionType := 16#0B,    // 0x0B = ISO-on-TCP
                    ActiveEstablished := TRUE,
                    RemoteAddress  := IP_V4(192,168,0,12),
                    RemotePort     := 102,
                    LocalTSAP      := B#16#10,
                    RemoteTSAP     := B#16#03,
                    SubnetMask     := IP_V4(255,255,255,0));

IF #Conn.Status = 0 AND #Conn.Done THEN
   // Connection is up; now use TSEND / TRCV with ID := 1
   #ts := TSEND(REQ := TRUE,
                ID  := 1,
                LEN := 20,
                DATA := P##SendBuf);
END_IF;

Block STATUS codes for SEND/RECEIVE failures

Refer to the per-block STATUS list in the Siemens "Communication Function Blocks" manual for the complete enumeration; this table lists only the codes most often seen during transport-type troubleshooting.

CP Module Configuration

Connection behavior on a SIMATIC rack is governed by two configuration places: the CP hardware configuration (slot, firmware, IP, subnet) and the S7 connection object in the net editor.

Step-by-step: Configuring a CP 1543-1 as ISO-on-TCP server

1. In the TIA Portal project tree, open "Devices & Networks" and place the CP 1543-1 into the station's rack. Wire its PN interface to the same subnet as the partner S7-1500.
2. Open the CP "Properties" dialog and assign an IPv4 address plus subnet mask consistent with the partner's subnet. Activate "Use router" only if the partner truly lives behind one.
3. In the security settings, verify that the IPv4 access control list permits the partner's IP on TCP/102. If access protection is enabled with no ACL entry, the connection will be silently dropped at the CP firewall even though the S7 net object is correct.
4. Open "Devices & Networks > S7 Connections" and create a new "S7 connection" specifying the partner as the active endpoint and the local CP as the local endpoint.
5. In the connection properties, expand "Address Details" and confirm: Local TSAP = configured value, Remote TSAP = partner's value, Port = 102, Connection type = ISO-on-TCP. TIA Portal may auto-suggest "TCP" if the partner CPU firmware only advertises that variant — switch the drop-down to ISO-on-TCP explicitly if the partner supports it.
6. Compile and download both stations. Watch the CP's "Connection" diagnostics page for STATUS = OK.

Impact on SCADA and OPC Systems

A SCADA system that exchanges tags with an S7 PLC via one of three channels:

1. Native S7 driver / LibNoDave / Snap7 / Siemens S7 OLE DCOM OPC Server over a connection that ultimately relies on the same TCP port 102 transport on the wire.
2. Siemens OPC UA server on the CPU (S7-1500) or SIMATIC NET OPC Server on the PC side.
3. S7 routing through the CP and CPU (used when the SCADA cannot directly address the CPU due to network segmentation, e.g. cellular or site-to-site VPN).

Switching the underlying transport on the PLC side from ISO to ISO-on-TCP, or changing the CP module, affects the SCADA as follows:

Hardware Migration Considerations

When the PLC fleet moves from S7-300/400 to S7-1200/1500, or swaps a CP 343-1 for a CP 1543-1, the connection objects must be re-created in the new project because:

• The new CP may not support the legacy "pure ISO" transport.
• TSAP conventions can differ by CPU generation; the high-byte slot value rule applies differently on S7-1500 vs S7-300.
• Security features (firewall, ACL, PUT/GET permission) on the new CP default to stricter values, often blocking legacy SCADA traffic until the ACL is opened.
• S7 routing through a CP may no longer be required because the S7-1500 CPU can be addressed directly via its own PN interfaces.

Migration checklist (abbreviated)

1. Inventory all S7 connections (active and configured but unused) in the source project.
2. For each connection, record: connection ID, partner IP/MAC, port, local TSAP, remote TSAP, transport type, used SEND/RECEIVE blocks.
3. Create equivalent connection objects in the new TIA Portal project with matching TSAPs and transport types where supported.
4. Update each SCADA / OPC client to point at the new device's IP and to honor new firewall rules.
5. Verify every connection with a simple SEND/RECEIVE round-trip before going on-line in production.

Diagnostic and Troubleshooting Matrix

Field-Commissioning Procedure (Summary)

1. Confirm both stations are on a common subnet or routed path appropriate to the chosen transport.
2. Verify CP module type and firmware in the project match the physically installed part numbers.
3. Compile, download, and place both CPUs in RUN.
4. From one CPU's online diagnostics, watch the S7 connection status. Expect "Established" within ~10 s after the boot of the passive side.
5. Execute a one-shot round-trip test using a small (16-byte) SEND/RECEIVE pair, verifying status, length, and content at both ends.
6. Roll forward to production traffic only after the round-trip is stable for several minutes.
7. Record connection IDs, TSAPs, IPs, and transport in the as-built documentation so future migrations start from an accurate baseline.