Operations Logbooks – Should We Automate Log Entries or Not?
One question we get from time to time has to do with automating entries in operational logbooks. “Can we?”, is the first question we get. The answer to that is a simple and straightforward, “yes.” A tougher question is, “Should we?”
To answer the question about whether one should use automation to add log entries to your logbook, you’ll need to consider the purpose of your logbook. Is the logbook being used to make decisions? Is the logbook intended to provide evidence that operators were aware of certain conditions? Is the logbook simply a handy place to collect information for concurrent or post analysis?
The pros to automatically having log entries added are:
- There is very little, if any, latency to getting the log entries into the log.
- The log entries are 100% consistent because they are automated.
- It’s efficient because operators don’t have to spend their time manually entering information into the log.
- There’s little doubt that entries will be made, so there is confidence that the entries will appear.
The cons to automatically having log entries added are:
- Since the entries arrive automatically, operators may or may not see the entries.
- Operators may not understand the log entries. Again, these are completely automatic; so, they do not necessarily require inference by an operator.
- Automated log entries may arrive faster than an operator can process them.
- Automated entries might need to be suppressed, if they become a nuisance, because they might add noise that obscures operators from seeing more important entries.
So, there’s no simple answer to the question of whether one should automate entries into their operating logs. However, if you do decide to integrate and route certain entries into your logs automatically, consider these suggestions.
Automated Logging Best Practices
1. Do be judicious. Consider what should be routed to your log. It should be infrequent. It should be important. The log entries should not be the only indication that operators will get with respect to alarms.
2. Require acknowledgements. It’s great that the log entries automatically appear in the logs; however, the principal purpose of an operating log is to ensure that operators are aware of the context of their operation. It does not help that an entry is in the log, if an operator doesn’t see and acknowledge it. You should configure your logbook so that operators MUST acknowledge automated entries. This implicitly means that automation should not be delivering more automated log entries than an operator can respond to while running the operation. See #1 above.
3. Do provide a way for operators to silence or suspend chatty automation. In real-time operations, sometimes components, transducers or communications will fail in such a way that an alarm is both repeating and distracting. This can actually disrupt your operators by overrunning them with messages and distracting them from the important signals that are correct. They should be able to identify and suspend a noisy signal.
4. Do consider adding a practice to confirm the integrity of the automation from time-to-time, where operators inspect the source systems for accuracy. After all, most alarm signals rarely occur and without system integrity checks it can be hard to be sure that the systems are, in fact, working as expected. Have some way to periodically ensure that routing is in tact.
5. Don’t use automation to be lazy. In some situations it may simply be better to have operators make entries to combat fatigue. It’s a balancing act, though. Too much busy work can be a bad thing, as well.
6. The best practice will be to have more than one way for operators to become aware of important conditions – providing fail-safe redundancy is best, when possible.
So, whatever you decide, just make sure you’ve considered all the pros and cons of using automation to add entries to your operational log, before filling your log with automated content.