An interactive tour of Emerson DeltaV — one of the dominant distributed control platforms in life-sciences manufacturing. Click through, build a recipe, tune a simulated bioreactor-style PID loop, and test what you've learned.
DeltaV is a Distributed Control System (DCS) built by Emerson. In a biopharma plant it's the central nervous system: every temperature loop, every valve, every batch step, every operator action — all orchestrated and recorded by DeltaV.
Think of it as the difference between a chef hand-stirring a pot and a kitchen with sensors on the stove, taps that turn themselves, and a digital recipe book that refuses to skip a step. That's a DCS — and in a regulated environment, the "refuses to skip" part matters enormously.
Controllers sit on the plant floor, close to the equipment. If a workstation crashes, the bioreactor keeps running. Resilience by design.
Controllers scan inputs and execute logic on a fixed cycle (typically 100–500 ms). PID loops, interlocks, and sequences run with predictable timing.
Audit trails, electronic signatures, version-controlled configuration. The system was built for industries where an auditor will ask: who changed this setpoint, and why?
You don't program a controller line-by-line. You instantiate Control Modules (a PID loop, a valve) and Equipment Modules (a bioreactor) from reusable library classes.
DeltaV Batch implements the ISA-88 standard directly. Recipes, phases, units — they're first-class citizens, not bolt-ons. Critical for biologics manufacturing.
Continuous Historian records every tag. Batch Historian links data to lot numbers. When deviations happen — and they will — investigators have the breadcrumbs.
A failed batch of monoclonal antibody can cost €5M+ and weeks of lost capacity. A DCS that enforces every recipe step, locks out manual overrides without justification, and produces a tamper-evident batch record isn't a luxury — it's the price of admission to manufacture under GMP.
DeltaV follows the Purdue / ISA-95 model: field instruments at the bottom, business systems at the top, with controllers and operator stations in between. Click any block below to drill in.
DeltaV organises hardware and software into layers that map to the Purdue Model. Field instruments at the bottom feed controllers, which talk to operator stations, which roll up to MES and ERP. Each layer is isolated by network — and each layer is validated separately in a GMP environment.
A DCS value is evidence, not the whole story. A deviation investigation should correlate the trend with device health, calibration context, and final-element response.
Transmitter diagnostics are normal.
Last calibration is within interval.
Base addition response is tracking controller demand.
At 14:22:16, BR-201 experiences a temperature excursion during Growth Hold. Select a timestamp to see three evidence streams update together.
PV near SP, controller output steady.
No active alarms or operator actions at this timestamp.
Batch BR-201 is in Growth Hold with normal phase execution context.
Normal DCS/BPCS control, protective interlocks, and SIS functions can all act on the same plant, but they are not the same layer.
A BPCS loop maintains temperature or level during normal operation.
Example action: Modulate cooling output to hold 37.0 °C.
What it is not: Not a dedicated safety instrumented function.
| Layer | Main purpose | Example |
|---|---|---|
| Normal control | Maintain process target | PID adjusts jacket cooling. |
| Protective logic | Block or override inappropriate action | Prevent transfer while high level exists. |
| SIS | Independent safety function where required | Dedicated high-high action for a hazardous scenario. |
Controller-resident items include control modules, equipment logic, parameters, and execution configuration needed for real-time control. Operator screens and engineering tools may reference that logic, but the controller must execute its strategy independently.
ProfessionalPLUS is the configuration authority. Controllers execute the downloaded runtime logic. That distinction matters when deciding what continues running during supervisory outages and what must be protected by backups.
Backups protect the ability to recover configuration, graphics, recipes, historian settings, and system context. They do not replace validation evidence; restored systems still need controlled verification appropriate to the change or incident.
Batch Executive is a supervisory orchestration layer. It coordinates recipe execution and resource usage, while lower-level phase and control logic acts on equipment through controllers.
Biologics aren't made continuously — they're made in batches. ISA-88 (S88) is the standard that splits a manufacturing procedure into nested layers. DeltaV speaks S88 natively. Click each layer below to expand.
A Procedure is the highest level of an S88 recipe — it defines what we're making, end to end. It links together every Unit Procedure required to produce one batch of product. The procedure itself runs no equipment directly; it sequences and synchronises the layers below.
Recipes describe the procedure. Equipment objects describe the plant resources that execute it.
Represents: The top-level manufacturing area or production context.
Typically contains: Units, shared resources, recipes, and area-level context.
BR-201 example: Upstream Culture process cell.
Validation / maintainability: Defines boundaries for recipe execution, ownership, and change impact.
| Object type | Plain-English role | BR-201 example |
|---|---|---|
| Process Cell | Manufacturing area | Upstream Culture |
| Unit Module | Major batch asset | BR-201 Bioreactor |
| Equipment Module | Reusable equipment grouping | Jacket Control |
| Control Module | Lowest control object | TIC-201 or XV-101 |
| Phase | Executable procedural action | Equilibrate_Phase |
A recipe is not the same thing as live execution. Batch Executive coordinates the control recipe, resource use, phase calls, and records generated during the batch.
The manufacturing intent is defined before runtime: procedural structure, formulas, and phase calls.
What DeltaV is doing here: Holding the approved procedural structure and recipe metadata.
Why this matters in biopharma / CSV: The approved recipe becomes the basis for controlled execution and traceability.
A master recipe is the approved template. A control recipe is the runtime instance for a specific batch, with selected formula values, equipment context, and execution history.
The procedure defines sequence. The formula supplies product-specific values such as amounts, temperatures, or hold times without rewriting the procedural structure.
A recipe parameter expresses process intent, such as target volume. An equipment parameter belongs to the module or phase that executes that intent on real plant assets.
Phase parameters pass values into executable phase logic, such as target mass, agitation setpoint, or transfer destination. Report values flow back as evidence.
Equipment acquisition reserves a unit or resource for a batch so another recipe cannot use the same asset in a conflicting way.
Tune, disturb, and recover a real-time bioreactor temperature loop. The main chart stays visible while you work.
Run a disturbance, tuning change, or mission, then ask for recommendations.
Select and start a failure scenario.
Return the loop to stable operation.
Select a mission and press Start Mission.
This mirrors the kind of view a control systems engineer sees in DeltaV Control Studio. Function blocks — AI, PID, AO, ALM — wired together to form a complete temperature control loop. Click any block to inspect or change its parameters. Changes apply immediately to the running demo controller. Values stream live along the wires.
Topology is locked for this demo — in real Control Studio you'd drag-wire pin to pin. Open any block to see how its parameters shape behaviour.
Click the SP_201 block and change its value to 40 °C — watch the PID respond and the AO drive harder. Click TAH-201 and lower its limit to 38 — see it trip in real time. Click TIC-201 and switch Mode to MAN — now you're driving the valve directly without the loop fighting you. This is exactly what happens in commissioning.
Perfect backend logic is useless if the operator can't understand the screen during a 3 AM crisis. Modern HMIs like DeltaV Live adhere to the ISA 101.01 Human-Centered Design (HCD) standard. The goal? Eliminate "alarm floods" and visual clutter so the operator can instantly spot anomalies.
dsp.tag context to understand reusable faceplate bindingLegacy systems used bright neon green for "running" and red for "stopped" on a black background. HCD systems use grey backgrounds. Pipes are dark grey. Static equipment is muted. Color is only used to draw attention to an abnormal state.
You cannot rely on color alone (up to 8% of male operators are colorblind). A critical alarm isn't just red—it's a red square. A warning is a yellow triangle. The shape guarantees the information is communicated regardless of hue.
A raw number like 85.0 L means nothing alone. DeltaV Live embeds historical sparklines directly into the graphic, alongside analog indicator bars. At a glance, the operator knows if the value is high, and if it's rising or falling.
In the Legacy theme, push the level to 92%. Notice how the flashing red number competes with the bright blue water and neon green pipes for your attention.
Now, flip to DeltaV Live. The screen calms down. Notice the yellow triangle alarm shape, the analog context bars under the numbers, and the embedded trend chart for temperature.
Start with philosophy, toolkits, style guide, console design, alarm conventions, and display templates before building screens.
Translate user, task, and functional requirements into display levels, layouts, display sets, and contextual displays.
Build displays and consoles in Graphics Studio, test them, train operators, and commission the runtime workstations.
Operate, audit, improve, manage change, and eventually decommission displays with the same controlled lifecycle.
DeltaV Live graphics are built in the central configuration database, then published to runtime databases on selected workstations. Operators receive an update indication, but accept the refresh when it will not interrupt work.
Display Sets define the L1-L4 hierarchy available to a workstation. Layouts define monitor frames: dynamic frames hold process displays, while static frames are used for fixed items such as alarm banners or toolbars.
A contextual display opens with runtime context. The same faceplate can bind to whichever control module the operator clicked by using dsp.tag and optional dsp.Context1 through dsp.Context4 values.
An overview display helps the operator spot broad abnormality. A detail display supports unit-level investigation. A faceplate is a contextual control surface for one module, loop, valve, or device.
Trends and bars show direction and proximity, not just a number. That helps an operator see whether a process is drifting, recovering, or approaching an alarm limit.
Display hierarchy lets operators move from plant overview to area, unit, equipment, and faceplate without losing context. It reduces hunting during abnormal situations.
When a single feed pump trips, fifty downstream sensors might trigger alarms within seconds. A legacy HMI just gives you a scrolling wall of red text. DeltaV Live uses filtering, auto-eclipsing, and shelving to point the operator directly to the root cause. Play in the sandbox below to see it in action.
An operator in the Bioreactor suite shouldn't see alarms from the Central Utilities boiler. By filtering the active list based on the logged-in user's role, the system prevents cross-area distraction.
If a tank has a High warning and a High-High critical alarm active simultaneously, showing both is redundant. The critical alarm "eclipses" (hides) the warning to clear up screen real estate.
What do you do with a broken sensor that keeps triggering false alarms every 2 seconds? You "Shelve" it. It is temporarily suppressed from the main list so it doesn't mask real plant emergencies.
Manipulate the plant below to generate alarms. Then use the tools on the right to manage the resulting flood.
DeltaV Live can add alarm rollups to the Navigation Bar. The count can be disabled, limited to the primary control display, or based on the configured Plant Hierarchy for the display.
Primary control display counts alarms associated with the selected display, such as the BR-201 unit display.
Alarm · Permissive · Interlock · Trip. These are not interchangeable: one informs, one allows start, one blocks or overrides, and one forces a protective state.
Informs the operator that attention or action may be required. It does not necessarily block action.
Operator sees: annunciation, priority, and acknowledgement state.
Allows an action to start only when required preconditions are true.
System does: prevents start until the condition is met.
Blocks or overrides an action while an unsafe or inappropriate condition exists.
System does: enforces logic while protected state exists.
Forces equipment or process into a protective stopped or safe state.
System does: drives a defined response and may require reset.
The operator is warned, but the system action may still be possible.
Pump start: Allowed
Valve request: Allowed with warning
Fault state: No forced stop
Priority describes how urgently the operator should respond. Severity describes how bad the condition can become. Consequence explains what may happen if no action is taken.
Shelving is typically a temporary operator-visible removal from the main list. Suppression is usually configured logic that prevents an alarm from appearing under defined conditions.
A standing alarm remains active for a long time and can become background noise. An alarm flood is many alarms arriving quickly, often masking the initiating cause.
First-out thinking asks which alarm or condition likely initiated the event, rather than treating every later symptom as an independent root cause.
In older systems, updating a pump graphic meant editing 50 distinct screens manually. DeltaV Live uses Object-Oriented Configuration via Class-Based GEMs (Graphical Elements). You edit the Master Class, and every instance in the plant updates instantly. But what if one specific pump is piped backwards? You apply a "local override" to that instance.
A single source of truth. You define the pump's colors, dynamic animations, and tag bindings in one central file. This completely eliminates copy-paste validation errors.
When the Master Class is updated, the changes propagate to every instance in the database. A site-wide graphical update can take minutes instead of weeks.
If one pump is mounted upside down, you don't build a new class. You rotate that specific instance. It keeps its unique rotation but still inherits future color updates from the Master.
Graphics Studio standards are shared constants or references used by displays, frames, and GEMs. If every display background references the same color standard, a controlled change to that standard cascades consistently through the library.
S_DispBackColor
Change the standard value. Each preview below is still its own GEM or display object, but the background property resolves through the same library standard.
Change the Master Class properties below. Watch how the instances on the right instantly inherit the changes.
1. Select Pump #3 and click Flip Horiz. Because it was piped backwards, you override that one instance.
2. Now, go back to the Master Class on the left and toggle the HMI Theme back to Legacy.
3. Notice the OOP magic: Pump #3 instantly inherits the new neon green body, but retains its flipped local override. You didn't have to rebuild it!
A DCS is useless if you can't prove to an auditor that it meets the design requirements. You don't just turn on a biopharma plant; you validate it through rigorous Installation, Operational, and Performance Qualifications (IQ/OQ/PQ) using the V-Model methodology.
Every User Requirement Specification (URS) must tie directly to a functional design, which ties directly to a specific test case. If there's no test script for it, the requirement officially hasn't been met.
In CSV, "I saw it work" isn't good enough. You need screenshots, historian trends, and electronic signatures to prove exactly what happened at a specific, timestamped moment.
When a test fails, you don't just "fix the code." You raise a formal Deviation, investigate the root cause, update the design specification, formally update the code via version control, and then re-test.
Verify URS-14: If Tank Level (LI-101) > 90%, Inlet Valve XV-101 must automatically close.
Verify URS-15: Operator must NOT be able to manually open Valve XV-101 while Level is > 90%.
Test failed. Valve XV-101 opened manually while the High-Level Interlock was active. Classify the root cause to initiate the module fix.
When an OQ defect is found, the fix must move through deviation handling, controlled configuration change, approval, re-test, and evidence closure.
Manual_Open := Operator_Request;
High_Level closes XV-101 automatically,
but manual open is not continuously gated.Manual_Open := Operator_Request
AND NOT High_Level_Interlock;
Manual open is blocked while interlock is active.Configuration Item: XV-101_CTRL
Previous Revision: Rev 03 · New Revision: Rev 04
Changed By: Automation Engineer
Reason: Correct manual-open interlock bypass
Deviation: DEV-OQ-INT-001
Status: Defect recorded / investigation open
Actual project scope varies by system boundaries, intended use, risk assessment, and site procedures. This map shows common categories to consider.
What is being validated: Role-based permissions behave as intended.
Why it matters: Only authorized roles should modify approved configuration or execute controlled actions.
Example requirement: Only authorized roles can modify approved configuration.
Example evidence: Executed challenge with role comparison.
A requirements traceability matrix proves that each approved requirement has an implementation and a test. It connects intent, design, risk, and evidence.
Objective evidence is durable and attributable: executed protocol steps, screenshots, records, audit trails, historian data, or approved test results. A memory of success is not enough.
A retest proves the corrected failure now passes. Regression testing asks whether the fix may have affected adjacent functions that were already accepted.
It asks what failed, whether product quality or data integrity could be affected, what systems or records are impacted, and what evidence is needed before closure.
1. Start Step 1 by using the simulator slider to push the tank level past 90%. Watch the valve auto-close, then click PASS.
2. Proceed to Step 2. Leave the level above 90% and try to click the manual "Command XV-101 OPEN" button.
3. Discover the software bug, click FAIL, fill out the deviation report to recompile the logic, and then re-test to validate the system!
This workflow shows how a requirement is tested, how failure is handled, and how evidence is maintained through deviation, correction, and re-test.
The next question is not simply: "Did we test it?"
It is: "How do we decide what level of assurance this function deserves, and what evidence is proportionate to its risk?"
The V-Model is the validation spine: intended use moves down the left side into design and configuration, then evidence climbs the right side through checks, OQ, and intended-use confirmation.
Defines what the validated system must do from the user and process point of view.
Click the cards in the order that proves this requirement: BR-201 temperature control must maintain Growth Hold at 37.0 °C ± 1.0 °C.
Click each evidence example to see whether it would support validation review.
The strongest evidence is attributable, contemporaneous, tied to an approved requirement, and durable enough for review.
A failed expected result does not disappear. It becomes a controlled investigation path.
A risk-based way to establish confidence that software performs as intended — with assurance effort proportionate to the consequences of failure.
The CSV validation workflow showed how to:
CSA adds another question:
"Did we choose the right assurance strategy for this function and its risk?"
Alert the operator that the temperature loop has moved outside the defined operating band during a disturbance.
Apply the assurance reasoning to the XV-101 interlock defect from the CSV module.
The software behaviour under test is intended to execute the defined control or logic response consistently when the requirement condition is present.
Incorrect behaviour could result in a control response that does not match the specified operating requirement, undermining confidence in the automated function.
Yes. A requirement-linked behavioural test is justified because the function's expected response must be demonstrated objectively.
Requirement linkage, test condition, observed failure, deviation record, root cause, corrected logic, and successful re-test.
CSA does not remove the need for validation discipline.
It sharpens the rationale behind that discipline.
The CSV workflow showed how to test, document, investigate, correct, and re-test.
CSA shows how to decide:
The single biggest mindset change in GxP software validation since GAMP 5. Move from “validation by documentation volume” to “assurance by critical thinking and actual software performance.”
Toggle between Traditional CSV and Modern CSA to experience the difference
80% effort on records • 20% on testing
20% documentation • 80% exercising the system
Focus on exercising software, not just producing records. Flip the 80/20 rule.
Traditional CSV often results in “validation by paperwork” where the volume of documents becomes the measure of compliance rather than the actual robustness of the validated system. CSA redirects effort toward meaningful testing activities that directly demonstrate fitness for intended use.
Evidence must be proportionate. A safety interlock needs a full script; an HMI change needs a simple log.
CSA embraces the principle that not all software features carry equal risk to product quality, patient safety, or data integrity. High-risk functions require rigorous scripted testing and comprehensive documentation. Lower-risk items can use leaner approaches.
Trust the vendor’s internal testing for standard features to avoid redundant in-house work.
Emerson provides extensive validation packages, IQ/OQ protocols, and test evidence for the DeltaV platform. Under CSA, you can leverage this vendor documentation for standard, non-configured functions instead of re-executing identical tests.
Use this tool to determine the right level of assurance for any DeltaV function.
Select a realistic DeltaV scenario and compare documentation-heavy versus risk-proportionate assurance thinking.
Module 5 covered FBD (continuous control loops). But the inside of every Module 3 phase is written in a different language: Sequential Function Charts (SFC). Steps execute actions while active. Transitions evaluate conditions continuously. When a transition goes TRUE, the chart advances. Pick a phase below and watch the logic actually run.
FBD is great for loops that need to run constantly. SFC is for things that happen in order — Pressurise then Heat then Sterilise. Every recipe phase in every biopharma plant is an SFC underneath.
Steps show their actions. Transitions show their boolean expressions and current evaluation against live state.
1. Load SIP_Phase, hit Run, and watch the active step (green pulse) crawl down. Sterilise sits until F0 hits 15 — that's a step action producing a step exit.
2. Switch to Cultivate_Phase and watch the chart fork into parallel branches at the AND-divergence. Both branches must finish before convergence.
3. Click any step to see its actions. Click any transition to see its boolean expression and whether it's currently TRUE against live state.
Submit a realistic control-system change, review impact, choose an assurance strategy, and see outcome tradeoffs in effort and evidence quality.
Investigate a realistic deviation: gather evidence, identify likely root cause, and propose corrective/preventive action with defensible validation reasoning.
Final pH of Lot #B20260515-042 measured at 6.2 (Specification: 6.8–7.2).
Three simulated GMP deviation investigations, each drawing on a different area of the DeltaV primer. You are the lead investigator. Collect evidence, reconstruct the timeline, assess product impact, and close the deviation with objective evidence.
Each case stresses a different skill: process diagnosis, alarm management, or procedural logic review.
Batch B-24017 on BR-201 exceeded the validated temperature range for 11 minutes during post-induction hold. Root cause unconfirmed. Eight evidence sources available.
A pressure excursion during a CIP cycle on Tank T-401 was not detected in real time. A maintenance shelving action on PT-505 was never reversed after the repair was complete.
The SIP_Phase on BR-202 exited before reaching its validated F₀ sterilisation target. The batch was allowed to proceed. A silent change-control record altered the exit criterion setpoint.
Practice answering realistic inspection questions, selecting the right evidence, and explaining decisions with CSA-style clarity.
An investigator asks how your DeltaV validation decisions are justified. Choose the audit pressure level, then answer with evidence and risk-based reasoning.
Change the rules and instantly see the consequences. Explore risk, effort, and long-term outcomes under different validation mindsets.
summarizing everything from system architecture and PID tuning through HMI design, alarms, GEMs, CSV, CSA, and related assurance themes. No timer. Wrong answers come with an explanation.
This capstone brings configuration change, runtime behavior, impact assessment, strategy selection, execution evidence, QA review, deviation handling, and inspector challenge into one guided validation flow.
It is designed to feel like a full workflow rather than a single concept lab. If the best next move is still fuzzy, revisit CSV Validation, Computer Software Assurance, Change Control, and the Investigation Sandbox first, then come back here and run the whole chain end to end.