Italian bakery — fleet of fermentation chambers

A mid-size Italian industrial bakery wants to monitor its 3 fermentation chambers under a single VPN tunnel. All 3 PLCs are Carel pCO5+ with pCOWeb cards (the dominant combination on Italian-made proofing chambers). Goal: per-chamber Asset Health Index, WhatsApp alerts when temperature/humidity drift out of range, and an automatic work order to the on-shift technician.

Executive summary

The game changer: a single WireGuard .conf covers all 3 chambers. Each PLC stays an independent asset in Rela with its own AHI, its own maintenance window and its own owner — but the customer configures the network once.

What is it for?

• Watch 3 distinct fermentation chambers (lines A, B, C) without overloading the operator.
• Capture the full cycle of each chamber: setpoint vs. measured value for temperature, humidity, active phase, door open.
• Tie every reading to the correct asset (chamber A, B, C) so AHI and Remaining Useful Life are per-equipment, not aggregated.
• Trigger different alerts and work orders depending on which chamber failed, with no rule duplication.

Before you start — why you configure the peer yourself

Your IT team may suggest "we'll give you credentials for our corporate VPN, connect with that". The answer is firm: no.

Three critical reasons (the full 9 are in Why a dedicated tunnel):

1. Least privilege: your corporate VPN opens the entire network (ERP, mail, SharePoint, OT). Rela only needs the PLC subnet. A breach on the Rela side hits one OT subnet, not the whole company.
2. Seconds to revoke: you delete the peer in your router whenever you want, no ticket nor coordination with us. The private key lives on your hardware and never leaves it.
3. Compliance (IEC 62443, NIST SP 800-82, SOC 2, ISO 27001): all require IT/OT separation via dedicated tunnel. Sharing corporate VPN credentials is a direct findable in any audit.

Sharing credentials falls outside the self-service model and escalates to enterprise custom deployment (different pricing, dedicated IPsec site-to-site tunnel).

How it works

flowchart LR
  PLC_A["Carel pCO5 plus<br/>Chamber Line A<br/>192.168.10.50"] --> R[("Customer router<br/>WireGuard + DNAT")]
  PLC_B["Carel pCO5 plus<br/>Chamber Line B<br/>192.168.10.51"] --> R
  PLC_C["Carel pCO5 plus<br/>Chamber Line C<br/>192.168.10.52"] --> R
  R -- "WireGuard tunnel" --> CONC[("Rela VPN<br/>concentrator")]
  CONC --> WORKER[("Cloud Run worker<br/>3 modbus_listener tasks")]
  WORKER --> PIPE[("Predictive pipeline<br/>anomaly + health + RUL")]
  PIPE --> AST_A[Asset Line A]
  PIPE --> AST_B[Asset Line B]
  PIPE --> AST_C[Asset Line C]

The flow in one sentence: each PLC speaks Modbus TCP on its LAN; the customer's router rewrites VPN addresses to LAN addresses; the Rela worker polls registers as if all 3 chambers were on its own network; the pipeline attributes each event to the correct asset.

Parameters / Configuration

Typical Carel pCO5+ Modbus mapping (standard fermentation firmware; OEMs may vary the addresses — always confirm with the manufacturer manual):

Network addresses (realistic example):

How to use it

Step 1 — Create the VPN tunnel (once)

1. Sidebar -> Settings -> Connectivity.
2. Enter label: Bakery - Production.
3. Click Create peer. The backend allocates 10.200.7.0/24 and a client tunnel address 10.200.7.2.
4. Download the WireGuard .conf. Import it into the customer's router (Mikrotik, pfSense, OPNsense — any router with native WireGuard support).

Step 2 — DNAT all 3 chambers on the router

The customer adds 3 NAT rules on the router (Mikrotik syntax):

/ip firewall nat
add chain=dstnat dst-address=10.200.7.50 dst-port=502 \
    protocol=tcp action=dst-nat to-addresses=192.168.10.50 to-ports=502
add chain=dstnat dst-address=10.200.7.51 dst-port=502 \
    protocol=tcp action=dst-nat to-addresses=192.168.10.51 to-ports=502
add chain=dstnat dst-address=10.200.7.52 dst-port=502 \
    protocol=tcp action=dst-nat to-addresses=192.168.10.52 to-ports=502

/ip firewall filter
add action=accept chain=forward in-interface=rela-vpn src-address=10.200.0.0/16

Why it matters: the Rela worker "sees" the chambers as 10.200.7.50/.51/.52. The router translates those addresses to the real LAN IP. Skip this step and all 3 chambers stay unreachable even with a healthy tunnel.

Step 3 — Create the 3 assets in Rela

Sidebar -> Assets -> + New. Repeat 3 times:

Step 4 — Create the machine agent

Sidebar -> Alarms -> Machine agents -> + New.

Name:                     Proofing Watcher
Model:                    gemini-3.1-pro-preview
Auto-assign task:         yes -> Department "Production"
Auto-notify WhatsApp:     yes -> Plant manager number
Escalation:               yes
  Step 1: 5 min  -> On-shift operator
  Step 2: 15 min -> Plant manager
  Step 3: 30 min -> Production manager
RCA enabled:              yes -> Min severity: critical

A single agent covers all 3 chambers; rules can later filter by source_id if you want different routing per chamber.

Step 5 — Create the 3 Modbus sources

Sidebar -> Alarms -> Sources -> + New source. Repeat 3 times, one per chamber:

Source ID:                proofing-line-a    (...-b, ...-c)
Agent:                    Proofing Watcher
Protocol:                 Modbus TCP
Modbus host:              10.200.7.50        (.51 for B, .52 for C)
Modbus port:              502
Unit ID:                  1
Connect timeout:          5 s

Registers:
  - measured_temperature  addr=2  type=float32  fc=3   unit="°C"
                          emit=data_change deadband=0.5
  - measured_humidity     addr=4  type=float32  fc=3   unit="%"
                          emit=data_change deadband=2.0
  - cycle_phase           addr=10 type=uint16   fc=3
                          emit=data_change deadband=0
  - door_open             addr=1  type=bool     fc=2
                          emit=bit_flip
  - probe_t_alarm         addr=20 type=bool     fc=2
                          emit=bit_flip

Min interval:             10 s
Min severity:             warning

Step 6 — Link each source to its asset

Sidebar -> Assets -> click Proofing Chamber Line A -> Edit -> field event_source_ids: add proofing-line-a. Save. Repeat for B and C.

Why it matters: without this link, events come from the PLC but the AHI, RUL and KPIs cannot tie them to a chamber. With the link the entire predictive pipeline runs per individual chamber.

Step 7 — Verify all 3 connections are live

Back to Alarms -> Sources. The 3 rows should show a blinking green dot. Within 60 seconds events should start appearing in Alarms -> Live with event_type=DATA_CHANGE and the decoded registers (temperature, humidity, phase).

If a chamber stays red, see Troubleshooting.

Real use cases

Door left open at end of shift

Operator forgets the door of Chamber B open at the end of the night shift. Within 30 seconds:

1. Carel pCO5+ flips coil 1 to 1.
2. Worker receives bit_flip -> MachineEventRequest{event_type: "DATA_CHANGE", metadata: {door_open: true}}.
3. Pipeline processes; Proofing Watcher generates task "Close chamber B door" assigned to on-shift operator.
4. WhatsApp arrives in under 1 minute.
5. If not closed within 5 minutes, escalates to plant manager.

Humidity probe drift

Chamber A reports humidity 80% while the setpoint was 78%. The ML anomaly detector (IsolationForest + LOF) learns the normal pattern in 7 days. When the probe starts drifting +5% consistently, before the dough is affected, AHI drops from A to B and RUL recommends recalibration within 2 weeks. PM task auto-generated.

Partial electrical fault

Power cut on Line C kills the fan. Probe alarm coil does not fire (probe still works), but temperature climbs 0.3 °C/min. Deterministic rules detect measured_temperature > setpoint + 3°C for 3 consecutive samples (recurrence config) and trigger severity critical. Direct escalation to plant manager.

Limitations and assumptions

• Modbus addresses depend on the OEM firmware. The table mapping is the standard Carel pattern, but every chamber manufacturer (Climaset, Forni Fiorini and other typical Italian OEMs) personalizes the firmware. Always request the manual from the integrator before configuring the registers.
• The 3 chambers must share the same customer LAN. If they live in separate sites, you need 3 different VPN tunnels (one peer per site). The "1 tunnel = 1 physical site" model holds.
• Modbus TCP is plaintext. Modbus has no native credentials — security comes from the WireGuard tunnel. The router firewall must accept traffic only from 10.200.0.0/16 toward the PLCs, never from the open internet.
• The listener runs on a single worker. A worker restart (deploy or crash) restarts all 3 listeners together with exponential backoff. The circuit breaker opens for 5 minutes on sustained failure. Typical data loss on a restart: 30 to 60 seconds.

Troubleshooting

Key benefits

• Single VPN setup: 1 customer, 1 router, 1 .conf — regardless of how many chambers exist.
• Per-asset traceability: AHI, RUL, KPIs and tasks are computed per individual chamber.
• Predictive maintenance from day 7: the model learns normal patterns in a week and starts detecting drift.
• Differentiated escalation: a critical chamber (Line A, sourdough) can have a more aggressive escalation than a backup chamber.
• Zero extra hardware: no gateway, sensor or datalogger sold or installed. Reuses existing PLC and network.

See also

• Heterogeneous fleet — 3 PLC brands under one VPN tunnel — when chambers come from different brands.
• Why a dedicated tunnel — the 9 reasons we never share the customer's corporate VPN.