Product: Mingcedar CONTROL

Cross-site federation and collection redundancy | Mingcedar

Select IO, Alarm, Trend and Screens separately in Sites.

Published 2026-10-25T12:48:42.630575447Z Updated 2026-10-25T12:48:42.630574586Z

<div class="manual-doc-article manual-doc-article-section"><h2 id="federation-redundancy">User guide: Cross-site federation and collection redundancy</h2>

Cross-site federation exposes remote capabilities. This section explains collection ownership and recovery checks. Released dedicated IO installers do not support remote databases and do not provide a cross-PC primary/standby setup.

<h3 id="federation-redundancy-item-1">Select capabilities per direction</h3>

<p>Select IO, Alarm, Trend and Screens separately in Sites.</p>

<ol>

<li>Configure a local connection and select the capabilities the local site needs. Configure the reverse direction separately when required.</li>

<li>IO scope selects remote devices, Alarm and Trend expose remote results, and Screens opens remote screens.</li>

<li>Scripts, event records and retention remain managed per runtime unit. See Sites and Remote data for the detailed workflow.</li>

</ol>

</article>

<h3 id="federation-redundancy-item-2">The active collector for a PLC</h3>

<p>Within a Runtime Unit, one active IO Owner collects and writes each PLC definition. Independent Sites do not coordinate automatically; avoid duplicate definitions for the same physical PLC.</p>

<ol>

<li>Inspect connection, collection and owner information in device details. Consumers use collected state without opening independent PLC connections.</li>

<li>The runtime requires candidates in one runtime unit with matching applied configuration, drivers, credentials, connectivity, license and capacity. These requirements alone do not establish an installer-supported cross-PC standby deployment.</li>

<li>Federation alone, or matching device names, does not create collection takeover between independent database domains.</li>

</ol>

</article>

<h3 id="federation-redundancy-item-3">Observe failure and recovery</h3>

<p>After recovery, check the actual collector and new values; do not assume another PC has automatically taken over.</p>

<ol>

<li>Inspect owner, device connectivity and Tag quality to distinguish service failure, network loss and temporarily invalid values.</li>

<li>After collection recovers, wait for valid new values, then check alarms and trends. Unavailable periods retain quality states and historical gaps.</li>

<li>Reconcile unconfirmed writes through request records and subsequent collection before deciding what to do next. Restored connectivity does not prove a previous command executed.</li>

</ol>

</article>

<h3 id="federation-owner-preparation">Dedicated IO deployment limits</h3>

<p>Windows/Linux dedicated-node provides IO only. Prepare PostgreSQL/Redis managed outside the installer, a schema, and local loopback addresses. Cross-machine data services are unsupported.</p>

<ol>

<li>For multiple PCs, install independent sites and connect their capabilities. Do not point a dedicated-node installation at another PC’s database.</li>

<li>Before installing dedicated IO, verify the role, same-machine data services, prepared schema, protected resource policy, drivers, network access and licensing.</li>

<li>Cross-PC automatic takeover requires a deployment plan verified for the delivered version.</li>

</ol>

</article>

</div>