Arbitration & Allocation
Arbitration and allocation is the ISA-88 mechanism by which control recipes claim physical resources — units, equipment modules, shared services — at runtime. It is the difference between 'recipe says it needs a 2,000 L reactor' and 'recipe is running on R-201 right now'.
Read the full summary
Arbitration is what makes recipe portability real: recipes describe capability requirements, and the arbitration engine binds them to specific instances at the right moment.
On this page · 9 sections
How does Arbitration & Allocation apply to your shop floor?
Pick your industry and scale — Ask V5 rewrites the definition in your context, gives a worked example, and shows what V5 does on day one.
01What arbitration and allocation are
ISA-88 separates resource definition (units, equipment modules, shared services) from resource use (recipes). Arbitration is the runtime matchmaking; allocation is the resulting reservation. A control recipe declares its needs, the arbitration engine finds compatible available resources, and the allocation is recorded for the duration of the request.
- Resource — any constrained entity: a unit, an equipment module, a shared utility (chilled water, vacuum, nitrogen).
- Capability — what a resource provides ('jacket-cool', 'CIP-ready', 'working-volume ≥ 1000 L').
- Request — what a control recipe needs at a particular moment in its lifecycle.
- Match — the arbitration result; a specific instance satisfying the request.
- Allocation — the reservation, holding the resource for the requestor until released.
02When arbitration happens
Different resources are arbitrated at different lifecycle points:
| Resource | Arbitration moment | Duration |
|---|---|---|
| Unit | Unit-procedure start | Unit procedure |
| Equipment module (shared CIP skid) | Phase start using it | Phase |
| Utility (chilled water, vacuum) | Phase start with demand | Phase or operation |
| Operator (signature requirement) | Permissive evaluation | Signature event |
| Material (lot reservation) | WO release or operation start | Operation |
Arbitrating too early (e.g. units at WO release rather than unit-procedure start) ties up resources unnecessarily and creates scheduling rigidity. Arbitrating too late risks starving an in-flight batch.
03Capability matching
The matching algorithm walks the capability vocabulary:
- Request resolves required capabilities and constraints (working volume range, material compatibility, current state).
- Engine queries the resource pool of compatible class(es) with current state filters (in-service, clean if required, calibration current).
- Candidates are scored by configured policy — round-robin, preferred-unit, least-recently-used, or campaign-locked.
- Highest-scoring candidate is offered; on acceptance, allocation is recorded; on rejection (race with another request), engine retries.
- If no candidate found within timeout, the requesting phase holds on a 'no compatible resource' exception.
04Conflict handling
- Concurrent requests — engine serialises; first request wins; second retries with the next-best candidate.
- Priority — high-priority work orders pre-empt low-priority queueing (configured policy, never default).
- Starvation — long-waiting requests escalate priority over time to prevent indefinite blocking.
- Deadlock — engine detects cycles (A waits on B waits on A); raises operations alert and refuses allocation.
- Force-allocation — privileged override available with mandatory rationale; logged as deviation.
05Release
Allocation that is not released is the most common arbitration bug. Discipline:
- Every arbitration scope (unit procedure, phase) has explicit release at its end.
- Abandoned batches release allocations on abort or stop.
- Stuck allocations (resource still allocated after the requesting batch ended) surface on dashboards and trigger auto-release after a timeout.
- Maintenance-driven OOS allocation has explicit clear path back to available pool.
- Resource state on release returns to known clean status (or dirty status flagged for CIP) — no ambiguity for the next requestor.
06Audit and record
- Every allocation captured with timestamp, requestor (batch/phase), resource, capability set matched and policy applied.
- Force-allocation events flagged for QA review with rationale.
- Resource history reconstructable — which batches used R-201 in Q3, in what order, with what changeover times.
- eBR records the resource bound to each phase, supporting the 21 CFR 211.188 'identification of major equipment' requirement.
07Cross-industry examples
- Pharma — multi-product API plant arbitrates jacketed reactors, filter-dryers and chromatography skids across simultaneous batches.
- Biopharma — shared chromatography skid arbitrated phase-by-phase across multiple product programmes.
- Food — shared pasteurisers and fillers arbitrated across SKUs with allergen-changeover gating.
- Cosmetics — shared vacuum-emulsifier arbitrated across emulsion variants with cleaning-strategy-aware sequencing.
- Chemicals — shared utilities (chilled water capacity, nitrogen pressure) arbitrated across exothermic reactions.
08Common mistakes
- Recipes pinning to specific instances ('R-201') rather than capabilities — defeats arbitration.
- Allocation at WO release instead of unit-procedure start — units tied up for hours before they are needed.
- No release on abort — stuck allocations require manual clearing.
- Force-allocation without rationale capture — audit useless.
- Capability vocabulary inconsistent across resources — matches fail unpredictably.
- Priority policies poorly configured — high-priority work starves routine production or vice versa.
- No dashboard surfacing allocation state — engineers learn about contention from operator complaints.
09How V5 Ultimate handles arbitration
Frequently asked questions
Q.Should I arbitrate at WO release or at unit-procedure start?+
At unit-procedure start, except for cases where pre-reservation is process-critical (e.g. a unit that needs a 4-hour pre-conditioning before use). Late binding maximises scheduling flexibility.
Q.What happens when no resource is available within timeout?+
The requesting phase holds in an exception state with a 'no compatible resource' code. The scheduler can either wait, escalate to operations, or take a recipe-defined alternative path (e.g. defer the unit procedure).
Q.Can two recipes share the same unit simultaneously?+
Generally no — units are exclusive resources. Shared equipment modules within a unit (e.g. a sampling system) can be shared if their state model supports it.
Q.How does arbitration interact with finite-capacity scheduling?+
The scheduler proposes allocations as part of the plan; arbitration enforces them at runtime and may reject if real-world state diverges (a unit went OOS unexpectedly). The scheduler then replans the affected work.
Q.What is force-allocation and when is it acceptable?+
An override that allocates a resource despite normal blocking conditions (e.g. allocating a unit before its CIP completes because hold-time risk is manageable). Acceptable in defined exceptional circumstances with elevated authorisation and full deviation capture — never as routine practice.
Primary sources
Further reading
Want to see how Arbitration & Allocation could fit into your own records and workflows? Explore the related V5 pages or talk to our team about what applies to your operation.