Skip to content
Proxus 2.0.0 Proxus 2.0: the largest release in Proxus history Release notes
Try free Book a demo

Integrations · AWS

Industrial data into AWS, without a bespoke pipeline.

Connect the equipment once, name the tags once, and deliver to AWS IoT Core as a configured target, instead of maintaining an export script nobody owns.

Book a demo All integrations Setup guide
Equipment to AWS Amazon Web Services
Model once, deliver to your systems Equipment sends data through an edge gateway to Unified Namespace, then to AWS. Controllers S7 / CIP / MELSEC Machines & robots FOCAS / MTConnect Meters & SCADA Modbus / OPC UA Modelled signals 02 / EDGE Proxus Edge Collect / evaluate / buffer 03 / PLATFORM Unified Namespace Modelled industrial signals AWS Destination 01 / PLANT FLOOR04 / CONSUMERS Model once, deliver to your systems Read from bottom to top. Field equipment is at the bottom and data travels upward. Equipment sends data through an edge gateway to Unified Namespace, then to AWS. 01 Plant floor PLCs / CNCs / robots 02 Proxus Edge Collect / evaluate /buffer 03 Unified Namespace Modelled industrialsignals 04 AWS Destination
Direction
Outbound from the plant to AWS IoT Core
Delivered
Each reading as JSON: device name and ID, tag name, value, data type and the time it was read
Reliability
Local buffering with replay on reconnect
Control
You choose which devices send to AWS; a pipeline can send single tags

Data path

What actually moves, and where it stops.

Initiated from inside the plant, buffered when the link drops

Model once, deliver to your systems Equipment sends data through an edge gateway to Unified Namespace, then to AWS. Controllers S7 / CIP / MELSEC Machines & robots FOCAS / MTConnect Meters & SCADA Modbus / OPC UA Modelled signals 02 / EDGE Proxus Edge Collect / evaluate / buffer 03 / PLATFORM Unified Namespace Modelled industrial signals AWS Destination 01 / PLANT FLOOR04 / CONSUMERS Model once, deliver to your systems Read from bottom to top. Field equipment is at the bottom and data travels upward. Equipment sends data through an edge gateway to Unified Namespace, then to AWS. 01 Plant floor PLCs / CNCs / robots 02 Proxus Edge Collect / evaluate /buffer 03 Unified Namespace Modelled industrialsignals 04 AWS Destination

Field

  • PLCs, CNCs, robots
  • OPC UA servers
  • Meters and SCADA

Proxus

  • Collect at the line
  • Model into the namespace
  • Buffer and forward

AWS

Amazon Web Services
  • MQTT topic
  • IoT rules
  • downstream services

How it works

From the machine to AWS, in four steps.

  1. 01

    Connect the assets

    Native drivers collect from controllers, machines and OPC UA servers on site.

  2. 02

    Give signals names

    Tags get names and scaling at the point of collection, so AWS receives names rather than register addresses.

  3. 03

    Publish to AWS

    An outbound target publishes the readings of the devices attached to it to an AWS IoT Core topic over MQTT, port 8883.

  4. 04

    Keep the plant copy

    The same data stays in the historian on the hub you host, so line-side use does not depend on the cloud link.

What you get

Why teams route AWS through Proxus.

  • Plant stays in control

    You choose which devices send to AWS, and can change that without touching collection.

  • Renewed certificates, no edits

    The gateway reads the thing’s certificate from the Certificate Store at every send, so a renewed or replaced certificate is used without changing the target.

  • Your topic, your IoT rules

    Readings are published to the topic you set (proxus_device_data by default), so AWS IoT rules route them onward from one place.

  • Checked from the sending gateway

    Test Connection connects with the thing’s certificate from the gateway you choose, so a wrong endpoint or certificate shows before any data is sent.

Where it is used

Typical deployments.

  • Multi-site data lake ingestion

    A consistent stream from every plant, with names attached before it arrives.

  • Cloud analytics and dashboards

    Feed cloud-native tooling while operations keeps its own live views.

  • Remote monitoring of distributed assets

    Field sites report to a central AWS account without opening inbound access.

Targets
AWS IoT Core over MQTT on port 8883; REST endpoints and brokers reachable from the plant are also supported
Payload
One JSON message per reading: deviceId, deviceName, measureName, timestamp, measureValueType and the value
Strategies
Pass Through, On Change, or Pipelines Only (only what a pipeline sends)
Security
The thing’s X.509 device certificate from the Proxus Certificate Store; the endpoint is verified against Amazon Root CA 1
You configure
EndPoint, ClientId, CertificateThumbprint, Topic. Test Connection checks the address and credentials from the hub or from a gateway you choose, without writing data.
Setup guide All target parameters

Proven in production

Running in production at these plants.

All deployments

Questions

Before you wire it up.

Which AWS service does Proxus deliver to?
AWS IoT Core is the direct target. From there, data can move into whatever storage and analytics services your account uses.
Can several plants publish into one AWS account?
Yes, and they publish the same modelled structure, which is what keeps cloud-side processing written once rather than per site.
How is authentication handled?
With the thing’s X.509 device certificate from the Proxus Certificate Store; the endpoint is verified against Amazon Root CA 1. A renewed certificate is picked up without editing the target.
Is there a way to limit volume?
On-change delivery and filtering at the source both reduce what is published, without reducing what you keep in your own historian.

Other integrations

Next step

See it delivering into your own AWS.

Bring one machine and an AWS IoT Core thing with its certificate. We connect the machine, publish to your topic in front of you, and show what the gateway does while the link is down.

Book a demo Talk to an engineer
  1. 01

    Scoping call

    Equipment, protocols, sites and the systems the data has to reach.

  2. 02

    Technical walkthrough

    A working demo against a scenario that resembles your plant, not a generic tour.

  3. 03

    Pilot plan

    A defined first line or site, with the deployment and security questions answered up front.

  4. 04

    Roll-out

    The same templates bring the next lines and sites online.