Unit Class Library
A unit class library is the catalogue of equipment unit classes — Reactor, Crystalliser, Drier, Tablet Press, Coater, Filler, Capper — that recipes can reference without binding to specific equipment instances. ISA-88.01 §4.4 defines the unit as the major equipment grouping that owns the procedural execution; the unit class is the reusable abstraction above the unit instance.
Read the full summary
A maintained unit class library is what lets a site recipe say "requires a jacketed reactor 1,000–3,000 L" rather than "requires Reactor R-201" — preserving recipe portability and equipment-train flexibility.
On this page · 8 sections
How does Unit Class Library 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 a unit class library is
ISA-88's physical model goes: Enterprise → Site → Area → Process Cell → Unit → Equipment Module → Control Module. The unit is the major equipment that holds the procedural execution — it's where a phase runs. A unit class describes a family of units that share capabilities; specific unit instances are members of a class.
- Class name and unique class ID — "JacketedReactor-Glass", "FluidBedDrier", "TabletPress-RotaryStation".
- Capability tags — what the class can do ("jacket-heat", "jacket-cool", "agitator-variable-speed", "vent-filter", "CIP-spray-ball").
- Allowable parameter ranges — working volume (e.g. 500–3000 L), temperature (e.g. -10 to +120 °C), pressure rating, agitator rpm.
- Default cleaning programme — which CIP/SIP phase class applies.
- Material-compatibility tags — "316L stainless", "glass-lined", "PTFE-wetted".
- Qualification requirements — what IQ/OQ/PQ evidence is needed for each instance.
02Why the library matters
Without a unit class library, recipes pin to specific unit instances ("Reactor R-201"). Consequences:
- Tech transfer is painful — the new site does not have R-201.
- Capacity planning is rigid — only R-201 can run the recipe even if R-202 is available.
- Equipment changes (replace R-201 with R-201A) require recipe revision across all affected recipes.
- Multi-site recipe management is impossible — every site has different equipment names.
With a unit class library, recipes reference the class; instances are allocated at control-recipe generation. Equipment swaps, capacity shifts and tech transfers become operational rather than recipe-revision events.
03Capabilities vs instances
The capability tag is the matching language. A phase declares the capabilities it needs (e.g. "jacket-heat", "agitator-variable-speed", "working-volume ≥ 1000 L"); a unit class declares the capabilities it provides; a unit instance inherits its class's capabilities plus any instance-specific overrides (e.g. "out-of-service").
At control-recipe generation, the equipment-arbitration step matches phase capability requirements against available unit instances of compatible classes. The richer the capability vocabulary, the more precisely arbitration can work.
04Qualification linkage
Each unit instance is qualified individually (IQ/OQ/PQ per Annex 15), but the qualification protocol is templated from the unit class:
- Class defines the IQ scope — installation, utility connections, documentation.
- Class defines the OQ scope — operational ranges to challenge, alarms to verify, interlocks to test.
- Class defines the PQ scope — performance with representative product, reproducibility.
- Instance carries the executed qualification evidence — which protocols passed, when, by whom.
- Re-qualification triggers (calibration drift, major maintenance, software update) are class-defined, instance-tracked.
05Library governance
The unit class library is a controlled artefact:
- Class definitions are versioned; revisions trigger impact assessment on instances.
- Adding capabilities to a class typically requires re-qualification or at least a delta OQ on every instance.
- Library Owner role — usually engineering / facilities, with MES + QA review.
- Periodic review per Annex 11 to retire obsolete classes and prevent duplicates.
- Naming convention enforced — no "Reactor-NEW", "Reactor2" sprawl.
06Cross-industry examples
- API manufacture — JacketedReactor-Glass, JacketedReactor-Hastelloy, Crystalliser, FilterDryer-NutscheDryer, FilterDryer-Agitated, RotaryEvaporator.
- OSD pharma — Blender-Vbender, Blender-Bin, Granulator-HighShear, FluidBedDrier, Mill-CoMill, TabletPress-RotaryStation, Coater-Perforated.
- Biopharma — Bioreactor-Stirred, Bioreactor-WaveBag, Centrifuge-DiskStack, Filter-Crossflow, ChromatographySkid, BufferTank-Hygienic.
- Food / beverage — MixingTank-Hygienic, Pasteuriser-HTST, Homogeniser, Filler-Rotary, Capper, Labeler, BlowMoulder.
- Cosmetics — Emulsifier-VacuumKettle, Premix-Tank, FillingLine-Tube, FillingLine-Bottle, Cartoner, Caser.
07Common mistakes
- Single-instance classes — every reactor is its own class, defeating reuse.
- Classes named after vendors ("GEA-Niro-Drier") rather than capability ("FluidBedDrier") — vendor swap requires recipe revision.
- Capability tags free-text — typos prevent capability matching at arbitration.
- No version control — class capability changes silently propagate.
- Instance attributes diverge from class — instance has capabilities the class did not declare; arbitration broken.
- Qualification evidence not linked to class — re-qualification trigger not enforced.
- Library duplicate classes ("Reactor", "ReactorNew", "ReactorRevised") — library becomes a junk drawer.
08How V5 Ultimate handles unit class libraries
Frequently asked questions
Q.How granular should unit classes be?+
Granular enough that two instances of the same class are functionally interchangeable for recipe purposes. Two glass-lined reactors with the same working-volume range and capabilities can share a class; a glass-lined reactor and a Hastelloy reactor should be separate classes because their material compatibility differs.
Q.Can a unit instance belong to multiple classes?+
ISA-88 strictly says one class. In practice, capability tags handle the multi-trait reality — a reactor of class "JacketedReactor-Glass" might carry capability tags "CIP-ready" and "high-vacuum" that not every member of the class has. Recipes match on capabilities, not class membership.
Q.How does this relate to the equipment master in the ERP?+
The ERP carries the asset-management view (financial, maintenance, depreciation). The unit class library carries the procedural-control view (capabilities, qualification, recipe compatibility). They share the instance identity but serve different consumers. V5 keeps them synchronised via the standard equipment-master integration.
Q.What happens when a unit is taken out of service?+
The instance's status flips to Out-of-Service in the equipment state machine. Capability matching at arbitration excludes the instance. Recipes that depend on the class continue running on other instances. If the class drops below capacity, work-order scheduling holds new releases until availability returns.
Q.Do I need a unit class library even for single-line, single-site operations?+
Honestly, less critical — a single-instance class adds overhead. But even single-site sites grow, add lines, install a backup, or replace equipment. Starting with the library discipline avoids retrofitting it later when the cost is much higher.
Primary sources
Further reading
Want to see how Unit Class Library could fit into your own records and workflows? Explore the related V5 pages or talk to our team about what applies to your operation.