Skip navigation
All People > ernstamort > Holger Amort's Blog > 2015 > September



PI and MES

PI and MES: Architecture I

PI and MES: Equipment Model

PI and MES: Batch Model



When integrating or better merging OSIsoft PI with a MES application there are typically two options being used:


  • PI-SDK or AF-SDK solutions for NET based MES systems
  • ODBC/JDBC both requiring PI OLEDB Enterprise & PI SQL Data Access Server for NET or Java based applications


Both options require support from the MES software as well to allow for mapping, data access and events.


Proficy Workflow is a good candidate for integration since it provides well documented SDK’s for 3rd party vendors to expand and enhance the core system. This is mostly accomplished by custom WCF services that are called from the workflow application.


Note: Proficy Workflow is not the only MES software that is based on NET and provides integration support. This is just an example and shows the general concept.


Proficy Workflow already has a connector for read and write access to PI tags. In this use case the MES application contains all the business logic, aggregation and analytic and the PI system is simply used as another data repository comparable to an OPC interface.


A better way is to merge the two application to achieve synergies and maximize the benefits of both. The following shows a much tighter integration of both systems:

PI and Proficy.png

As an ISA 95 compliant workflow engine Proficy uses the following resource models

      Equipment Model
      Material Model
      Personnel Model

and production models

      Work Process Segments
      Work Definition Segments
      Work Schedules
      Work Responses


The equipment model is the only data model that it shares with the PI system. Out of the box Proficy MES does not support batch or the more generic event frames.

Therefor to fully utilize PI from MES requires the development of the following interfaces:


  1. Synchronizing the Equipment Model: Even though both data structure are ISA 95 compliant, the table structures are different and therefore require mapping.
  2. AF Data access and events: Events can be used to trigger workflows that provide actions based on for example a calculation. An example would be the creation of a maintenance order based on runtime conditions (e.g. Condition Based Maintenance). This interface should be bi-directional so MES data can also be processed in PI.
  3. EF Data access and events: To fully utilize the batch capabilities of PI requires the MES system to process new batch information. The batch completion event could for example trigger quality control workflows or workflows that communicate resource balances to the ERP system.
    Another example would be OEE events such as Planned Downtime or Breakdowns that are captured in PI and reviewed/processed in MES.


The main benefit of this integration type is that data analytic in PI is not happening in an isolated environment and that the results can be used to trigger business transactions. The benefit from the MES perspective is a much more granular data access, aggregation and overall that Engineering and Business will be looking at the same set of data.


The drawback is that an approach like this will require some customization. As mentioned earlier some of the risks can be mitigated by choosing a MES system that already offers well document interfaces. Also it is important to standardize the data models. ISA 88 and ISA 95 might be restrictive in the implementation but do have the benefits that the subsequent integration is seamless.


In the upcoming blogs I will show the three interfaces, some code examples and applications.


PI and MES: Batch Model

Posted by ernstamort Sep 18, 2015

PI and MES

PI and MES: Architecture I

PI and MES: Equipment Model



The OSIsoft PI-Batch database has always conformed to the ISA 88 batch standards. It provided three mechanisms to create batch structures:


  1. PI Batch Generator: A Windows Service to create batches based on the batch generator in the SMT.
  2. PI Batch Interfaces: These are interface that connect to batch control system and provide automatic creation of tags, modules, aliases and batches
  3. Programmatically through the use of the PI-SDK


The major shortcoming of the PI-Batch Database was the lack of scalability and sole focus on batch structures.

The Event Frames Database was designed to overcome these limitation and broaden the scope of time segmentation by introducing the event concept. Now any type of manufacturing (for example discrete and batch control) can be modeled and in addition time framing such as up- or downtime, Condition Based Maintenance, Process Models, ... can be captured using the same data structure.


The Event Frame Database (EF) is highly flexible and can be configured for any type of event. OSIsoft provides a set of ISA 88 batch templates within the Event Frame Generator (PI-EFGEN) to build these structures. The following table shows the relationship between ISA 88 (referred as ‘Procedural Control Model’), PI Batch and EF Batch:



ISA 88

PI Batch

EF Batch



PI Batch



Unit Procedure

PI Unit Batch

Unit Procedure



PI Sub Batch




PI Sub Sub Batch





Phase State




Phase Step


The Event Frame Templates and References are attached (see below). Similar to the Element templates, there are base templates that are derived from a universal template called ‘EventFrame Base’ and derived templates based on the corresponding base templates (e.g. EventFrame Base -> Phase Base -> Phase).


There are different tools to create Event Frames:

  1. Event Frame Generator: Mostly used to create Batch structures.
  2. PI Analysis: Allows to create single event frames on Element level.
  3. PI Batch Interfaces: Are transitioning from PI Batch to EF
  4. Programmatically through AF-SDK.


Event Frames allow to reference Elements. This mapping leads to the following simplified relationship:


     Procedure Model (EF) + Equipment Model (AF) = Process Functionality


The following shows the relationship in detail:

Batch Model.png


Another option is for Elements to reference Event Frames. The benefit of this design is that event frames can reference Element attributes such as Start and Stop trigger, recipe, procedure, without losing AF as the abstraction layer.


In summary, Event Frames provide very flexible structures for time segmentation. Using the out-of-the-box or custom templates allow fully ISA 88 compliant batch structures.


Next Blog:


PI and MES: Functional Integration (Example: Proficy Workflow)

Previous Posts:

1) PI and MES

2) PI and MES: Architecture I



The major difference between PI and MES models are that PI is primarily data centric whereas MES is centered on orders/work requests. So data models in PI are most commonly developed around the physical structure and layout of the plant or the process and don’t need to follow any specific conventions. On the other side MES data structures need to be compliant to the Enterprise Resource Planning (ERP) data structure that they are communicating with.


The two main standards for MES data structures are ISA 95 and ISA 88. The following Wiki links give a short explanation with the main references:


ISA 95 is a general standard for interfacing ERP and control systems, whereas ISA 88 is specific to batch systems. The ISA 95 and ISA 88 equipment models can be merged to include the batch structure.

The following shows a combined equipment structure that is often used as a template for the equipment structure:


Equipment Model.png


In PI the same structure can be created using Element templates and references. Best practice is to start with a base template and then derive the different equipment level templates from it. The reference types enforce the hierarchy and help to guide the development.


The following file contains the full S95\S88 equipment structure as seen above with the corresponding reference types:


5/2/2016: Some minor updates

Historians in general are considered a sub system or data source in the overall controls architecture. The following shows the S95 functional hierarchy model with the addition of the PI historian:


The MES system (Level 3) is the intermediate layer between the ERP system (Level 4) and the control system (Level 0, 1, 2). The MES layer provides a variety of different functions:


  • Operations/Detail Scheduling
  • Resource Allocation & Status
  • Dispatching Production Units
  • Product Tracking and Genealogy
  • Performance Analysis
  • Document Control
  • Labor Management
  • Maintenance Management
  • Process Management
  • Quality Management
  • Data Collection\Acquisition


To perform these activities\tasks requires interfaces to connect to the different systems and data sources, data models to contextualize the information and a state machine workflow for execution. Workflows are either triggered based on time or events and state changes are captured in a SQL database.


In a PI-MES hybrid some functionality will reside in PI and some in the MES software. The functionality that should be performed in PI are:

  1. Events, Alarms
  2. Process data
  3. Time Series Aggregates and other calculations
  4. Process Models (Predictive/Forecast)
  5. Equipment and batch data model


In a commercial MES solution 1) and 2) are typically provided as interface either through PI or as standard OPC interface. 3) and 4) are functionalities that are best performed in PI due to the wide spread availability of programming interfaces (API, SDK, OLEDB) and calculation engines (PI-ACE, PI-Analysis, CEP, …).

Equipment and batch data model exist both in PI (AF and EF) as well as in the MES. These objects require synchronization between the PI and MES system.


The next blog will explain how to set up the equipment and batch model in PI to be S95 and S88 compliant in order to be synchronized with the MES system.