ISA-95 levels, and where your data actually has to go

ISA-95 is most often encountered as a diagram with five levels on it, used to justify a purchase. It is more useful as a way of deciding where a piece of functionality belongs.

The levels

Level 0. The process. The physical thing. Material moving, reacting, being packed.

Level 1. Sensing and manipulating. Instruments and final elements. The transmitter, the valve, the drive.

Level 2. Monitoring and supervisory control. PLCs, DCS, SCADA. Timescale of milliseconds to minutes. This is where control engineers live.

Level 3. Manufacturing operations management. Detailed scheduling, dispatching, production tracking, quality, maintenance, the production record. Timescale of shifts and days.

Level 4. Business planning and logistics. ERP. Orders, materials planning, finance. Timescale of days and months.

The timescales are the most useful part. A function that has to happen in fifty milliseconds cannot live at level 3, whatever the architecture diagram says, and a function that concerns a shift does not belong in a PLC.

Where the difficulty is

Level 2 is well understood and well tooled. Level 4 is somebody else's system with its own consultants.

Level 3 is where most integration projects actually live, and it is the least well defined. It is where the question 'how does a works order become something a machine does, and how does what the machine did become a production record' is answered.

Plants without a level 3 answer have it anyway, implemented as a printed schedule on a clipboard and a spreadsheet somebody maintains. That is a level 3 implementation, and recognising it as one is the first step to improving it deliberately.

The models worth knowing

The standard defines object models for the information exchanged, and two are worth knowing by name because they turn up in every integration specification.

Production schedule and production performance. What was asked for, and what happened. The pair that crosses the level 3 to 4 boundary.

The resource models. Personnel, equipment, material and process segments. A process segment is a step in making something, described independently of the equipment that performs it, which is the same separation ISA-88 makes for batch.

The unit of exchange

The practical question that decides an integration design: what does level 3 send down, and what comes back?

Sending down a works order and expecting the PLC to interpret it puts business logic in a controller, which is the wrong level and ages badly.

The usual shape is that level 3 sends a specific instruction, product, quantity, parameters, and level 2 executes it and reports events: started, quantity produced, quantity rejected, downtime with a reason, finished.

The reason codes are worth designing carefully. A downtime record with a reason code is analysable; one without is a number.

Where security enters

The same hierarchy is the basis of network segmentation in the Purdue model and in IEC 62443.

Levels 0 to 2 are the control network. Level 3 sits in a zone of its own. Level 4 is the business network. The boundaries between them are where firewalls and data diodes go.

The pattern to avoid is a level 4 system polling a PLC directly, which is a route from the business network to the control network, past every boundary the model exists to create.

Using it without buying anything

The levels are most useful as a question to ask of any proposed feature: which level does this belong to, and what is its timescale?

A dashboard requirement that turns out to need a value every hundred milliseconds is really a level 2 requirement. A PLC that has been asked to hold a production schedule is doing level 3 work in the wrong place, and it will be discovered when the schedule changes.