The Inmation to IOTA Driver provides communication between IOTA Vue API (back-end) and AspenTech Inmation (ASPIN) system (source). The driver supports the following object types:
| IOTA Type | Supported? | Source Type |
|---|---|---|
| Tag | 🟢 | IoItem, IoProperty, DataHolderItem, GenItem, AnalogMeasurement, Variable, BinaryState, CalculatedValue, DiscreteValue, S95EquipmentProperty, TextualState, ActionItem |
| Asset | 🟢 | Core, DataFolder, GenFolder, DataSource, Variable Group, DataStoreGroup, IoDevice, IoItemGroup, IoNode, IoTyoeDropZone, |
| Asset, Area, ControlModule, Division, Enterprise, EquipmentModule, Plant, PlantCompound, ProcessCell, Site, Train, Unit | ||
| S95EMEnterprise, S95EMSite, S95EMArea, S95EMProcessCell, S95EMPCUnit, S95EMProductionUnit, S95EMProductionLine, S95EMWorkCell, S95EMStorageZone, S95EMStorageUnit, S95EMWorkCenter, S95EMWorkUnit, S95EMEquipmentModule, S95EMControlModule, S95EMPUUnit | ||
| 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 Inmation systems.
QuickStart
The driver setup process requires 3 steps:
Configure IOTA Vue data source for communication with the ASPIN-Driver service.
Install ASPIN-Driver service on local network in close proximity to AspenTech Inmation system.
Configure AspenTech Inmation 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 | 33.3 Mb |
| Data modes | Read |
| Request/Response pattern | Asynchronous |
| Source Communications | .Net API (SCI) and WebApi |
| Back-end Communication | NATs message bus |
| Message bus driver type | aspin |
| Near Real-Time Data Updates | Yes |
| Multiple AspenTech IP21 Historians | Yes |
Dependencies
| Name | Version |
|---|---|
| Microsoft Windows | 2012 and above |
| Microsoft .Net Framework | 4.8 |
Security
Source Security
The ASPIN-Driver uses an explicit username and password to establish communication with the source AspenTech Inmation System. There are 2 communication types available: SCI and WebAPI.
Simple Call Interface (SCI) Security
The SCI call interface authorizes users on the course of each individual call. In order to achieve flexibility for the ASPIN-Driver, the submitted profile name and password are not checked against the operating system authentication, but instead the Profile Credentials in Core Services.
Web API Security
The ASPIN-Driver uses Token Authentication (also called Bearer authentication). Bearer authentication is an HTTP authentication scheme that involves security tokens called bearer tokens. The bearer token is a cryptic string, which can be acquired by calling the token endpoint based on Oauth 2.0. The returned access token is a JSON Web Token (JWT). JWT is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed.
The Driver supports 3 user authorities:
Built-In- Authenticates user against a Profile in the Access ModelActive Directory- Authenticates domain user against Active Directory (AD)Local Machine- Authenticates user against the local Windows Security Account Manager (SAM)
IOTA API (back-end) Security
The ASPIN-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.