ISA-95 in Practice: A Director's Guide to the Standard Most Plants Only Know as a Pyramid

ISA-95, published internationally as IEC 62264, is an eight-part standard for connecting business systems to manufacturing operations. It defines the models, terms and transactions for Level 3, manufacturing operations management, and for the interface between Level 3 and the business systems above it. The pyramid most people know is only the first page. The value is in the shared names and models that follow it.

That gap is expensive. Most plants we see never adopt a naming or model standard. Each machine, line and system arrives with its own names, and because the plant keeps running, nobody notices the cost until the next project. Then the MES, the historian, the new line or the ERP interface starts with someone re-engineering what already exists, mapping every tag again from scratch. The plant pays for that work on every project, and it pays again the next time.

This guide is for the engineering director planning modernization or an MES deployment. It covers what each of the eight parts of ISA-95 is actually for, how the standard differs from the Purdue model it is constantly confused with, a worked equipment hierarchy for a food plant, and how much of the standard a mid-size plant needs. It also takes a position on adoption. If you are starting from scratch, take the time to implement the standard properly. If you are not, build edge translators that map what you have into the standard, so the next change is plug and play rather than another engineering project.

What is ISA-95, and why is it more than a pyramid?

ISA-95 is a modelling and vocabulary standard, not an architecture diagram. Its scope is Level 3, manufacturing operations management, and the information exchanged between Level 3 and Level 4, business planning and logistics. Part 1 alone defines three hierarchies and a functional data flow model. Parts 2 to 8 define the objects, activities, transactions and messaging that make integration repeatable.

The scope statement in Part 1 is narrower than most people assume. It describes the manufacturing operations management domain and “the interface content and associated transactions within Level 3 and between Level 3 and Level 4”, and notes that the interface between Level 3 and Level 2 is only briefly discussed (IEC 62264-1). ISA-95 is not a standard for wiring PLCs, designing networks or securing them. It is a standard for making sure that when an ERP system sends a job to the plant and the plant reports back what it made, both sides use the same words for the same things.

That is why the pyramid is the least useful thing to learn about it. The pyramid tells you where systems sit. The rest of the standard tells you what they say to each other, and that is where integration projects succeed or fail.

The standard is published by ISA as the ANSI/ISA-95 series and by IEC as IEC 62264. The two run on different editions, which causes confusion when teams compare documents. As of October 2026, ISA lists eight parts:

Part	Title	Latest ANSI/ISA edition	IEC counterpart	What it gives a director	When you need it
1	Models and Terminology	2025	IEC 62264-1:2013	The shared vocabulary, the levels and the three hierarchies	Always, from day one
2	Objects and Attributes for Enterprise-Control System Integration	2018	IEC 62264-2:2026 (Ed. 3)	What is exchanged between the plant and ERP: personnel, equipment, material, process segments, schedules and performance	When you integrate ERP
3	Activity Models of Manufacturing Operations Management	2013	IEC 62264-3:2016	What Level 3 actually does, in eight activities across four areas	When you write MES requirements
4	Objects and Attributes for MOM Integration	2018	IEC 62264-4:2015	What Level 3 systems exchange with each other	When several systems share Level 3
5	Business-to-Manufacturing Transactions	2018	IEC 62264-5:2016	The verbs and exchange patterns for plant and ERP messages	When you specify the ERP interface
6	Messaging Service Model	2014	IEC 62264-6:2020	How those messages are carried between applications	When you build or buy integration middleware
7	Alias Service Model	2017	None	Handling the different names systems use for the same object	Brownfield integration across many systems
8	Information Exchange Profiles	2020	None	Packaging exchanges into reusable profiles	Mature, multi-system programmes

Two editions changed recently. ISA revised Part 1 in 2025, and announced the update in an April 2025 press release. IEC published the third edition of IEC 62264-2 on 6 March 2026, under a new title, consolidating the production-specific object models into the general operations models (IEC 62264-2:2026). If your team is working from a printout that lists six parts, it is out of date.

ISA-95 vs the Purdue model: same levels, different questions

The Purdue model is the reference architecture ISA-95 grew from, and today it is used mainly to draw network and security boundaries. ISA-95 uses the same numbered levels to describe functions and the information exchanged between them. Purdue answers “which systems may talk across this firewall”. ISA-95 answers “what do these systems need to tell each other, and in what words”.

The confusion is understandable. Both use Levels 0 to 4, and Part 1 states that its interface content is based on the Purdue Reference Model for computer-integrated manufacturing as published by ISA. NIST’s guide to OT security puts it plainly: the ISA-95 standard grew from the Purdue Enterprise Reference Architecture (NIST SP 800-82r3). Even ISA’s own overview page describes ISA-95 as relying on the Purdue model to describe network segmentation, which blurs the line further.

Question	Purdue model	ISA-95
Origin	Theodore Williams’ reference model for computer-integrated manufacturing, published by ISA in 1989	ANSI/ISA-95 Part 1, first published in 2000; current edition 2025
What it is	An enterprise reference architecture	Models, terminology and transactions for Level 3 and the Level 3/4 interface
What a “level” means	A layer of systems, used to place equipment and draw boundaries	A layer of functions, used to define what each layer does and exchanges
Main use today	Network segmentation and OT security architecture	MES requirements, ERP integration, naming and data models
The typical mistake	Treating it as a data model	Treating it as a security model, or adding a “Level 5”

Two corrections are worth making explicitly in any plant discussion. First, ISA-95 does not define DMZs, zones or firewalls. That belongs to ISA/IEC 62443 and to network design. Second, there is no Level 5 in ISA-95; network-oriented drawings of the Purdue model sometimes add one for enterprise networks, and it migrates into ISA-95 slides by accident. For the network side of the question, see our guide on how the Purdue levels shape a plant network.

The three hierarchies in ISA-95 Part 1, and the one most plants confuse

Part 1 defines a functional hierarchy (what work happens at each level), a role-based equipment hierarchy (what each piece of equipment does in the process) and a physical asset hierarchy (the serial-numbered thing filling that role). Most naming schemes merge the last two. When a pump is swapped, the role should keep its name and history while the asset record moves with the pump.

The scope of Part 1 lists the three by name: “a functional hierarchy model, a role-based equipment hierarchy model, and a physical asset equipment hierarchy model” (IEC 62264-1). The physical asset model was added in the 2013 edition, precisely because the role and the thing are different.

The distinction sounds academic until something breaks. Take “Mix Tank 2” in a blending room. Its role is to mix a batch at a set temperature for a set time. The agitator motor, the load cells and the tank itself are physical assets, each with a serial number, a maintenance history and a supplier. When the agitator motor fails and maintenance installs a spare, the role has not changed. Production still schedules Mix Tank 2, the historian should still show one continuous trend for Mix Tank 2, and the batch records should still say Mix Tank 2. Meanwhile, the maintenance system needs to know that the old motor came out and a new one went in.

The OPC Foundation’s ISA-95 information model shows how the standard handles this: a physical asset carries its own identity, and an asset assignment records the history of which equipment role it filled (OPC 10030). Two records, linked, each doing its own job.

Plants that use one hierarchy for both get one of two failures. If the names are asset tags, every replacement breaks continuity: the historian starts a new series, dashboards go blank and the MES loses track of the equipment. If the names are roles but the asset data is stored against them, the maintenance history follows the location instead of the motor, and a rebuilt motor installed somewhere else arrives with no history at all. Keep the role hierarchy for production and data, keep the asset register for maintenance, and link the two.

A worked ISA-95 equipment hierarchy for a hybrid food plant

Below the enterprise, site and area levels, ISA-95 gives each style of production its own work centre type: process cells and units for batch, production units and units for continuous processes, production lines and work cells for discrete packaging, and storage zones and units for warehousing. A plant that mixes all four should use all four, not force everything into “line” and “cell”.

The terms come straight from the standard. Part 1 defines enterprise, site and area, then work centres and work units of four types. The OPC Foundation’s free definitions are a useful reference: a work centre is “typically the grouping of equipment scheduled by the Level 4 or Level 3 functions”, and work units are “the lowest form of elements in an equipment hierarchy typically scheduled by Level 3 functions” (OPC 10030).

Consider an illustrative food plant that blends product in batches, pasteurizes it continuously, fills and packs it on two packaging lines, and stores finished goods before shipping. That is four styles of production under one roof, which is normal for food and beverage.

Plant equipment	ISA-95 element	Type of production	Example role name
The plant	Site		Plant1
Blending room	Area		Processing
Batch blending system	Process cell	Batch	Blending
Each mix tank	Unit	Batch	MixTank1, MixTank2
Pasteurizer	Production unit	Continuous	HTST1
Packaging hall	Area		Packaging
Each packaging line	Production line	Discrete	Line1, Line2
Filler, capper, case packer, palletizer	Work cell	Discrete	Filler, Capper, CasePacker, Palletizer
Finished goods warehouse	Area and storage zone	Storage	Warehouse, FinishedGoods
Racking lanes	Storage unit	Storage	Lane01

The names that follow from this read naturally to anyone in the plant: Plant1/Processing/Blending/MixTank1 and Plant1/Packaging/Line1/Filler. Both are role names. Neither contains a PLC address, a vendor name or a serial number, and neither changes when the equipment underneath is replaced.

Compare that with the example path that appears in most vendor material on the subject: Enterprise, Site, Area, Line, Cell, applied to everything. It works for the packaging hall and misdescribes the rest of the plant. A batch blending system is not a line, a mix tank is not a work cell, and a pasteurizer is neither. The mislabelling matters when an MES arrives, because MES products model batch and discrete work differently, and a hierarchy that has already flattened the difference forces the MES team to unpick it.

What happens without a naming standard: why every project gets re-engineered

Without a shared model, every system that consumes plant data has to be mapped to every source’s local names. The MES, the historian, dashboards and the ERP interface each rebuild the same knowledge of which tag means what. With a standard model, each source is mapped once and every new consumer reads the same names. That is the difference between an engineering project and a configuration task.

This is the pattern we see most in plants that have grown one project at a time. The first historian was configured against the PLC tags of the day, so everything a data historian actually does with that data, from trends to reports, inherited those names. The OEE dashboard was built by a different integrator against the same PLCs, with its own interpretation of which bit means “running”. The MES project, years later, started with a tag-mapping exercise that re-derived both. Each time, someone opened programs written by people who have since left, decided what B3:0/5 means on that machine, and encoded the answer in one more place. When a machine is replaced, every one of those places has to change.

The arithmetic explains why costs climb. With N sources and M consuming systems connected point to point, the plant maintains up to N × M mappings, and every new system adds N more. With a shared model in the middle, the plant maintains N mappings into the model and M connections out of it. Ten machines and five consuming systems is up to fifty interpretations of the same data against fifteen. The number is illustrative, but the shape is not: point-to-point integration grows with the product, a model grows with the sum.

The standard states its own purpose in these terms. Part 1 aims to “increase uniformity and consistency of interface terminology and reduce the risk, cost, and errors associated with implementing these interfaces” (IEC 62264-1). Part 3 aims to make enterprise and operations systems “inter-operate and easily integrate”.

There is no credible published figure for what a missing naming standard costs a plant, and we would rather not invent one. The closest primary research is older and broader. A 2004 NIST study of supply-chain integration estimated the cost of inadequate integration infrastructure at more than $5,000,000,000 a year in the US automotive industry and almost $3,900,000,000 in electronics, about 1.2 percent of the value of shipments, and listed “the use of translators to convert data from one format to another” among the cost drivers (NIST Planning Report 04-2). That study covered business-to-business messaging, not the plant floor, and its survey drew on 55 respondents at 46 firms. It is an analogue, not a measurement of your plant. The mechanism, though, is the same one.

Inside Level 3: using the ISA-95 activity model as an MES requirements checklist

Part 3 defines eight activities that repeat across four areas of operations: production, maintenance, quality and inventory. They are definition management, resource management, detailed scheduling, dispatching, execution management, data collection, tracking and performance analysis. Used as the rows of an MES requirements matrix, they make vendors answer the same questions in the same words.

The model comes from IEC 62264-3, which applies the same generic activities to production operations, maintenance operations, quality test operations and inventory operations. That symmetry is what makes it useful as a checklist: thirty-two cells that together describe everything manufacturing operations management can do.

Activity	What it means in a food plant	Where it often lives today
Definition management	Recipes, specifications and work instructions for each product	Spreadsheets, the batch system, document control
Resource management	What people, equipment and materials are available and qualified	Shift sheets, the CMMS, ERP
Detailed scheduling	The sequence of jobs on each line and unit for the next shift or day	A planner’s spreadsheet, adjusted on the floor
Dispatching	Releasing jobs to specific equipment and crews	Whiteboards, radio, the shift lead
Execution management	Making sure each job runs to its definition	Operators, the batch system, paper checklists
Data collection	Capturing what happened: quantities, times, states, test results	SCADA, the historian, paper
Tracking	Following material, lots and jobs through the process	Paper batch records, ERP backflushing
Performance analysis	KPIs, losses and root cause	Excel, after the fact, if at all

The most useful exercise for a director is to score the current state. Take the four areas as columns and the eight activities as rows, and mark each cell by where it is done today: in a system, on paper, in a spreadsheet, or not at all. The gaps become MES requirements, and the cells already handled well by existing systems become integration requirements rather than replacement candidates. Vendors who answer against the same thirty-two cells can be compared directly, which is rarely true of feature lists.

Use the current terms when you write the requirements. The 2016 revision of Part 3 replaced “work order” with job order and “dispatch list” with job list, and older vendor documents still use the old words. For how this feeds a vendor decision, see our MES selection work, and for how MES and batch systems divide the work, see our page on how MES and batch systems fit together.

Talking to ERP: ISA-95 objects, transactions and B2MML

Part 2 defines what crosses between the plant and ERP: personnel, equipment, physical assets, material, process segments and the operations schedule, performance and capability that use them. Part 5 defines how: verbs such as GET, PROCESS, CONFIRM and SYNC, exchanged by push, pull or publish. Settle who owns each type of master data before writing a single interface.

Part 2’s common object models cover personnel, role-based equipment, physical assets, material, process segments, and containers, tools and software, followed by the operations models built on them: operations definition, schedule, performance and capability. The 2026 IEC edition folds the older production-specific models into those general operations models.

IEC 62264-5 then defines the transactions in terms of verbs applied to those objects:

Verb	What it does	Plant example
GET / SHOW	Request information, and return it	MES asks ERP for the material master of a new product
PROCESS / ACKNOWLEDGE	Send something to be acted on, and confirm receipt	ERP sends the day’s job orders to the plant
CHANGE / CANCEL	Modify or withdraw something already sent	Planning moves a job to another line, or cancels it
CONFIRM / RESPOND	Report back on what was asked	The plant reports quantities produced against a job order
SYNC (add, change, delete)	Keep master data aligned between systems	Equipment or personnel records synchronised from the owning system

Part 5 also describes three exchange patterns: push, pull and publish. Choosing one per object type is part of the interface specification.

The decision that matters most comes before any of this: who owns each type of data. If ERP owns the material master and the MES owns equipment, every interface follows from that. If nobody has decided, both systems will edit the same records, and the integration will fail in ways that look like software bugs but are governance problems. For each object type, name the system of record, the systems that consume it, and the verb that keeps them aligned. Our IT/OT integration work usually starts with exactly that table.

B2MML deserves a careful note. It is MESA International’s XML implementation of ISA-95, at version V0700, published on MESA’s GitHub repository under a royalty-free licence, and its schemas implement the same Part 5 verbs. The repository was last updated in 2023, and its own README says the JSON variant has not been tested. MESA ceased operations on 30 June 2026, and ISA assumed MESA’s educational programs and content; the announcement does not mention B2MML. Before standardising an interface on it, confirm its current licence and maintenance status with ISA.

Greenfield: adopting ISA-95 from day one

If you are building a new plant or line, take the time to implement the standard before the first PLC is programmed. Draw the role-based hierarchy, write the naming standard from it, define the equipment, material and personnel models you need, and make every vendor deliver to them. It costs weeks at the start and saves re-engineering on every project after.

A new build is the one moment when every vendor can be told what to deliver before anything exists. The sequence we recommend:

1. Draw the role-based equipment hierarchy for the whole site, using the correct work centre types for batch, continuous, discrete and storage areas.
2. Write the naming standard from it. Define the role names, separators, abbreviations, and the standard names for common states and measurements, so Running, Starved and Blocked mean the same thing on every machine.
3. Define the object models you need now: equipment classes with their standard attributes, material classes and lots, and personnel classes where qualifications matter.
4. Define the process segments, the logical steps that turn materials into products. They are the bridge between what ERP plans and what the plant executes, and the MES is built on them.
5. Write the MES requirements against the Part 3 activity model, as above.
6. Specify the ERP interface against Part 2 objects and Part 5 transactions, with a named system of record for each object.
7. Put the hierarchy and naming standard into every integrator and OEM scope of work, with acceptance tests that check delivered tags and models against it.

The last step is the one that makes the rest stick. A standard that is not in the contract is a suggestion, and every machine that arrives without it becomes a brownfield problem on day one. For how these models feed the wider data design, see our page on plant data architecture.

Brownfield: edge translators that map existing tags into the ISA-95 model

In an existing plant, do not rename the PLCs. Put a translation layer at the edge that maps each machine’s local tags into a standard model instance named by the ISA-95 hierarchy. New systems subscribe to the model, not to the PLC. The legacy names stay where they are, and the next project starts from the model instead of the tag list.

Most plants are not starting from scratch. They have twenty years of machines from a dozen builders, each with its own tag names, its own state codes and its own idea of what “running” means. Renaming all of that to fit a standard would be a capital project of its own, with downtime and validation attached, and it would buy almost nothing the day it finished.

The better approach is to leave the source alone and translate at the boundary. An edge translator reads a machine’s local tags and publishes them as an instance of a standard model: a filler that looks like every other filler, under a name that follows the ISA-95 hierarchy. Plant1/Packaging/Line1/Filler carries the same attributes, units and states whether the machine underneath is ten years old or arrived last month. The translator holds the mapping. Everything above it reads the model.

The payoff comes on the next project. When the MES, a new dashboard or an ERP interface arrives, it subscribes to the model. Nobody opens the PLC program to work out which tag means what, because that work was done once, in the translator, and documented there. Add a new line, and its translator maps into the same model, so every consumer picks it up without changes. That is what plug and play means here: not that integration disappears, but that each source is mapped once and each consumer is built once.

This pattern is not a vendor invention, and you do not need any one product to use it. The tools that do it well share the same structure: a model definition, one instance per real thing, and a mapping from source tags to model attributes.

Approach	What it standardises	Where the mapping lives	Note
OPC Foundation UA Edge Translator	Translates brownfield devices into OPC UA information models, ideally a companion specification	A Web of Things Thing Description per device	Open source; the OPC Foundation describes it as solving the “brownfield” use case
CESMII Smart Manufacturing Profiles	A type definition plus a binding to PLC tags or sensors	The profile’s binding, applied by an edge gateway	An application can be “written once, and re-deployed” against any platform that implements the profile
HighByte Intelligence Hub models and instances	A model as “the standard definition of something” and an instance as “the actual thing”	Attribute references and expressions per instance	Consumers “rely on standardized information regardless of the underlying data sources”
Ignition User Defined Types	A UDT definition with parameterised instances	Instance parameters pointing at each PLC’s tags	Common in plants already running Ignition
Litmus Edge digital twins	Model templates with attributes and output schemas	Topic mappings and parameter overrides per instance	Edge-platform equivalent of the same pattern

Sources: OPC Foundation UA Edge Translator, CESMII SM Profiles, HighByte modeling guide, Ignition UDT documentation, Litmus Edge digital twins.

Three rules keep a translator layer from turning into another tangle. First, the model comes from the standard and the plant’s naming standard, not from whichever machine happens to be integrated first. Second, the name is a role, not an asset: the filler on Line 1 is Line1/Filler, and the serial number is an attribute that changes when the machine does. Third, the mappings are documented and versioned like code, because the translator is now the only place that knows what N7:42 on a twenty-year-old controller actually means.

Sparkplug deserves a note here, because many brownfield projects use it as the transport. Sparkplug decouples devices from consumers, which is the same principle. But its topic structure has a fixed depth and its IDs cannot contain a slash, so an ISA-95 hierarchy cannot map one level per topic segment (Sparkplug 3.0 specification). The hierarchy has to live in the group, node and device IDs, in metric names, or in the payload. Decide that convention once, and write it into the naming standard.

ISA-95 and the unified namespace

A unified namespace and ISA-95 solve different halves of the same problem. The namespace is where current plant data lives and how systems reach it. ISA-95 supplies the names, the hierarchy and the models that make that data mean the same thing everywhere. MQTT is a transport and a broker is a product; neither one is a namespace until a naming standard is applied.

The two failures mirror each other. A unified namespace without a model is a shared place full of inconsistent names: every machine publishes, and every consumer still has to work out what each topic means. A model without a namespace is a standard that every project still integrates point to point. Together they give one place to find data and one meaning for it.

The ISA-95 equipment hierarchy is the natural structure for the namespace, for the reasons above: role names survive equipment changes, and the work centre types keep batch, continuous and discrete areas honest. The edge translators of the previous section are what publish into it. Some practitioners argue for keeping the topic tree shallow and putting the hierarchy into payload attributes; others map it into the topic path. Either works if it is decided once and written into the naming standard. What fails is each project deciding for itself.

For more on the namespace side, see our guide to the unified namespace and our comparison for choosing a UNS broker.

Where ISA-88 meets ISA-95 in a batch plant

ISA-88 governs how batches are executed: procedures, recipes, units and equipment modules. ISA-95 governs what operations management exchanges with the business. In a batch plant the two meet at the recipe. General and site recipes are equipment-independent and sit with the enterprise; master and control recipes are bound to specific equipment.

ISA’s own technical report on using the two together summarises the difference: ISA-95 is oriented to the “definition of workflow and information exchange for Manufacturing Operations Management”, while ISA-88 is oriented to “physical work execution for Batch and other types of manufacturing” (ISA-TR88.95.01). The two share vocabulary: ISA-95’s process cell and unit come directly from the batch control standard, IEC 61512-1, which Part 1 cites as a normative reference.

In practice, the hand-off sits where an equipment-independent recipe becomes an equipment-bound one. The product definition and site recipe describe what to make, independent of which mix tank does it. The master recipe and control recipe describe how a specific process cell will make it. ISA-95 carries the first across the Level 3/4 boundary; ISA-88 governs the second inside the batch system. Keeping that line clear is what lets a batch system, an MES and an ERP system each own their part of the recipe without overwriting each other. It is also what makes batch genealogy and batch traceability hold together across the three.

How much ISA-95 does a mid-size plant actually need?

Not all of it at once. Every plant needs the equipment hierarchy and a naming standard now, because everything else builds on them. The Part 3 activity model and the core object models matter when you select and deploy an MES. The Part 5 transactions matter when you integrate ERP. Parts 6 to 8 matter when you build or buy integration middleware.

Adopt now	Adopt with an MES	Adopt with ERP integration	Adopt later, if needed
Role-based equipment hierarchy (Part 1)	Part 3 activity model as the requirements matrix	Part 2 objects with a named system of record for each	Part 4 exchanges between several Level 3 systems
Naming standard built from it	Equipment and material object models	Part 5 verbs and exchange patterns	Parts 6 to 8 messaging, aliasing and exchange profiles
Standard state and measurement names	Process segments	B2MML or an equivalent schema, after checking its status
Edge translators for existing machines

Over-modelling is the opposite risk, and it is real. Signs of it include attributes that no consumer reads, Part 4 exchange models built for a site with one Level 3 system, and namespaces twelve levels deep because every subdivision of the building became a level. The standard describes what can be modelled, not what must be. Model what a consumer will use in the next two projects, and leave room to add the rest.

Common ISA-95 mistakes

The common mistakes come from learning the pyramid and stopping there: using one hierarchy for both roles and assets, forcing every area into lines and cells, treating ISA-95 as a security model, buying an MES before writing the hierarchy, and assuming a protocol or a broker brings the standard with it.

1. Learning only the pyramid. The levels are the least useful part of the standard. Teams that stop there never reach the models that make integration repeatable.
2. One hierarchy for roles and assets. Names built from asset tags break history on every replacement; asset data stored against roles loses track of the equipment itself.
3. Lines and cells everywhere. Batch and continuous equipment described as lines and cells confuses every MES that models them properly.
4. Treating ISA-95 as a security model. It defines functions and information, not zones or firewalls. Security architecture belongs to ISA/IEC 62443.
5. Buying an MES before writing the hierarchy. The vendor’s default model becomes the plant standard by accident, and the next system has to adapt to it.
6. No owner for master data. Two systems editing the same material or equipment records produces failures that look like software bugs.
7. Assuming the transport brings the model. MQTT, Sparkplug and a broker move data. None of them implements ISA-95 unless a naming standard is applied.
8. A new translator for every project. If each integration builds its own mapping, the plant has edge translators and still no standard. Map into one model, once.

Frequently asked questions

What is ISA-95 in simple terms?

ISA-95 is an international standard, also published as IEC 62264, that gives manufacturers a shared set of names, models and messages for connecting plant operations to business systems such as ERP. It defines how to describe equipment, materials, people and production activities so that an MES, a historian and an ERP system mean the same thing when they exchange information.

What are the levels of ISA-95?

ISA-95 uses five levels. Level 0 is the physical process, Level 1 is sensing and manipulation, Level 2 is monitoring and supervisory control, Level 3 is manufacturing operations management, and Level 4 is business planning and logistics. The standard itself focuses on Level 3 and on the information exchanged between Level 3 and Level 4. There is no Level 5 in ISA-95.

What is the difference between ISA-95 and the Purdue model?

The Purdue model is the reference architecture ISA-95 grew from, and today it is used mainly to draw network and security boundaries between levels. ISA-95 uses the same numbered levels to define functions, models and the information systems exchange. Purdue answers which systems may talk across a boundary; ISA-95 answers what they need to tell each other, and in what words.

Does a unified namespace replace ISA-95?

No. A unified namespace is where current plant data lives and how systems reach it. ISA-95 supplies the hierarchy, names and models that make that data mean the same thing on every machine and every site. A namespace without a naming standard is a shared place full of inconsistent names, so most well-designed namespaces use the ISA-95 equipment hierarchy for their structure.

Do I need an MES to use ISA-95?

No. The equipment hierarchy and a naming standard built from it pay off before any MES exists, because every historian, dashboard and integration project can reuse them. The Part 3 activity model becomes important when you write MES requirements, and the Part 5 transactions when you integrate ERP. Plants can adopt the standard in stages as those projects arrive.

Start with the hierarchy

Whether the plant is new or twenty years old, the first step is the same: draw the role-based equipment hierarchy and write the naming standard that follows from it. In a new plant, every vendor builds to it. In an existing plant, edge translators map into it, one machine at a time, and each project after that starts from the model rather than the tag list.

ISA-95 is a much deeper standard than the pyramid suggests, and a plant does not need all of it on day one. It needs the parts that stop it paying for the same integration twice.

If you are planning a modernization or an MES deployment and want help turning ISA-95 into a hierarchy, a naming standard and a requirements set your vendors can build to, we can help. Start with our MES selection and implementation support, or send us a message about your plant. And keep this guide as the reference for the conversations ahead.