ANSI/ISA‑95 is a family of standards that defines a common way to model, name, and exchange information between enterprise systems (such as ERP and PLM) and manufacturing/control systems (such as MES, SCADA, and equipment control). It is primarily about structure and interfaces, not about specific software products or visual dashboards.
What ISA‑95 is intended to do
At a high level, ISA‑95 provides:
- A reference hierarchy of levels from physical control to enterprise planning, to clarify which systems do what:
- Level 0: Physical process (machines, materials, sensors)
- Level 1: Basic sensing and manipulation (instrumentation, I/O)
- Level 2: Monitoring and supervision (SCADA, cell controllers, HMIs)
- Level 3: Manufacturing operations management (MES, LIMS, WMS on the shop floor)
- Level 4: Business planning and logistics (ERP, APS, PLM at the enterprise level)
- Standard models for manufacturing information, such as:
- Products, materials, and Bill of Materials (BOM) views relevant to production
- Equipment and production assets
- Personnel and work centers
- Production schedules, work orders, and dispatch lists
- Production performance and genealogy information
- Guidance for interfaces between Level 3 and Level 4, including what kinds of data should flow which way (for example, planned orders and recipes down, production results and consumption up).
What ISA‑95 is not
For regulated and long‑lifecycle manufacturing environments, it is important to be explicit about what ISA‑95 does not provide:
- Not a software product: It does not give you an MES, ERP, or integration platform. Vendors may say they are “ISA‑95 compliant” or “ISA‑95 based,” but the standard itself is documentation, not an application.
- Not a compliance framework: It does not guarantee regulatory compliance, audit outcomes, or quality system adequacy. It can help structure data and responsibilities, but you must still design and validate processes and controls.
- Not a plug‑and‑play integration guarantee: Two systems that both reference ISA‑95 may still require extensive mapping and custom integration. Real‑world vendor interpretations vary, and brownfield integrations often keep legacy models.
- Not a full replacement strategy: Using ISA‑95 models does not remove the need for coexistence with legacy ERP, MES, SCADA, historians, or custom databases.
Key parts of the ISA‑95 standard
The ISA‑95 standard is split into multiple parts. Commonly used ones in industrial environments include:
- ISA‑95 Part 1: Models and terminology. Defines the basic concepts and high‑level models for enterprise and control system integration.
- ISA‑95 Part 2: Object models and attributes. Describes detailed information models (such as material definitions, equipment, personnel) and the attributes associated with each.
- ISA‑95 Part 3: Models of manufacturing operations management. Organizes production, maintenance, quality, and inventory operations into a structured set of activities.
- ISA‑95 Part 4 and beyond: Focus on exchanging information between systems, often in conjunction with specific technologies or other standards (for example, B2MML and OPC UA companion specifications).
How ISA‑95 helps in brownfield, regulated environments
In plants with existing MES, ERP, historians, and equipment, ISA‑95 is most useful as a reference architecture and vocabulary for integration, not as a mandate to rebuild everything:
- Clarifies system roles: Helps decide which system should be the source of truth for orders, recipes, equipment, master data, and production records.
- Structures integration requirements: Provides a standard way to describe what data must be exchanged between systems and at which level, improving traceability of integration design and change control.
- Supports long equipment lifecycles: Gives a stable reference model while specific technologies (middleware, protocols, data lakes) change over time.
- Facilitates validation and documentation: A clear separation of responsibilities by level and function can make it easier to document data flows, assess impact of changes, and justify segregation of duties for audits and regulators.
Common limitations and failure modes
Many ISA‑95 initiatives in real plants run into predictable issues:
- Over‑ambitious full replacement: Attempting to redesign all systems “to ISA‑95” at once often fails in aerospace, pharma, and similar sectors due to validation burden, downtime risk, and integration complexity. Incremental alignment is usually more realistic.
- Vague vendor claims: “ISA‑95 compliant” products may support some models but not others. You still need detailed interface specifications, data dictionaries, and mapping documents.
- Incomplete data readiness: If equipment, material, and personnel master data are inconsistent across systems, simply adopting ISA‑95 models does not fix the underlying data quality issues.
- Misalignment with actual operations: Plants with complex rework flows, outside processing, or bespoke quality processes often need to adapt the standard models, not apply them literally.
- Underestimating change control: Aligning legacy systems to ISA‑95 often touches validated code, master data structures, and interfaces. Each change can trigger documentation, testing, and re‑qualification activities.
Practical ways to use ISA‑95
In a regulated, brownfield environment, ISA‑95 can be used effectively in smaller, well‑bounded steps:
- As a common language between IT, OT, quality, and operations when scoping MES/ERP/SCADA integrations.
- To map current state: Document which existing systems currently implement each Level 3 function, and how they interface with Level 4.
- To design new interfaces: Use the ISA‑95 models to define message content, master data ownership, and event triggers between MES and ERP, or between MES and equipment.
- To structure requirements for vendors: Reference ISA‑95 objects and activities in RFPs, URS, and integration specifications, while still validating that the vendor’s implementation matches your specific needs.
Used this way, ISA‑95 provides a stable conceptual framework for integrating enterprise and manufacturing systems, while still respecting existing investments, validation constraints, and the realities of mixed‑vendor, long‑lifecycle plants.
