The GE-Driver provides communication between IOTA Vue API (back-end) and GE Proficy historian (source).
The driver supports the following object types:
| IOTA Type | Supported? | Source Type |
|---|---|---|
| Tag | 🟢 | Tag |
| Asset | ⚫ | |
| Timeframe | ⚫ |
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 GE-Driver can support write-back to source GE Proficy historian.
Single GE-Driver service can support multiple connections to different GE Proficy historians.
QuickStart
The driver setup process requires 3 steps:
Configure IOTA Vue data source for communication with the GE-Driver service.
Install GE-Driver service on local network in close proximity to GE Proficy historian.
Configure GE Proficy historian 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 | 18 Mb |
| Data modes | Read |
| Request/Response pattern | Asynchronous |
| Source Communication | User API |
| Source versions supported | 4.0, 4.5, 5.0, 5.5, 6.0, 6.1, 7.0, 8.0, 8.1 |
| Back-end Communication | NATs message bus |
| Message bus driver type | geproficy |
| Near Real-Time Data Updates | Yes |
| Multiple GE Proficy Historians | Yes |
Dependencies
| Name | Version |
|---|---|
| Microsoft Windows | 2012 and above |
| Microsoft .Net Framework | 4.7.2 |
Security
Source Security
By default, the GE-Driver service uses configured service's user identity for connection via NTLM authentication protocol to GE Proficy historians.
If required, the GE-Driver provides an explicit username and password data access support for each connection instance
IOTA API (back-end) Security
The GE-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.