In my opinion, the first step is to update the UI to disallow the write in the first place. The user should know whether-or-not they have permission to write before they attempt to do so. Tags have a “.CanWrite” property (value is unique per-client) and can be bound in the UI to disable the entry in the first place. Note that this doesn’t capture all possible scenarios as might be required from a proper audit trail (those previously listed, also tag deadband preventing a value update, floating point representation error after successful write, etc.).
I’ve not built a proper audit tool personally (despite my own empty threats to do so). But, I have spent enough time compiling data for other parties (managers, engineers, lawyers) that I’ve resolved that:
- It’s a difficult problem to solve for ‘all users’ & ‘all use-cases’.
- I’m grateful that I have too much data to work with, instead of not enough.
- Despite 1 & 2, I’m still frustrated every time I have to handle all of the useless data in the audit logs.