最新三週上線看導入方式

專欄/現場筆記

Management of change starts with a diff

Most of the time in an MOC review goes to finding what a change touches. A structured revision diff and a traversal of the verified plant graph answer that faster, and the engineers who sign stay accountable.

作者 Operon Team · 2026年10月14日· 6 分鐘閱讀

分享

本文目前僅提供英文版本。

Every management of change review starts with the same question: what does this change touch? The request names a valve, a line or an instrument. The reviewer has to establish everything connected to it that the change could affect, on every drawing where it appears, and then make sure those drawings will be right once the change is built.

On many sites that question is still answered by hand. An engineer traces a line across sheets, cross-checks the line list and the instrument index, and pulls the relief system documentation. This post looks at where that time goes, and how a structured revision diff and a traversal of a verified plant graph shorten it without moving the signature off the engineer.

What management of change asks for

OSHA's Process Safety Management standard, 29 CFR 1910.119, applies to processes that involve listed highly hazardous chemicals at or above threshold quantities, along with large inventories of flammable liquids and gases. One of its elements is management of change: the employer needs written procedures for managing changes to process chemicals, technology, equipment and procedures, and to facilities that affect a covered process. A replacement in kind, one that still satisfies the design specification, is outside its scope.

Before a change goes ahead, the procedure has to address the technical basis for the change, its impact on safety and health, any changes to operating procedures, the time the change needs, and who must authorize it. Employees whose work the change affects are informed and trained before startup. When the change alters the process safety information, that information is updated, and a modification significant enough to alter it also calls for a pre-startup safety review. EPA's Risk Management Program carries a parallel requirement for Program 3 processes.

None of that is new to a PSM manager. The point is what it implies for drawings.

The P&ID is process safety information

Under PSM, process safety information includes the P&IDs, alongside the relief system design and its design basis, safety systems such as interlocks, and materials of construction. It has to be compiled before a process hazard analysis, and the PHA is updated and revalidated at least every five years. When the method is a HAZOP, the team works through the P&IDs node by node.

That makes a current P&ID a safety requirement, not a drafting courtesy. If the drawing does not match the plant, the PHA analyzed a different plant, an operating procedure may refer to a valve that has moved, and the next MOC reviewer starts from the wrong picture.

Keeping drawings current is mostly a matter of red-lines. A change is implemented, someone marks up the affected sheets in the field, and the markup joins a queue to be drafted into the masters. Until it is drafted, the master P&ID and the plant disagree, and anyone working from the master is working from the old plant.

Where MOC packages lose time

The engineering judgment in an MOC review is the part worth paying for. Most of the elapsed time goes to work around it.

Finding the affected drawings

The change request names a tag. The drawing index is organized by sheet number, not by tag, and the older sheets are scans nobody can search. The tag may appear on the P&ID, the line list, the instrument index, a loop diagram, an isometric and a cause-and-effect chart, and the line it sits on continues through off-page connectors onto sheets with no obvious relation to the first. Building the list of affected documents is a search problem, usually solved by memory or by brute force.

Tracing what the change touches

With the sheets found, the reviewer traces the change's reach. For a change on one line, that means the questions every experienced reviewer asks:

  • What else is on this line, between which isolation points, and on which sheets?
  • Which instruments are connected to it, and which loops and interlocks are they part of?
  • Which relief device protects the equipment it ties into, and does the change alter the relief path or the load the device was sized for?
  • Are there block valves in that relief path, and are they shown car-sealed or locked open?

Each answer means following lines by eye across sheets. It is slow, and it is exactly where a branch or a connector gets missed.

Red-lines that never make it back

The last loss comes after the change is built. The MOC is supposed to close with the process safety information updated, but when red-lines wait in a drafting backlog, the masters stay stale. The next change on the same line starts from a drawing that is already wrong, and nobody knows until a field check or a PHA revalidation turns up the discrepancy.

A change, read as a diff

When the affected sheets already live in a typed graph, a proposed change can be read structurally. Once the change is drafted as a new revision of those sheets, we compare that revision with the current verified one object by object, not pixel by pixel.

Take an illustrative change: adding a bypass around flow control valve FV-101, and moving pressure transmitter PT-102 from upstream of the valve to downstream. The structured diff reports it as a short list:

  • Added: a block valve on each side of FV-101, and a bypass line around the station with a globe valve for manual throttling
  • Moved: PT-102, with its process connection now on the downstream segment
  • Unchanged: everything else on the line, which is itself a finding worth confirming
  • Outside the cloud: any change the drafter did not mark, flagged for the reviewer

Each entry points to the region on the old and new revisions it came from. The reviewer is reading a change set, not playing spot the difference across two plots.

Traversal answers the review questions

A diff says what changed. The harder question is what the change touches, and that is a graph traversal. Starting from the changed objects, it walks outward:

  • Along the line: every valve, reducer, spec break, branch and in-line instrument, on every sheet the line crosses, out to the equipment and isolation points that bound it.
  • Into the instrumentation: every instrument with a process connection on the affected segments, the loops they belong to, and the final elements those loops drive.
  • To the relief path: the relief device protecting the connected equipment, the block valves in its inlet and outlet, and the position each one is shown in.

Where a traversal stops matters as much as where it goes. Treat a normally open block valve as a boundary and the traversal misses everything beyond it, even though nothing there is isolated. Run it without limits and it returns half the unit. Sensible boundaries are the ones a reviewer would draw, equipment and closed isolation points, with room to widen them when the change warrants it.

The output is a list of objects, each resolved to its sheet and region. It does not say whether the change is safe. It gives the reviewer a starting list drawn from every sheet, rather than from the sheets someone remembered, in the time it takes to run a query.

A diff tells you what changed. A traversal tells you what the change touches. The engineer still decides what it means.

Engineers stay accountable

None of this moves the decision. The diff and the traversal are evidence assembled for the reviewer, and the MOC approvers still sign. What changes is what they sign against:

  • every item in the package traces to the sheet and region of the drawing it came from
  • the drawing data underneath was verified by a named engineer, and the verification is on record
  • the diff and traversal results stay with the package, so an auditor can see what the reviewer saw

That depends on verification upstream. A traversal over unverified detections would put a model's guess into a safety review. Ours runs over the graph your engineers signed off, as we describe in Why we verify every tag.

The same diff can close the loop after implementation. When the as-built revision of the affected sheets is issued, comparing it with the approved MOC revision shows whether what was built matches what was approved. And a closed change whose sheets still match the pre-change revision is something you can find with a query, rather than at the next PHA revalidation.

Shorter reviews, same signatures

Management of change is how a plant keeps its documented basis of safety true while the plant itself changes. Much of the time it consumes is clerical: finding the drawings, tracing the lines, getting red-lines back into the masters. Those are the parts a structured diff and a verified graph handle well. The judgment, and the signature, stay with your engineers.

For how revision deltas come out of the graph, see Reading a P&ID like an engineer. For how we work with process plants, see chemicals and energy.

分享

從最花成本的那件工作開始。

告訴我們你的團隊在哪裡花掉最多時間。三週後,一個為你公司打造的 AI 員工就在做那件事。