Moving a Legacy System Over to Ignition

Problem

The client is Continental Cement, a continuous-process cement plant located in Hannibal, Missouri. The project involved porting a Citect SCADA platform project based on TOP Server as the OPC server. The Citect system is a legacy system with various iterations enhanced over time by various parties. Each party had their own methodology, naming conventions, and standards for graphic objects. The goal of the port was to move the entire legacy system to Ignition, and, as part of the process, normalize the tag tree and naming conventions with uniform HMI navigation behavior. As there was no overall documentation for the legacy system, the port consisted of reverse-engineering the entire Citect system. Due to this, for functional validation to be effective, the ‘new’ Ignition windows had to contain graphics objects with a look, window placement, and behavior equivalent to the Citect system.

It became clear at the outset that the ability to normalize the Ignition tag tree into hierarchical groupings of Equipment Type and Component type was required to drive and validate the port. The Citect tag system consists of approximately 25,000 tags referencing the TOP Server OPC server. Due to the volume of tags, coupled with the tag organization requirement, using the Ignition tag-by-tag/drag-and-drop method from the TOP Server was not feasible. Additionally, the Citect original tag name had to be maintained somewhere for reference to reverse-engineer the HMI port. A second problem surfaced in regard to the functional test validation process; a method was required to expose the Ignition tags inside the new Ignition HMI screens. This would allow validation that the correct equipment type was referenced from the calling object and appropriate tag attributes were set in the tag.
 

Solution

Citect is extremely limited in its ability to reliably export system internals, but does have a tag file available known as ‘variable.dbf.’ This file contains the Citect tag name, engineering unit data, documentation, and a path reference to TOP Server. The file is available to be copied and used externally from Citect.

TOP Server also has an export feature available for its tag structure consisting of approximately the same attributes as Citect.Ignition has the ability to import tags. Additionally, the IA Script Module has the functionality to browse, create, and edit tags programmatically.

An analysis was performed on the data relationships of the available export formats resulting in a scheme where the Citect and TOP Server data could be placed in SQL tables. An appropriate joining scheme was then applied and used to create required associations, and at the same time, maintain the Citect Tag Name reference for the HMI aspect. Once the tables were loaded, Overbridge created an application using native Ignition script to present, filter, manage, and create logical equipment groups of the joined tag data. Using a row selection function, coupled with the ability to group selected rows into an output folder or UDT, tag creation in Ignition was accomplished programmatically. The Overbridge user entered criteria to create a logical piece of equipment, name it, and then either export as XML, export as CSV, or perform a direct write into the Ignition tag tree of the tag group. As part of the process, an auto document feature was developed to create an equipment tag creation document. The result was the creation of the Ignition tag without touching the OPC portion of the Designer. In fact, the Designer was rarely used in the creation of the tags.

Prior to laying out the Ignition windows, all Citect objects were analyzed. This method allowed us to come up with a common set of templates. Once templates and/or direct objects were placed on the Ignition window, they were referenced to the tag tree. Due to the scheme used in the tag tree, an Equipment Type folder or UDT reference allowed access to all of its underlying components and tags. Using the IA Scripting Module, an app function was developed exposing all of the tags available in context of the equipment type of an object in the active window. This allowed validation of the equipment assignment to an object, and, additionally, allowed editing of attributes for the tag without the requirement of going to the Designer to accomplish same.
 

Result

As a result of the solutions developed by Overbridge in Ignition, the Ignition tag was created without touching the OPC portion of the Designer. Also, tag assignment to a window object can be validated ‘in context’ with direct editing of tag attributes. This eliminates the requirement of going to the Designer to do so.