Advanced Kepware: Alarms, Historical Data, and Redundancy

KEPServerEX from PTC/Kepware is the most widely deployed OPC server in industrial automation, and most users only scratch the surface of its capabilities. Beyond basic tag reading and writing, KEPServerEX offers a mature alarm and event subsystem, database logging via ODBC/SQL, and a full redundancy solution through RedundancyMaster. This article goes deep into these advanced features, providing configuration guidance, best practices, and performance optimisation techniques for Turkish and regional industrial users.

Alarm and Event Configuration

KEPServerEX can generate alarms based on tag conditions — value thresholds, quality changes, or communication status shifts. Alarms appear in the OPC AE (Alarms & Events) address space and can be consumed by any OPC AE-compliant client.

Alarm Types

Configuring Alarms in KEPServerEX

1. Right-click the tag in the project tree and select Alarms & Events → Configure Alarm.
2. Select the alarm type (e.g., Level Alarm).
3. Set the threshold values:
   • High High Limit (HH) — Critical high, triggers most severe alarm.
   • High Limit (H) — Warning high.
   • Low Limit (L) — Warning low.
   • Low Low Limit (LL) — Critical low.
4. Configure deadband to prevent alarm chatter (e.g., 2% of range).
5. Set the severity (1–1000, where 1000 is most critical).
6. Define the alarm message template:

   Alarm: {TagName} exceeded {LimitType} limit.
   Current value: {Value} at {Timestamp}

7. Optionally enable alarm acknowledgement — operators must acknowledge the alarm in the client.

Alarm Groups and Areas

Organise alarms by area for better management:

• Create area nodes under the Alarms & Events tree: Plant1.ReactorArea, Plant1.PackagingArea.
• Assign alarms to areas for filtering in the OPC AE client.
• Enable area-level alarming to suppress all alarms in an area during maintenance mode.

Database Logging (ODBC/SQL)

KEPServerEX can log tag data, alarms, and events to any ODBC-compliant database. This is the primary mechanism for building a process historian without a separate historian product.

Supported Database Targets

• Microsoft SQL Server (2016+), SQL Server Express
• PostgreSQL 12+ (via ODBC driver)
• MySQL / MariaDB 10.3+
• SQLite (for lightweight, local logging)
• Oracle Database (12c+)

ODBC Data Source Configuration

1. Install the appropriate ODBC driver on the KEPServerEX machine.
2. Open ODBC Data Source Administrator (64-bit).
3. Create a System DSN:
   • Name: KepwareHistorian
   • Server: 192.168.1.50 (database server IP)
   • Database: PlantHistorian
   • Authentication: SQL Server Authentication or Windows Integrated
4. Test the connection — verify DSN is accessible from the KEPServerEX service account.

Data Logging Configuration

1. In KEPServerEX, navigate to Logging → Data Logging.
2. Click New Log Group — give it a name, e.g., PLC01_TagGroup.
3. Select the ODBC DSN (KepwareHistorian).
4. Configure logging interval:
   • Periodic — Logs every N seconds (e.g., 10 s for level data, 60 s for temperature).
   • On Change — Logs only when the value changes by a defined deadband (reduces storage).
   • On Event — Logs triggered by an alarm or system event.
5. Select the tags to log. Use tag groups or wildcards for efficiency.
6. Define the table name template: TagLog_{GroupName}_{YYYYMM} for automatic monthly partitioning.
7. Click Enable to start logging.

Table Schema Created by Kepware

CREATE TABLE TagLog_Default (
    DateTime      DATETIME NOT NULL,
    TagName       NVARCHAR(256) NOT NULL,
    Value         FLOAT NULL,
    Quality       NVARCHAR(50) NULL,
    QualityCode   INT NULL,
    Timestamp     DATETIME NULL,   -- source timestamp
    CONSTRAINT PK_TagLog PRIMARY KEY (DateTime, TagName)
);

Best Practices for Database Logging

• Partition tables by month or week to keep index rebuild times manageable.
• Use On-Change logging with a 1–2% deadband for analog values — this typically reduces storage by 60–80% compared to periodic logging.
• Separate logging groups for fast-changing tags (e.g., vibration data at 100 ms) and slow-changing tags (e.g., tank level at 60 s).
• Monitor database disk space — a medium-sized plant with 5000 tags logging every 10 seconds generates approximately 2–3 GB per month.
• Set a retention policy — archive and purge data older than 12–24 months from the operational database.

RedundancyMaster Setup

RedundancyMaster is a separate Kepware product that provides automatic failover between two KEPServerEX instances. It is essential for applications where OPC data availability is critical (e.g., pipeline monitoring, emergency shutdown systems).

Architecture

                    +-----------------------+
                    |  RedundancyMaster     |
                    |  (watchdog service)   |
                    +-----------+-----------+
                                |
          +---------------------+---------------------+
          |                                           |
+---------v----------+                     +---------v----------+
| KEPServerEX        |                     | KEPServerEX        |
| Primary Server     |<--- OPC UA/DA ----->| Secondary Server   |
| (Active)           |    sync             | (Standby)          |
+--------------------+                     +--------------------+
          |                                           |
          +-------------------+-----------------------+
                              |
                    +---------v----------+
                    | OPC Client(s)      |
                    | (HMI, SCADA, etc.) |
                    +--------------------+

Configuration Steps

1. Install KEPServerEX on both the primary and secondary servers. Configure identical channels, devices, and tags on both.
2. Install RedundancyMaster on a third machine (or on the primary server).
3. Launch RedundancyMaster Administration.
4. Add the primary server:
   • Server name: PRIMARY_KEP
   • OPC UA endpoint: opc.tcp://192.168.1.10:49320
   • Admin endpoint: http://192.168.1.10:57412
5. Add the secondary server with the same configuration (different IP: 192.168.1.11).
6. Configure the health check interval — default 5 seconds. Adjust to 2 seconds for critical processes.
7. Set the failover threshold — number of consecutive health check failures before switching. Default: 3 (15 seconds total).
8. Select synchronisation options:
   • Tag data sync — Replicates runtime tag values from primary to secondary.
   • Configuration sync — Replicates project configuration (channels, devices, tags).
   • Alarm state sync — Replicates active alarm states and acknowledgements.
9. Configure the virtual OPC UA endpoint that clients will use:

   opc.tcp://redundancy-cluster:49320

10. Start the RedundancyMaster service. Verify status shows Primary Active and Secondary Standby.

Failover Scenarios

Scenario	Behaviour	Impact on Clients
Primary server crash	RM detects missing health check, promotes secondary within 15 s	Brief data gap (15–30 s total)
Network link failure	Same as crash — secondary takes over	Data gap, alarms may re-arm on recovery
Planned maintenance	Manual switchover via RM console — zero data loss	Transparent to clients
Primary recovers	RM detects recovery, re-syncs data, does NOT auto-fail-back	No impact (manual failback)
Both servers fail	RM marks both as unavailable; all subscriptions invalidated	Full data loss until at least one recovers

Event-Triggered Actions

KEPServerEX can execute event-triggered actions in response to alarms, tag changes, or system events. These are configured per alarm or tag.

Available Actions

• Write to tag — Set a tag value (e.g., acknowledge alarm, reset counter).
• Run external program — Execute an .exe or script file on the KEPServerEX machine.
• Send email — Via SMTP (requires SMTP server configuration in KEPServerEX).
• Log to file — Append a line to a CSV or text file.
• Send SNMP trap — For integration with network management systems (Nagios, PRTG, Zabbix).
• Execute SQL query — Write directly to a database table.

Example: Email Notification on High Temperature

Event:    Alarm "Reactor_Temp" enters Active state
Trigger:  Tag value >= HH_Limit (150.0 °C)
Action:   Send Email
To:       [email protected]
Subject:  [CRITICAL] Reactor Temperature Alarm
Body:     Reactor temperature has reached {Value} °C at {Timestamp}.
          Please acknowledge immediately.

Scripting in Kepware (Lua)

Kepware includes a Lua scripting engine for custom logic that runs inside KEPServerEX. Lua scripts have access to the internal tag database and can read/write tags, send emails, log data, and execute HTTP requests.

Enabling Lua Scripting

1. In KEPServerEX, navigate to Tools → Lua Script.
2. Create a new script or import an existing .lua file.
3. Enable the script and set its execution trigger:
   • On Startup — Runs once when KEPServerEX starts.
   • Periodic — Runs at a defined interval (e.g., every 5 seconds).
   • On Tag Change — Triggered when a specific tag changes.
   • On Event — Triggered by an alarm or system event.

Example: Write Calculation Result to Tag

-- Lua script: Calculate efficiency and write to output tag
local rawFlow = kepware.readTag("Flow_RAW")
local rawTemp = kepware.readTag("Temp_RAW")
local rawPress = kepware.readTag("Pressure_RAW")

-- Correct flow for temperature and pressure
local correctedFlow = rawFlow *
    math.sqrt((273.15 + 20.0) / (273.15 + rawTemp)) *
    (rawPress / 1013.25)

kepware.writeTag("Flow_Corrected", correctedFlow)
kepware.logMessage("Corrected flow calculated: " .. correctedFlow)

Performance Optimisation for High Tag Counts

When managing 10,000+ tags, KEPServerEX performance depends heavily on configuration. Apply these optimisations:

Optimisation	Configuration	Typical Gain
Disable unused channels	Set scan rate to 0 for channels not in active use	Frees CPU cycles from polling
Use tag groups	Group related tags; avoid individual tag polling	Reduces OPC subscription overhead
Adjust scan rates	Slow tags (tank levels): 5000 ms. Fast tags (vibration): 100 ms	Balances CPU vs. responsiveness
Enable auto-demotion	Automatically reduces polling frequency for unresponsive devices	Prevents bus bandwidth waste
Use OPC UA subscriptions	Prefer OPC UA subscriptions over DA groups for large tag sets	Subscription sampling is more efficient than polling
Increase MaxTagsPerRequest	Set to protocol maximum (e.g., Modbus: 125)	More data per read, fewer transactions
Disable unused alarms	Remove alarm configuration from tags that don't need it	Reduces AE processing overhead
Separate logging threads	Assign different ODBC DSNs to different log groups for parallel writes	Prevents DB write queue blocking

Key takeaway: KEPServerEX is far more than a tag server. Its alarm engine, ODBC historian, RedundancyMaster failover, and Lua scripting capabilities make it a central nervous system for industrial data. Invest time in configuring these features properly — a well-tuned Kepware deployment runs for years without intervention.

---

References & Further Reading

1. PTC Kepware KEPServerEX — Advanced Features Documentation — Official product documentation for alarm and event configuration, ODBC data logging, redundancy setup, and Lua scripting in KEPServerEX.
2. PTC Kepware RedundancyMaster — High Availability Configuration — Official documentation for RedundancyMaster, covering active/standby failover, health check configuration, and synchronisation settings.
3. PTC Kepware Technical Support — Knowledge Base — Official Kepware support portal with technical articles on high-tag-count optimisation, performance tuning, and troubleshooting advanced configurations.
4. Lua 5.4 Reference Manual — Official Lua programming language reference used for KEPServerEX scripting, covering the language syntax, standard libraries, and embedding API.
5. OPC UA Part 3: Address Space Model — Alarms and Conditions — Official OPC UA specification for the Alarms and Conditions (A&C) address space model consumed by KEPServerEX alarm configurations.