AVEVA CDS

AVEVA Connect Data Services: formerly ADH, and before that OCS.

A tag sync matches your PI points to CDS streams — finding the ones
that are already there, creating only what is missing — and keeps their definitions in
step; a tag sync task moves the values into them.

Fields

Stream authenticates as a registered application, not as a person, so the form
asks for a tenant, a client ID and a client secret rather than a username and
password. Create that application in AVEVA Connect first: Stream cannot register
one for you.

Field	Notes
Resource	The regional endpoint: prefilled with the US-West default
Namespace Id	The namespace inside that region
Tenant Id	The CDS tenant
Client Id	The registered application
Client Secret	Its secret: stored encrypted, never sent back to the browser
Community Id	Optional: only for a tenant that publishes through a community

Resource is regional, and it matters

A namespace in one region is not reachable through another region's resource.
If a namespace you can see in the CDS portal is reported as missing, the resource
is the first thing to check, before the namespace ID and before the credentials.

What a tag sync writes here

The defaults mirror AVEVA's own PI-to-CDS connector, so a namespace that connector
has already populated resolves as found and is maintained, rather than having a second
set of streams created beside it.

A CDS stream is keyed by its Stream ID, and the default is
PI_[tag.servername]_[tag.id] — the PI server's name and the point's id, which is
exactly how a stream AVEVA's connector made is named (PI_devserver2019_1).

Why the point id, not the tag name	A point id is unique within a server and never changes. A tag can be renamed, and a rename would otherwise strand the stream and create a new one next to it
Why the server name in front	A point id is only unique within one server. A namespace collecting several sites would map two different points onto one stream without it

The id is not readable, which is what Name and metadata.tag are for: both carry the
tag name, so the stream is searchable by it while the key stays stable.

The metadata

Eight values are populated by default:

Metadata	From
engunits	The point's engineering units
pointid	The point id
pointsource	The point source
pointtype	The source data type
step	Whether the point is stepped
tag	The tag name
zero, span	The bottom of the point's range, and its width

The first six are what AVEVA's connector writes. zero and span are added on top,
because nothing else on a CDS stream records the point's range and a consumer reading
the values has no other way to recover it.

metadata.* is an open family — any key after the dot is legal — so this is the set that
is populated by default, not the set that is allowed. Two worth knowing about:

• sourcetag is in the connector's own list but is left blank on every stream, and
  Stream has no source token to fill it from. Add the row if your site uses it.
• pipath is offered but not filled in: the connector does not write it, and the
  source path is the one thing a stream otherwise carries no trace of.

Data types

Type ID is derived by the service and cannot be mapped. A numeric source keeps its
PI type as an SDS type of its own; everything else becomes a string.

PI point type	CDS stream type
Float16	PI-Float32
Float32	PI-Float32
Float64	PI-Float64
Int16	PI-Int16
Int32	PI-Int32
String	PI-String
Digital	PI-String
Timestamp	PI-String
Blob	PI-String
Unknown or empty	PI-String

There is no PI-Digital. A digital source becomes a string stream carrying its
state names, and its values go over as the text the AF driver reports for them.

The split between numeric and string is the same one
Cognite CDF makes — CDS simply keeps more of the PI type
on the numeric side, where CDF flattens all five to "not a string".

A CDS destination is addressed by an id rather than a name, which is why the
Tag State and Audit views
offer Destination ID as something to search on.

Check the first resolve says Found, not Missing

If you are pointing a sync at a namespace AVEVA's connector already fills, run the
Destination tab once with both write policies on Never
before you turn anything on. The button then reads Search rather than Sync, it
resolves every pair and writes nothing, and the streams that already exist should come
back Found.

[tag.servername] resolves to the PI server's own name, as PI reports it — a server
registered as IVAN2024 gives PI_IVAN2024_1, and one registered as devserver2019
gives PI_devserver2019_1. So a column of Missing against streams you can see in the
CDS portal usually means one of two things:

• the streams were made from a different PI server than the one this sync reads, and
  they are genuinely not this server's tags; or
• that server's name was spelled differently when those ids were made.

Either way, correct the Stream ID template before creating anything, not after.

Related

• Endpoints: the list, and how a connection is tested
• Cognite CDF: the other industrial cloud type
• Tag Sync: creating and maintaining the streams