The Alarming Upgrade Process Explained

Starting in version 11, AlarmWorX64™ Server and AlarmWorX64 Logger are obsolete and they have been replaced with the new Alarm Server and Alarm Historian. The main goal for Alarm Server and Alarm Historian is to overcome the limitations of the existing alarm services. To move from the previous alarm applications to the new ones, the Data Migration Utility includes new plugins to convert the server and logger configurations, logged data, and displays. It also allows you to update configurations of other applications to use new subscriptions and alarm tags from the new alarm services.

Conversion of Configurations

First, you need to convert existing logger and server configurations, which both have their own plugin in the Data Migration Utility. You can either convert the configurations to new databases or use existing databases. Converting always creates a new CwxImporter Converted project in Workbench. You can reuse this project or change the active databases in your existing project in Workbench. The conversion of the legacy logger creates a Point Map File that includes mapping the old columns and subscription to the new ones. The utility will reuse this file when importing historical data. For reference, it is the same approach as for TrendWorX64™ Logger to Historian.

Important: You must upgrade the databases to the latest version before running the Data Migration Utility. This tool will not upgrade the databases before converting.

AlarmWorX64 Server to Alarm Server Configuration

It converts the configuration of the legacy server to the Alarm Server. In the new Alarm Server design, the alarm type is an essential part of alarm configuration. The conversion creates the alarm types from templates if they exist or from basic types such as Digital or LoLo. Each alarm source must have an alarm type assigned. The conversion creates alarm sources directly in the proper area where associated area tag exists. If an alarm is in multiple areas in AlarmWorX64 Server, the utility creates the additional areas as alarm links to the first instance of the alarm.

AlarmWorX64 Logger to Alarm Historian Configuration

It converts the configuration of the AlarmWorX64 Logger to the Alarm Historian. The conversion process converts the existing configurations into the following objects:

Logger—There is a logger object with converted properties for each configuration.
Collection—There is a collection object associated with a logger for each configuration.

There is a list of columns from each configuration. The Data Migration Utility compares these to the Alarm Historian common fields and adds any additional columns as needed. For each collection, it also converts all nested subscriptions from the legacy subscriptions. For example, there is a following syntax for the Alarm Server:

Path Usage	AlarmWorX64 Server Path	Alarm Server Path
Entire alarm server	@ICONICS.AlarmSvr.1.Server	ae:
Specific area	@ICONICS.AlarmSvr.1\Area1\Area2.Area	ae:/Area1/Area2
Alarm in root of alarm server	@ICONICS.AlarmSvr.1\Alarm1.Source	ae:.Alarm1
Alarm in subarea	@ICONICS.AlarmSvr.1\Alarm1.Source	ae:/Area1/Area2.Alarm1

For the legacy Alarm Server, the alarm in a subarea has the same syntax as the one in the root. That is the effect of the flat list of source tags in the AlarmWorX64 Server. Area tags referenced other tags to place the alarms in the correct areas. However, this negatively impacted the AlarmWorX64 Server performance. Converting subscriptions to sources is possible but requires a specification of an active Alarm Server configuration database.

Conversion of Logged Data and Displays

The Alarm Historian logs alarms and events into separate storage files while maintaining a persistent index of those files. Each logger object in the Alarm Historian typically has an assigned folder on the disk drive where it creates its own series of storage files. After having configurations properly converted, you can also import logged data from AlarmWorX64 Logger. There is a plugin called AlarmWorX64 Logger to Alarm Historian Data Conversion. You use the mapping file from the configuration import as an input for this plugin. Then you specify the database to store the alarms. The Data Migration Utility reads the data logged by AlarmWorX64 Logger from the SQL Server. You may also need to set other settings like:

Time range—The start and end time representing the interval of data read.
Batch size—The amount of data to be converted in one cycle.
Converted configuration—Which AlarmWorX64 Logger configuration should the utility import if there are multiple configurations in the database.

The mapping file conversion translates the logged data in your old database to the new Alarm Historian format. The utility imports the data in batches based on the selected configurations and the specified time ranges (specified by the size).

The utility creates SQLite storage files with the file extension .almd. The Alarm Historian also maintains a persistent index of the storage files. There is one index file per logger object, and it contains the list of storage files from which the Alarm Historian retrieves data. You can view and edit them in the Alarm Historian provider in Workbench.

To access it, navigate to: Your project > Alarms and Notifications > Alarm Historian > Product Configuration > Archiving Management.

The same plugin allows you to update displays. You just need to set the folder where you want the displays update. The Data Migration Utility updates the subscriptions in the same way as described in the Alarm Historian configuration conversion. It converts legacy alarms and events subscriptions into the new syntax. There is an exception for the sources because the Alarm Server database describing the sources conversions is not available.

The plugin updates existing files, so make sure you create a backup of your original files before running this process.

Updating other configurations

The Data Migration Utility can also update providers that use the existing AlarmWorX64 Server path to receive alarms. The AlarmWorX64 Server to Alarm Server Configuration Plugin can convert the subscription or alarm points to the new Alarm Server syntax. For this update, it may be necessary to also provide the connection to the old and converted Alarm Server databases. To ensure the best conversion results, you should run this before making any changes to the converted database, as the utility may not be able to associate the alarm paths as expected.

The paths to the alarm points and subscriptions in the Project Explorer in Workbench:

Assets: Product configuration > Alarms & Events Settings > General settings and Alarm & Events sources
Alert Notifications: Email Nodes and SMS/Text Nodes > Alarms Subscription
Bridging: Transactions > Configuration > Transaction > Alarm Subscriptions
Connected Field Service: Worker User > Alarms and Workflows > Alarm Configuration > Alarm Subscriptions
Internet of Things: Publish List > Published Alarms
Reports: Configuration > Report Execution > Tag
Triggers: Alarm Trigger > Alarm Subscriptions

Conversion Troubleshooting

The conversion process should give enough information to successfully convert all parts. For important problems, there are always details that you can expand and get more information on what went wrong. The Alarm Server exposes two basic areas of information – Performance counters and Trace messages. Performance counters can be monitored in standard Microsoft Windows tools and give information about a server performance (process dynamics), such as the number of processed input/output events. Trace messages allow to monitor processing logic and eventual error states. You can find the performance counters for the Alarm Server in the section named ICONICS Alarm Server (Performance Monitor tool - Windows).

Point tracing settings allow you to enable traces for specific input and output data points. Each data point then traces all messages related to the point subscriptions—subscribe, release, point properties, and data updates. You can find them in both providers under System Settings.

Enable—Enables/disables point tracing for all point traces.
Input Point Names—Enables input data point updates, such as updates that are coming from the FrameWorX™ infrastructure. The data point names are the same as in the FrameWorX Server and must be separated by a semicolon.
Output Point Names—Enables output point tracing. The point names are the same as in the GENESIS data point browser, including the point manager prefix. The names must be separated by a semicolon. This feature enables tracing of all the traffic between the Alarm Server and its clients. That includes requests, responses, data updates, event updates, an so on.
Trace Level—The level of generated trace messages. Setting higher levels allows to filter out other generic messages out of the trace log.