ISA-95 remains relevant because its five functional levels still divide physical processes, control, manufacturing operations, and enterprise planning, even when IIoT bypasses parts of the hierarchy [S4].
The standard covers 8 parts, with Part 5 central to business-to-manufacturing integration, while IIoT changes connectivity, latency, and analytics placement rather than removing functional responsibility [S4].
ISA-95 Defines Functions, Not a Required Wiring Diagram
ISA-95, published internationally as IEC 62264, defines how enterprise systems integrate with manufacturing control systems through a functional hierarchy numbered 0 to 4 and a second hierarchy covering sites, areas, and equipment [S4]. Its five levels are the physical process, sensing and manipulation, monitoring and control, manufacturing operations management, and business planning and logistics [S4].
ISA-95 defines five functional levels: Level 0 for the physical process, Level 1 for sensing and manipulation, Level 2 for monitoring and supervision, Level 3 for manufacturing operations management, and Level 4 for business planning and logistics. The electrical automation layer remains valuable because it translates physical signals into deterministic control actions even when the same measurements are also sent to cloud analytics.
ISA-95 does not require every transaction to pass sequentially through every layer. The standard assigns responsibilities and models information flows, while real projects may connect ERP systems to supervisory systems and sometimes directly to controllers [S4]. This distinction is decisive: a functional model can survive a flattened network because the division of accountability remains intact.
What IIoT Actually Flattens
IIoT changes the data path by allowing sensors and edge devices to send information to cloud analytics without first passing through SCADA and MES [S3]. One cited architecture separates a hierarchical control path, PLC to SCADA to MES to ERP, from a flattened analytics path, PLC to edge device to cloud analytics or AI [S3].
The S3 excerpt describes a hierarchical model in which data flows through intermediate layers, as well as direct sensor-to-cloud and edge-computing architectures that bypass those layers. Those are architectural changes, not evidence that Level 1 control, Level 2 supervision, or Level 3 production coordination have disappeared.
ISA’s own Industry 4.0 discussion points to using the networked activity model in ISA-95 Part 3 instead of simply replacing the hierarchical pyramid [S1]. This supports a complementary design: retain functional levels for governance and responsibility, while enabling distributed communication where the operating requirement justifies it.
Five Levels Against Four Architectural Options
The five-level ISA-95 model remains the reference vocabulary, but four implementation patterns behave differently across control latency, enterprise integration, data reuse, and operational complexity. A hybrid design preserves control hierarchy while opening selected analytics paths; a fully flattened design maximizes direct data access but does not remove the need for functional allocation. [S2]
Who Should Retain ISA-95, and Who Can Use Alternatives
ISA-95 suits plants that must connect ERP, MES, control, and production assets while preserving clear responsibility for product definitions, schedules, capabilities, and performance [S5]. Its equipment hierarchy also gives multi-site organizations a consistent structure from enterprise through site, area, work center, and work unit [S5].
The model is less suitable as a justification for maintaining every legacy interface or for treating all data as a mandatory upward flow. The S2 excerpt identifies the absence of some content as a notable critique of ISA-95 but does not complete the statement.
For greenfield analytics, direct edge-to-cloud links may be the better choice when the use case is fleet visibility, machine-level condition monitoring, or cloud-based prediction. For safety-related control, batch release, production accounting, or ERP order execution, functional boundaries remain more important than the shortest route for analytics data.
Real Implementation Patterns for IIoT Projects
A high-value implementation can place an edge gateway beside PLCs, preserve SCADA and MES as operational systems, and publish selected tagged measurements to cloud services. The gateway handles local buffering and protocol conversion, while the cloud receives a governed data product rather than every raw signal [S3].
A second pattern uses ISA-95 Part 3 activity models to coordinate work across a distributed architecture instead of forcing production activities into a rigid pyramid [S1]. A third pattern uses a unified namespace so that a physical asset can be represented consistently across ERP, MES, historians, and analytics services [S2].
The relevant distinction between a Unified Namespace and the traditional pyramid is architectural intent: the pyramid organizes functions into levels, while a unified namespace organizes context around shared names and links [S2]. This can reduce duplicate mappings, but it does not automatically resolve ownership, event semantics, latency, or cybersecurity boundaries.
Failure Modes of a Flattened Architecture
The first failure mode is bypass without accountability. If a PLC publishes directly to the cloud while the MES remains the production system of record, teams can receive two versions of the same event without a defined authoritative source [S4]. The second is uncontrolled interface growth: removing a rigid pyramid does not remove the need to manage gateways, identifiers, schemas, and lifecycle support [S2].
The third is timing distortion. Level 1 handles millisecond-scale sensing, whereas Level 4 handles planning horizons of days to months, so an ERP response should not be treated as a substitute for a local control action [S4]. The fourth is semantic inconsistency. ISA-95 defines common terms, models, and transaction objects, including B2MML as a related data format, while an ad hoc IIoT schema may omit the context required for production decisions [S4].
Standards and Procurement Decisions
Procurement language should distinguish conformance from topology. IEC 62264 and ISA-95 provide the vocabulary, functional hierarchy, equipment model, and transaction models; they do not dictate that every device must communicate only with its adjacent level [S4]. A specification can therefore require ISA-95-aligned responsibility allocation without prescribing the physical network as a strict pyramid.
ISA-95 has 8 parts: Part 1 covers models and terminology, Part 2 object models and attributes, Part 3 MOM activity models, Part 4 MOM objects and attributes, and Part 5 business-to-manufacturing transaction models [S5]. For new projects, those parts should be mapped to interfaces for product definition, production capability, production schedules, and production performance [S5].
The ISA-95 equipment hierarchy from enterprise to work cell provides a useful implementation detail for naming plant assets consistently across ERP transactions, MES records, and IIoT device registrations. This is a trackable engineering decision: define the responsible system for each event, publish the ISA-95 alignment matrix, and list every direct edge-to-cloud feed with its data owner and operational purpose.