How to Document an Industrial Edge Gateway Architecture for IT and OT Teams

Document an industrial edge gateway architecture as a set of interfaces, owners and dependencies that both IT and OT teams can review. For a Robustel EG5120 project, show where each value originates, what the gateway does with it, where it goes and who maintains that handoff. Pair the drawing with a concise interface register and acceptance evidence. A diagram is useful only when another engineer can turn its arrows into specific configuration and verification work.

Illustrative industrial environment; final implementation is project specific.

Key Takeaways

• Give every architecture arrow a direction, purpose and accountable owner.
• Document measurement meaning alongside network and application details.
• Separate design requirements from documented capability and completed test evidence.
• Keep interface dependencies current when devices, software or consumers change.

In This Guide

• What must the drawing explain?
• What belongs in the register?
• How should review work?
• How does it stay current?

What must the architecture drawing explain?

Start with the operational question the system answers. A drawing for energy reporting should make the source measurements and consuming reports clear. A drawing for maintenance access should make the authorized target and access owner clear. Combining several purposes without labels makes review harder.

Draw the field assets, the gateway application and each receiving system. Label every arrow with what crosses the boundary and in which direction. A cable line and a measurement flow are different statements, so distinguish them in the drawing legend.

The E2C Factory overview describes collection, edge processing and northbound integration. Use that functional distinction when documenting a Factory deployment. Confirm the selected EG5120 build against the application compatibility information, rather than labeling an unconfigured hardware box with every possible software function.

Include required supporting services as dependencies. For example, if an approved design uses a named broker, show it with an owner. If clock configuration, name resolution or another service is essential to the chosen application, record that requirement and how it will be verified.

Use a bounded system view. Show the interfaces the team controls and label externally owned systems. Avoid implying that a line on the drawing establishes network permission or a service agreement.

What belongs in the interface register?

Give each arrow a stable interface ID and a row in a register. This lets reviewers discuss a particular handoff without relying on its position in the drawing.

Keep specification, implementation and evidence separate. “The consumer needs fresh pressure data” is a requirement. The chosen application settings are an implementation. A captured observation comparison is evidence. One column should not silently substitute for the others.

Add the publication or transformation rule where it affects meaning. If a value is filtered, scaled or aggregated, identify the responsible configuration and who approved the interpretation. IT can then build the consumer without guessing what happened between the field device and the endpoint.

How should IT and OT review the document?

Ask OT to confirm the source asset, measurement meaning and permitted interaction with equipment. Ask IT to confirm the receiving interface, identity ownership and required service dependencies. The gateway integrator should explain how the proposed configuration satisfies both sides.

Then review one representative observation together. Trace its identity and value from the physical source through the gateway and into the consumer. Note each conversion or naming change. This small walkthrough often reveals missing assumptions more effectively than reviewing a long device list.

Record gateway management and maintenance access as separate interfaces where they are used. RCMS supports device operations, while the RobustVPN guide describes a remote-access arrangement. Document the services actually selected, including their scope and owners.

Illustrative joint architecture review at an industrial site.

Do not use “secure connection” as a complete interface specification. Identify the required authentication, approved access scope and applicable configuration evidence. Where the implementation is undecided, mark it as an open design item rather than drawing a finished approval boundary.

Use a question-led review:

1. Can the OT owner identify the physical source for every critical value?
2. Can the IT owner explain the received value without an undocumented conversion?
3. Can operations identify who restores each external dependency?
4. Can the integrator point to a configuration and test for every required handoff?

These are proposed review questions, not certifications or guarantees. The purpose is to make the design understandable enough to test and maintain.

How does the architecture record stay current?

Attach a revision to the drawing and interface register together. A revised diagram with an outdated endpoint table can be more misleading than a clearly labeled draft.

Define change triggers. A new field-device model may affect the point definition. A gateway application update may require compatibility review. A new consumer may require a new identity, different data meaning or a different acceptance case. Record which interfaces each change touches.

Keep a short decision log for significant choices. State the decision, its reason, the owner and the evidence available at the time. This prevents a future maintainer from treating an intentional constraint as an accidental omission.

Before handover, distinguish the intended design from the installed configuration. Verify the actual versions, named destinations and owners, then attach the accepted test results. Where a temporary arrangement remains, label its scope and the work required to reach the intended state.

Make the final package navigable: one system drawing, one interface register, one dependency list and the necessary linked evidence. The document should let an engineer find the owner and test for a failing handoff quickly without reading an entire procurement history.

Frequently asked questions about IT and OT architecture documents

Is a network topology diagram sufficient?

It explains physical or logical connectivity, but may omit data meaning, application behavior and responsibility. Add an interface register that connects those decisions to acceptance evidence.

Should every tag appear on the main diagram?

Usually a representative data category is clearer. Link the detailed point list from the relevant interface record so the drawing remains readable and the exact specification remains available.

How should an unconfirmed capability be shown?

Mark it as a requirement or open item with an owner. Do not label it as implemented until the selected product and software have appropriate evidence and validation.

Who owns the finished document?

Name one coordinating owner, with IT, OT and integration owners responsible for their interfaces. Shared review does not remove the need for a person who controls revisions.

What should you do next?

Take one intended EG5120 deployment and create its interface register before expanding the drawing. Use the applicable Robustel Support documentation to verify product and application responsibilities, then review one source-to-consumer observation jointly with IT and OT.

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.