Handling Equipment Model Lifecycle as Part of a Packaged Application
Introduction
Equipment models are essential part of a package application, because they contextualize the data and enable generic application logic from installation to another one. Typical application is evolving over time and this means that also the equipment models are evolving. Details of some properties may change, new properties introduced, and sometimes some properties become obsolete. It is important to have a clear understanding how these changes will affect existing equipment instances when the application is upgraded with a new version. This document tries to give guidance for handling the equipment model lifecycle.
Here are some things that shall be considered:
Do we have a need to customize the equipment model in a customer installation?
If we need to customize, could it be so that the actual package application provides the base model that is then inherited by the models at the customer installation. When a new version of the application is introduced, it may affect to the base model, but all the customizations and customized instances are not affected otherwise than perhaps with the extended functionalities coming from the base model.
All the changes start from thinking how the application upgrade is enabled.
Do the changes with a script that is part of the application installation. New properties can be introduced and some details of existing modified, but deletion of properties may not be good for the existing installations. If some property is not anymore needed, it can be documented to be obsolete, but let it stay there to provide backward compatibility.
How are the equipment models handled in hierarchical systems?
Many customer systems are consisted from multiple ABB Ability™ History nodes where data is transferred between the nodes. It is important to understand what happens for the equipment models and instances in the application upgrade. Netsync may create the equipment model and then instances, but it doesn’t update the model in the target node, if the model in the source is changed. This may lead to situation where there are instances with properties that do not exist in the model. Good practice is to upgrade the models in all the nodes where instances may exist even though the application itself is not running in the node. This means that there should be a standalone installation/upgrade script for the models in addition to the full application installation package.
How do the calculation work in upgrade, if there are instances created with old model?
When upgrading application to an existing installation, and if the new equipment model introduces new properties that are used in the calculations, it shall be taken into account in the calculation code that some existing instances may not have yet the new properties. Similar problem may exist also with dashboards.
Once you have fully considered the points above, we can now move on to the automated equipment model lifecycle mechanism.
The component installer and RTDB Service Manager work together to automate the lifecycle management of Equipment Model component, including installation, upgrade, uninstallation, and version control . The process operates in two coordinated phases: the installer prepares the component package, and the Service Manager automatically applies all lifecycle actions on that package.
Phase One Component Installer
For Your Reference: Integrating SQL Database Seeding Into the Automated Workflow
Updated about 2 months ago