AspenTech OT Data Fabric - Differences to AspenTech Inmation

Product Media

AspenTech Inmation OT Data Fabric is distributed in two different types of media:

Windows Setup
Container Image (Linux)

The former "full setup" (inmationSetup.exe) is replaced with AspenTech-Inmation-OT-DataFabric-Setup.exe in AspenTech Inmation OT Data Fabric. Since the .NET based Web API and DataStudio no longer exist, a big part of the former full setup requirements are no longer needed.

The Windows setup can install multiple service instances, as well as integrate and install MongoDB (with external msi file).

The container image contains the same media as the setup.

User Interface

AspenTech Inmation OT Data Fabric completely relies on a web based configuration interface. The thick client application DataStudio is deprecated and not included anymore. The Configuration App is an out-of-the-box web application for interacting with Inmation in terms of configuring the system and or reading/displaying data.

The Configuration App was built using regular WebStudio functionality, which means that it is essentially a compilation of standard widgets and interactions between them — the same widgets that are available for customers to built their own UI.

Object Models and Paths

A major difference to AspenTech Inmation results from the removal of the System object and the component services’ objects from the IO model. While in AspenTech Inmation the path to an object in the IO model contained the hierarchy of objects representing the component services, in AspenTech Inmation OT Data Fabric, those are now structured in a separate model called "System Model".

This separates the IO object hierarchy from the component services hierarchy, which makes paths to IO objects independent from their hosting service, allowing for an cross-component move of objects.

Path in AspenTech Inmation

[IO Model:]      /System/Core/Connector/OPCUA_Source/Item_A

Path in AspenTech Inmation OT Data Fabric

[System Model:]   /Node_Core/Node_Connector
[IO Model:]       /Folder_Connector/OPCUA_Source/Item_A

Object Ownership

AspenTech Inmation uses a multi-master object ownership model. In this model the configuration of objects can be changed by any component that knows the particular object (has it in memory) at any time (also when disconnected). The multi-master model of AspenTech Inmation introduced a number of difficulties when synchronizing objects between components, especially when those were running on different Inmation versions.

With AspenTech Inmation OT Data Fabric, a single master object ownership model is introduced. This means an object always belongs to only one component (one Node), and can only be created or changed by this one, not by others anymore. Changes to objects (as well as creation/deletion of objects) can still be initiated by a higher level Node though. This will result in a change request traveling to the owning Node. Once the owning Node has executed the change, the object synchronization will notify all Nodes that need to know about the change.

Configuration Only When Connected

Implicitly this means that changes can only be commissioned to Nodes when they are connected.

Scripting with Ownership

Object Creation

The separation of System and IO model also introduces the necessity to be able to specify what Node owns an object when it is being created. This is especially required when creating an object at the top level of the IO hierarchy, for example. For this the mass configuration capability has been extended with the owner parameter.

local mass = {
    {
        class = syslib.model.classes.GenFolder,
        ObjectName = "RootFolder1",
        path = "/RootFolder1",
        owner = "/Home"
    },
    {
        class = syslib.model.classes.GenFolder,
        ObjectName = "ChildFolder1",
        path = "/RootFolder1/ChildFolder1"
    },
    {
        class = syslib.model.classes.GenFolder,
        ObjectName = "RootFolder2",
        path = "/RootFolder2",
        owner = "/Home/Europe/Europe"
    },
    {
        class = syslib.model.classes.GenFolder,
        ObjectName = "ChildFolder2",
        path = "/RootFolder2/ChildFolder2"
    }
}

local ret = syslib.mass(mass)
return syslib.json().encode(ret)

If the owner is omitted, an object on model root level will be automatically owned by the Node executing the Lua code. When creating a child object in a model, it inherits the owner of its parent object.

Setting (Property) Values

Lua functions like syslib.setvalue can still be used to modify properties, but now these changes are forwarded to the owner Node. The change then gets propagated back to the Node that triggered the change. The Lua call triggering the change will block until the change is visible or an error occurred. This also applies to the creation & deletion of objects owned by another node. Modification of dynamic values works as before, and syslib.setvalue does not block here.

Object GUIDs

While in AspenTech Inmation, objects had a unique identifier based on a 64bit integer, in AspenTech Inmation OT Data Fabric, this is now a GUID. This change provides a unique identifier that cannot be repeated, instead of identifiers that are only unique within the scope of one system.

Object GUIDs in Lua Scripting

Working with objects in Lua scripting has to be adjusted to the usage of GUIDs.

In Lua scripts GUIDs are of type string`.

Lua functions where numids (former integer object IDs) were passed as parameters do now accepts GUIDs.

To read the GUID of an object, :guid() was added to object’s methods.

Data Stores

With the removal of the System object, also the out of the box data stores that came with that object have been removed. Storing data in AspenTech Inmation OT Data Fabric requires that a data store and a corresponding Data Store Set are explicitly configured.

Object Class Specialization

AspenTech Inmation contained a number of object classes that were able to "morph" into specialized versions. Best example is the Data Source object, that had a large number of sub-types.

📂 Data Source (Class Code: 5)
 ┗📂 Modbus
 ┗📂 ODBC
 ┗📂 OPC DA
 ┗📂 OPC UA
 ┗📂 ...

In OT Data Fabric, these class types are replaced by new classes that each represent the specialized version independently. For example there are now new class types for various data sources.

📂 Modbus Data Source (Class Code: 3871)
📂 ODBC Data Source   (Class Code: 3865)
📂 OPC DA Data Source (Class Code: 3854)
📂 OPC UA Data Source (Class Code: 3812)
📂 ..

Multiple AspenTech Inmation Classes Affected

The example above only shows the changes for one class type, but the same conceptual change has been done for other similar class types too.

Package Management

Nodes also have Package Installer properties like Cores or Connectors in AspenTech Inmation. For now, Package Management is not supported on Nodes that run on Linux. Currently packages are not transmitted between nodes, so the package manager is used only to install or uninstall packages like the _PI Bridge package. To do so, you need to put the package into the folder data\work\packages\received (you might have to create the received folder). You can then configure the package installer properties of the node accordingly and specify the package name and version like in AspenTech Inmation.

Package Installer