System Configuration Checklist

ABB Ability™ History is generic software that enables implementation of various industrial information systems. This means that there are multiple different system components that can be used and multiple ways to configure them. It is not always obvious how things should be done to meet the requirements and to enable long life-cycle for the system without need for rework later on. This article can be used to get overall understanding on ABB Ability™ History capabilities and as a checklist when planning system implementation.

Architecture

Well thought system architecture is the foundation for secure, cost efficient, and high quality service of the system over its long life-cycle.

System Topology

System topology can be just one single node or network of tens of interconnected nodes with different kinds of roles depending on the requirements. There are multiple questions such as "Where are the users, data sources, external applications, which kinds of network and cyber security restrictions etc." that affects to the topology.

What is the primary place of the system in the hierarchy of the information systems (Purdue model)?
Most of the industrial (process, condition monitoring, energy management, etc.) information system are at layer 3, i.e. plant information system layer, but could be also that the system is only at level 2 or then it is e.g. Cloud based system.

Is there need for data collector nodes (DCNs)?
DCNs are typically used to support network segregation and cyber security between L2 (automation system layer) and L3 (information system layer). DCNs provide more robustness to data collection and automatic data backfill in case of network or other disturbances.

Is there need for enterprise/Cloud level system above the primary node?
ABB Ability™ History node in Cloud enables cost efficient bidirectional data transfer between plant level and Cloud, and lots of flexibility to data feed and interactions with 3rd party systems.

More information on system topologies can be found here System architecture and topology

High Availability

High availability (HA) is supported by ABB Ability™ History on all system levels, i.e. DCNs, main/plant level nodes, and in Cloud. In addition to two computing nodes, HA requires special configuration in database, so called CRC indexes to tables, high performance network between the HA nodes, and design how the redundant data acquisition and applications are working.

Single node system can be upgraded to HA system later on, but it requires more engineering work and might be time consuming depending on the size of the database. If the system will ultimately run in HA configuration, it shall be configured to HA even if there is just one node at the beginning. It must be noted that HA configuration requires more computing resources than single node.

More information on HA here High Availability and instructions for HA Installation.

Operating Systems

ABB Ability™ History can be run on Windows or Linux operating system (OS) on physical hardware or virtual machines, or on Linux containers. Different system layers, e.g. DCN and main nodes, can run on different OS, and even HA nodes can run on different OS. Database is binary compatible on different OS. Some services are OS dependent, e.g. classic OPC interfaces are available only on Windows.

More information on installation on different OS Installation guides

Computing Resources

How to select the right amount of computing resources, e.g. number of CPU cores, RAM memory, and disk space, is not a straight forward question to answer, because the requirements depend on multiple system parameters such as system topology, HA configuration, amount of time series streams, total data throughput, amount of concurrent users, and how much applications and consuming resources.

Learn more on System Sizing and Performance

Enabled Services

The essential system services are installed by the ABB Ability™ History installation, but there are also servicesand APIs that might be needed and must be separately installed or enabled. E.g. there are multiple generations of OPC UA client and server with slightly different functionalities. Check the services from List of Services.

User Authentication and Role Definitions

ABB Ability™ History doesn't store any user ids, but it can be connected to multiple user id management systems concurrently. All APIs and tools require user authentication and there are available multiple authorization models. It is recommended to use role based authorization and design the roles and authorization at the beginning of the system implementation so that configuration can be kept simple and easy to validate.

Learn more on Security, Authentication and Authorization

Certificates

Certificates are used for authentication, authorization, and communication encryption at multiple places. Most APIs, tools, node to node communication, and data acquisition links take benefit of certificates. Acquiring proper certificates and planning their life-cycle is important for ensuring cyber security and uninterrupted system operation.

More information on Certificates

Test and Development Systems

Most of the systems are continuously maintained and developed with new functionalities. It is recommended to define controlled process how the software upgrades and new functionalities as well as applications developed by the system tooling are deployed to production system to ensure uninterrupted operation and cyber security. In mission critical systems it is recommended to have full scope test system including HA configuration for the most important system layer with live data updates from DCNs. All software upgrades shall be first deployed to the test system to validate them before deployment to the production system.

For the development of the equipment models, calculations and dashboards, separate development system is recommended, where the developed application is finalized by creating an installation package for it. The installation is first deployed to the test system and after validation then to the production system.

Remote Access for Maintenance

For prompt support and maintenance of the system, remote access is an essential tool for the supplier. ABB Ability™ History contains built-in secure remote access capability. Secure Remote Access

System Monitoring

ABB Ability™ History collects diagnostic information on itself and it contains separate system monitoring service that collects diagnostic data on resource usage of the system node. The diagnostic data is stored with history recording in the database as equipment data. The diagnostic data can be browsed with the Engineering UI.

It is recommended to implement watchdog type of signals with history recording for all the essential data collection and system interfaces to enable monitoring of the continuous data flows.

In a large system it is recommended to organize separate system monitoring node where the diagnostic data from all the system nodes are forwarded with Netsync to enable central monitoring. Alarm limits can be defined for the resource usage signals and they can be used as notification triggers to notify system maintainers on exceptional situations.

Backups

ABB Ability™ History contains backup utility that takes scheduled backups according to its configuration to disk on the system node. For disaster recovery it is recommended to define process for storing the backups regularly to safe place and test the quality of the backups by restoring a copy of the system from the backup. Backup and Restore

Anti-virus

When configuring anti-virus software in a ABB Ability™ History node, notice to exclude the RTDB database and RTDB backup directories or the entire database disk from the scan list, because anti-virus software would introduce a huge performance penalty when continuously checking the changing database files. https://docs.cpmplus.net/docs/system-security#anti-virus-software

Information Models

Tag/Variable is the classic information model for a measured signal. It is typically the natural choice when collecting data from a control system. It shall be noted that the name of a Variable must be unique and when transferring data from a node to another, the id of the Variable changes. Sometimes same Variable name is used in multiple control systems and when connecting several plant wide systems to an enterprise level system, the names might conflict. Tags and Variables

When collecting data from independent devices such as electrical drives or relays, it is recommended to use equipment modeling, because it reduces required engineering work and the ids of the instances are globally unique that makes them easy to handle also in enterprise level system. Equipment Model

Equipment models may evolve over time and it is important to design how to manage their life-cycle and how to deploy upgrades in hierarchical system. More information on Equipment model life-cycle

Variables and Equipment models are not excluding each other, but a typical system may contain both, and many times the data is collected from controls systems to Variables and then equipment models are created above for the applications. More information on Equipment Model and especially on referencing Variables from properties with Property Sharing

Attention shall be paid to the attributes of the Variables and Equipment properties. Data type of the signal is the most essential, but also min/max for the value, engineering unit, history table, data compression settings etc. shall be considered to avoid problems later on. Configuration classes

Engineering work to create Tag/Variables and Equipment models and instances is typically the most significant work in setting up a system. Typically bulk load tools are used to create the initial setup. Tutorials to Tag/Variable bulk load tool and Equipment model bulk load tool.

Data Acquisition

Typical approach to handle the time series data acquisition from control systems and devices is to use so called master protocols. Master protocol means that the active part of the communication such as OPC UA client or Modbus master is running in ABB Ability™ History node and there is the configuration data for the data collection. Data collection services

The master of the protocol is connecting to the source of the data, i.e. server, and this means that there must be network ports open for this connection. If the networks are segregated and no ports are allowed to open, the data acquisition can be handled by DCNs. Basics on Live data production

Time series data can also be written to the database by APIs either to current values or to History values .

In HA systems, special attention shall be paid to redundant data collections. Are there redundant servers available and e.g. does the control system tolerate concurrent double data collection. If there are data writing, such as controller set-points, back to the control system, how do they behave in redundant system?
Some concepts about the Redundant data production

History Tables

Basics of time series data concepts and how the historical data is collected are good to understand Time series concepts. There are preconfigured history tables, but for good reason new ones can be created. The right raw data history table for a signal is essential, because what provides the best performance for a measured signal from control system may cause significant waste of resources for a calculated signal. Good rule of thump is that Stream History shall be used for measured signals and Current History for the calculated signals.

Various kinds of precalculated aggregate histories can be collected, but only if there is a good use case for them, because they all consume resources, and the data retrieval supports online aggregation. Information on Aggregates and Data processing.

The length of a history table and how it is configured might be ignored when installing the system, but later on wrong configuration may lead to problems. The default settings are working, but when adjusting the length and so called split length, the impact shall be understood, and the split length can't be adjusted later on. More on history table structure can be found on Aggregated Histories.

Calculations

There are multiple things to consider when implementing Calculations.

Inputs, Outputs, Scheduling

Basic things for input/outputs, whether to use Equipment models or individual Variables, how to do scheduling, what is the calculation period, how many periods are calculated at the time are important to decide. Calculation concepts and parameter mapping.

Typically calculations are dealing with history values, i.e. input values are read from history over defined time period and the results are stored to some history table representing the calculation period. Only for good reason the calculation shall deal with current values. Though it is much more efficient to handle current values, it shall be understood whether the results are deterministic in case of data backfill or if there is need for recalculation. Input values can be read from any type of history table, but results must not be stored to Stream history type of table, if there is need for recalculation. It is typically recommended to use discreate attribute for output and no compression to avoid misinterpretation of the results. Also impact of HA configuration to calculation results is worth of considering.

Dashboards

UI tooling support multiple ways to implement UIs for the end users, and there is not a single right way to do it https://docs.cpmplus.net/docs/cpmplus-view.
Here are some things that shall be considered:

Role based UIs. Single system may have multiple UIs that may share dashboards. Better user experience may be achieved when a dedicated UI is implemented for particular user role instead of collecting all things within same UI.

Equipment model based vs. single dashboards. If equipment modeling is used for data storing, it is recommended to implement the dashboards based on equipment models to reduce the engineering work and provide better maintainability for the dashboards. Sometimes it may even be reasonable to implement equipment models just for the dashboards.

Inheritance. Dashboards support inheritance and if multiple dashboards have some common elements, it may be worth of implementing a base dashboard that is inherited by the others. This may reduce maintenance work in future, if there are changes to the common elements.

History data in process diagrams. Process diagram type of dashboards can be implemented to support showing all the values and charts from selected time in history, if all the widgets are connected to time control. This feature has some performance penalty, but if the feature is needed, it is better to implement it from the beginning instead of converting the dashboards later on.

Dashboard scripting. Sometimes there is need to implement logic in dashboard that can't be achieved with the existing functionalities of the widgets. This is supported, but it shall be considered how the scripts work over time, if the functionalities of the widgets evolve.

3rd party widgets. UI tooling support use of the 3rd party widgets, but it shall be considered how new versions of them are deployed to the system and what if the functionalities are evolving and needs changes to the wrapper of the widget.