ISA CAP common mistakes
ISA CAP · Understand the traps and how to avoid them.
Selects controller action by memorizing a rule such as 'reverse valve means reverse controller' without tracing whether an increase in controller output ultimately raises or lowers the measured variable, producing positive feedback on the exam scenario.
The shortcut ignores the sign of the transmitter, process, and final element together, so candidates misclassify direct- versus reverse-acting loops.
What to do instead
Draw the loop and multiply the signs from controller output through the final element and process to the transmitter; set controller action so increasing error drives output in the direction that reduces error, then confirm with a bump test or trend inspection.
Treats accuracy, repeatability, resolution, and turndown as interchangeable when comparing instruments, such as choosing the transmitter with the best stated accuracy while ignoring poor repeatability or rangeability at the installed span.
Vendor data sheets emphasize different specifications and candidates memorize one term without mapping it to the measurement requirement.
What to do instead
Define each specification, convert them to the installed range, and combine them into an uncertainty or suitability check against the process requirement before selecting the instrument.
Interprets a trend by assuming process variable, setpoint, and controller output are the same signal, then recommends tuning changes before checking whether the output is saturated, limited, or in manual.
Candidates focus on the visible PV/SP gap and skip the controller output and final-element status that explain why the gap exists.
What to do instead
Identify each tag and trace PV, SP, CO, mode, and output limits; if CO is saturated or the valve is at a limit, address the constraint rather than tuning the PID.
Assigns a SIL to a single device, such as calling a transmitter or valve 'SIL 2', instead of verifying that the entire safety instrumented function meets the target SIL.
Vendor labels and component certificates are easier to recall than loop-level reliability calculations and architecture constraints.
What to do instead
Define the SIF boundary and calculate or verify the loop PFDavg/PFH using sensor, logic solver, and final elements, including redundancy, diagnostics, proof test interval, and common cause.
Uses PFDavg for a high-demand or continuous-mode SIF, or uses PFH for a low-demand SIF, without first determining the demand mode.
The formulas look similar and candidates apply the one most recently memorized instead of checking demand frequency.
What to do instead
Classify demand mode from expected demand rate and use PFDavg for low-demand mode and PFH for high-demand/continuous mode, then check the SIL table appropriate to that mode.
Assumes proof testing restores the SIF to 'as new' and ignores proof test coverage, undetected failures, and common cause between redundant channels.
Candidates equate 'proof tested' with 'perfectly tested' and omit partial stroke coverage, test interval effects, and dependent failures.
What to do instead
Include proof test coverage in PFDavg/PFH, verify that the test exercises the required failure modes, and apply beta or common-cause factors when evaluating redundant architectures.
Builds a project schedule by listing activities without dependencies, resources, or deliverables, then reports progress by counting completed tasks instead of using earned value against a baseline.
Task lists are easy to produce, but they hide the critical path and make percent-complete misleading.
What to do instead
Create a WBS with dependencies and resource loading, identify the critical path, baseline scope/cost/schedule, and track earned value using planned value, earned value, and actual cost.
Closes out an automation project after commissioning loops, skipping formal verification and validation against the user requirements and failing to update as-built documentation and management of change.
Commissioning feels like the finish line, and candidates conflate 'equipment runs' with 'system meets intended use'.
What to do instead
Use phase gates that separate commissioning, verification, and validation; validate against the URS, complete turnover packages, update as-builts, and route changes through MOC.
Assigns OT device IP addresses by picking convenient numbers without a subnet mask, gateway, VLAN plan, or duplicate-address check, then expects routing and broadcast behavior to work.
Candidates treat IP addressing as memorized octets rather than a designed address plan with network and host boundaries.
What to do instead
Calculate the subnet, assign unique addresses within the correct network, define gateways and VLANs, and verify connectivity and duplicate-address conflicts with an address plan and basic network checks.
Treats industrial protocols such as Modbus TCP, EtherNet/IP, HART, and Profinet as interchangeable and assumes ordinary Ethernet delivers deterministic control timing without considering jitter, QoS, segmentation, or cybersecurity.
All are 'networks' at a high level, but candidates miss differences in protocol layer, polling model, determinism, and OT security exposure.
What to do instead
Map each protocol to its layer and service model, check scan rates and timing requirements, use managed switches with QoS and segmentation, and apply OT security zones and conduits rather than flat IT-style connectivity.