PCS7 to Teleperm XP Ethernet Communication ISO-on-TCP

1. System Overview and Scope

Interfacing a modern Siemens PCS 7 process control system with a legacy Teleperm XP (or Teleperm ME / AS 488) distributed control system over Ethernet is a routine brownfield integration task. The architecture described in this reference uses two redundant PCS 7 servers and up to eight OS clients on the plant bus, and adds a dedicated redundant Industrial Ethernet segment to a Teleperm XP automation system for supervisory data acquisition and OS-level display.

The relevant traffic type is one-directional supervisory exchange: Teleperm XP publishes process values, alarms, and operator messages that the PCS 7 OS server must consume, archive, and re-display. Two practical constraints dominate the design:

1. PCS 7 uses ISO-on-TCP (RFC 1006) on top of TCP/IP as its preferred open protocol for cross-vendor / cross-generation bridging, because it preserves the S7 transport semantics that both the CP 443-1 and the CP 1613 / CP 1623 server cards understand natively.
2. Teleperm XP / AS 488 systems expose a fixed, well-defined set of Ethernet-capable CPs (e.g., CP 1430 / CP 1430 TF, or the SIMATIC-Net derived CP 343-1 / CP 443-1 on the Teleperm ME side). These are not "PC stations" - they are S7-compatible stations that can be addressed as ISO transport partners, but they must be modeled as a peer in the PCS 7 project.

The MAC-address handling in the source design (giving the CP 443-1 MAC of the PCS 7 AS to the Teleperm system as if it were a CP 1613 of the server) is incorrect and will create a layer-2 loop or duplicate-address scenario. The correct approach is to model the Teleperm XP station as a separate Other Station in NetPro and bind an IP, not a borrowed MAC, to the PCS 7 side of the ISO-on-TCP connection.

2. Hardware Topology

Redundant plant-bus and redundant Teleperm-bus are kept physically and logically separate. The recommended topology is shown in the diagram below.

The Teleperm bus runs as a physically separate LAN segment. The two PCS 7 OS server CP 1613 / CP 1623 cards each connect to the Teleperm bus through a dedicated secondary Ethernet port; one acts as the active link, the other as a hot-standby that takes over on a CP or link failure. The PCS 7 AS does not need to be on the Teleperm bus unless the application requires it to exchange S7 data with the Teleperm XP; for read-only OS data exchange, all traffic is sourced from the OS server pair.

3. Addressing Strategy and the MAC-Address Trap

It is a recurring mistake to treat the MAC address of a PCS 7 server CP 1613 as if it were the MAC of a CP 443-1 on the AS. The CP 1613 / CP 1623 is the network interface of a PC station (WinCC Application / S7 PC station), while the CP 443-1 belongs to an S7-400 station. These are different NetPro object types with different connection endpoints.

Rules that must be enforced at the network layer:

1. Every MAC address on the plant bus and the Teleperm bus must be globally unique within the bridged domain. Borrowing a MAC is acceptable only on virtual bridges that strip the outer MAC (e.g., VPN encapsulation), not on plain Industrial Ethernet switches.
2. The ISO-on-TCP connection is identified by an IP pair plus a TSAP (Transport Service Access Point) on each side. The TSAP is what the S7 transport uses to route the connection to the correct application endpoint inside the station - the IP is only a layer-3 reachability hint.
3. The Teleperm XP station must be entered in NetPro as a "Other Station" object of type S7 / unspecified. The PCS 7 side does not need to know the Teleperm CPU type; it only needs to know the partner IP, partner TSAP, local TSAP, and whether it is an active or passive connection endpoint.

4. NetPro Configuration: Modeling the Teleperm XP Station

Configuration is performed once in the engineering station and downloaded to all S7 PC stations, the AS, and (via the OS server's WinCC explorer) the redundant OS server pair.

1. Insert "Other Station" object. In SIMATIC Manager, right-click the project, choose Insert New Object > Other Station. Name it e.g. TPXP_AS488. This is the NetPro placeholder for the Teleperm XP automation system.
2. Add an Ethernet interface. Open the new object, insert an "IE General" or the Teleperm-specific CP type. Assign a fixed IP - e.g. 10.20.40.50 - and a subnet mask consistent with the Teleperm bus.
3. Bind the connection. On the OS server PC station, right-click the CP 1613 / CP 1623 that is dedicated to the Teleperm bus, and choose Insert New Connection. The partner is the "Other Station" just created. The connection type is ISO-on-TCP connection (also listed as "TCP connection" with the ISO transport attribute - in SIMATIC terms this is the "ISO-on-TCP" variant, RFC 1006).
4. Configure TSAPs. Local TSAP: a unique two-byte hex string assigned to the OS server side, conventionally written as 00.01 for the active server and 00.02 for the standby, followed by any required rack/slot padding. Partner TSAP: the value that the Teleperm XP's CP 1430 TF has been configured to listen on - this is plant-specific and must be obtained from the Teleperm commissioning documentation.
5. Establish the connection role. Choose "Active connection establishment" on the OS server side so that PCS 7 initiates the TCP three-way handshake. The Teleperm CP is then a passive listener, which matches its typical Teleperm XP role.
6. Compile and download. Use NetPro > PLC > Compile and Download Objects. Compilation must finish without errors; warnings about unknown partner CPU are expected for an "Other Station" and are not blocking.

5. ISO-on-TCP Connection Parameters

The NetPro dialog "Properties - ISO-on-TCP Connection" exposes the fields in the table below. Values shown are a typical starting point for a Teleperm XP integration; confirm with the Teleperm engineering team before downloading.

6. AG_SEND / AG_RECV Program Structure

Once NetPro has established the connection reference, the user program on the OS server side uses the AG_SEND and AG_RECV function blocks from the SIMATIC_NET CP library (FB 12 / FB 13 in PCS 7 V8/V9 nomenclature) to exchange data. The blocks are connected to the connection ID that NetPro has generated. The same block pair is used whether the data is destined for an S7-400, a third-party PLC, or the Teleperm XP - the only difference is the TSAP routing.

Recommended structure on the OS server side (CFC or STL):

// One DB per logical Teleperm data area
DATA_BLOCK DB_TPXP_FRAME
  STRUCT
      hdr  : BYTE;     // Teleperm transport header
      data : ARRAY[1..232] OF BYTE; // payload
  END_STRUCT
END_DATA_BLOCK

// AG_RECV (FB 13) - call cyclic, e.g. OB35 (100 ms)
CALL FB 13, DB_TPXP_RECV
    ID         := W#16#0001;     // connection ID from NetPro
    LADDR      := W#16#0100;     // CP 1613 logical base address
    RECV       := P#DB_TPXP_FRAME.data BYTE 240;
    NDR        := #recv_done;    // new data received
    ERROR      := #recv_err;     // 0 = ok, <>0 see STATUS
    STATUS     := #recv_status;  // S7 status word
    LEN        := #recv_len;     // bytes received

// AG_SEND (FB 12) - triggered by #send_trigger
CALL FB 12, DB_TPXP_SEND
    ID         := W#16#0001;
    LADDR      := W#16#0100;
    SEND       := P#DB_TPXP_FRAME.data BYTE 240;
    LEN        := #send_len;
    DONE       := #send_done;
    ERROR      := #send_err;
    STATUS     := #send_status;
    REQ        := #send_trigger;  // rising edge initiates send

Notes on the program structure:

• AG_SEND is a rising-edge triggered block; pulse the REQ input for one cycle per transfer.
• AG_RECV must be called every cycle, otherwise incoming frames are buffered in the CP and the receive window fills.
• The connection ID, the LADDR (logical address of the CP 1613 / CP 1623), and the TSAP pairing are all generated / confirmed by NetPro - never hard-code TSAPs in the application code.
• For redundant OS servers, instantiate the AG_SEND / AG_RECV block pair on both servers. Only the active server executes the block; the PCS 7 redundancy control (WinCC Redundancy) gates the REQ trigger by the current server role.

7. Teleperm XP / AS 488 Side Configuration

From the PCS 7 perspective the Teleperm system is an opaque peer. The Teleperm engineering team must:

1. Configure the CP 1430 TF (or equivalent) for ISO transport with the partner IP 10.20.30.11 and 10.20.30.12 as two passive listeners, each associated with a TSAP (10.01 and 10.02). Both servers can be in the partner list; the Teleperm CP will accept the first connection and reject duplicates.
2. Define which Teleperm data blocks (DBs) or process images are exported to the ISO transport. This is usually a Teleperm XP "CFC / SCD" mapping or a "PG-AG coupling" block list, and is documented in the Teleperm XP engineering package.
3. Provide a list of partner IP / TSAP / DB mappings to the PCS 7 commissioning team so that the PCS 7 application program can interpret the incoming bytes. Byte ordering on Teleperm XP is typically Motorola (big-endian) for older AS 488 firmware and Intel (little-endian) for newer variants; confirm per plant.
4. Set the Teleperm CP time-of-day synchronization source. If PCS 7 is the time master, the Teleperm CP should be set to "Slave on LAN" and pointed at the OS server pair; otherwise, treat PCS 7 as a slave of Teleperm XP time if that is the plant's existing master.

8. Redundancy Behavior on the Teleperm Bus

PCS 7 supports two redundancy patterns for the OS server <-> Teleperm bus link:

The redundant Ethernet bus between the OS servers and the Teleperm XP should be built as a ring (HRP or MRP) using SCALANCE X-200 / X-400 managed switches. STP is acceptable for non-real-time segments, but a ring protocol is preferred for sub-second failover in process plants.

9. Step-by-Step Commissioning Procedure

1. Pre-check. Verify physical cabling of the Teleperm bus, SFP types, and that both OS servers see link on the Teleperm bus port. ping 10.20.40.50 from each OS server should succeed. If it does not, stop and resolve the L2 issue - ISO-on-TCP cannot work over a broken L2 path.
2. NetPro build. Insert "Other Station" with Teleperm IP, create the ISO-on-TCP connection from OS server CP 1613, set TSAPs, compile, download to both OS server PC stations and the AS.
3. WinCC channel binding. On each OS server, open WinCC Explorer and ensure the S7 channel set points to the new connection ID. The "Industrial Ethernet" channel driver uses the connection ID to look up the underlying CP / connection.
4. AG_SEND / AG_RECV smoke test. Run a small test CFC that calls AG_RECV every 100 ms and increments a counter in the OS archive when NDR is true. After Teleperm publishes the first frame, the counter must increment steadily.
5. Failover test. Force the active OS server to fail (WinCC Redundancy > Switch). The standby must take over the connection within the configured monitor time, and the OS archive must continue without gap. Repeat at least three times to confirm clean failover.
6. Cable fault test. Unplug one ring segment on the Teleperm bus. Ring manager (HRP/MRP) should reconverge in < 300 ms. Connection should not drop, or should drop and recover automatically without operator intervention.
7. Long-run stability. Leave the link in service for at least 72 h of continuous operation. Check the S7 diagnostic buffer of the OS server CP for repeated transient errors and the WinCC Tag Logging for teleperm-side data dropout.

10. Verification Checklist

11. Troubleshooting Matrix

12. FAQ