How history is recorded
YTCC keeps the history of signals and events in a history database of its own for each project, on the same database server as the configuration. Trends, the event list, exports and the alarm history read from it. Recording runs on the server, whether or not a screen is open.
What is recorded
A signal is recorded only if it is assigned to an archive table. A project starts with two tables:
| Table | Holds | Recorded | Kept |
|---|---|---|---|
hist_values | Measured values: value, quality, arrival time, time source | On change | 365 days |
hist_events | Events: state changes of on/off and enumerated signals, alarms, commands, system and operator events | Every change | 1825 days (5 years) |
You can add tables, for example one that records energy counters every minute for ten years. An assignment can be made for a whole signal type, so every instance of the type is recorded, or for a single signal, which can also exclude a signal from its type's table. A signal may be in several tables. Text signals are not recorded in value tables; on/off values are stored as 0 and 1. See Archive tables and assignments.
On change or periodic
| Mode | Records |
|---|---|
| On change | The first value, then every change larger than the deadband (an absolute value or a percentage of the signal's range). A change of quality or of the value source (automatic, manual, simulated) is always recorded. Min interval (ms) holds back changes that come faster; Max interval (s) repeats an unchanged value, so that a trend shows the signal is alive. |
| Periodic | The current value every Cycle (s), whether it changed or not. Suitable for counters and reports. |
The writer collects values and writes them in groups (1000 rows or every half second, whichever comes first). The history of a day is kept as one part, so old days can be removed without touching the rest.
Time of a value
Each recorded value has two times: the device time if the device sends one (for example IEC 104 with a time tag), otherwise the time it arrived at YTCC, and the arrival time. A third field says whether the device time is valid. Trends and lists use the device time; see Time stamps and time zones.
Retention
Each table has a Max days and a Max (GB). Every hour, the oldest days are removed when a table is older or larger than its limit; the last Protect days are never removed for size. Removing data for size raises an alarm (high) and an event; at 80 % of the size limit a warning alarm (medium) appears first. A value whose time lies before the retention window is not recorded.
Disk protection
The history service watches the disk. A level is reached when both the used percentage and the free space pass their limits:
| Level | Default | Alarm | Effect |
|---|---|---|---|
| Warning | 80 % used and less than 50 GB free | Medium | None |
| High | 90 % and less than 30 GB | High | None |
| Critical | 95 % and less than 20 GB | Critical | Recording of values pauses; events, alarms and commands are still recorded |
When free space falls below the minimum (the smaller of 10 % and 20 GB), YTCC frees space step by step: the oldest days of value tables (not the protected days), then old log and backup files, then the oldest days of event tables, and finally it stops recording values. Each step is written to the event list. A reserve file (2 GB by default) keeps room for emergencies and is released when the disk is almost full. The limits are in Historian settings.
When the history database is not reachable
Values and events wait in a buffer on the server and are written when the database is back: values up to 5 GB (at most 10 % of the disk) and one day, events up to 1 GB. When the buffer is full, the oldest data is dropped. A table that falls behind raises an alarm (medium at 50 % of the buffer, high at 80 %), and lost data raises a gap alarm (high).