Alert logging database: the alarm and event journal that stores every active, clear and acknowledge transition with its timestamps

01

Event time, receive time and severity: the fields every stored alarm needs

OPC UA Part 5 (v1.05.06) makes EventId, EventType, SourceNode, SourceName, Time, ReceiveTime, Message and Severity mandatory properties of its BaseEventType, with LocalTime optional. Time is the time the event occurred, set as close to the event generator as possible, and once set intermediate OPC UA servers shall not alter it; ReceiveTime is the time the server received the event, and each server in a chain applies its own, so the same EventId can arrive with different receive times. [1]

A journal that stores only one timestamp loses that distinction. Storing both lets an investigator see whether a late alarm was raised late at the device or delivered late through the network. LocalTime, where supplied, carries the offset in minutes between Time and local time at the source and a flag for daylight saving. [1]

Severity in OPC UA runs from 1 (lowest) to 1,000 (highest). The specification recommends mapping high-urgency events to 667–1,000, medium to 334–666 and low to 1–333, and gives a worked mapping of a 16-level source in which source level 15 becomes 1,000, level 8 becomes 685, level 7 becomes 650 and level 0 becomes 1. [1] Inductive Automation's Ignition journal, by contrast, stores priority as an integer from 0 (Diagnostic) to 4 (Critical). [2] A database that receives from both kinds of system needs a documented mapping table, or priority-based queries will mix scales.

Ignition's core alarm_events table holds an id, the event UUID shared by one active/clear/acknowledge cycle, the source path, display path, priority, event type (0 active, 1 clear, 2 acknowledgement, and from 8.1.8 4 enabled and 5 disabled), a bitmask of event flags and the event time; associated values go in a separate alarm_event_data table keyed on id. [2]

02

Buffering during outages, pruning age and digests that reveal edits

Ignition states that by default current alarm data is only stored in memory with a finite number of events per alarm, and that a journal profile is needed to store alarm data in a SQL database, remotely on another Gateway, or internally in the install directory. For database profiles, Use Store and Forward is enabled by default and protects data from loss during temporary database connectivity issues; with it disabled, events are written directly against the database. [2]

Filters decide what is never written. Ignition's journal stores only events at or above a Minimum Priority (default Low), does not store events from shelved alarms unless that option is enabled, and combines its source and display-path filters with a logical AND. [2] The filter settings belong in the alarm philosophy document, because an event filtered out is absent from every later report.

Retention is a setting, not a default: Ignition journals store data indefinitely unless data pruning is enabled, the prune age defaults to 1 year when enabled, and the manual strongly encourages a pruning value for internal profiles to avoid running out of disk space. It also notes that because the data sit in a database, an administrator is free to delete them manually at any time. [2]

NIST SP 800-92 (2006) separates log retention, archiving on a regular basis, from log preservation, keeping logs that would otherwise be discarded because they record activity of particular interest. It describes integrity checking as calculating a message digest for each log file and storing the digest securely, so that a recalculated digest that does not match shows the file has been altered; the guide names MD5 and SHA-1 as the algorithms in use at the time. [3]

03

Clock drift between alarm sources

NIST SP 800-92 warns that each host stamps log entries from its own internal clock, so an inaccurate clock gives inaccurate timestamps, and recommends time synchronization such as NTP servers to keep log sources consistent; organisations with systems in more than one time zone may need to convert all logged times to a single zone. [3]

Its example: timestamps might show event A 45 seconds before event B when A actually happened two minutes after B. [3] Editorial calculation: the recorded order is wrong by 45 + 120 = 165 seconds, enough to reverse the apparent first-out alarm in a trip sequence. The figures are NIST's illustration, not a measured drift; the tolerance a plant needs depends on how closely its alarms follow each other.

For the journal specification, name the clock that stamps each source, the synchronization method and the zone in which times are stored.

04

Specify the journal by fields, sources and retention

Paste it into your enquiry below or into an email to a maker, then replace every bracket.

Sources: [systems and protocols feeding the journal; event rate]
Fields: [event time; receive time; source; severity/priority; event type; associated data]
Time: [clock source; synchronization; time zone stored]
Buffering: [store-and-forward; capacity during outage]
Filters: [minimum priority; shelved events; source filters]
Retention: [prune age; archive and preservation rules; integrity checks]

See manufacturer records Send an enquiry through CNFX