Connecting Multiple Siemens LOGO! 8 Controllers to AWS Cloud

Overview: Multi-Site LOGO! 8 Data Acquisition Architecture

When temperature, status, or process values must be collected from a few dozen to several hundred distributed sites, the Siemens LOGO! 8 (0BA8 generation, sold as LOGO! 8.3 from firmware FS-03 onward) is a frequent choice for the field device because of its compact footprint, integrated Ethernet interface, and built-in AWS IoT client. The real engineering problem is not the field device itself; it is the network topology, the connection accounting on every LOGO!, and the choice of uplink (LAN, cellular 4G/LTE router, or site-to-site VPN).

This reference consolidates the constraints of a typical 80-site deployment: a LOGO! 0BA8 acting as a server or client can sustain only a limited number of S7/LOGO! partner connections, so a hierarchical data collector pattern is required to scale beyond ~16 LOGO! per aggregation node. The article then maps the field wiring, the LOGO! Web Editor (LWE) dashboard, the AWS IoT Core shadow, and the 4G/LTE router selection into a single commissioning workflow.

LOGO! 8 (0BA8) Connection Accounting and Limits

The 0BA8 generation exposes a fixed pool of S7 partner connections for LOGO!-to-LOGO! or LOGO!-to-S7-1200/1500 traffic. The pool is split into static and dynamic halves and is enforced by the LOGO! firmware. Exceeding the configured count causes the connection attempt to be rejected with no diagnostic LED, which is the most common cause of "dead" data points in a multi-site deployment.

The network variable path is a different transport than the S7 partner path. Network variables use a simple UDP-based publish/subscribe between LOGO! 0BA8 devices on the same Ethernet segment, and they do not consume entries from the 8+8 connection pool. They are ideal for low-overhead sensor broadcast between a small cluster of LOGO!s on a single LAN, but they do not cross routers and they do not traverse 4G/LTE cellular links without a VPN tunnel.

Topology 1: Flat Direct-to-Cloud (Recommended for 1–200 sites)

For geographically scattered sites, the cleanest architecture is to have every LOGO! 8.3 publish directly to AWS IoT Core and skip the LOGO!-to-LOGO! hop. This removes the 16-connection ceiling entirely because the AWS IoT client uses its own TLS session and does not interact with the S7 partner pool.

Prerequisites

• LOGO! 8.3 (FS-03 firmware or newer) at every site; for example part number 6ED1052-1MD08-0BA0 (LOGO! 8.3 12/24 RCE) or 6ED1052-1HB08-0BA0 (LOGO! 8.3 230 RCE).
• LOGO! Soft Comfort V8.3 (or newer) installed on the engineering workstation.
• AWS account with IoT Core activated in a single region.
• Per-site Internet uplink: existing LAN with a free Ethernet port, or an industrial 4G/LTE router such as the SCALANCE M876-4 (6GK5876-4AA00-2BA2) or a third-party M2M router (Teltonika RUT950, Robustel R2000, etc.).
• Local DNS, NTP reachable from the LOGO! (AWS provides NTP via time.aws on port 123; the LOGO! supports NTP synchronization).

Step-by-Step

1. Create a unique AWS IoT Thing per site (e.g. site-munich-01, site-rome-02). Each Thing gets its own X.509 device certificate and private key.
2. In the LOGO! project (LOGO! Soft Comfort), open the Web Editor / Cloud Connector configuration and add an AWS IoT account entry. Paste the endpoint hostname (e.g. a1b2c3d4-ats.iot.eu-central-1.amazonaws.com), the certificate, the private key, and an optional root CA.
3. Map the analog input that reads the temperature sensor (for example AM1 on a LOGO! 8.3 12/24 RCE) to a cloud variable. The LOGO! publishes it as a JSON payload on the MQTT topic logo/<thingname>/data.
4. Use the LOGO! Web Editor (LWE) in the project to build a dashboard that aggregates values from all Things. Add the IoT names as remote tags so the same dashboard reads from multiple LOGO!s.
5. Download the project to the LOGO!. On power-up the LOGO! opens a TLS session to AWS IoT Core, performs the MQTT connect with the certificate, and starts publishing.

The result is that the central computer is replaced by a browser pointed at the LWE dashboard, or by any MQTT consumer subscribed to the topic filter. The laptop or SCADA workstation no longer needs to be online, and a 4G/LTE uplink at the remote site is sufficient because the LOGO! only opens an outbound TCP/8883 connection.

Topology 2: Hierarchical Data Collector (Legacy / Air-Gapped Networks)

If the application is local to a single plant (no cloud, no public Internet) or if the LOGO! 8.3 firmware is unavailable, the historical approach is a pyramid of LOGO! data collectors. A collector LOGO! aggregates a small number of leaf LOGO!s and exposes a single upward interface. A second-tier collector aggregates first-tier collectors, and so on.

This means an 80-leaf deployment is feasible with 10 first-tier collectors and 1 second-tier collector, with the second-tier LOGO! holding the aggregated data. The top tier can be a SIMATIC S7-1200 (CPU 1214C DC/DC/DC, 6ES7214-1AG40-0XB0) or S7-1500 if more processing or storage is needed.

Network Variable (NI/NQ) Communication Between LOGO! 8 Devices

For two or more LOGO! 0BA8s on the same physical Ethernet, network variables offer a low-overhead broadcast. The sending LOGO! exposes Network Outputs (NQ) on a specific multicast group; the receiving LOGO! binds them to Network Inputs (NI). Up to 16 NI/NQ pairs are configurable per LOGO!.

1. In LOGO! Soft Comfort, open the project of the sending LOGO! and assign the analog value to a network output, e.g. NQ1 = AM1 / 10.0 (divide by 10.0 to convert 0–1000 raw to 0.0–100.0 °C).
2. Set the multicast group ID. The same ID must be used on every peer on the LAN; it does not need to be unique globally.
3. On the receiving LOGO!, create a Network Input bound to the same NQ number. The value can be used like any local analog input, e.g. fed into a threshold switch or a cloud connector block.
4. Verify the wiring with the LOGO! on-line test: in Tools > Transfer > Network Test (LOGO! Soft Comfort) the receiving side must show the value updating at the configured cycle (default 1 s).

Network variables do not consume the S7 partner pool, so they are the right tool for a small LAN cluster inside one building. They are not routable across the public Internet, so they cannot be used to reach remote sites without a site-to-site VPN.

AWS IoT Core Integration: Topics, Shadows, and the LWE Dashboard

LOGO! 8.3 uses a single MQTT topic to publish and an optional shadow document to receive commands (for example, change a setpoint). The default topic layout published by the LOGO! cloud connector is:

logo/<thing-name>/data    →  telemetry JSON
logo/<thing-name>/shadow/update    →  desired/reported state

A sample payload from a temperature-only deployment looks like:

{
  "thing" : "site-munich-01",
  "ts"    : 1714750000,
  "v"     : { "AM1_TempC" : 21.4 }
}

To aggregate 80 sites on a single LWE dashboard, the LWE project must reference the other Things as remote tags. Each remote tag is an HTTP/MQTT binding that the LOGO! uses to fetch the latest value from the AWS shadow of the remote Thing. Because the LWE container runs inside a single LOGO!, the same 16-connection ceiling still applies if the dashboard LOGO! also serves as a collector; the typical workaround is to render the dashboard in the browser (LWE export as HTML5) and have the browser subscribe to AWS IoT directly via the AWS IoT MQTT over WebSockets endpoint (wss://<endpoint>/mqtt).

Recommended LWE dashboard layout for an 80-site rollout

• Group LOGO! Things by region (Munich, Rome, Lyon) in a single LWE page that uses JavaScript to call the AWS IoT Data Plane REST endpoint https://<endpoint>/things/<thingname>/shadow.
• Cache the last value locally in the browser and refresh on a 10-second poll to stay well under the AWS soft limit (default 200 requests/s per account, adjustable).
• Color-code rows whose AM1_TempC deviates more than ±2 °C from the per-site setpoint. The LWE supports conditional formatting through the embedded JavaScript.

4G/LTE Router Sizing and SIM Provisioning

For a cellular uplink, the LOGO! only needs an Ethernet port and a routable address. The router handles SIM, NAT, and firewall. A typical 80-site deployment will see each site publish ~5 KB/minute of telemetry when a single analog value is sampled at 1 Hz and a small shadow delta is included. That is ~7 MB per site per day – well within any M2M data plan.

Commissioning Verification

After deploying a new site, perform the following checks before handing over to operations. They are written as a one-page checklist that fits a tablet in the field cabinet.

1. LOGO! Soft Comfort Online > Test: the analog input (AM1) reads the expected °C value within ±0.5 °C of a reference thermometer.
2. On the LOGO! display or the Web Server, navigate to Cloud status. The state must read Connected and the certificate must show Valid.
3. In the AWS IoT console, open Test > MQTT test client and subscribe to logo/site-munich-01/data. Verify a new JSON message appears at the configured publish interval (default 60 s in the cloud connector block).
4. From the operations workstation, open the LWE dashboard. The new site's row must turn from grey (no data) to green within one publish cycle.
5. Power-cycle the 4G/LTE router. The LOGO! must reconnect to AWS IoT within 120 seconds without operator intervention; if it does not, escalate to check the certificate slot in the cloud connector configuration.

Troubleshooting Matrix

When to Choose SIMATIC S7-1200 over a LOGO! Data Collector

If a single aggregator is expected to talk to more than 16 LOGO!s and perform local logic (recipe handling, alarm management, datalogging to a USB stick or SD card), promote the aggregator from a LOGO! to a SIMATIC S7-1200. The S7-1200 CPU 1214C supports up to 16 S7 connections for PUT/GET in firmware V4.x and far more in the newer V4.4/V4.5 firmware. Pairing the S7-1200 with a CP 1243-8 IRC (6GK7243-8RX30-0XE0) or the integrated PROFINET interface, the controller can additionally push the aggregated dataset to AWS IoT via the S7-1200's HTTP client or via a MindSphere / Insights Hub connector.

The decision rule of thumb:

• ≤16 leaves per hub, no local logic, cloud-first → LOGO! 8.3 direct to AWS IoT.
• ≤64 leaves per hub, some local logic, optional cloud → LOGO! 0BA8 hierarchical collectors.
• >64 leaves per hub, datalogging, recipes → SIMATIC S7-1200/S7-1500 as top tier.
• Greenfield with strict SLA, >100 sites → LOGO! 8.3 + AWS IoT Core with S7-1200 fallback aggregator.

FAQ