Wonderware Galaxy Alarm Query Syntax: Top-Level Area Setup

1. Overview: Galaxy Alarm Query Architecture

The Galaxy in AVEVA (formerly Wonderware) System Platform is the logical container that aggregates every Area, Platform, WinPlatform, and derived attribute instance deployed from the Galaxy Repository via the IDE (IDE — Integrated Development Environment, the System Platform configuration toolset) to one or more Alarm Providers on a GR node (Galaxy Repository node). Alarm consumers — the Standard Alarm Client, the Alarm Hot Backup Manager, OMI (Operations Management Interface) Alarm widgets, InTouch, and third-party OPC A&E (Alarm & Events) subscribers — issue queries to an alarm provider using a hierarchical path. The query path follows the deployed Model View hierarchy exactly as it appears in the IDE's Model tab (not the Deployment tab).

When the path resolves to a real, deployed Area, the provider returns every alarm whose source attribute is an instance under that Area (including all nested sub-Areas). When the path does not resolve — because the segment is not a deployed Area, the area is empty, or the area is collapsed/expanded incorrectly in Model view — the query returns an empty result set, not an error. This silent-empty behavior is the most common root cause of "the query works for one area but not the galaxy" reports.

Official syntax and behavior is documented in the AVEVA System Platform Alarm Queries reference:

• AVEVA Documentation — Alarm queries

2. Query Syntax Reference

The alarm query syntax accepted by the Alarm Provider service follows a path-resolution model. Each component is a deployed Model View element name, case-sensitive, with the provider's logical name as the root.

The provider name is the logical name assigned to the AlarmProvider object in the IDE, not the Windows computer name. When the client connects to the local node and a single AlarmProvider named Galaxy is configured, the ProviderName\ prefix is optional. When the client must reach an AlarmProvider on a remote GR node, the ProviderName\ prefix is mandatory.

3. Why \galaxy Alone Returns No Alarms

The string \galaxy is interpreted by the alarm client as a path with a single segment: the provider itself. The provider is not a queryable container — only Areas, Platforms, and derived-attribute instances are. To return alarms, the query must traverse at least one segment below the provider that corresponds to a deployed Model View element.

For galaxy-wide visibility the path must resolve to a real Area that contains every other Area in the deployment as descendants. That container is the Top-Level Area. Without it, there is no single path that returns the entire deployed alarm set.

4. Prerequisites

Before any galaxy-wide query can return results, the deployment must satisfy the following conditions:

1. IDE installed on an engineering workstation with a Galaxy Repository connection (SQL Server-backed) and write privileges to the repository database.
2. System Platform 2014 R2 or later is recommended; earlier versions (2012, 2012 R2) use the same query grammar but may require manual Hot Backup Manager registration. Verify your version under Help > About in the IDE.
3. AlarmProvider service installed and running on every GR node. Confirm with sc query "ArchestrA Alarm Provider" on the GR node, or check the SMC (System Management Console) > ArchestrA Services.
4. Model View populated in the IDE with at least one Area. Areas are created in the Model tab, not the Deployment tab.
5. At least one deployed instance with an alarm-enabled attribute (a $Alarm derived attribute or a template attribute with the Generate Alarm option selected).
6. Client connectivity: the Alarm Client (Standard Alarm Client, OMI Alarm widget, or InTouch AlarmView) must be configured with the same ProviderName and remote-node prefix rules.

5. Configuring the Top-Level Area in Model View

The Top-Level Area is a single Area object that contains every other Area in the galaxy as descendants. It is the only construct that makes a single, stable path capable of returning every alarm in the deployment.

1. Open the IDE and connect to the Galaxy Repository.
2. Select Model in the View dropdown (not Deployment — Deployment does not show Area hierarchy).
3. Right-click the Areas node and choose New Area. Name it descriptively, for example Plant, Utility, or TopArea. The name becomes the first resolvable segment after \galaxy!.
4. Drag and drop every existing top-level Area (e.g., Area001, Area002, Area003, TestArea, TestArea2) onto the new Top-Level Area. The IDE updates the Containment reference on each child.
5. If the Areas are already deployed, redeploy them so the containment reference is propagated to the Alarm Provider. Right-click each Area > Deploy. Verify the deployment status indicator turns green.
6. From the Alarm Client, issue the query: \Galaxy!TopArea. The provider resolves the path and returns every alarm whose source instance is contained (directly or transitively) under TopArea.

6. Remote Node Alarm Provider Syntax

When the Alarm Client runs on a node that is not the Alarm Provider's host, the ProviderName\ prefix is mandatory. The provider name is the logical ComputerName or a DNS alias registered in the Galaxy > ComputerNames container — never the Windows NETBIOS name unless they are explicitly aliased.

Syntax:

Where:

• ProviderName — the logical name of the remote Alarm Provider as registered in the Galaxy.
• Galaxy — the literal provider root. On remote nodes this is not optional, even if the local node has a single provider also called Galaxy.
• !AreaName — the deployed Area, exactly as named in Model view.

For a galaxy named Utility hosted on a remote provider named AlarmNode01, the correct galaxy-wide query is:

Common remote-node failures and their causes:

7. Hot Backup and Primary/Backup Provider Behavior

When a galaxy is configured with Hot Backup via the Hot Backup Manager, the Alarm Client can subscribe to either the primary or the backup provider. The \galaxy! path, as documented in the AVEVA alarm reference, returns alarms from whichever provider is currently active — the AVEVA documentation states the query "Shows all alarms from primary or backup alarm provider as configured in the Hot Backup Manager."

This behavior is intentional: a successful query that returns an empty set when the primary is healthy almost always means a Model View containment issue, not a Hot Backup issue. A successful query that returns an empty set only during failover indicates that the backup provider's deployed Areas differ from the primary's — verify by running aaDeployCheck on both nodes.

8. Standard Alarm Client Configuration for Galaxy-Wide Display

To bind the Standard Alarm Client (or OMI Alarm widget) to a galaxy-wide query so the banner shows every alarm in the deployment:

1. Open the Alarm Client configuration (SMC > Alarm Client or the OMI Alarm widget's Properties panel).
2. Locate the Filter / Query String field.
3. Enter the Top-Level Area path, for example \Galaxy!TopArea. For a remote provider, use \\AlarmNode01\Galaxy!TopArea.
4. Set the filter mode to Server Filter (preferred for large alarm sets) rather than Client Filter. Server-side filtering reduces the OPC A&E event stream and improves client responsiveness.
5. Set Priority to include the full range 1–999 to avoid silent exclusion.
6. Enable Hold and Shelved filter inclusion if the operational requirement is total visibility, or disable for unacknowledged-active only.
7. Click Apply and verify the alarm count equals the total expected from the Alarm Summary report.

9. Common Query Failures and Root Causes

10. Step-by-Step: Building a Queryable Galaxy

This procedure converts a flat Model View (no Top-Level Area) into a hierarchical view that supports galaxy-wide queries.

1. Audit the existing Model View. In the IDE, open the Model tab and list every Area currently present. Record each Area's Name, Description, and current parent.
2. Design the hierarchy. Decide on a single naming convention. A common pattern: Company > Site > Area > SubArea. The top of the pattern is the Top-Level Area.
3. Create the Top-Level Area. In the Model tab, right-click Areas > New Area. Name it to match the chosen convention's root (for example, Plant). Set the Description field for documentation.
4. Re-parent the existing Areas. Drag each existing top-level Area onto the new Top-Level Area. The containment reference updates in the IDE; deployment is still required.
5. Resolve redeployment conflicts. If any Area is already deployed, mark it For Delete in the Deployment tab, redeploy to remove it, then redeploy under the new parent. Skipping this step leaves the Alarm Provider with two disjoint containments and queries against the new parent return nothing.
6. Deploy the Top-Level Area. Right-click Plant > Deploy. Verify the deployment indicator turns green and the Alarm Provider log records the new area.
7. Deploy child Areas. Redeploy each child Area to propagate the new containment. Bulk-select and deploy to reduce time.
8. Test with the Standard Alarm Client. Issue \Galaxy!Plant against the local provider. Confirm the returned alarm count matches the sum of all child Areas.
9. Test with the OMI Alarm widget. Bind a banner widget to \Galaxy!Plant with server-side filter mode. Confirm a low-priority test alarm appears within 2 s of trigger.
10. Document the Top-Level Area in the project README so future engineers do not flatten the hierarchy.

11. Verification Checklist

Use this checklist to confirm the galaxy-wide query is operating correctly:

• Model view shows a single Top-Level Area containing every other Area.
• Deployment status of Top-Level Area is Deployed (green indicator) on every GR node.
• Deployment status of every child Area is Deployed and shows the correct parent in the Containment field.
• Alarm Provider service is Running on every node that hosts deployed Areas.
• \Galaxy!TopArea from the local Alarm Client returns the expected alarm count.
• \\<ProviderName>\Galaxy!TopArea from a remote Alarm Client returns the expected count.
• Hot Backup Manager reports both primary and backup providers in In Sync state.
• User account used by the client has ArchestrA Alarm Read privilege.
• No firewall rules are blocking UDP 5425 or TCP 5427 between client and provider.

12. Best Practices for Galaxy Model View Design

• One Top-Level Area per galaxy. Multiple competing top-level areas fragment the alarm namespace and produce ambiguous queries.
• Use containment, not naming, to express hierarchy. Embedding SiteA_Line1_Unit2 in a flat name is not a substitute for proper containment. Containment is what the Alarm Provider indexes.
• Match the Model hierarchy to the operational hierarchy. Operators think in plant > line > unit terms; the query paths should mirror that mental model.
• Plan for one Area per alarm query. The AVEVA best-practice rule is that every distinct alarm query the application issues should map to a distinct Area path. Designing Areas around queries — not around physical layout alone — simplifies both client configuration and access control.
• Document area-to-query mapping in the project repository (typically the Docs/AlarmMap.md file) so support engineers can resolve "empty query" tickets without re-deriving the hierarchy.
• Redeploy after any Model view change. Containment references are not live; the Alarm Provider only learns about them during deployment.

Frequently Asked Questions