Cognite CDF

Cognite Data Fusion.

A tag sync matches your PI points to CDF time series — 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

As with AVEVA CDS, Stream authenticates as a registered
application rather than as a person. Create the application in your identity
provider first: Stream cannot register one for you.

Field	Notes
Cluster	The CDF cluster, e.g. az-eastus-1
Project	The CDF project
Tenant ID	The directory the application lives in
Client ID	The registered application
Client Secret	Its secret: stored encrypted, never sent back to the browser
Data set	Optional default: the data set new time series are filed under
Space	Optional default: the data-modelling space, when the project uses one

Cluster and Project take the place of CDS's resource and namespace; the
form is otherwise the same shape.

The two Defaults are exactly that. A tag sync can override either from its
mapping, so one connection serves several syncs filing into
different data sets.

What a tag sync writes here

A CDF time series is keyed by its External ID, and the default is
pi:[tag.servername]_[tag.name] — the PI server's name and the point's tag name.

Why the server name in front	A tag name is only unique within one server. A project collecting several archives has no other way to keep SINUSOID from two of them apart
Why the pi: prefix	A CDF project is rarely fed by one source, and the external id is the only thing a consumer sees. CDF permits the colon — CDS does not, which is why its key is shaped differently

[tag.servername] resolves to the PI server's own name, as PI reports it, the same
token CDS keys on — so the two cloud types read alike. The cost is
that renaming the PI server changes the key: the next sync finds nothing under the
new name and creates a second series beside the first. Correct the External ID
template before running a sync against a renamed server, not after.

isString and unitExternalId are derived by the service and cannot be mapped.

Data types

CDF has two data types, so isString is the whole of the type mapping — and it runs
the opposite way round from the obvious reading. Only five PI types are numeric;
everything else is a string.

PI point type	CDF series	isString
Float16	numeric	false
Float32	numeric	false
Float64	numeric	false
Int16	numeric	false
Int32	numeric	false
String	string	true
Digital	string	true
Timestamp	string	true
Blob	string	true
Unknown or empty	string	true

A digital source therefore arrives as a string carrying its state names, not as a
number, and its values go over as the text the AF driver reports for them.

It is the same numeric-or-string split AVEVA CDS makes.
CDS keeps the PI type on the numeric side — a Float32 stays PI-Float32 — where CDF
flattens all five to "not a string".

A series created before this rule needs re-creating

Timestamp, Blob and unknown sources used to become numeric series. The type check
then compared a string source against a numeric series and reported a mismatch that no
run could clear.

Those series are now correctly reported as a mismatch. Nothing repairs one in place —
a CDF series cannot change type — so delete it and let the sync create it again, if the
data matters.

unitExternalId is looked up from the source UOM in CDF's own unit catalogue.

metadata.* is an open family — any key after the dot is legal, so the point source, PI
path and instrument tag that the mapping starts with are a beginning rather than the
list.

CDF upserts by timestamp. It overwrites at a timestamp by nature, so a "keep
existing" write mode cannot mean anything there and Stream does not offer one.

Related

• Endpoints: the list, and how a connection is tested
• AVEVA CDS: the other industrial cloud type
• Tag Sync: creating and maintaining the time series