I don't know if this is available in an audit log. It would be polite to ask for your particular use case, but I just wouldn't understand it. With buffering (to name one), a PIValue including its particular time stamp may be written milliseconds to hours after it was captured by whatever interface.
@Joel: The event flow of the PI System is not deterministic and does not offer a guarantee of feedback. The variation of time you would notice for the calls to complete is multiple:
- network latency
- connection failover if used with a high availability
- PI Data Archive
- buffering enabled
- disk I/O
- machine resources
Are you interested to know when the value is really archived versus the represented time of the value? This would give you like a data "residence time in the data pipeline". Can you describe more your use case?
In addition to what Rick and Mathieu posted, I would be curious about the data source. Is this one of OSIsoft's Interfaces? If so and if it is based on UNIINT there's a good chance to trace when updates are read / received from the data source and when these events are being forwarded. With a UNIINT based interface I would suggest enabling the tracing for a single point / data item. If the communication from the interface to PI Data Archive (PI Server) is buffered, it is possible to monitor the buffer queue. This doesn't show each single event but because the buffer operates first-in-first-out, one can estimate how long it would take. Usually there shouldn't be any significant queue visible - even not with weak links because exceeding the bandwidth is even worse if the bandwidth is limited.
When a new event arrives for a particular point and the Timestamp of this arriving event is more recent than the current snapshot, the snapshot becomes updated with the new event. Depending on compression, the previous snapshot becomes pushed into the archive.
What can be useful in your case as well is creating a small application that signs up with PI Update Manager for either PI Snapshot or PI Archive updates and regularly check for arrived events. If you sign up for snapshot or archive updates really depends on what information you are interested in. Your application would need to log the timestamps of when it request for updates from Update Manager. Polling news from PI Update Manager once a second is doable. This is till not 100% accurate but allows you to get a rough idea.
I don't know if this is available in an audit log.
The audit trail doesn't record each point update received but e.g. when a point becomes substituted. If each update from each regular resource would generate an audit record, audit files would grow larger than PI Data Archives.
Think Mathieu hit the nail on the head in that the PI System is not deterministic. It sounds like you want to know when the value is observable in the PI Server and not really when it was written by the source application/interface.
Assuming you're not doing this for a mass number of tags, you could use a high frequency poll via AF SDK (not PI SDK) of the Update Manager (e.g. 50ms) to know approximately when the value first became observable, although the PI Server could be overloaded/busy and delay in serving your RPC - when the value is actually observed would vary depending on the consumer's polling cycle.
What is the "error" interval you're able to tolerate? i.e. do you need to know the exact time when the value is written? or is a 500ms "lag" sufficient? You also did not specify what "written" means. Do you mean the snapshot or archive? If it's to disk, there's some finite time interval before you can read the data back out. This list goes on and on so it would be extremely helpful if you can describe what you're trying to do. Please don't forget the PI System is not a control system, you should not be using it for real time control :-).