How to Create a Repeatable Edge Gateway Site Template

Create a repeatable edge gateway site template by separating the shared baseline from values that must be confirmed at every installation. For a Robustel EG5120 rollout, the template should identify software, field-device mappings, network identities, destination settings and acceptance evidence. Include an exception register so a site can differ for a documented reason. The result is a completed site record that another engineer can verify, rather than an unexplained copy of whichever gateway happened to work first.

Illustrative industrial environment; final implementation is project specific.

Key Takeaways

• Separate reusable design decisions from site-specific identities and configuration values.
• Record software, hardware and license compatibility before applying a baseline.
• Treat configuration import as one step within a verified site deployment.
• Keep exceptions visible and feed accepted changes back into the template deliberately.

In This Guide

• What should be shared?
• What fields does the template need?
• How is a baseline applied?
• How are exceptions maintained?

What should be shared and what must change?

A shared baseline describes the intended system behavior. It might define naming rules, which data categories are collected, how a consumer interprets them and what evidence is required at handover. A site record supplies the actual identities and values needed to implement that behavior.

Do not mix these into one opaque configuration file. Keep a readable design record alongside the configuration artifacts so reviewers can understand what should remain constant and what should change.

For EG5120 projects using Factory, record the application build and the requirements in the official download listing. Include the selected market and edition using the version comparison. Those references define prerequisites to check, not a promise that every copied workload will operate identically.

A shared naming pattern does not mean shared device identity. Each gateway, field asset and publishing endpoint must remain distinguishable in the completed record. Likewise, a reusable credential procedure should reference how a site's credential is obtained, not distribute a common secret in the template.

Design the baseline from a representative accepted configuration. A temporary laboratory address, demonstration topic or test source should be easy to spot before the template reaches the field.

What fields should the site template contain?

Use a short, structured record with a required owner for each section. The following example is a project worksheet, not an import file or a Robustel configuration syntax.

Add a field for “not applicable” with a reason. An empty cell should mean incomplete, not silently optional. This distinction prevents an installer from guessing whether a missing serial setting reflects an Ethernet device or an unfinished review.

Give the template a revision and identify its owner. Record which site first validated the baseline and what evidence supported it. The record should remain understandable even if the original commissioning engineer is unavailable.

How should the baseline be applied to a new site?

Start by confirming the target unit and reviewing its completed site variables. Compare the proposed hardware resources, software versions and required entitlements with the accepted baseline before copying configuration.

The Factory manual's migration chapter describes export/import compatibility and warns that unsupported items may be skipped. It also directs users not to manually alter the exported file. Treat the readable site worksheet and the manufacturer's configuration artifact as different objects.

Use the supported configuration method for the target system. After applying the baseline, inspect the import or configuration result and compare the running setup with the site record. If a required item was skipped, document it and configure it through the supported workflow before acceptance.

Illustrative preparation of repeatable site configurations.

Test the site-specific values deliberately. Confirm that a received observation belongs to this site and this physical asset. Check that the operational team sees the intended gateway identity and that the completed record points to the correct local contact.

Where RCMS is part of the deployment, assign the appropriate device-management ownership as a site variable. A shared rollout process should not accidentally place a customer's gateway in an unintended operational group or leave it owned by a temporary commissioning account.

Use one representative observation for each important data path. The goal is to prove that reused settings and local variables work together. A configuration file checksum alone cannot demonstrate that the correct meter, machine or destination was selected.

How should site exceptions be maintained?

Classify an exception by its impact. An approved alternate upstream endpoint may preserve the data contract, while a changed device register map may alter measurement meaning. They should not receive the same review merely because both appear as one edited field.

A useful exception record contains the baseline requirement, the site condition, the proposed variation, affected tests and approving owner. Give the exception an expiry or review trigger where appropriate.

For example, a site may temporarily use a test destination while the production application is prepared. Record the temporary endpoint, what evidence remains valid and what must be repeated at cutover. Do not mark the permanent integration accepted on the strength of a temporary subscriber.

Review recurring exceptions periodically. When several sites require the same valid variation, decide whether it belongs in a revised baseline or a named configuration family. Do not silently edit the master template after each deployment; retain an intelligible revision history.

Finish each site with an as-built record. It should show the baseline revision, actual configuration references, accepted exceptions and handover evidence. This makes later replacement or troubleshooting practical without forcing the maintainer to reconstruct commissioning decisions from memory.

Frequently asked questions about gateway site templates

Is a site template the same as a configuration backup?

No. The template describes required decisions and evidence. A backup is one artifact referenced by that record and may cover only part of the installation.

Can I reuse a template across different gateway models?

Reuse the planning structure where useful, but review each model's hardware, software and application compatibility. Do not assume an exported configuration can transfer unchanged.

Should site passwords be written into the template?

Record a protected credential reference, custodian and retrieval procedure. Follow the organization's credential policy and avoid exposing secret values in the general site worksheet.

When should an exception become a baseline change?

When the responsible owner determines it is broadly applicable and the affected behavior has been validated. Revise the template visibly and identify which sites need re-review.

What should you do next?

Complete one site record for an EG5120 deployment, then ask a second engineer to apply it to a suitable test installation. Use the Factory migration documentation for supported configuration reuse and close every unexplained difference before expanding the rollout.

About the Author

Mark, Technical Support Engineer at Robustel

Mark is a Technical Support Engineer at Robustel with hands-on experience in industrial networking and edge connectivity. He helps customers plan, deploy, configure, and troubleshoot industrial IoT solutions, including cellular routers, edge gateways, and LoRaWAN systems. His work spans technical support, product training, configuration review, and practical deployment guidance for reliable and repeatable field operations across global projects and long-term operational support.