First published in 2000. As told by Chris Monchinski, 2019–20 Vice President, ISA Standards & Practices Department.
ISA-95 from its inception sought to solve an important issue in our industry: normalizing the integration practices between isolated enterprise and control systems and, in doing so, reducing costs and increasing success rates for these efforts. 
The ISA95 committee began its work by surveying existing standards and common practices. The reference models it found for integration from enterprise to control were fragmented, lacking in detail, and quite dated.
The ISA-95 Part 1 and 2 standards ultimately define only primary data exchanges between enterprise and control. In doing so, the standards have also defined an entire framework of models to describe enterprise and control system applications, operations, and functions.
The concept of vertical levels of an enterprise, where key operations and applications interoperate in common time horizons and with common purpose, was adopted. Levels helped to define logical integration boundaries.
A lot has been discussed in recent years regarding the concept of levels, as many have observed that computing power, storage, and communications protocols have allowed a wider array of devices and systems to be connected. ISA-95 levels have always been logical boundaries that allow a practitioner to define boundaries that subsequently support the integration between systems. Viewed this way, all integration efforts begin with a definition of logical boundaries and operational space—a concept universal and still relevant to any integration effort today.The ISA-95 equipment hierarchy model, an often-referenced model in manufacturing, expanded on an early physical hierarchy model in ISA-88 and demonstrated its universality across discrete, continuous, and logistics industries. Another key concept introduced in ISA-95 Parts 1 and 2 is the process segment, which provides a logical grouping of resources, personnel, equipment, and materials to support dynamic views of operational data—a key for supporting scheduling and resource planning activities between business planning and operational domains.
Although the ISA-95 standard title is “Enterprise to Control,” ISA-95 Parts 3 and 4 formally defined the level 3 space, creating the term “manufacturing operations management” and creating complex models for resource management, quality test data management, and the representation of resource routing.
ISA-95 further evolved when Part 2 was revised to recognize the importance of equipment as a class of resources separate from a new resource type, the asset model, which facilitated new adoption of the standard for integrating production and maintenance activities.
The Part 5 standard expanded on this collection of objects and logical exchanges by contributing a transactional representation of ISA-95. Finally, we cannot overlook that the development of Business to Manufacturing Markup Language (B2MML), spearheaded by Dave Emerson and the XML-WG, encouraged the adoption of ISA-95, helping organizations, vendors, and solutions integrators realize the potential of following this industry standard to accelerate interoperability.
A “standard” can be thought of as a collection of the best ideas from across industry, and of course it helps to form those ideas around a solid architecture. The ISA-95 standards find robust adoption in manufacturing both as a reference architecture and as a facilitator of successful integration efforts.
I began my participation with ISA-95 at its earliest development, during the creation of ISA-95 Part 1. I had the fortunate opportunity to work closely with J. Keith Unger and Dennis Brandl. They both had just emerged from the successful creation and ongoing industry adoption of the ISA-88 standards. I have been the cochair of ISA-95 since 2011.
Perhaps the most challenging part of maintaining a successful standard is knowing when to adopt changes so that it remains effective and valuable to industry. Recent revisions to ISA-95 Parts 2, 4, and 5 (2018) were spearheaded by our Process Centric Messaging Working Group, led by Charlie Gifford. This group sought to reduce the complexity and granularity inherent in ISA-95 message exchanges by introducing the operations event model, which allows for a collection of data with common context to be exchanged as a single message.
ISA-95 Part 6 (Messaging Service Model) and Part 7 (Alias Service Model), put forth first as technical reports by Dennis Brandl and Alan Johnston (MIMOSA), were also driven by the real-world needs of practitioners. Most recently, the ISA95 committee is poised to release a new Part 8, which will define a framework for developing an ecosystem of “ISA-95 ready” profiles that can be adopted by integration scenario or industry type.
