Logging Events
Logging events provides a structured record of what happens to safety functions and their associated instruments during operation. Within Safety Lifecycle Manager (SLM), logging events such as demands, tests, bypasses and failures helps build performance information, reports, prior-use records and operational dashboards.
Events can include demands or activations, bypasses, tests, maintenance activities, faults and failures, and service status changes. Each type captures information relevant to what happened, which functions and devices were involved, and what the outcome was.
This guide explains the SLM event-logging workflow, the operational events that can be captured, how manual and automated event records are handled, why approval matters, and how finalized event information contributes to performance monitoring.
What Is Logging Events in SLM?
SIS event logging is the process of recording operational activities and occurrences involving safety instrumented functions and their associated equipment. These records provide the underlying data needed to understand how safety functions and devices are performing during actual operation.
Within SLM’s Operate & Maintain module, users can capture demands or activations, bypasses, tests, maintenance events, fault or failure events, and Service Status Change Events.
Events can be initiated at different levels of the SLM object hierarchy depending on the event type and workflow. For example, an operational event can be initiated from a unit and associated with the relevant function, or it can be recorded directly from the function itself. Test events can also be initiated from an applicable test group.
Capturing this information consistently provides more than an event history. Once the appropriate workflow and approval requirements have been completed, the resulting data can contribute to reports, KPI dashboards and other operational records.
For broader context on the equipment and functions being monitored, the Safety Instrumented System guide explains the role of SIS functions and equipment within the functional safety lifecycle.
Operational Event Types Captured in SLM
Logging events consistently allows different types of operational activity to become part of the same structured SIS lifecycle history.
Different operational events answer different questions about SIS performance. A demand event records an occasion when the safety function was called upon to respond. Test events capture the results of planned testing activities, while fault and failure events provide information about equipment problems identified during operation.
Bypass events record periods when a safety function or associated equipment is bypassed. Maintenance events provide a record of relevant maintenance activity, while Service Status Change Events document changes such as commissioning, decommissioning and equipment replacement.
The type of event affects the information that needs to be captured. A demand, for example, can include whether it was a real process demand or a spurious trip, the result of the demand, function response time, fault codes, contributing factors and related events.
That classification matters because different event characteristics can affect how the resulting information is categorized and subsequently represented within SLM reports and dashboards.
Where an event changes whether equipment is actively in service, the Service Status Change Event guide explains how SLM records commissioning, decommissioning and other lifecycle status changes.
Logging Events Manually in SLM
SLM provides step-by-step workflows for manually recording operational event results. The exact fields and stages vary according to event type, but the objective is to capture enough information for the event record to represent what actually occurred.
For a demand event, the general information can include the event date and time, description, demand type and overall result. Users can also record function response time, fault codes, contributing factors and related demand events where applicable.
The workflow can then identify the devices associated with the safety instrumented function that participated in the event. Users can select individual devices or, where appropriate, include the relevant input and output equipment.
Where failures occurred, the affected instruments can be identified separately. SLM can populate pass information for equipment not selected as having failed, while the failed equipment can have additional details recorded.
These details can include as-found and as-left information, failure codes, notes, mitigating actions, whether the issue is safety critical, associated maintenance information and work-order references. Observed device response times can also be captured where applicable.
Recording Tests and Bypass Events
Although the principles of SIS event logging remain consistent, tests and bypasses have workflows designed around the information required for those particular activities.
A test event can be initiated from the unit or from a test group containing the relevant functions and devices. The workflow can record as-found and as-left results, identify which functions were included in the test, select the associated devices and document failures for functions or equipment.
Where testing needs to be deferred, the demonstrated SLM workflow also provides a test-deferral authorization process. Once testing takes place, the resulting event information can become part of the operational history for the affected equipment.
The Configuring Test Groups guide explains the related SLM workflow for organizing equipment into groups used for testing activities.
Bypasses can similarly be initiated from the unit or the affected function. A bypass authorization can record information such as the reason for the bypass, operating conditions, anticipated start date and time, and the applicable maximum allowable bypass duration configured for the organization.
The workflow can also capture related HAZOP information, associated procedures and the devices included in the bypass. Following authorization, the bypass event provides the execution record showing when the bypass actually occurred and supports the applicable approval workflow.
Automated Event Records and Historian Integration
Operational event information does not always have to originate from manual entry. Where Historian Integration has been configured, SLM can support semi-automated capture of applicable operational events.
The training workflow demonstrates Automated Event Record notifications for information such as demand events, bypass activations, faults and test events received through the integration.
Access to these Automated Event Record notifications is controlled through the user’s profile. Users with the applicable AER notification setting can receive notifications when qualifying records are generated.
For example, when a demand event occurs, an appropriate user can receive an email and an in-system notification indicating that an event has been detected. The record can then be reviewed as part of the applicable SLM workflow.
This distinction is important: automated detection can reduce reliance on users manually identifying that an event occurred, but the resulting operational record still needs to follow the organization’s configured review and approval process where required.
Event Approval and Audit History
Approval is an important stage because simply creating an event does not necessarily mean that its information should immediately affect operational calculations.
Logging events with the appropriate review and approval controls helps ensure that operational calculations are based on information that has been checked before it contributes to reports and KPIs.
For applicable Operate & Maintain reports and KPI dashboards, the event needs to be reviewed and approved before it is taken into consideration by the relevant calculations.
Demand, bypass and test event records can therefore be submitted to users configured as approvers for the applicable site. Submission generates a notification to the selected approver so the event can be reviewed.
Depending on configured roles and responsibilities, a user designated as an approver may also have authorization to approve an event themselves.
SLM maintains an approval history showing information such as when the event was submitted, who it was submitted to, when approval occurred and who approved it. This provides an auditable record around both the operational event and its review.
How Event Data Supports Prior Use and Reliability Tracking
Logging events can also contribute to equipment reliability history. Where a commissioned device is correctly associated with a Prior Use Certificate, applicable event results and operating information can contribute to the accumulated data held against that PUC.
This creates an important relationship between event quality and reliability information. Tests, demands, bypasses, failures and other applicable events do not exist only as standalone historical records; they can become part of the operating experience associated with the equipment.
The How to Gather Prior Use Failure Rate Data guide explains how commissioned devices and their finalized or approved events contribute information to associated Prior Use Certificates.
The underlying model-level records are covered in the Failure Rate Library, which explains how SLM manages Prior Use Certificates, reliability sources and accumulated operating experience.
This connection makes consistent event classification particularly important. Reliable lifecycle analysis depends on knowing what occurred, when it occurred, which equipment was affected and what the result was.
How Logging Events Supports Dashboards and Metrics
Once applicable events have been recorded and completed through the required approval process, SLM can use that information to populate Operate & Maintain dashboards and reports automatically.
For bypass management, site- and unit-level information can show active bypasses, approved authorizations awaiting execution, records awaiting approval and closed bypasses. This gives users visibility into current and historical bypass activity rather than requiring each event to be reviewed independently.
Demand information can also contribute to Tier 3 metric scorecards. These views can help users compare actual demand experience with the applicable design or PHA demand rate and investigate functions whose operational experience warrants further review.
Users can move from summarized metrics into the underlying event records to investigate the information behind the result. The Tier 3 Metrics guide covers this performance-monitoring workflow in greater detail.
Event records therefore form the underlying evidence for many higher-level performance views. A dashboard can summarize trends, but the value of those trends depends on the quality and completeness of the operational records from which they are calculated.
Why Operational Event Records Matter for SIS Lifecycle Management
Safety instrumented systems continue to generate important lifecycle information after commissioning. Demands occur, equipment is tested, bypasses are applied, failures are discovered, maintenance is performed and devices move into and out of service.
Capturing these activities in structured records provides a chronology that can be reviewed when assessing equipment performance, investigating recurring problems or understanding why operational indicators have changed.
This operational focus is consistent with the wider SIS lifecycle framework. IEC 61511-1 addresses safety instrumented systems across lifecycle activities including operation and maintenance. The specific event-entry, automated-record and dashboard workflows described here are SLM capabilities rather than workflows prescribed by the standard.
Maintaining that distinction is important. Functional safety requirements establish the lifecycle framework, while organizations need suitable processes and records to demonstrate how their own equipment is being operated, maintained and monitored.
Managing Operational Events with Safety Lifecycle Manager
Logging events in SLM connects individual operational occurrences with broader lifecycle information. Manual workflows allow users to document detailed event results, while configured Historian Integration can assist with identifying applicable events through Automated Event Records.
Approval workflows provide review and traceability before applicable event information contributes to calculations. Once finalized, event data can support dashboards, reports, Tier 3 metrics, prior-use information and investigation of equipment performance.
The MSS Safety Systems solution supports the broader management of safety-system lifecycle information. Within its Operate & Maintain workflows, structured event capture provides the operational evidence needed to understand what has happened to functions and devices after they enter service.
The objective is not simply to build a larger event database. It is to maintain usable operational history that engineers and functional safety teams can trace from summarized performance indicators back to the events and equipment that produced them.
