0:07 Welcome to this application explainer video, part of our operate and maintenance topic range.
0:13 In this video we will be covering the subject of logging of events.
0:19 The SNM Operate and Maintain module is used to capture events for the safety functions and instruments.
0:25 Collecting this data leads to the automated population of key Performance indicators, reports, prior use collection, and better visibility into the performance of the facility.
0:36 What we’ll cover in these chapters Chapter One Event Types Within the SLM System, Chapter 2 Manual Entry Event Workflow, Chapter 3 Historian Integration, Automated Event Records, Chapter Four, Event Approvals, and Chapter 5 Dashboard Population.
1:01 In Chapter One, we’ll be covering what type of events can be captured within the SLM system and the things to consider.
1:08 Are there any prerequisites for the event capture and dashboard population?
1:13 Today we’ll be looking at the logging of operational events within the SLM system.
1:17 First, the user should navigate to the Operate and Maintain module using the Module slider at the top.
1:26 From then we’ll use the SLM object tree to navigate to the unit object to identify different types of events that are available in the SLM Operate and Maintain module.
1:38 Using the Edit Tools button, we’ll be able to see a list of events that are available for capture here within this module.
1:46 These events include demands or activations, bypasses, tests, maintenance events, fault failure events, and service status change events.
2:00 Operational events can be logged from different levels of the SLM object tree.
2:06 From the unit selecting an event, the first step will be to identify the function that you’re looking to log for this event.
2:13 If you want to log the event directly on the function, you can navigate using the object tree to that function object and log the event from there.
2:22 The first step will now just be entering the general data.
2:26 If you’re logging test events, then you can kick the logging of that event off from the actual test group object and enter test deferral authorization or recording of a test event using various buttons in chapter 2.
2:43 We’ll be covering manual event entry workflow, differences in workflow for different event types and things to consider.
2:51 At what level is the event created?
2:53 What information is important to the capture for dashboards and reports?
2:58 For operational events, the SLM system is a step by step workflow to allow users to manually enter those event results.
3:06 We can log the demand event from the unit or here from the actual function itself.
3:12 Going to the Edit Tools button, we can add a demand event and you can see the steps available for logging information here.
3:20 Each event type has slightly different characteristics and information that can be captured, but the intent is to complete the full results of those events so that the SLM operate and maintain.
3:30 Dashboards and reports are complete and valuable.
3:36 For the General Data tab of this, we have to enter information in and around the event date, time, description, and demand type.
3:44 What type of demand is this?
3:47 Is it a real process demand?
3:48 Is it a spurious trip?
3:49 This may affect some of the dashboards and how this evidence categorised in the calculations that are affecting them.
3:55 What is the demand result?
3:57 I’ll put a pass with failed safe failures.
4:00 We can enter a function response time.
4:02 We can enter in any fault codes, any contributing factors, any related demand events, and the results as well.
4:10 Using this Next button, we can move to Step 2, where we’re able to select the devices that are associated with the SIF.
4:16 That’s again to be part of this demand event so I can individually select these or using this check box, I’ll capture all of the input and output devices.
4:27 Using the next step, I can move to Step 3, where I identify the failures, so which these pieces of instrumentation had a failure associated with them.
4:36 I can select them individually again using the check box.
4:39 To get all of them, Select Next then prompts me to add information about the failures.
4:45 So for all the instruments that we have not selected as having failures in step three, the SLM system will automatically fill these in with pass information.
4:56 But here for the failure codes we can add the As found as left information.
5:00 Here we can capture any failure codes for the As found as left failure type, any notes descriptions, mitigating actions.
5:07 Is it safety critical And then getting into any maintenance activities that might be required?
5:12 Is there a work order number?
5:14 Is there any maintenance notes associated with that?
5:17 So that we can capture the kind of information for each of the failures here and then once that’s complete using the next, we can enter in the device response times for the output.
5:26 The SIFT function response time is entered on the step one General Data tab, but here I can see what the target response time is and I can log the observed response time as this event took place.
5:38 Once all of that information is complete, you can hit save and SLM will take you to the demand event object where we can look at adding any other information or going through the actual approval process.
5:50 For capturing a testing event, we can navigate again to the unit object or to the test group object where there may be multiple functions and multiple devices associated with them.
6:00 On the test group object we can select Record Test event where if we need to go through a deferral we can use this button to defer the test event by hitting record.
6:10 You can see the step by step workflow very similar to demand event workflow.
6:15 So selecting the as found and as left for the functional test, selecting which functions of this test group are part of this test if you’re testing multiple functions at the same time, of those functions that are associated devices, which of them are being captured as part of the test, Selecting the failures and entering the failure data for functions and the failed devices as well.
6:37 So it’s a very similar workflow to the demand event workflow, but slightly different for capturing the test events.
6:44 For capturing bypasses we can navigate either to the unit or against the actual function that we’re putting in bypass.
6:51 Using the Edit tools button we can add a bypass authorisation.
6:55 Again a step by step workflow allowing you to either create a new bypass authorisation or copying one that may have previously been completed.
7:02 Here we’ll create a new one.
7:04 You can enter in information around the bypass authorisation, Any descriptions, Reasons for the bypass plant, operating conditions at the time of bypass, anticipated start dates and times.
7:16 This is putting in the maximum allowable bypass duration as set in the global module for the organization.
7:21 Once we have all of this information captured, we can go to next and look at any HAZOP data that may be related to this function going into bypass.
7:29 So how does this functional bypass affect the hazardous scenarios that it may be related to?
7:34 We can enter in some information around that, any procedures that may be associated with those.
7:39 We can then hit next and select the devices that are again associated with the SIF, which of them are going to be part of this bypass or use the full loop.
7:47 We can also individually select devices that may be associated with it and then we can hit save.
7:54 This has queued up the bypass authorization, but then has taken us to the bypass event.
7:59 We can then go through the execution process where we can note where the actual bypass took place, where it’s at.
8:06 We can also go through the approval process here to make sure the right people approving this bypass is able to happen.
8:16 In Chapter 3 we’ll be covering Historian integration and Automated Event records and things to consider roles and responsibilities of qualifying events.
8:26 If the user has set up a Historian Integration to semi automate the caption of the events like activations or bypasses in the SLM system, the user will see these automated event record notifications which is in this yellow triangle up here.
8:40 It’s specific to the individual user account.
8:43 If you select this, it will pull up a list of those events, demand events, bypass activations, faults, test events that are being pulled from the automated event record so you can see how they’re coming in, what they look like, where they’re coming from, the CGI, the activation source for the actual bypass authorisation.
9:05 With this, the user needs to understand that only certain individuals will have access to the automated event record.
9:11 It’s a part of your user profile that can be turned on.
9:14 It’s simply AER notifications that can be selected here.
9:20 Individuals that have access to the Automated Event record will receive notifications about the records as they’re taking place.
9:27 When a demand event happens, an individual will get an e-mail and a notification within the tool allowing them to understand that the event has taken place.
9:39 In Chapter 4, we’ll be covering Event approval workflow and things to consider.
9:45 Who is responsible for the approvals?
9:47 Is the role configured to allow approvals before these events are taken into consideration?
9:53 For the calculations that are happening on some of the SLM operate and maintain reports and KPI dashboards, the event needs to be viewed and approved for it to continue with the calculations.
10:04 So on an actual event, whether it’s a demand event, a bypass event or a test event, when come to the actual event you’ll see a demand Event approval tab here.
10:15 With this we can submit to individuals that are selected at this particular site that are set up as approvers.
10:21 We can select them and save it and submit to approval.
10:31 This will then send an e-mail to that individual letting them know that this event is up for approval and is their responsibility to do that.
10:40 If you use the user A designated as an approver, you may have the authorisation to self approve the event that is set up as part of the roles and responsibilities that you as an individual will have.
10:50 This will keep an entire log of all the approvals that have taken place when it was submitted, who it was submitted to, when it was approved and who approved it.
11:00 All of that information is captured here in the Demand Event Approval log in Chapter 5.
11:09 We’ll be covering a dashboard and things to consider.
11:12 Has the event been approved and finalised?
11:16 Once these events are captured in the SLM, operate and maintain module, and have gone through the correct approval process, they’ll start to automatically populate on various dashboards.
11:26 So talking about bypasses, a unit level or site level, there’s a Bypass Status tab that allows you to view any active bypasses, any approved bypass authorisations that are pending bypass, any ones that are not approved, any ones that have been submitted to approval and all of the closed bypasses with notes on if they’ve been exceeding their approval time for bypass for demands and other pieces, they’re Tier 3 metric scorecards that capture what is the demand rate versus what is the real demand that’s taken place, how many of them are there?
12:02 From a bad actor’s perspective, we can look at these metrics and see for demand rates, which of my Sips are not meeting their design PHA demand rate, look at the number of demands.
12:13 I can click on these and I can see those demand objects here and go in and find information about them.
12:20 So once those events are logged and approved, they’ll start to automatically begin populating on these dashboards and reports that are now available for the user to access.
