Generation of Events and Messages

One of the most critical functions of a GMP monitoring system, aside from recording parameters, is ensuring timely responses to deviations and nonconformities in the production process through audiovisual alerts to personnel.

To alert personnel, various visual elements on the terminal of the control station are used, including local signal lights, traffic lights, and signal panels installed in production areas. Audible devices such as buzzers, speakers, etc., as well as notifications via email, messaging apps, SMS, and similar means, are also employed.

The process of alerting personnel is typically multi-stage and consists of the following steps:

  1. Event Generation
  2. Message Generation
  3. Alert Output
  4. Acknowledgment of the Message
  5. Deactivation (Reset) of the Event (where applicable)

Event Generation

An event in an electronic system can be defined as the identification of certain circumstances or the fulfillment of specific conditions. There are various programmatic mechanisms for implementing events, ranging from system/hardware interrupts at the lowest level to event generation and handling (catching) in high-level object-oriented programming languages. Additionally, there are systems where the event concept is realized through the processing of different status flags.

The lifecycle of an event in an electronic system can be described as follows:

  • A hardware and/or software component of the electronic system regularly checks for the fulfillment of a condition or a set of conditions.
  • If the condition or set of conditions is met, the electronic system component makes changes to certain records in the system reflecting a status (including abstract statuses) accessible to other components of the electronic system—this is what generates the event. These records may also contain event-related information (for example, the code for a key pressed on the keyboard for a "key press" event).
  • Other components of the electronic system regularly check these records.
  • If they detect the presence of a certain status in the records (i.e., they "catch" the event), they initiate a procedure/subroutine/macro (the event handler), which processes the event, using any accompanying event information from the records if necessary. During event processing, these components may, in turn, generate new events, which will be caught and processed by other system components.
  • The event handler may also modify the records associated with the original event, such as resetting the status set at the time of event generation, to ensure that the event is no longer caught and processed by system components, marking it as processed.

All events in a GMP monitoring system can be classified into two categories: process events and system events.

Process Events
Process events include various circumstances related to changes in system-monitored parameters and the routine operation of the monitoring system, such as:

  • Observed parameters exceeding established limits
  • Operator changes to system settings or alert/alarm thresholds for monitored parameters
  • Operator acknowledgment of warnings/alarms
  • Operator account password expiration

System Events
System events encompass circumstances related to various failures or deviations in the operation of the monitoring system itself, such as:

  • Loss of communication with a sensor, input module, communication gateway, etc.
  • Hardware failures (disk errors, etc.)
  • Software failures (module crashes/restarts)
  • Unexpected changes in system time (clock adjustments, indicating a possible attempt to manipulate system time)

It is critical that the GMP monitoring system not only generates but also logs (records) all critical/significant events from a GMP perspective. Since system failures may render event generation and logging functions inaccessible, these capabilities must be duplicated. This ensures that in the event of any module failure, event information is preserved and recorded.


Message Generation

Not every event in the GMP monitoring system requires operator notification. Additionally, an event may lack the necessary accompanying information or instructions for the system to determine how to notify the operator. Therefore, the system requires an additional mechanism to interpret events and generate appropriate messages.

The message generation algorithm analyzes events and creates corresponding messages, adding necessary accompanying information and text comments for the operator, as well as providing the system with instructions on the message category, audiovisual signals to be used, and other relevant details.

Once generated, the message is sent for execution (i.e., the operator alert is triggered).

Typically, messages can be classified into the following three categories:

  1. Alarm (Emergency)
  2. Warning
  3. Informational Message

Alert Output

The Human-Machine Interface (HMI) system reads messages from the relevant queue or system log and displays the corresponding alerts for the operator. These alerts can be presented on the main control station terminal, local terminals, signal lights, beacons, panels, buzzers, loudspeakers, or sent through email, messaging apps, or via SMS to mobile phones.


Quitting (Acknowledgment) of Messages and Event Deactivation

The quitting (acknowledging) function for messages is necessary for several reasons:

  • To provide documented confirmation that responsible personnel have received and been informed about the issue.
  • To silence an alarm signal that may interfere with ongoing work.
  • To prevent the active message list from becoming overcrowded, which could lead to a critical message being missed by the operator amid multiple alerts.
  • In some implementations, messages may appear as pop-ups on the screen, potentially hiding other important information.

When acknowledging a message, the GMP monitoring system should log the following details: the name/account of the user acknowledging the message, the time of acknowledgment, and, if applicable, the user's comment or reason for the acknowledgment.

Additionally, the system should temporarily suppress the repeated generation of the same message if the original conditions that triggered the event and message still persist. This suppression should deactivate once the original conditions cease (i.e., the event is deactivated or reset), allowing the message to be generated again if the conditions reoccur.


Tarqvara GMP Monitoring System

In the Tarqvara GMP monitoring system, the comparison of channel parameter values with established limits and the control of various system functions for errors are performed every second. When certain conditions are met, corresponding messages (alarms/warnings) are generated.

Each message can have the following status:

  1. Message inactive
  2. Message active
  3. Message acknowledged (quitted)

The lifecycle of a message related to a parameter proceeds as follows:

  • Message inactive
  • The parameter value exceeds the allowable limits.
  • A delay timer for message generation begins.
  • After the delay period, the message is generated.
  • Message active
  • The warning/alarm signal is triggered, and the interface element displaying the channel is marked with the corresponding warning/alarm color coding.
  • If the parameter returns to normal values, the message status remains active.
  • A user with sufficient privileges acknowledges (confirms) the message using the appropriate interface function. During acknowledgment, the user can add a text comment, which is saved in the message history. Group acknowledgment of multiple messages with a shared text comment is also possible.
  • Message acknowledged
  • The warning/alarm signal is turned off, and the interface element displaying the channel is marked with the corresponding acknowledgment color coding.
  • The message remains in the "acknowledged" status as long as the parameter value is outside the allowable limits.
  • Once the parameter value returns to normal, the message is deactivated (reset).
  • Message inactive

Messages related to system events do not have a delay timer and are generated immediately.

In the case of emergency shutdowns of software modules or the system, or in the event of communication failures between the server and sensors, an emergency message is generated immediately after operations are restored.

Warning and alarm messages, as well as system failure messages, are also displayed on local signal panels in the affected areas as visual and audible alerts.

Some events generated in the Tarqvara GMP monitoring system do not trigger message generation but are still logged in the Audit Trail.


See also:
GMP Monitoring Systems
Tarqvara GMP Monitoring System
Audit Trail
IT Solutions / GAMP / Data Integrity (RDI)
Computerized Systems Validation (CSV)