What is ABB Ability™ History

A process historian software and a platform

ABB Ability™ History is a process historian software that provides a highly scalable software platform that can be embedded in a device and moved to the cloud. It consists of independent but integrated software technology components that all together provide a platform to build solutions in process industries and utilities. ABB Ability™ History is a versatile software that can be used as a standalone embedded data logger for a piece of equipment and as a Collaborative Production Management (CPM) solution that integrates the real-time control system data with the current business context to support fast operational decision-making on the asset, plant or enterprise as a whole.

In addition to the core historian functionality, data collection, processing, and storage, ABB Ability™ History contains analytics tools, various public interfaces, and UI SDKs to ease the development of tailored dashboards and industrial solutions.

ABB Ability™ History provides a platform to facilitate integrated asset and process management that can cover the assets in manufacturing facilities from power distribution, instrumentation, process control, and condition monitoring of individual equipment to management of large production lines and processes.

A relational database

The core of ABB Ability™ History is a relational database with built-in columnar features optimised for time series signal processing and storing. ABB Ability™ History implements the standard data models for process information, events/alarms, and equipment models with respective services for data processing, including measured signal stream processing, alarm detection, and online aggregation. The equipment model is a dynamic modelling tool for application-specific data models.

The same data storage technology and application platform are scalable to run as embedded in an intelligent electronic device and a plant-wide system for asset management services. The platform provides data collection and storage, data transfer between systems, and freedom for application deployment to the instance of the platform where the application fits best.

Software Architecture

Here is a brief explanation of the software architecture. ABB Ability™ History software stack is categorised into layers named Service Layer, Data Abstraction Layer, Vtrin Driver Layer, Data Storage and Connectivity Layer.

Device Connectivity Layer

At the bottom of the stack, we have the Device Connectivity Layer. The purpose of this layer is to connect and implement data collection from the devices, processes and systems (Data Producers). The data collection is implemented using two types of protocols in ABB Ability™ History. The first, referred to as an "active protocol", is executed using DataLink, which fetches or subscribes data to be transferred from the data producer/s; while the second, "passive protocols" use APIs in which Data Producers push case data.

In the active protocol scheme, at the start of History, the RTDB-ServiceManager (one of the ABB Ability™ History services) starts the communication service to collect data from the Data producers. Each service reads its configuration from the database. Based on this configuration, connections to the data producers are established.

The active protocol services get data from Data producers either by polling or by using subscriptions and callbacks. The services read the configuration and insert data into the database by using internal APIs designed for high-throughput data production.

History supports the following active protocols:

• Classic OPC (DA, HDA, and AE)
• OPC UA
• Modbus TCP

The corresponding services are:

• In Windows, RTDB-EcOpcClient connects to classic OPC servers and UA Servers.
• In Linux, RTDB-OpcUAClient connects to the OPC UA Servers.
• RTDB-EcModbusMaster to Modbus slaves.

All services are configured using the same configuration classes

Data Storage Layer

The Data Storage Layer Referred to as "RTDB", the purpose of this layer is to provide high-performance relational database services for storing and retrieving any data, especially time series data. In addition to storage services, RTDB provides rich functionality for time-series data, such as data preprocessing, event and alarm triggering, calculating aggregates and data retention for old data.

Vtrin Driver Layer

Data provider is an interface from the data abstraction interface to the native API of the database. ABB Ability™ History contains ready-made data providers for RTDB, SQL Server, PostgreSQL, Oracle, OPC and ODBC/SQL data sources. An example of the benefit of the data abstraction interface is that the implementation of a data provider for a data source enables the reuse of the above public interfaces and tools, and enables, e.g. UI or an OPC UA server for your data storage.

Data Abstraction Interface

ABB Ability™ History's data abstraction interface is called VtrinLib. The purpose of the data abstraction interface is to support modular software structure and to enable flexible evolution of the technologies, and independent life cycles for applications, products, and end customer systems and solutions.

Data abstraction interface is used by the service layer, i.e. all the data producers and consumers, such as engineering tooling, UIs, calculations, and server-side public interfaces such as OPC UA Server. The data abstraction interface is a .NET API recommended for applications unless they prefer some other public interface.

The data abstraction interface decouples data producers and consumers from the data storage. The primary storage is RTDB, the core database of ABB Ability™ History, but the data abstraction interface provides connectivity to other databases with the data provider concept.

The data abstraction interface also enables the use of other databases at the storage layer.

Further information on the Data Abstraction article and separate accessing data VtrinLib article.

Service Layer

Service Layer is situated at the top and contains various services and tools: - Public APIs, engineering and analytics tooling, systems integration, and user interfaces. It is used to implement different functionalities like data exchange, data production, configuring and monitoring History itself.

👍

The name VtrinLib describes both the data abstraction layer (middleware of ABB Ability™ History) and the software API that is available as .NET API, REST API, and server side WSS API.

Public APIs

• Vtrinlib (.NET client API) is the most flexible interface and is available as a .NET client API. Other interfaces are built on top of Vtrinlib. VtrinLib is also available as a REST API.
• ODBC/SQL Interface to the data in the data abstraction interface. The table classes are presented as virtual tables in the SQL interface. The primary purpose of this interface is to support data for reporting and analytical tools.
• OData API is a standard REST query API for classes and instances. It is good for doing calculations and analytics on top of History. It supports reading and writing time-series data and reading structural data.
• OPC UA Server provides an industry-standard, secure, and platform-independent interface to the data available in the data abstraction interface.
• OPC DA/HDA servers are widely supported and used when legacy software should be integrated. Provides access to real-time, history, and aggregated history data. OPC servers can be installed on a remote computer to avoid the need for DCOM communication.
• WSS Server API connections can be done with any standard WebSocket library compliant with RFC 6455. In addition to the standard WSS server API, there are also JavaScript client APIs for web browsers, EqM API server-side interface definition for feeding data to equipment model, and EqM client SDK, which is a reference implementation that can be used to implement embedded device connection to feed data from an IED to ABB Ability™ History or some other data storage.

Engineering Tools

• Engineering UI is a web application managing ABB Ability™ History. The web-based user interface securely connects to the server to configure, monitor and audit the ABB Ability™ History database, enriching the use of the data. Engineering UI is part of the default ABB Ability™ History installation. The Engineering UI, being a web-based application, runs on any operating system with modern web browser software (such as Chrome, Firefox, or Edge), including a mobile operating system like iOS and Android.

• Calculation Tool is part of ABB Ability™ History industrial Low Code Application Platform (iLCAP) code editor provided by our browser-based engineering UI. It consists of a server-side service for executing the calculations. It is particularly designed for time series data handling, but it handles other data types as well. Equipped with a browser-based code editor, diagnostics to monitor calculation execution and resource consumption.

• Bulk Load Tool aiming to increase users' productivity in Equipment Modeling. Equipment models can be created in any spreadsheet application, such as Excel, LibreOffice Calc, etc. Spreadsheet styles do not affect parsing processes, thus leaving users with visually appealing works in their favourite applications. Currently, .xlsx file format is supported.

Systems Integration

Tag Consistency Controller TCC, also referred to as RTDB_TagConsistencyController, is a service in ABB Ability™ History that controls the transferring of Tag definitions between nodes in a hierarchical system. It controls the Tag consistency between parent and child nodes (e.g. Main Nodes and DCNs). TCC service runs in the parent node.

EventForwarder is a service used to ensure all event information collected and buffered by DCNs is available in the Main node. Located in the Main node, it fetches events from one or more DCNs using the RTDB_Eventforwarder service.

VtrinLink is a service that transfers numerical process data (current values and current history) from data collector nodes into the main node and ensures the consistency of the histories with backfill functionality. It reads the Tag configuration available in the Main node and, based on that information, connects to one or more data collector nodes. It uses the services of Vtrin Server RTDB Internal to connect to the data collectors.

Vtrin- Netsync (later just NetSync) is an RTDB service that syncs equipment model instances and their data between ABB Ability™ History nodes. It is used to build networked systems from multiple History nodes. NetSync provides high-performance capabilities for syncing large amounts of time-series data between History nodes and from History to 3rd party systems. These nodes are called the source node and the target node. Typically, NetSync runs on the source node because, in networked systems, the source nodes are placed in a more secure network than the target node. However, NetSync can also run on the target node or any other machine when/if the source node has an older History version that is missing NetSync. It is also possible to sync time-series data from variables on the source node into equipment properties on the target node.

User Interface SDKs

View ABB Ability™ History provides a tooling (UI SDK) to implement a user interface for an industrial application or solution. The concept is based on HTML5 and WebSocket technologies, and tooling that enables to creation desktop-like user experience in a web browser with a minimum amount of coding.

Using UI SDK support to implement a plant or enterprise-level web/mobile user interface for PIMS, MOM or AM systems that serve hundreds of concurrent users and thousands of close-to-real-time dashboards.

The dashboards for the UIs can be created with the wysiwyg editor of the UI SDK without programming. The dashboards are implemented with the widgets from the widget library that is coming with the UI SDK as part of ABB Ability™ History. The widget library can be extended with its own widget implementations and 3rd party libraries.

System architecture

Hierarchical & Networked

ABB Ability™ History provides the flexibility in system topologies (Hierarchical & Networked) that is needed to implement modern industrial solutions. It provides scalability in system size and performance from low-footprint embedded systems to enterprise-wide historians with high-resolution data recording.

Because of industrial cybersecurity, the data collection is implemented hierarchically. The Data Collector Nodes (DCNs) are connected to devices and control systems with their preferred protocols in the automation network. The data is transferred with a secure connection to the production line or plant-level system and then to the enterprise level (if needed) that may reside in the Cloud.

ABB Ability™ History supports bidirectional data transfer, though the connection is typically initiated from the more secure zone. Data transfers are defined with simple rules based on the information models. Data feed can be defined for multiple targets. Also, 3rd party systems are supported with extendable interfaces.

All ABB Ability™ History nodes can be installed in a high-availability configuration. Application hosting is supported at all levels from DCN to Cloud, and all APIs and other services are available in all the ABB Ability™ History instances.

ABB Ability™ History provides OPC DA/HDA/AE, UA, and Modbus (TCP) clients for data acquisition, and industry-standard server APIs for data ingestion. The implementation of other types of data collection interfaces is supported by templates and hosting services.

ABB Ability™ History provides redundancy with online data replication and load sharing at both DCN and main history levels.

Equipment model

One of the key aspects in ABB Ability™ History is its predefined meta-information model called the "Equipment model". It is used in modelling industrial assets and processes and implementing applications against them. The unified equipment model presentation reduces efforts while communicating between systems and subsystems. The ability to collect time series history for an equipment property is one of the major advantages when considering the adoption of the Equipment Model. It also allows the dynamic addition of new properties to production systems, simplifying the deployment of new features. Adding new equipment instances to an existing system is also straightforward. The default values defined in the equipment model configuration serve this purpose, together with pre-defined history data collection attributes.

The equipment model has built-in support for time series handling, and there is a lot of support in tooling for equipment model engineering, starting from data acquisition and ending up with calculations, visualisation, public APIs, and external systems data transfer.

Please find further information on time series handling under time series concepts.

The equipment model supports inheritance to enable model-type hierarchies between similar types of equipment. Inheritance allows common properties to be automatically available for all the inherited types. For example, a base equipment type could be an "electrical apparatus" from which an "electric motor" is derived, and this could further be inherited as a "low voltage motor".

Furthermore, equipment instances can be organised in hierarchies for multiple purposes. Each equipment is referred to as an instance, and each instance of an equipment model type is placed in at least one logical hierarchy. The purpose of this logical hierarchy can be a process hierarchy, a locational hierarchy, or any logical or natural hierarchy. As an example, a hierarchy can contain process paths like Site.Production line.Process unit.Equipment . Also, additional hierarchies can be created for other purposes.

Relational & Non-Relational Database

The core of ABB Ability™ History is RTDB, a relational database with built-in columnar features that are designed and optimised for time series data management. ABB Ability™ History combines the best features of the different databases to provide the maximum performance and functionality for time series data management with the flexibility of a relational database for additional application data.
ABB Ability™ History provides database and data management services for handling time-series data and events/alarms. A time-series data item consists of the timestamps, quality information, and a value that can be either any basic data type, an array of basic data types or a blob.

Other Attributes

Security

ABB Ability™ History has been designed to handle various cybersecurity aspects

• All the interfaces require user authentication. The authentication is supported by multiple ID management systems with single sign-on support; certificate-based authentication can also be used
• Data transport security between client and server is based on a secure WebSocket (TLS/SSL).
• Data security is applied to all public interfaces.
• Audit trail logs are collected for client actions.

Data security definitions are based on data class-specific access control list (ACL) definitions. Data security covers:

• Object class, e.g. the Variable or relational table.
• Attribute, e.g. the property of a Variable or column in a table.
• Instance, e.g. the value or engineering attribute of an individual Variable or row in a table.
• Inheritance can be used in the security definitions to support engineering for large databases.
• Time-based security for process history. For example, a client can have access to historical values of a Variable for a specific period.

The ABB Ability™ History visualisation security provides

• Hierarchical security definitions in navigation
• Data security is applied to each presented value.

High Availability – Database and Application Redundancy

ABB Ability™ History supports configurations where there are two instances of the database that are replicating their content in real-time, and providing high availability of the data and also redundancy for the system applications and services for users. The redundancy of ABB Ability™ History provides the following benefits:

• The reliability of the system is higher than achieved with a typical cluster-based configuration.
• Data collection can be secured in three phases:
  1. A Variable can have redundant data collection interfaces or protocols. For example, you can have the primary collection with OPC DA and use Modbus/TCP as a backup.
  2. The DCNs can be redundant and can buffer all the incoming measured data and events/alarms for predefined periods, such as 1 week or a month. After the failure has been corrected, the missing data is automatically transferred from the DCNs to the main ABB Ability™ History server.
  3. The redundant main History servers collect data from all the DCNs (single and redundant ones). The software upgrades, etc., can be handled during continuous system operation, because one node can be shut down and the system will still continue to provide all the services. Data that was not stored in a node is backfilled from the other instances of the database automatically by merging the database tables row by row.
• Load sharing for applications and users. Any of the database instances can be used to serve the users or to run the applications.
• The performance of the system is improved in failure situations. Data processing and history recording services are run all the time in all the nodes, and consistency control of the databases with possible data merge operations are continuous tasks to prepare the system to handle the possible single point of failure with minimum disturbance to the performance or normal operation of the system.