Configuring WinCC Unified HMI Without a CPU in Project

Splitting the HMI out of the controller project is supported and routine. The cost is that everything TIA Portal generates for you in an integrated project — the connection object, the tag address resolution, and the certificate trust between the Unified Runtime and the CPU — becomes your responsibility. Most failed attempts stop at the certificate stage, conclude that non-integrated operation "does not work," and go back to merging projects on every HMI revision. It works; the trust chain just has to be built by hand.

Integrated vs. Non-Integrated Connection: What Changes

The term integrated here means the HMI station and the CPU live in the same TIA Portal project, so the engineering tool owns both sides of the link. It generates the HMI connection, resolves HMI tags against the PLC tag table or data block symbols, keeps addresses synchronized when a DB is edited, and — where secure PG/HMI communication is active — issues both device certificates from the same project CA.

A non-integrated connection means the HMI project holds only a connection definition: driver, CPU IP address, rack and slot. There is no PLC hardware configuration on that side. You create the connection manually, create HMI tags manually against that connection, and supply the certificate trust manually. Nothing in the runtime cares whether the CPU object exists in your project; the runtime opens a socket to an IP address and speaks the S7 protocol over TCP port 102.

If you want a placeholder for structure, add an unspecified or proxy PLC device to the HMI project. It gives you a device to hang the connection on without carrying the real hardware configuration, and it will not be downloaded to anything.

Check 1: Addressing Mode of the PLC Tags

Take the reading in the PLC project: open each data block the HMI needs and read the block attribute for optimized block access.

Build one dedicated HMI interface DB with optimized access switched off and freeze its layout. Every internal DB stays optimized. This is the single design decision that makes decoupled projects survivable, because it isolates the offsets the HMI depends on from the blocks your PLC team edits daily.

Check 2: CPU Access Protection and Secure Communication

Open the CPU properties and read two settings: the protection level (access level for HMI/read/write) and the connection mechanism controlling whether the CPU permits only secure PG/PC and HMI communication.

The mechanism: with secure PG/HMI communication enforced, the CPU terminates the session with TLS. The HMI must present a device certificate signed by a certification authority the CPU trusts, and must itself trust the CA that signed the CPU's communication certificate. In one project, TIA Portal issues both from the project CA and the trust exists silently. Across two projects there are two CAs, neither knows the other, and the TCP connection is established and then dropped. That is the symptom that reads as "the connection does not work" — link lights on, ping fine, no data.

• Protection level blocks HMI access → HMI tags stay at bad quality even with certificates correct. Raise the access level or supply the configured password on the connection.
• Secure communication enforced, no trust exchange → connection cycles. Go to Check 3.
• Legacy PG/HMI communication permitted → no certificate work needed; the connection comes up as soon as the address, rack and slot are right. Accept the reduced security posture consciously, and only where the HMI–PLC segment is a protected control network.

Check 3: Certificate Exchange Between Two Projects

Work in the global security settings of each project; the certificate manager is only visible after you log in as a project user with the appropriate rights.

1. In the PLC project, open the certificate manager and export the CA certificate that signed the CPU's communication certificate (public part only, no private key).
2. In the HMI project, import that file into the certificate manager and mark it trusted for the Unified Runtime device.
3. Export the CA of the HMI project the same way.
4. Import it in the PLC project and add it to the CPU's list of trusted certificates in the protection and security settings.
5. Download the CPU. Changes to protection and certificate settings take effect on a full hardware download, not a delta download of blocks.
6. Download or deploy the Unified Runtime configuration so the panel or PC station receives its updated certificate store.
7. Set the clock on both devices, ideally from the same NTP source. A certificate outside its validity window is rejected exactly like an untrusted one, and a panel that boots with a 1970 clock will never connect.

Repeat steps 1–2 whenever either project's CA is regenerated. Regenerating the CA is the most common cause of a link that worked last month and does not today.

Alternative Branch: OPC UA Instead of the S7 Driver

If Check 1 returned optimized DBs you cannot convert, or you want the interface to be self-describing, run the CPU's OPC UA server and configure the Unified station as an OPC UA client. Tags are addressed by browse path rather than byte offset, so DB layout changes do not silently repoint a tag, and the HMI project needs nothing from the PLC project except the node names.

Two prerequisites: the CPU needs the OPC UA server license activated in its hardware configuration, and the client certificate must be moved into the server's trust list — the same trust problem as Check 3, solved either by importing the client certificate in the CPU configuration or by accepting it from the CPU's web server certificate page. Default endpoint port is 4840. Open it through any firewall between the two segments, alongside or instead of port 102.

Commissioning Verification

1. Reachability. Ping the CPU from the HMI device. Expect replies with stable latency; packet loss here is a network problem, not a configuration problem.
2. Port reachability. Probe TCP 102 (or 4840 for OPC UA) from the HMI device. Expect an open socket. Closed means firewall or wrong IP.
3. Connection state in Runtime. Open the Unified Runtime diagnostics and read the connection status. Expect established and stable. A state that toggles established/disconnected at a fixed interval is the certificate rejection signature, not a wiring fault.
4. CPU diagnostic buffer. Read it after a connection attempt. Entries about rejected or aborted secure communication confirm the trust chain; entries about access protection confirm the protection level.
5. End-to-end value. Force a known value into the interface DB from a PLC watch table and read the matching HMI tag. Expect the identical value with good quality. A plausible but wrong value means the manual tag offset does not match the DB layout — return to Check 1.
6. Write path. Write from an HMI I/O field and observe the change in the watch table. Expect acceptance. Rejection with a live read path means the CPU access level permits read only.
7. Offset regression. After every PLC download that touched the interface DB, repeat check 5 on the first and last tag of the block. Both correct means the layout did not shift.

Frequently Asked Questions