Our ordinary fixture-inspection request is brief and the application sometimes misses it. I cannot find agreed ownership or clearing rules. How should both teams define receipt and completion for this coupon job? Safety functions are separate.
Have you observed the request arriving and disappearing between application reads, or is that still the suspected explanation? I'd establish that first, then have both interface owners define how the request remains identifiable until its agreed response, rather than just choose a less unlucky pulse width.
The retained trace shows the request rise and fall between two application reads. The PLC clears it after a duration; the application supplies no receipt acknowledgement. That explains this missed request.
Give each response a meaning people can explain. Request seen, accepted for processing and inspection completed are not interchangeable. Otherwise the pulse problem can be fixed while the shift still misreads which stage the coupon reached.
Both owners are drafting it. PLC retains an identified request; application owns the matching receipt response. Daniel and Amara, they are separating receipt from acceptance and completion, including a busy response rather than implying every seen request starts an inspection.
That separation is useful. The clearing rule must name which response permits it and what is retained afterwards, so a request is not lost merely because its receipt was acknowledged before the application had somewhere durable to keep it.
Aaron's question belongs in the operator explanation too. A timeout can mean the result is unknown, not that the inspection definitely never happened. Please don't make the recovery message casually invite another attempt.
The current draft preserves unresolved attempts on timeout with no automatic resubmission. Hazel, receipt is defined after the application retains the identified request; acceptance remains a separate decision. Both sides keep the identity needed to reconcile the later result.
The agreed identity includes a durable run scope and attempt value, not just a counter reset at startup. Both owners have added restart reconciliation and the case where durable retention fails before receipt is acknowledged.
Now exercise the actual implementation with controlled delayed reads and replies, including duplicate receipt, old completion and restart. The point is to show that timing variation changes waiting, not ownership of the inspection or the number of accepted requests.
The offline implementation checks now retain each accepted request once and link repeated responses to it. A late completion cannot close another attempt. Unresolved and busy cases remain visible without creating another accepted inspection; installed timing checks are still due.
Keep that remaining check prominent in the handover. Has the covering technician seen the busy and unresolved messages, or has only the development team read them?
Only development so far. The technician's message check and the installed handshake assessment are scheduled together under the interface owners. The missed-pulse cause is identified and the software design is checked offline, but I have not marked the operational handover complete.