# 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.

- Canonical URL: https://wiki.aspotomasyon.com/article/advanced-kepware-alarms-history-redundancy
- Publisher: ASP OTOMASYON A.Ş. (ASP OTOMASYON Wiki)
- Category: OPC Solutions
- Published: 2026-05-13 · Updated: 2026-09-13
- Reading time: 8 min · Language: English

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.

![A conceptual OPC UA client/server path. Application certificates establish application trust; user authorization controls what a connected user may do.](https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-context.svg)

*A conceptual OPC UA client/server path. Application certificates establish application trust; user authorization controls what a connected user may do.*

## 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

| Alarm Type | Trigger Condition | Typical Use |
| --- | --- | --- |
| Level Alarm | Tag value crosses a defined threshold | High temperature, low pressure |
| Deviation Alarm | Tag deviates from a setpoint by a defined amount | Process variable vs. setpoint monitoring |
| Rate-of-Change Alarm | Tag changes faster than a defined rate | Sudden pressure drop detection |
| Quality Alarm | Tag quality changes (Good → Bad/Uncertain) | Communication loss, device fault |
| Digital Alarm | Boolean tag changes to a specific state | Motor start/stop, valve open/closed |

### 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     |
                    |  (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:       operator@company.com.tr
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](https://www.ptc.com/en/products/kepware/kepserverex) — 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](https://www.ptc.com/en/products/kepware) — Official documentation for RedundancyMaster, covering active/standby failover, health check configuration, and synchronisation settings.
3. [PTC Kepware Technical Support — Knowledge Base](https://www.ptc.com/en/support/help/kepware) — Official Kepware support portal with technical articles on high-tag-count optimisation, performance tuning, and troubleshooting advanced configurations.
4. [Lua 5.4 Reference Manual](https://www.lua.org/manual/5.4/) — 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](https://reference.opcfoundation.org/v104/Core/docs/Part3/) — Official OPC UA specification for the Alarms and Conditions (A&C) address space model consumed by KEPServerEX alarm configurations.

## Apply this to your project

- Record the endpoint, supported security policies, application identity, certificate expiry, and user permissions.
- Verify the value, engineering unit, StatusCode, and source timestamp together at the receiving application.
- Test disconnection and recovery with representative subscriptions; preserve evidence of any data gaps or repeated values.

[Follow an ASP project guide](https://wiki.aspotomasyon.com/guides) to connect the fundamentals with implementation and acceptance.

![Engineering review sequence: Discover → Authenticate → Subscribe → Recover. Keep the recorded evidence with the accepted configuration.](https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-review.svg)

*Engineering review sequence: Discover → Authenticate → Subscribe → Recover. Keep the recorded evidence with the accepted configuration.*

## Primary references and further reading

Use the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.

- [OPC Foundation — OPC UA Part 4: Services](https://reference.opcfoundation.org/specs/OPC-10000-4/)
- [OPC Foundation — OPC UA Part 2: Security Model](https://reference.opcfoundation.org/specs/OPC-10000-2/)

---

Cite the canonical article: https://wiki.aspotomasyon.com/article/advanced-kepware-alarms-history-redundancy (Advanced Kepware: Alarms, Historical Data, and Redundancy, ASP OTOMASYON, updated 2026-09-13).