Running a Project That Mixes ISA 5.1 and KKS

ISA 5.1 and KKS are two different answers to the same question: how do you give every instrument, valve, and control loop on a plant a name that means something to everyone who touches it. ISA 5.1 names a device by its function in a loop (what it measures, what it does). KKS names a device by its place in the plant (which system, which unit, which piece of equipment). A project that carries both, common in power generation, desalination, and any job where equipment from a KKS-run plant meets engineering built on ISA convention, is really running two independent naming systems on the same asset. The answer is never to rename one system to match the other. It is to pick a master register, leave both tag sets intact, and maintain a cross-reference document that ties them together for the life of the plant.

Why the Two Standards End Up on the Same Job

ISA 5.1 is the default in North American process engineering and in most global oil, gas, chemical, and pharmaceutical work. KKS (the plant classification system that originated in central European power engineering) is the standard for power generation, desalination, and utility-scale process plants built to European practice.

They collide in a handful of recurring situations. A turbine, boiler, or balance-of-plant package supplied by a European OEM arrives with KKS-coded documentation and gets dropped into an otherwise ISA-tagged process plant. A desalination or combined-cycle project is executed by a European engineering, procurement, and construction contractor for an owner whose downstream or associated process units are already tagged to ISA convention. A brownfield expansion inherits an existing KKS plant structure, but the expansion's instrument engineering firm defaults to ISA because that is what their P&ID templates and instrument index software are set up for.

None of these are edge cases. On a mixed-standard project, expect ISA and KKS tags to appear side by side on the same equipment list before the project is a month old.

What Each System Actually Encodes

The two standards are not competing versions of the same idea. They organize information around different questions, and that is the root of every downstream problem.

ISA 5.1 organizes around function. The tag tells you what the instrument measures or does first, and its position in the plant is secondary information carried elsewhere (the P&ID drawing number, the area designation). The loop number is central: instruments that share a loop number belong to the same control function, regardless of where they physically sit.

KKS organizes around location and system. The code tells you which process system, which unit, and which component a device belongs to first, and its function is secondary information you read off the drawing or the equipment list, not off the tag itself. Two instruments in the same control loop can carry completely unrelated KKS codes if they sit in different parts of the plant hierarchy.

Neither system is more complete than the other. ISA tells you what a device does and leaves location as a separate fact. KKS tells you where a device sits and leaves function as a separate fact. A project that only has one register is always missing half the picture the other standard would have given it for free.

Where the Mismatch Actually Bites

The two registers do not fail loudly. They fail quietly, in the handoffs between disciplines and contractors.

A feedwater flow transmitter tagged FT-101 on the process side is the same physical device the turbine-island vendor's documentation identifies by a KKS code like 10LAC21CF001. If the process P&ID uses one name and the DCS point database is built off the vendor's KKS submittal, commissioning ends up with two names for one signal, and nobody notices until the loop check finds a mismatch.

Electrical and instrumentation handoffs are the other common failure point. Cable and termination schedules built by electrical engineering often follow the plant's KKS structure, because that is how conduit and cable routing is organized. The I/O list built by instrument engineering follows ISA. If nobody owns the translation between the two, terminations get labeled against the wrong register, and a technician in the field is left guessing which name belongs on which wire.

Safety instrumented functions raise a specific version of the same problem. A shutdown valve tagged XV-301, driven by a safety instrumented function SIF-101, is a logical function first. KKS codes physical components, not logical functions, so a safety function like SIF-101 frequently has no clean KKS home of its own. It exists as a set of KKS-coded field devices (the valve, the initiators, the final element) without a single KKS code that represents the function as a whole. Treating the absence of a KKS equivalent as an oversight, and inventing one, creates a code that means nothing to the plant's KKS structure and confuses the next engineer who looks for it there.

Revision handling is the slowest-moving version of the failure. When a P&ID renumbers a tag (LT-103 becomes LT-103A, say), the KKS-side documents do not follow automatically, because they were never derived from the ISA register in the first place. Without a controlled link between the two, the two registers drift apart one revision at a time until they no longer agree on which devices exist.

Pick a Master Register, Never Rename in Place

The instinct to standardize everything onto one system, usually by renaming the minority tag set to match the other, feels tidy on paper and destroys traceability in practice. Renaming in place breaks the link between the field device, the vendor documentation, the as-built cable schedule, and any historical maintenance record, all of which may already reference the original tag. Once that link is broken, reconstructing it later means walking the plant again.

The better approach is decided at kickoff, not discovered mid-project: assign each document set to the register it is built for. Process P&IDs, the instrument index, and the I/O list carry ISA 5.1, because that is the register process, control, and safety engineering are structured around. The plant structure diagram, cable and terminal schedules, and the DCS or SCADA hierarchy carry KKS, because that is the register the plant's operating and maintenance organization is structured around. Neither register is wrong. Each is the correct tool for the document it lives in.

Both tags then travel together wherever the two disciplines meet: a small reference block near the instrument bubble on the P&ID carrying the KKS location code, a cross-reference column in the I/O list, and the ISA tag stored as a searchable attribute alongside the KKS point number in the DCS database.

Building the Cross-Reference Document

The cross-reference is a single controlled register, one row per physical device or logical function, held separately from both the P&ID and the plant structure diagram so that neither one owns it exclusively. At minimum it carries the master tag, the equivalent code, a plain-language description, the process system, and the discipline responsible for keeping the row current.

That last row matters as much as the others. Recording "no direct equivalent" for a safety function is the correct entry, not a gap to fill. It tells the next engineer that the function is intentionally represented by its constituent KKS-coded devices rather than by a single code of its own.

Who Owns It and When It Gets Touched

The register needs one named owner, typically the instrument and controls lead, and a fixed set of checkpoints where it gets updated: issue-for-design of the P&IDs, freeze of the I/O list, load of the DCS database, and the pre-commissioning walk-down. Any renumbering event on either side, ISA or KKS, triggers an update to the cross-reference before the next document revision goes out. Treating the register as a one-time deliverable rather than a living document is how projects end up with a cross-reference that was accurate at issue-for-construction and wrong by the time commissioning starts.

Keeping the Cross-Reference Alive Through Revisions

The cross-reference carries its own revision block, tied to the P&ID revision it was last checked against, with a change column logging the old and new tag whenever a renumbering happens on either side. That log is what keeps historical documents decodable years later, when a maintenance record references a tag that no longer exists on the current P&ID.

The final check is physical, not documentary. A commissioning walk-down verifies tag correspondence in the field before turnover, because vendor packages occasionally ship with an internal tag that matches neither the ISA nor the KKS register, and that third naming convention has to be captured in the cross-reference too rather than left for the next person to discover during troubleshooting.

Once the walk-down closes out and both registers are confirmed against the as-built plant, keeping them in step through every later revision, rather than reconciling them by hand each time, is the specific problem a cross-standard tag translation approach is built to solve.

Further reading

• /solutions/cross-standard-tag-translation
• /learn/isa-5-1-tag-numbering-explained
• /learn/kks-coding-system-explained
• /blog/managing-tag-registers-across-multiple-contractors