Take a technical deep dive into ISA-88 and ISA-95

Which specifications should you use in requirements documentation to ensure that an integrator implements what the customer needs?

The International Society of Automation (ISA) is the defining organization for documentation in the automation world. Customers of integrators can use the ISA as a guide to ensure that they build documentation that communicates what the customer wants from the integrator. For instance, many people confuse a functional specification (FS) with software design specification (SDS) and a technical specification (TS). Per the ISA, the FS is the user’s point of view, the SDS is the developers point of view, and the TS is the infrastructure view. Refer to ISA-5.06.01, ISA 5.1, ISA-18.2, and ISA-88, ISA-95, 101, and 106 for specific ISA information.

Functional specification (FS)

In the ISA framework, the functional specification is the user's view. It is primarily governed by ISA-5.06.01, which focuses on documenting software requirements.

Purpose: Define what the system does from a process perspective.

ISA layout focus:

• process description: high-level narrative of the operation
• logic requirements: described using cause-and-effect tables or ISA-5.1 instrumentation symbols
• operating modes: defines states like manual, auto and semi-auto
• alarms: guided by ISA-18.2, listing priorities and setpoints.

Software design specification (SDS)

The SDS is the developer’s view. It maps the functional needs to specific software objects. For batch or procedural systems, this follows the models in ISA-88 or ISA-106.

Purpose: Define the modular structure of the code.

ISA layout focus:

• physical and procedural models: mapping logic to ISA-88 “equipment modules” and “control modules”
• state machines: detailed sequential function charts (SFCs) showing exact transitions between steps (for example, idle → starting → running)
• data structures: specific definitions for user-defined types (UDTs) and tag naming conventions.

Technical specification (TS)

In ISA terms, the technical specification is often the infrastructure view. It covers the physical and digital environment that supports the software.

Purpose: Define the hardware and communication requirements.

ISA layout focus:

• system architecture: following the ISA-95 Automation Pyramid to show how Level 1 (PLC) talks to Level 2 (SCADA)
• network layout: details on protocols (Ethernet/IP, Profinet) and ISA-62443 security zones
• HMI standards: using ISA-101 to specify color schemes, faceplate behaviors and screen hierarchies.

Motivation to define specifications

The idea for customer specifications is that the customer should control the machine control face. It is easier for plant maintenance to know that each machine is laid out the same, regardless of the functionality of the machine. If plants standardize on a PLC platform and standardize on software structure and then use standard parts for instruments, valves and pressure sensors, then it is easy for technicians to cross-train on machines and not work in silos.

Most integrators respect this, but the customer would have to spell it out in the requirements up front. If the customer does not, then every machine in the plant will be built to what each integrator thinks and the task of learning each machine changes due to how the machine or control system was designed and implemented.

Audits and reliability

An FS may be used to train operators. A TS may be given to the maintenance department for spare parts and hardware components. The SDS should tie both the FS and TS together because the TS is an input to the SDS, and the FS is an output of the SDS.

The physical components chosen must be known to program; the program direction comes from the SDS, and then the SDS and the components drive the FS. If a system is audited, it’s easy to check the system against ISA-88 if the code is based on ISA-88 and SDS standards.

ISA-88 standards ensure that the software is modular, scalable and clearly separates what to do (recipe) from how to do it (equipment). Core ISA-88 models break the equipment down into physical verification, procedural control verification, recipe and parameter governance, exception, safety and permissive handling, documentation and traceability.

Get your subscription to Control Design’s daily newsletter.

Physical model verification

This section ensures the software architecture matches the physical plant hierarchy. This means defining units and what the minimum is for the machine to create a batch or execute a recipe. In non-pharmaceutical or food production terms, equipment modules (EMs) may be used.

Are groups of devices that perform a specific task, such as a dosing skid or heating jacket, defined as Ems, rather than individual disparate tags? Control modules (CMs) or devices are below equipment and then non-product logic is remaining.

Procedural control model verification

This ensures the software follows the standard hierarchy of batch or action execution. This can be written as software phases. Atomic phases are the smallest element of procedural control and are deterministic—for example, “add ingredient x” or “heat to temperature y”—rather than monolithic "do everything" blocks.

Operations or unit procedures are groups of logic. For instance, if a peanut butter and jelly sandwich is being made, preparation includes peanut butter, jelly and bread. Recipe or unit procedures would include how many PBJs are to be made resulting in x number of cycles.

This cycle management would be broken into states indicating the behavior. Mandatory state examples include idle, running, holding, restarting and aborting. These would be transitions triggered by an indication to change phases—"If Temp > 50°C AND Time > 10 min."

Recipe and parameter governance

Software that is flexible enough to handle formula changes without code edits would allow for parameterization. The SDS defines parameters—setpoints, timers—that are passed from the recipe to the phase logic and down to the unit. Hard-coded values are not allowed. Units for measure should be included—two scoops at 8 ounces.

Exception and safety handling

The SDS distinguishes between interlocks (safety shutdowns) and permissives (conditions required to start). Exception states should be defined rules for how the system recovers after failure. The SDS should have clear definition of these states. Allocation logic would be used to minimize or resolve deadlocks when the machine process shares a unit between two functions, like a filter—for example, if two machines were dipping into the same peanut butter jar, they need to sequence in a queue.

Documentation and traceability

The SDS will use ISA-88 terms such as unit, phase or operation consistently throughout. The idea is to be able to trace functional requirements with a traceability matrix. Thus, if the SDS is done properly, it should correlate to the functional spec and show that the integrator specified a software definition for the functions required to run the machine. The technical specification would show the components needed to make the functionality work.

Conclusion

ISA should be used as a resource to provide specification data that may be molded to a customer’s needs. If the customer creates a functional specification and then chooses the components needed for the functionality, it will be easy to create a software design specification that explains the system. The system will be documented and reliable, not to mention the FS, TS and SDS will be utilized for training after the system is built.