The Events List displays a row of values for each event that occurs in your ClearSCADA system, and uses columns to separate and categorize the values. The column headings indicate what the values in each column represent. The columns that are displayed on your Events List can be configured by a system administrator (see Events Journal List Settings).
The default column headings for the Events List are:
Events have a severity level that indicates the importance of the event. Severity for events works in exactly the same way as Severity for alarms and has the same range of severity levels (see Alarm Severity).
The date and time at which the event was recorded. Events have both an ‘occurrence time’ and a ‘received time’. Whenever the ClearSCADA server provides the time stamp, these times are one and the same. Whenever ClearSCADA receives a time stamped event from an outstation, the Time column displays that record’s ‘occurrence time’ (the time stamp provided by the outstation or scanner).
Events that are generated at the master station (ClearSCADA) are time stamped by the server. If an event occurs at the outstation, the time stamp of that event depends on the driver. With some drivers, the outstation time stamps the data and then passes that data to ClearSCADA. With other drivers, the time stamp might be generated by the outstation or the server, depending how the data was reported. Outstations on some drivers do not support time stamping of data, and therefore the server time stamps that data when it receives it from the outstation.
The name of the item with which the event is associated. The Source is not always the name of an item in the ClearSCADA database. For items that are in the ClearSCADA database, the FullName of the item is displayed.
A short text description of the system occurrence that caused the event to be generated.
The identity of the user that caused the event to be generated. Users include:
The name of a user that is logged on to ClearSCADA and whose activity caused an event to be generated. <User Name> generated activities might include, for example, logging on and off ClearSCADA, modifying an item’s configuration, or sending controls to plant.
This is a built-in user account that is disabled on new ClearSCADA installations by default. Events are assigned to the Guest user should someone perform activities on a ViewX Client without being logged onto ClearSCADA via that client. Guest user access is typically restricted to help prevent unauthorized interaction with the system.
This is a built-in user account that can only be used with Original WebX clients (as opposed to WebX clients). Events are assigned to the Web user should someone perform activities on an Original WebX client without being logged onto ClearSCADA via that client. Web user access is typically restricted to help prevent unauthorized interaction with the system. (Unlike Original WebX clients, you do need to log on to a WebX client in order to interact with ClearSCADA.)
If enabled on your system, the Super User account provides access to all ClearSCADA features. The account is typically used to initially set up ClearSCADA and is then typically removed once appropriate administrator-level user accounts have been set up.
For more information on any of the above users, see User Accounts.
Built-in Internal Users
ClearSCADA also includes several built-in internal ‘users’:
Events generated due to driver-instigated activities, such as configuration upload.
Events generated due to a Logic program’s activity. For instance, an activity such as a One Shot call being triggered by a Logic program.
Events generated due to actions being triggered by Method Calls (see Stand-Alone Method Calls).
Events generated due to actions being triggered by a Schedule (see Using Schedules to Automate Regular Functions).
Events that are not generated by another type of user. Alarm-related events, for example, such as those logged to indicate an alarm being cleared or raised, are assigned to the System user.
If the event was not caused by ‘user’ interaction, there will be no entry in this column.
Each event has a category that indicates the type of event. This allows you to filter the Events List so that it only displays events of a specific category, such as outstation communications events (see Add a Filter to a List).
The event categories include:
The event was logged due to an action being performed. An action can be triggered manually by an operator, or automatically—for instance, by a Method Call, Logic, or a Schedule.
The event was logged due to the permitted time for either receiving, responding to, or clearing an alarm being exceeded. Alarm Analysis periods can optionally be configured for Severity ranges (see Add a Severity Range).
The event was logged due to an alarm being redirected (as part of the Alarm Redirection feature that allows, for example, alarms to be sent to pagers).
The event was logged due to a detected problem associated with either deleting, duplicating, or recreating an archive volume (the media to which data is being archived). For example, the archive volume being full.
The event was logged due to data being archived, for instance onto hard disk, CD, DVD, or compact flash. Archiving provides the ability to store historic and/or event data offline. For more information on archiving, see Archiving.
The event was logged due to an operation associated with a database Backup item. For example, an event is logged whenever a backup is initiated
The event was generated due to a successful callback, an unsuccessful callback, or an unexpected callback. (The callback feature allows you to send a message to an outstation to instruct it to dial in. The outstation should then report its data within a specific amount of time).
The event is associated with a communications channel’s status. For example, an event is logged if channel communications is interrupted unexpectedly (an alarm is also raised).
The event was logged due to a comment being created (see Insert a Comment for an Event).
The event was logged due to configuration changes being made (for example, a new item being created, the configuration of an existing item being modified, an item being renamed or deleted from the database).
If you have the Configuration Changes feature enabled on your system, you can keep a detailed record of any configuration changes. You can use the Property Change History List to view a summary of the configuration changes on your system (see Display a List of Property Changes).
The event was logged because a Control Feedback point or an Uncommanded Change point did not have a required value (see Control Feedback Settings and see Uncommanded Change Settings).
The event was logged due to both successful and unsuccessful control activity. For example, a control request, or execution.
This category is used for miscellaneous events associated with server activity. For example, an event logged due to unexpected activity occurring while receiving a request from a ViewX or WebX client.
The event has been logged due to a PSTN outstation dialing in more often than expected.
The event is associated with file upload activity, for example, outstation data being uploaded to ClearSCADA. Where supported by a driver, if the system set-up does not allow ClearSCADA to communicate with one or more outstations, file uploading can be used to upload the data from those outstations to ClearSCADA.
The event is associated with a Forecast item. For example, an event is logged if an alarm is raised due to a Forecast from an external application having values that are outside the alarm limits for the Forecast item in ClearSCADA.
The event was logged due to an operation associated with historic data (for example, historic data being inserted, or modified).
The event was logged due to an alarm raised to indicate errors detected in historic data that is being retrieved.
The event was logged due to an operation associated with the export of historic data from ClearSCADA.
The event was logged due to an alarm raised to indicate that the value of the maximum number of records per data file (granule) exceeds one of the historic limits set, see Define the Acceptable Limits for Historic Data Files.
The event was logged due to an alarms raised to indicate write errors detected when historic data is being recorded.
The event was logged due to an external application raising an alarm using the SetInterfaceAlarm method. The SetInterfaceAlarm method is purely for use with the Automation Interface. For more information, see the database Schema.
The event was generated by an external application, using the SetInterfaceEvent method. The SetInterfaceEvent method is purely for use with the Automation Interface. For more information, see the database Schema.
The event was logged due to a change in outstation communications status (for example, due to an incoming call).
The event was logged due to a request from an advanced driver timing out internally. For example, an event is logged if a request fails to complete within the Scanner Command Timeout duration (see Define the Scanner Command and Request Timeouts).
The event was generated when a general outstation error was detected (an outstation error that is not included in the Outstation Hardware or Outstation Comms categories).
The event is associated with the status of the outstation’s hardware.
The event is associated with the status of an outstation. For example, an event can be logged when an outstation is reset, or when an outstation requests configuration.
The event is associated with the communications status of a pager service. For example, an event is logged when there is an attempt to connect with a pager.
The event has been logged due to a miscellaneous error associated with a point being detected.
The event has been logged due to a point’s value not having changed by a specified amount for a defined period of time. Such events can only be logged for points that are configured to use the No Change feature.
The event is associated with a significant change in the value of a point. This type of event can only be logged for points that are configured to use the Significant Change feature.
The event has been logged due to a point changing state. The point states are those that are defined in the configuration of each point.
The event is associated with the status of a point. These are miscellaneous events that are not covered by Point State.
The event has been logged due to a Test PSTN Connection request on a multi-drop outstation.
The event is associated with a scanner or a point source (simple drivers). For example, an event is logged when an alarm is raised due to a scanner error being detected.
The event has been logged due to a successful scheduled dial in, an unsuccessful scheduled dial in, or an unexpected scheduled dial in.
The event is associated with the status of a server or channel (simple drivers). For example, an event is logged when there is a switch from one channel to another.
The event is associated with the status of an outstation set. For example, an event is logged if the outstation set switches from one communications channel to another (switches lines).
The event has been logged due to an occurrence that affects the entire system, such as the server being stopped and restarted. The System category is also used for miscellaneous events that are not suited to the other categories.
The event has been logged due to a system-wide problem being detected, such as licenses expiring.
The event has been logged due to a ClearSCADA Server receiving a text message from an outstation or another ClearSCADA server.
The event has been logged due to an unknown PSTN outstation dialing-in to ClearSCADA.
Additional Columns in the Events List
Other columns that may be included in the Events List are:
This column is only available if the Area of Interest feature is enabled on your system. The column lists the Area of Interest with which the event is associated. Only alarm-related events have an Area of Interest; the entry is blank for other types of event. Additionally, the Events List is restricted so that it only includes events that have either no Area of Interest, or an Area of Interest to which the logged on user has access. For more information, see Restrict Alarm and Event Access to Specific Areas of Interest.
The event has been logged due to a change in the item’s alarm state. For example, an alarm being raised, cleared, acknowledged, or disabled.
The IP Address or computer name of the client computer that generated the event. The type of information that is displayed is dependent on the setting of the 'Use DNS lookup for ClientName column' check box in the Events section of the ClearSCADA Server Configuration tool (see Events Display Settings for the Event Journal (Events List)).
Indicates whether the event has been deleted. Events are not removed from the database when they are deleted; instead they are merely marked as deleted, which hides them from view when the default Events List filter is used. An event can be deleted, for example, by using the DeleteInterfaceEvent automation method in the CDBObject database table (for more information about this method, see the Database Schema).
The item ID of the item in the database that is associated with the event.
The name of the Historic Region that contains the event (where applicable). Historic Regions are sections of historic data that remain online—the events within them are not deleted.
This information is especially useful when filtering an Events List. For example, if your system has a Historic Region for a time period in which a specific event occurred, such as a power outage, you can filter the Events List by the relevant Historic Region. You can then use the filtered Events List to examine what happened on your system during the power outage.
The time at which the event was received at the ClearSCADA server. The time includes the date on which the event was received.
Further Information
Events logged due to alarms or alarm redirections: see Alarm-Related Entries in the Events List.