Overview
The AVEVA Historian Driver (WWH) provides connectivity between IOTA and AVEVA (Wonderware) Historian. The driver is state-less, i.e. it doesn't maintain source connections and data caches. The single WWH Driver service can support multiple connections to different AVEVA Historians.
The driver supports the following object types:
IOTA Type | Supported? | Source Type |
---|---|---|
Tag | 🟢 | Data table |
Asset | ⚫ | |
Timeframe | ⚫ |
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 | MS-SQL Native Client |
Back-end Communication | NATs message bus |
Message bus driver type | wwh |
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 |
Security
Source Security
By default, the WWH Driver service uses configured service's user identity for secure connections to MS-SQL Server (served as gateway to AVEVA Historian). In addition, WWH Driver supports explicit user/password authentication mechanism for each configured server connection.
IOTA API (back-end) Security
The WWH Driver uses NATs message bus to communicate with the IOTA Vue Cluster. The two-way data traffic is encrypted using Transport Layer Security (TLS) on port 443. In addition, the message bus communication security model uses a public-key signature system based on Ed25519 called NKeys. With NKeys, the server can verify identities without ever storing or 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 client's identity. If the public key is known to the server, authentication succeeds.