The AF-Driver provides communication between IOTA Vue the Cluster (back-end) and OSIsoft PI System + PI Data Archive (source).
The driver supports all the PI System object types:
| IOTA Type | Supported? | Source Type |
|---|---|---|
| Tag | 🟢 | PI Point |
| Asset | 🟢 | AF Element with AF Attributes |
| Timeframe | 🟢 | AF EventFrame with AF Attributes |
The driver is state-less, i.e. driver does not maintain source connections and any data caches.
Depending on the driver's deployment build version, the AF-Driver can support write-back to source PI System + PI Data Archive.
Single AF-Driver service can support multiple connections to different PI Systems and PI Data Archives.
QuickStart
The driver setup process requires 3 steps:
Configure IOTA Vue data source for communication with the AF-Driver service.
Install AF-Driver service on local network in close proximity to PI System and PI Data Archive.
Configure PI System and Data Archive connections
Diagram
Technical Specification
| Description | Value |
|---|---|
| Development Language | C# |
| Processor Architecture | 64-bit |
| Supported Operating Systems | Windows 2012+ |
| Minimum Requirements CPU/Memory | 4 cores / 8 Gb |
| Deployment Size | 13.7 Mb |
| Data modes | Read/Write* |
| Request/Response pattern | Asynchronous |
| Source Communication | OSIsoft AF-SDK |
| Back-end Communication | NATs message bus |
| Message bus driver type | osiaf |
| Near Real-Time Data Updates | Yes |
| Multiple PI Systems/Data Archives | Yes |
Dependencies
| Name | Version |
|---|---|
| Microsoft Windows | 2012 and above |
| Microsoft .Net Framework | 4.7.2 |
| AVEVA/OSIsoft AF-SDK | 2.10.6.195 and above |
Security
Source Security
There are two levels of authentication and authorization to consider for the AF-Driver:
- The driver process authenticates to PI and/or AF, and those servers authorize it accordingly.
- Optionally, you can map user groups defined in your identity provider (IdP) to PI and AF identities to enable user- and tag-level access controls. At this level, it is your IdP which authenticates users and the driver with authorizes them to access PI and AF.
If you only configure the first of these levels, then all IOTA users will have the same level of access in PI and AF, which you can control via the PI and AF identities that you've mapped to the Windows account running the driver service. If this is acceptable, then you do not need to bother with configuring the second level.
On the other hand, you might require different users to be authorized differently. For example:
- Some users might need to write data back to PI or AF via IOTA, but most users should be forbidden from doing so.
- Perhaps users from one plant or business unit should not be able to see data from another plant or business unit.
The second level of authentication and authorization described above can accommodate cases like these. By mapping user groups to PI and AF identities, you can further constrain the actions that a given user can perform based on their group memberships.
For more information about configuring authentication and authorization at both levels, see Configuration.
IOTA API (back-end) Security
The AF-Driver uses NATS message bus to communicate with back-end IOTA API. The two-way data traffic is encrypted using Transport Layer Security (TLS) on port 443.
In addition, the message bus communication security model uses public-key signature system based on Ed25519 called NKeys.
With NKeys, the server can verify identities without ever storing or ever seeing private keys.
The authentication system works by requiring a connecting client to provide its public key and digitally sign a challenge with its private key.
The server generates a random challenge with every connection request, making it immune to playback attacks.
The generated signature is validated against the provided public key, thus proving the identity of the client.
If the public key is known to the server, authentication succeeds.