Guidance for building a solution

This is a simple check list on matters that you should take into account when building an ABB Ability™ History based system.

System topology and redundancy

Start the planning by thinking, whether your system is a singe node standalone application or perhaps plant wide system that needs to have data collector nodes and hierarchical system structure, or perhaps enterprise level system on top of all. What are the roles of the different nodes, what connections they have to other systems for data acquisition or IT integration, and where are the users. Are any of the nodes in mission critical role and need to be in high availability (HA) configuration. Would the data acquisition need also redundant configurations and how it is supported by the source systems.

Find information on system architecture and topologies System architecture and topology.

Sizing of the nodes

What is the amount of the life signals, i.e. measured data from devices and control systems, calculated values, and aggregated values, you will have in your system. What is the volume of the life data stream that needs to be processed per second. How long you want to store the data in each node. How many concurrent users there are in each node, and which kinds of calculations and other applications there will be consuming system resources. If you have hierarchical system or high availability configurations, do you have required network bandwidth between them.

Find help for system sizing in System sizing and performance .

Object models

One significant question is which kind of object model you are going to use for your time series data; Tag/Variable or Equipment model, or perhaps a mixture of them. If you are building a condition monitoring system for well defined devices, the best approach is most probably equipment model that supports the application development throughout the project implementation. However, most of the manufacturing operation systems get most of the data from control systems that typically provide the data in flat or simple hierarchical Tag/Variable format.

The data object model, i.e. Tag/Variable or Equipment model, affects to the data transfer between the hierarchical nodes. Tag/Variable is supported in hierarchical systems by VtrinLink service and Equipment models in hierarchical and networked topologies by Netsync service. Equipment model is more flexible and fits better to enterprise level systems where the data is collected from multiple factories and where e.g. the Tag/Variable address spaces may conflict.

Equipment models and Tag//Variables can also be combined. Low level data acquisition can take place with Tag/Variable and then applications introduce equipment models with properties that are wired to Variables. Data transfer to upper levels could be then equipment model based, or a combination of them both.

Learn more about the object models in Time series concepts.

History tables

Time series data is stored in history tables. Structurally there are two types of history tables; CurrentHistory and StreamHistory. Measured data that's nature is "write once, read frequently" shall be stored in StreamHistory types of tables and data that is frequently updated such as calculation results and aggregates in CurrentHistory type of tables. ABB Ability™ History contains several predefined history tables that should be used if applicable, but you can also create new once according to your needs. Think whether there is need to have different retention policies, because the policy is per table. Each equipment property and Variable have attribute that defines which history table is the default storage for its' raw values.

Events are stored in event log tables. ABB Ability™ History contains several predefined event log tables, e.g. OPCEventLog and EquipmentEventLog, that are used to store process events recorded from devices and control systems. Internally created events and alarms are stored in AlarmLog. New event log tables can be created to store e.g. production related events or device maintenance events.

Learn more on history tables in Time series concepts.

Aggregations

ABB Ability™ History contains predefined history tables for aggregated values and collection definitions for them. An example of such is time average (AVG) collection chain: CurrentHistory --> AVG1Minute --> AVG1Hour --> AVG1Day. The predefined aggregation collections can be applied to Variables and Equipment properties, and new once can be created. It shall also be thought what happens after possible backfilling or maintenance of history values, i.e. recollection of the aggregated values. Predefined collection chains have defined recollections, but with new definitions it shall configured separately. It should also be though where the aggregated values are collected in the system topology to minimize data transfers between nodes, but also make the aggregates available where needed.

Calculations

Should the calculations be equipment model based to enable easy deployment to all instances. How to reuse the equations in case of Variables to various similar process units. How to support the traceability and understanding to users.

What is the best place to perform calculations. Sometimes it is the data collector node, e.g. to calculate the vibration KPIs and transfer only the KPIs to upper system levels instead of the high resolution data. Sometimes the calculations need data from multiple systems and users, and must be run where the data is available. Fleet analytics shall be run in a node where the data from all the instances are available.

Recalculations, triggering the calculations based on events such as batch completion, using the aggregated source values and user entered lab measurements etc. need thinking all the special cases. Things may also be more complex in redundant environment, if the data streams are coming in different order, and not always available at the same millisecond in all nodes.

Learn more about calculations and tooling in Calculation tool overview.

Visualization

Is there just one application for all users or do you need separate applications for some user roles or perhaps customized UI for mobile users. Multiple applications are supported with different kinds of navigations and they can also share same dashboards, if applicable.

Learn more about the visualization in UI & UX Design and from number of webinar recordings that you find here Application Development.

Security

Who are the users of the system and can they be grouped by different roles. Where is the user authentication management system or is there need to support multiple of them and are there any limitations in connecting them, e.g. from the control system network. Are there some system users, and are they authenticated like human users or with certificates.

How the data shall be protected. Divide the users to groups by roles and define what rights (create, read, update, delete) they should have to various types of data. Remember to get proper certificates to secure data transfers and user access.

Learn more about the security Security .

System monitoring

Someone is responsible for keeping the system up and running and ensuring that the system meets the possible availability and service level targets. Here you need to design how to monitor the system performance, resource consumption, data flows from devices up to the users, and of course the cyber security. Plan whether you want to monitor each node separately or collect of the monitoring data to central place and implement easy to use dashboards for the monitoring.

ABB Ability™ History provides lots of preconfigured functionalities for system monitoring, but they are useless unless you use them.

Learn more about system monitoring in Engineering UI.

Securing your application configurations

By default ABB Ability™ History is configured to take daily online backups that typically contain also the application configurations, especially when the calculations and visualizations are stored in the database. It is good practice to ensure how the restoring would work in case of system failure. Another aspect is the version control of the application configurations and storing them regularly in some version management system for reuse and protecting the application against possible mistakes in later developments.

Learn more on Database administration.

Keep your system updated

To get all the newest fixes and cyber security updates to your system, follow the new versions of ABB Ability™ History and upgrade your system as soon as it is possible. If your system is in mission critical role, it is recommended to have separate development system that is as close copy of the production system as possible and upgrade it first to verify that all application functionalities work before upgrading the production system.