# ConverEDGE: machine connectivity across your shop floor

Explore PLC data collection, industrial interoperability and edge computing choices for useful machine connectivity across a mixed shop floor.

Canonical: https://vieox.com/insights/converedge-direct-device-communication/
Publisher: VIEOX
Published: 2026-10-22
Updated: 2026-10-25

## Can ConverEDGE communicate directly with the different devices already on our shop floor?

Yes. ConverEDGE can communicate directly with virtually any device on the shop floor. For a particular connection, confirm the device interface, access arrangements, firmware and available data. That broad communication capability provides a starting point for useful operational information; the equipment identity, timing and process context still need to be understood.

A shop floor rarely comes from one supplier or one generation of equipment. ConverEDGE can communicate directly with virtually any device on that floor, opening access to operational data across a mixed estate. Machine connectivity becomes useful when that data retains its meaning for production, quality, engineering and the people building industrial analytics.

## Start with the equipment you already operate

Production teams work with equipment acquired at different times, from different suppliers, for different tasks. A newer machine may sit beside an older installation that still performs an essential operation. Each can hold information relevant to output, interruptions or the condition of the process. Supplier boundaries should not define the question the team is allowed to investigate.

ConverEDGE's direct device communication capability brings that mixed estate into the discussion. Begin with the operating question and the devices that could help answer it. Include legacy equipment in the assessment instead of ruling it out because of age. Equally, a recent purchase does not establish which information its installed configuration makes accessible.

For an Industry 4.0 initiative, start with the production task and its existing operational technology (OT). Industrial IoT can extend the available observations where additional connected sensing is useful. The information plan should show how those sources serve the same operating question, with clear ownership for their installation and use.


## Confirm the actual connection and available data

Virtually any device describes broad communication capability; it does not mean every device exposes every measurement. Check the exact model, installed firmware, enabled interfaces and documentation. Establish who can authorise access and whether the required information is available through that interface. An accessible production count does not establish access to a detailed alarm history or an internal process measurement.

For older or restricted equipment, identify the specific constraint: an unavailable interface, missing documentation, access restrictions or a measurement the device does not produce. Agree any additional work before including that information in the scope. A physical connection alone cannot supply a value that the equipment neither measures nor exposes. Record confirmed access and unresolved questions separately.


## How to collect data from PLCs

Begin with the programmable logic controller (PLC) model, firmware and the machine owner’s approved interface. Identify the required tags, their types, units and meanings, then agree a read-only collection scope for the review. Confirm permissions, credentials and any certificate requirements with the responsible controls and security teams before enabling access.

Siemens’ OPC UA guidance for its S7 controllers describes client and user identity checks, protected exchange and restricting exposed tags to those needed. Its S7-1500 access guidance distinguishes occasional reads from recurring access and warns that communication settings must preserve application behaviour. These are device-specific references: use the installed controller’s documentation rather than assuming one configuration applies to every PLC.

During an agreed pilot, compare the collected record with the machine’s own indications. Check event timing, unavailable values and restart behaviour, and assess the collection load with the controls owner. Preserve the tag-to-asset mapping for later users. A successful read establishes access to a value; its meaning and suitability for a dashboard or AI input still need verification.


Sources: [3](https://docs.tia.siemens.cloud/r/en-us/v20/configuring-automation-systems/using-opc-ua-communication-s7-1200-s7-1500-s7-1500t/security-at-opc-ua-s7-1200-s7-1500-s7-1500t/security-settings-s7-1200-s7-1500-s7-1500t), [4](https://docs.tia.siemens.cloud/r/en-us/v20/configuring-automation-systems/using-opc-ua-communication-s7-1200-s7-1500-s7-1500t/using-the-s7-1500-as-an-opc-ua-server-s7-1500-s7-1500t/accessing-opc-ua-server-data-s7-1500-s7-1500t)

## Industrial interoperability needs shared meaning

Direct acquisition brings data from the device into view. Usable context explains which asset it belongs to, what its values represent, their units and time reference, and the operating conditions around them. A state marked stopped may represent planned waiting, a changeover or an interruption. A rising count may record completed cycles rather than accepted products.

W3C's Web of Things architecture describes metadata for interpreting device capabilities and adapting to different implementations. OPC Foundation's object model represents objects and their relationships as well as variables.

These standards illustrate the importance of meaning; they are not a ConverEDGE compatibility list. For your review, agree equipment names, state definitions and relevant job or shift information with the people who use them. Preserve uncertainty where a record cannot distinguish two conditions. A clearer description is more useful than a confident but unsupported classification.


Sources: [1](https://www.w3.org/TR/2023/REC-wot-architecture11-20231205/), [2](https://reference.opcfoundation.org/specs/OPC-10000-3/4.3)

## Where industrial edge computing fits

Edge computing places selected data processing close to the equipment producing it. NIST’s fog-computing model describes distributed resources between connected devices and central services, with attention to latency and local context. It provides an architectural reference for deciding which work belongs near the machine and which belongs in a plant or central system.

When evaluating industrial edge computing solutions, define the local task first: acquiring records, preparing a useful extract or running an agreed analysis. Check processing and storage capacity, network availability, support ownership and update arrangements. If buffering is proposed, test what happens during an interruption and how later delivery preserves the original observation time.

Placement follows the operating need. Agree what must remain available locally, what may leave the site and how missing information will be shown. Confirm the proposed ConverEDGE deployment against these requirements during assessment; the edge label alone does not establish offline behaviour, response time or authority to control equipment.


Sources: [5](https://csrc.nist.gov/pubs/sp/500/325/final)

## An illustrative review of a mixed production cell

Hypothetical example: consider a cell containing an older processing machine, a newer packaging station and a separate energy meter. The team wants to understand why output falls during some production periods. It first confirms which counts, operating states and readings each device exposes, together with the access needed to acquire them. This is a planning example, not a reported customer deployment.

The review then pairs those records with the product being made and the operator's account of the period. A packaging pause could coincide with an upstream interruption, but coincidence alone does not establish the cause. Comparing the time references, checking count definitions and asking what happened on the floor makes the evidence more useful. The outcome sought is a better investigation, with fewer gaps between equipment records and the team's experience.


## Pilot a representative mix of devices

Choose a small group that includes the differences likely to matter later: suppliers, equipment ages, interfaces and operating roles. Avoid selecting only the easiest device if the wider question depends on another one. Bring production, maintenance and the people responsible for access into the discussion, with the supplier involved where documentation or configuration needs clarification.

Compare acquired values with the equipment's own indications during agreed observations. Check how the record represents an unavailable value, a restart or a change in operating state. Define success in practical terms: can the responsible team interpret the record and use it to answer the selected question? Document remaining gaps before deciding how far to extend the connection scope.


## Connect broader access to business value

The business opportunity is a more complete basis for everyday decisions. Direct access across devices can reduce reliance on separate manual collections, make cross-equipment reviews easier and help teams see where information is missing. The value depends on the question, the quality of the available record and how people use it; connectivity alone does not establish a productivity or cost saving.

Start a ConverEDGE conversation with a device inventory and one recurring operating question. Use the pilot to establish what is available, what needs clarification and what deserves further development. Where the requirement is unusual, an R&D-capable partner can help investigate the uncertainty and define a practical next step.


## Practical starting points

- Name the operating question and the person who will use the result.
- List device models, firmware, interfaces and available documentation.
- Confirm access ownership and any configuration constraints.
- Identify the values required and those actually exposed.
- Agree equipment identity, units, timing and operating definitions.
- Agree collection load, processing location and behaviour during communication gaps.
- Choose representative devices and observations for the pilot.
- Record unresolved gaps and evidence needed before expansion.

## Questions, answered

### Does older equipment have to be replaced first?

Age alone is not the deciding factor. Assess the installed device's interface, accessible information and documentation. Some requirements may need additional work where an interface or measurement is unavailable; establish that scope before assuming replacement or promising a complete record.

### Does direct communication mean automatic machine control?

This capability statement concerns device communication and data acquisition. It does not establish write access, command execution or authority to change machine operation. Any proposed control requirement needs a separate, explicit assessment.

### What should we bring to an initial discussion?

Bring a representative device list, available interface documentation and one question your team repeatedly struggles to answer. Include known access restrictions and examples of the information currently used. That gives the discussion a concrete starting point without requiring a finished integration specification.

## Sources and further reading

- [W3C — Web of Things Architecture 1.1, section 6.1: Fundamental Concepts](https://www.w3.org/TR/2023/REC-wot-architecture11-20231205/)
- [OPC Foundation — OPC UA Part 3: Address Space Model, section 4.3: Object Model](https://reference.opcfoundation.org/specs/OPC-10000-3/4.3)
- [Siemens — STEP 7 V20: OPC UA security settings for S7-1200 and S7-1500 controllers](https://docs.tia.siemens.cloud/r/en-us/v20/configuring-automation-systems/using-opc-ua-communication-s7-1200-s7-1500-s7-1500t/security-at-opc-ua-s7-1200-s7-1500-s7-1500t/security-settings-s7-1200-s7-1500-s7-1500t)
- [Siemens — STEP 7 V20: Accessing OPC UA server data on S7-1500 controllers](https://docs.tia.siemens.cloud/r/en-us/v20/configuring-automation-systems/using-opc-ua-communication-s7-1200-s7-1500-s7-1500t/using-the-s7-1500-as-an-opc-ua-server-s7-1500-s7-1500t/accessing-opc-ua-server-data-s7-1500-s7-1500t)
- [NIST SP 500-325 — Fog Computing Conceptual Model](https://csrc.nist.gov/pubs/sp/500/325/final)

## Related reading

- [Why operational data needs context](https://vieox.com/insights/operational-data-context/)
- [Investigating production downtime](https://vieox.com/insights/investigating-production-downtime/)
- [The benefits of an R&D-capable partner](https://vieox.com/insights/benefits-of-an-r-and-d-capable-partner/)
- [Explore ConverEDGE](https://vieox.com/converedge/)
- [Discuss your device estate](https://vieox.com/contact/)
