Read the documents behind plant decisions.

NFPA 70E addresses electrical safe work practices. An arc-flash study supplies part of the technical basis for that program, but a study report and equipment labels do not replace the plant's work rules, training, maintenance, or job planning.

Begin with the electrical model

The study depends on the installed system, not only the one-line diagram. Collect utility fault data, transformer ratings and impedance, conductor sizes and lengths, motor contribution, protective-device models and settings, equipment ratings, and the operating modes the plant actually uses. Open ties, alternate sources, generator operation, and temporary settings can change the result.

Field verification matters when drawings, labels, and settings disagree. Record assumptions and unresolved data so the plant can see which results need confirmation before they are used for work planning.

Read the studies as a connected set

• The short-circuit study compares available fault current with equipment duties and ratings.
• The protection-coordination study reviews device settings and clearing behavior across the distribution path.
• The arc-flash analysis uses the documented system and clearing times to calculate incident-energy results and boundaries at the equipment studied.

A setting change made for coordination can affect clearing time and the arc-flash result. Review the model, device settings, study tables, and labels as one technical package.

Carry the result into plant practice

Equipment labels communicate study results at the point of work. The electrical safety program still has to address equipment condition, normal and abnormal operation, energized-work decisions, job briefing, shock and arc-flash boundaries, PPE selection, training, and control of changes. Confirm the edition and policies that apply to the facility with the responsible safety and engineering team.

Capital-project engineering works when the operating basis survives each change in level of detail. A design-build structure can bring engineering, equipment, construction planning, and field input together earlier, but it still needs clear owner decisions and controlled technical documents.

Fix the operating basis before fixing the building

Start with products, production rates, process steps, cleaning methods, material and people flows, operating schedules, utility needs, and the constraints of the site. Convert them into requirements, mass balances, block flow diagrams, conceptual layouts, and system narratives. These documents give the team a common test for later decisions.

Use phase gates to expose open decisions

1. Concept: compare process routes, layouts, equipment approaches, schedule, construction strategy, and cost work.
2. Preliminary engineering: advance process descriptions, product and energy balances, equipment layouts, flows, building disciplines, and utility loads.
3. Detailed engineering: coordinate drawings and specifications with selected process equipment and vendor information.
4. Construction and startup: manage bid questions, submittals, field changes, inspections, deficiencies, record documents, checks, and turnover.

At each gate, list the decisions that are closed, the assumptions still carrying the design, who owns each open item, and the date when it begins to affect procurement or construction.

Make design-build interfaces visible

Early construction input can shape work packaging, access, shutdowns, temporary conditions, and field sequencing. Equipment procurement needs performance requirements, bid review, supplier-document review, factory testing where required, and utility connections tied back to the design basis. Architecture, civil, and structural work should be coordinated with qualified local firms and the process and plant-system documents.

The Purdue model is a way to organize manufacturing functions and trust boundaries. It is not a ready-made switch diagram. A useful OT design starts with the production systems, the data they exchange, and the consequence of losing each path.

Map functions and data flows first

List controllers, HMIs, SCADA servers, historians, environmental monitoring, vision, robotics, drives, engineering workstations, databases, business-system links, and remote-access needs. For every flow, record the source, destination, protocol, direction, owner, timing need, and plant effect if the connection is unavailable.

Place field devices and controllers near the process-control layers, supervisory systems above them, and site manufacturing operations above the control areas. The exact boundary depends on the plant architecture. The value of the model is a shared language for separating functions that should not have the same trust or access.

Use the IDMZ as a controlled exchange layer

An industrial demilitarized zone, or IDMZ, sits between manufacturing and enterprise environments. Services that exchange data across that boundary can terminate or relay there rather than opening direct paths between the two environments. Firewalls on both sides can apply separate rules and ownership.

Historian replication, approved file transfer, patch or update staging, remote-access entry, and other shared services need an explicit data path and operating owner. Avoid broad rules based only on subnet. Define the systems, ports, direction, authentication, logging, and recovery method for each approved exchange.

Design for plant operation

• Document zones, conduits, switch and firewall configurations, virtual hosts, and network panels.
• Match redundancy to the production effect of a switch, firewall, server, or link failure.
• Put vendor and employee remote access behind controlled entry, named access, time limits, and plant approval.
• Plan configuration backup, spare strategy, monitoring, testing, and recovery with the operations team.

Instrumentation turns process conditions into information and control actions. A cause-and-effect matrix makes the required response visible before control logic is written and gives testing teams a direct path back to process intent.

Define the measurement from the process

For each point, state what must be measured, the normal and credible operating range, the process connection, material compatibility, cleaning or environmental needs, accuracy and response needs, signal type, and what the control system will do with the value. A tag alone is not an instrument requirement.

Keep the P&ID, instrument index, datasheets, I/O list, control narrative, alarm list, and loop or installation details aligned. When a range, fail state, or equipment operating mode changes, identify every document and control function affected by the change.

Write causes and effects in testable language

A cause is a defined condition such as high pressure, low flow, loss of permissive, equipment fault, or emergency input. An effect is the required response such as stopping a pump, closing a valve, removing heat, preventing a start, or alarming the operator.

• Separate alarms, permissives, interlocks, and shutdown actions.
• Record the setpoint or initiating state, time delay, latching behavior, reset method, and required fail position.
• State what happens on bad signal quality, loss of power, loss of communication, and manual or maintenance mode.
• Define bypass authority, indication, expiration, and the condition required to return to service.

Trace the matrix into testing

Control narratives and functional specifications should point to the same causes and effects used for programming. Factory and site tests can then verify the input, logic path, final element, alarm message, timing, reset, and recorded result. Qualification records can reference the approved requirement and test where the process calls for IQ, OQ, or PQ documentation.