Communication, command and system alarms
Besides the alarms you define on signals, YTCC raises three kinds of alarms by itself: when a device or a driver stops communicating, when a command fails, and when the history service has a problem with the disk or with recording. These alarms have no alarm definition, so you cannot change their text. Only the priority of the command alarm is set in the configuration.
Common rules
| Kind | Raised when | Priority | Ends |
|---|---|---|---|
| Communication | A device stays not connected, or a driver process stops | High | Goes when the device or driver communicates again; closes when acknowledged |
| Command failed | A command is rejected, times out, or its read-back or feedback does not match | The Failure alarm of the signal | Closes when acknowledged |
| System | The history service reports a disk, size or recording problem | Depends on the problem | Goes when the problem ends |
All three kinds:
- must be acknowledged and cannot be shelved (see Alarms that cannot be shelved);
- have no area, so they count in
Alarms.Summaryonly, not in area or group counters (see Alarm counters); - appear in the alarm list with an empty Source and Area. The Tag column, which you can add with
Columns, shows
<driver>.<device>or<driver>for a communication alarm, the signal path for a command alarm and<project>.<code>for a system alarm; - are not counted in Last 10 min and are never marked FLOOD or CHATTERING.
Communication alarms
YTCC raises one alarm per device and one per driver, never one per signal. A device with 400 signals gives one alarm.
- Device. The alarm comes when the device stays not connected for 5 seconds without a break. A device that has not been seen connected since the alarm service started waits the longer of this delay and 30 seconds, so a normal start does not raise alarms.
- Driver. The alarm comes when the driver sends no heartbeat for 6 seconds, or when no heartbeat has arrived 30 seconds after the alarm service started.
| Event | Text in English |
|---|---|
| Device lost | <device> communication lost — <reason>. The reason is the last error reported by the driver, or no connection. |
| Device back | <device> communication restored |
| Driver stopped | <driver> no communication — driver not responding, or … — driver did not start when no heartbeat ever came |
| Driver back | <driver> communication restored — driver running |
| Device removed from the configuration | <device> communication alarm closed — equipment no longer configured |
| Driver removed from the configuration | <driver> driver no longer configured |
The alarm keeps its lost text in the list. The back and removed texts are written to the alarm history with the event that ends the alarm. The device name is the name given to the device in the configuration, or its key when it has no name.
The server writes these texts in the project's Operator language; 13 languages are available. A change of the language applies after the project is restarted, and alarms already recorded keep their language. How devices and drivers report their state is described in Communication state and communication alarms.
Command failed alarms
A command raises an alarm when its result is one of these:
- the device or the server rejected it, for example because the device does not communicate or the command expired;
- no response arrived in time;
- the read-back value did not match;
- the feedback signal did not reach the expected value.
There is no alarm when YTCC itself holds the command back: while a previous command to the same signal is still running, or while a write limit waits for confirmation. The priority comes from Failure alarm on the signal's Command tab (see Set up commands).
The text is Command failed: <signal> ← <value> · <user> · <reason>, for example
Command failed: P101.Start ← 1 · operator1 · no response. The alarm starts as Gone (unacked) and closes when it is
acknowledged. If the same signal fails again for the same reason before that, no new alarm comes: the open alarm takes
the latest text and a repeat count, for example (×3).
System alarms of the history service
The history service raises one alarm per problem code. It comes when the problem starts and goes when it ends.
| Code | Priority | Meaning |
|---|---|---|
disk_warn | Medium | The history disk reached the warning level |
disk_high | High | The history disk reached the high level |
disk_crit | Critical | The history disk reached the critical level; recording of values pauses |
reserve_used | Critical | The disk filled up and the reserve file was released |
hist_size_warn | Medium | A history table reached 80 % of its size limit |
hist_size_drop | High | Days were removed from a table because of its size limit |
hist_disabled | Medium | History recording is switched off in Historian settings |
js_discard | High | The buffer in front of the history database overflowed; data may be lost |
hist_loss | Medium | Values older than the retention window were not recorded |
hist_gap.<table> | High | Data for a table was lost from the buffer |
hist_lag.<table> | Medium, High | A table falls behind: medium at 50 % of its buffer, high at 80 % |
hist_guard_down | High | The history guard process sent no heartbeat for 15 seconds |
A disk level is reached only when both the used percentage and the free space pass their limits. By default the levels are 80 %, 90 % and 95 % used, together with less free space than 2.5, 1.5 and 1 times Min free (GB) (20 GB, so 50, 30 and 20 GB). Only one disk alarm is open at a time, and a level drops back only when the disk is 2 percentage points below it. The limits and what each level does are in How history is recorded and Archive tables and assignments.
When a project starts, the alarm service closes open system alarms that belong to another project, for example ones that came with a backup or a copy of that project. Nothing in this project could end them otherwise. The alarm archive is not changed, and the closing stays in the event list with its reason.