Concepts

In general, scripts are attached to objects that exist in the different models of AspenTech Inmation OT DataFabric. Technically speaking, scripts are hosted by properties of objects. Depending on the object type, the property that hosts the script can be different, and the effect of setting it can have a different outcome.

Because scripts reside in object properties, they can be read and written like any other property, including access from external interfaces like .NET API!

Some object types are able to execute scripts while others can only store them. The latter type is used to store scripts in higher tree levels, so that their successors (children in tree) can access and make use of them. Such scripts are stored as Lua script libraries.

Object Types Actively Executing Scripts

The object types that can execute scripts are:

I/O Model

  • GenericItem: This object type is used to generate data on a periodical basis. It can generate data in various ways, including a Lua script execution.

  • ActionItems: This object type is used to execute a script on an event trigger. Various triggers can be defined - the most common one being another object changing its value.

  • Rule: The Rule object type can be used during automatic object discovery to make changes to the discovered object while it is being created in AspenTech Inmation OT DataFabric. One action type of a rule is the execution of a Lua script.

Object Types Passively Executing Scripts

Script Libraries should be placed in Script Library Item objects in the Script Model. All other options to store script libraries that are addressed below are only supported for reasons of backward compatibility.

The object types that can keep script libraries are:

Script Model

  • Script Library Item - Libraries setup here are available to all objects below the particular Script Delegate object, including descendant Nodes.

System Model

  • Node: Libraries setup here are available to all objects that are 'owned' by that specific Node.

I/O Model

  • Datasources: Libraries setup here are available to all objects below the particular Datasource object.

  • I/O Nodes: Libraries setup here are available to all objects below the particular object of the various IO-Node types. e.g. .

  • Folder: Libraries setup here are available to all objects below the particular Folder object.

Lua Scope and System Extension

In addition, the scripting engine was extended by a Lua library that allows you to work with AspenTech Inmation OT DataFabric models, objects and their properties. Functions in the syslib library can be used to create, update, or delete objects. For a detailed description of the AspenTech Inmation Lua extension, please refer to the Lua Scripting Feature documentation and the Lua API docs.

Distributed Script Execution and Its Limitations

The ability to have scripts housed at various levels of the system , means the scripts can be executed by different Nodes, running on different physically distributed hosts (for instance, a Node in the headquarters, or Nodes in remote locations). This distributed computation approach has an impact on the execution possibilities of each script, and when these scripts can execute. Clearly a script on a Node can no longer be executed when the Node service is shut down. On the other hand, it can be executed independently from an active connection to its parent Node. The same applies to scripts on higher level nodes, which can run independently of any lower level Nodes. This ability comes with the limitation that a lower level Node can only work with objects, and their values, that belong to this Nodes’s model tree hierarchy, meaning objects that are successors of this specific Node. The higher level Nodes however, can operate on all objects, including ones of subordinate Nodes, because they are all successors of the higher level Node object.

Scripts and Thread Balance

The Lua script engine is embedded in the backend services of AspenTech Inmation OT DataFabric. Therefore, all execution of scripts happens on the server side. This allows the complete server side CPU power of all participating machines within AspenTech Inmation OT DataFabric to be used, but also requires that users create scripts in a responsible way. The real time engine of the backend services also executes scripts in real time on shared resources. Should a script cause a very high memory allocation, or CPU load, this can have a negative impact on the backend service executing it! This has particular relevance for scripts that run for a time longer than a second (for example when scripts query data from some other data source like a SQL database). In these cases, it is strongly advised that they are run on a dedicated thread. To configure this, check the Dedicated Thread Execution property of the script.

However, it does not make sense to run all scripts on a dedicated thread as a high number of threads can also slow down a backend service (depending on the available hardware). Because of this it is important to balance the number of scripts running on dedicated threads with the ones running on shared resources. Should you run into the situation where many scripts (1000+) have to execute the same long running code, we recommend that you create a single script running on a dedicated thread, that can deal with a queue of executions within the script environment.