Our Python log, PLC trace and controller events disagree on time. The job label was reused after restart too. I can see a timeout in this coupon-acceptance attempt, but I cannot tell whether the later acknowledgement belongs to it. How do I reconstruct this without choosing whichever clock tells the neatest story?
Keep each source's event order and original times first. Add the restart boundaries and whatever request identity each side actually recorded. A shifted clock may explain some ordering, but it cannot make a reused job label unique. Which identity travels with that acknowledgement?
Only the job label appears in the application message. The PLC trace has its own request counter, but our Python log never recorded that counter beside the reused label. I have left the acknowledgement unassigned.
Sofia's question may recover a link without guessing from times. I'd still show each clock's uncertainty separately, and get the two interface owners to confirm which events really correspond before calculating a response duration.
The retained PLC trace links its acknowledgement to the request before restart. That identifies the PLC exchange, but Python reused the same label for its next attempt and kept no shared counter. We cannot prove which application attempt received that event from the surviving record alone.
And use this exact gap for the revised logging acceptance test. A durable run and attempt identity needs to survive the actual interface, not exist only in Python's nicest log. Include a restart with a retained acknowledgement and check what the person reading the report can distinguish. Your historical conclusion can stay limited while the next capture gets better.