I am documenting an FR5 machined-bush interface for a planned enclosed machining cell. The machine supplier means request received when writing ready; the integrator means loading area available. I need an agreed sequence, not another revised word that leaves those meanings in conflict. What should the teams decide together?
Ask what each side would do after receiving ready while preparation is incomplete. That example exposes the disagreement without debating which supplier owns the English word.
I would write a small event sequence with both teams, beginning with a request and an explicit receipt acknowledgement. Then show the separate condition they need before loading can proceed. For each, record who produces it, what evidence makes it true and what the receiver may do. The useful question is whether both suppliers predict the same next action, not whether the signal names look tidy.
Lin, be careful with may proceed. This ordinary interface cannot replace the required safety conditions. The document needs to keep those responsibilities separate.
Yes, I meant the process sequence only. Safety permissions and protective functions remain their own assessed design. I'll spell that out rather than leave proceed doing too much work.
Their current descriptions would produce different actions in Aisha's incomplete-preparation example. The integrator would interpret receipt as available space. We have not agreed clearing behaviour either.
Not in the original notes. We have now agreed that receipt acknowledgement and loading-area availability are separate process meanings. The revised sequence still needs request correspondence, clearing and restart cases before I can accept it.
For the restart walkthrough, write what each side actually knows on return, including any retained request or acknowledgement. Then ask each supplier what they would publish and what action they would wait for. A blank startup diagram can conceal the old state you are trying to reconcile. You do not need to invent new signals during the meeting; first establish the behaviour the design has to support.
Will maintenance see those waiting reasons in the handover? Otherwise the clarified interface can still leave an unexplained ready message on the screen.
Maintenance is reviewing the waiting descriptions with us. The normal sequence is clearer, but fault and restart responses remain open. I have not treated the renamed entries as completed interface acceptance.
I'd be interested in the delayed-old-reply result when the teams reach it. Agreement on the happy path is common; the unresolved correspondence is where your new definitions will be tested.