Forward refinement for dynamic concurrent processes #
This file introduces the first process-level refinement notion for the dynamic concurrent core.
The central object is ForwardSimulation between two Process.Systems. It
captures the usual implementation/specification picture:
- implementation and specification states are related by a simulation invariant;
- every admissible implementation start state can be matched by some specification start state;
- every concrete implementation step can be simulated by a specification step;
- the simulation may additionally insist that the two steps agree on events, tickets, controller data, or local observations; and
- safety obligations may be transferred from the specification side back to the implementation side.
This gives a reusable refinement layer that is independent of any particular concurrent frontend and rich enough to support observational reasoning, not just state-reachability arguments.
ForwardSimulation impl spec matchStep is a forward simulation from the
implementation system impl to the specification system spec.
The meaning is:
- every initial implementation state is related to some initial specification state;
- assumptions are preserved from implementation to specification;
- every implementation step transcript can be matched by some specification
step transcript satisfying
matchStep; - related safe specification states imply safe implementation states.
This is intentionally phrased over the dynamic Process.System core rather
than any particular concurrent frontend.
The parameter matchStep determines what behavioral information the
simulation preserves at each step. Choosing different transcript relations
recovers event-preserving, ticket-preserving, controller-preserving, or
observation-preserving refinements.
- assumptions {pImpl : impl.Proc} {pSpec : spec.Proc} : self.stateRel pImpl pSpec → impl.assumptions pImpl → spec.assumptions pSpec
Instances For
Choose the matching specification transcript for one implementation transcript.
This is the specification-side step selected by the simulation for the given implementation step.
Instances For
The chosen matching transcript satisfies matchStep and preserves the state
relation to the next residual states.
matchedState sim run hrel n is the specification-side state reached after
matching the first n steps of the implementation run run, starting from an
initial related specification state witnessed by hrel.
This is the fundamental state-transport construction behind run-level refinement: it recursively follows the implementation run while using the simulation to pick matching specification transcripts.
Instances For
The specification transcript chosen to match the nth implementation step of
the run run, relative to the initial related specification state witnessed by
hrel.
This is the stepwise witness used to build the whole matched specification run.
Instances For
mapRun sim run hrel is the specification run obtained by recursively matching
every step of the implementation run run, starting from an initial related
specification state witnessed by hrel.
So mapRun turns a forward simulation into an execution-level translation from
implementation runs to matching specification runs.
Instances For
At every step index n, the mapped specification run remains related to the
implementation run by stateRel.
At every step index n, the mapped specification transcript matches the
implementation transcript by matchStep.
This is the run-level form of the step-matching guarantee.
If every state along the mapped specification run is safe, then every state along the implementation run is safe.
This is the basic safety-transport principle of forward simulation.
If an implementation run is admissible, then its mapped specification run is also admissible.
So ambient assumptions are preserved along the run translation induced by the simulation.
The first n steps of the mapped specification run match the first n
implementation steps according to matchStep.
The mapped specification run matches the implementation run at every finite
prefix according to matchStep.
A controller-preserving simulation preserves the current controller sequence of every finite run prefix.
A controller-path-preserving simulation preserves the controller-path sequence of every finite run prefix.
An event-preserving simulation preserves the stable event sequence of every finite run prefix.
A ticket-preserving simulation preserves the stable ticket sequence of every finite run prefix.
An observation-preserving simulation preserves one party's packed observations of every finite run prefix.
If the specification system satisfies safety under some fairness assumption, then the implementation system also satisfies safety under any implementation fairness assumption that transfers along the simulation.
This is the top-level preservation theorem: once fairness is known to transfer, forward simulation lets one discharge implementation-side safety obligations by proving them on the specification side.