Connect OPC UA to AWS IoT SiteWise
| Product | AWS IoT SiteWise |
|---|---|
| Category | Cloud |
| OPC UA role | Client |
SiteWise ingests OPC UA data through a gateway component that runs on-premises, subscribes to your servers and forwards to AWS. Its distinguishing feature is an asset model layer in the cloud, which is where you re-attach the machine semantics the transport does not carry.
Before you start
- A gateway host on the plant network that can reach the OPC UA servers and AWS.
- An OPC UA data source configuration per server, including the security policy and any credentials.
- A certificate trust plan on each server, as with any OPC UA client.
- An asset model design. This is the real work, and doing it after ingestion starts is more expensive than doing it first.
Setting it up
- Install the gateway on-premisesIt runs as a local component and holds the OPC UA client. Give its certificate store a persistent location.
- Add each server as a data sourceEndpoint URL, security policy and mode, and credentials. Start with security None to prove reachability, then move to SignAndEncrypt and deal with the trust exchange separately.
- Trust the gateway certificate on each serverMove it from the server's rejected store to trusted. Same workflow as every other OPC UA client, same time cost across a fleet.
- Choose your property filtersIngest the nodes you need rather than everything the server exposes. Ingestion is metered and an unfiltered browse-and-collect gets expensive quickly.
- Model the assetsDefine asset models and properties in the cloud and map incoming streams onto them. This is where a machine becomes a machine rather than a list of tags, and where you define transforms and metrics.
- Define metrics rather than computing downstreamAvailability and counts can be expressed as SiteWise transforms and metrics over ingested properties, which is cheaper and more consistent than recomputing them in every dashboard.
What the address space looks like
Flat property streams inbound, re-modelled into an asset hierarchy in the cloud. If your machine implements Machinery or MachineTool, that structure is not automatically reflected - you rebuild the equivalent shape in the asset model. Worth mapping the two deliberately so the cloud model and the machine model do not drift apart.
The traps
- Ingestion and storage are metered. An unfiltered collection strategy produces a bill rather than an insight - decide what you need before you connect.
- The asset model is a second modelling exercise on top of whatever the machine already exposes. Budget for it, and keep a written mapping between the two.
- The gateway is another OPC UA client, so every certificate, endpoint and namespace-index problem in this reference applies to it unchanged.
- Timestamp handling matters: if a PLC-embedded server only populates ServerTimestamp meaningfully, that is what lands in the cloud, and it is not when the event happened.
- Data arriving out of order or late needs a decision about how metrics recompute. Make it explicitly rather than discovering it in a month-end number.
Getting OEE data out of it
Workable, provided the machine exposes state, counts and reasons and you model them properly. Availability from a state machine mapped to an asset property, performance from counters against a modelled ideal cycle time, quality from reject counts. The honest limits are the same everywhere: planned production time, shift calendars and order context come from ERP or MES, and the resolution of your availability figure is bounded by the publishing interval you chose.
Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.