The IP21-Driver provides communication between IOTA Vue API (back-end) and AspenTech InfoPlus.21 (IP21) historian (source).
The driver supports the following object types:
| IOTA Type | Supported? | Source Type |
|---|---|---|
| Tag | 🟢 | Analog, Discrete, Text |
| Asset | ⚫ | |
| Timeframe | ⚫ |
The driver is state-less, i.e. driver does not maintain source connections and any data caches.
Single IP21-Driver service can support multiple connections to different AspenTech IP21 historians.
QuickStart
The driver setup process requires 3 steps:
Configure IOTA Vue data source for communication with the IP21-Driver service.
Install IP21-Driver service on local network in close proximity to AspenTech IP21 historian.
Configure AspenTech IP21 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 | 5.03 Mb |
| Data modes | Read |
| Request/Response pattern | Asynchronous |
| Source Communication | AspenTech SQLplus DataProvider |
| Back-end Communication | NATs message bus |
| Message bus driver type | aspenip21 |
| Near Real-Time Data Updates | Yes |
| Multiple AspenTech IP21 Historians | Yes |
Dependencies
| Name | Version |
|---|---|
| Microsoft Windows | 2012 and above |
| Microsoft .Net Framework | 4.7.2 |
Security
Source Security
The IP21-Driver uses an explicit username and password to establish communication with the source AspenTech InfoPlus.21 historian.
IOTA API (back-end) Security
The IP21-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.